Marc Lázaro Martí COMUNICACIONS SENSE FILS AMB EL MÒDUL...
Transcript of Marc Lázaro Martí COMUNICACIONS SENSE FILS AMB EL MÒDUL...
Marc Lázaro Martí
COMUNICACIONS SENSE FILS AMB EL MÒDUL ESP32: ANÀLISI, DISSENY E IMPLEMENTACIÓ
TREBALL DE FI DE GRAU
dirigit per Enric Vidal Idiarte
Grau d’Enginyeria Electrònica Industrial i Automàtica
Tarragona
2017
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
Índex
1. Introducció .................................................................................................................... 5
1.1. Antecedents ....................................................................................................................... 5
1.2. Objectius ........................................................................................................................... 6
1.3. Conceptes previs ............................................................................................................... 7
1.3.1. Internet of things (IoT) ............................................................................................... 7
1.3.2. Comunicacions Wireless ............................................................................................ 8
1.3.2.1. Bluetooth............................................................................................................................. 8
1.3.2.2. Wi-Fi ................................................................................................................................. 12
2. Hardware del mòdul ESP32 ...................................................................................... 14
2.1. Processador ..................................................................................................................... 15
2.2. Memòria .......................................................................................................................... 16
2.3. Connectivitat Wireless & Ethernet ............................................................................... 17
2.4. Perifèrics ......................................................................................................................... 17
2.4.1. ADC & DAC (Analog to Digital & Digital to Analog Converter) .......................... 17
2.4.2. I2C (Inter-Integrated Circuit) .................................................................................... 18
2.4.3. UART (Universal Asynchronous Reciever / Transmiter) ........................................ 18
2.4.4. CAN 2.0 (Controller Area Network) ........................................................................ 19
2.4.5. SPI (Serial Peripheral Interface) ............................................................................... 19
2.4.6. I2S (Integrated Inter-IC Sound) ................................................................................ 20
2.4.7. RMII (Reduced Media-Independent Interface) ........................................................ 21
2.4.8. PWM (Pulse Width Modulation) ............................................................................. 21
2.5. Seguretat ......................................................................................................................... 22
3. Desenvolupament software pel mòdul ESP32. ........................................................ 23
3.1. Metodologia de l’enginyeria de software ...................................................................... 23
3.2. ESP-IDF (Espressif IoT Development Framework) ................................................... 24
3.2.1. Instal·lació de la Toolchain proporcionada per Espressif. ....................................... 25
3.3. Iniciar un projecte .......................................................................................................... 28
3.3.1 Configurar el projecte (“make menuconfig”) .................................................................. 28
3.3.1.1. SDK tool configuration ..................................................................................................... 29
3.3.1.2. Bootloader configuration .................................................................................................. 30
3.3.1.3. Security features: .............................................................................................................. 30
3.3.1.4. Serial flasher configuration: .............................................................................................. 31
3.3.1.5. Partition table: ................................................................................................................... 32
3.3.1.6. Compiler options: ............................................................................................................. 34
3.3.1.7. Component configuration: ................................................................................................ 34
3.3.2. Carregar el projecte a la placa (“make flash”) .......................................................... 35
3.4. Eclipse IDE. .................................................................................................................... 36
3.4.1. Descarregar & Configurar Eclipse IDE. ................................................................... 36
3.4.2. Importar projecte a Eclipse....................................................................................... 37
3.4.3. Configurar les variables d’entorn del projecte. ........................................................ 39
3.4.4. Configurar les variables de compilació del Projecte. ............................................... 40
3.4.5. Solucionar errors de dependències ........................................................................... 42
3.4.6. Carregar projecte a l’ESP32 des de l’Eclipse. .......................................................... 44
3.5. Estructurar un projecte ................................................................................................. 45
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
4. Projectes demostratius ............................................................................................... 48
4.1. Comunicacions Bluetooth (GATT client & GATT server)......................................... 48
4.2. Comunicacions Wi-Fi (Protocol TCP) .......................................................................... 52
4.3. Actualització firmware de forma remota (OTA, Over the aire) ................................ 56
4.4. Escriptura / Lectura memòria no-volatil (NVS) .......................................................... 60
5. Conclusions ................................................................................................................. 62
6. Annexos ....................................................................................................................... 63
6.1. Annexos projecte comunicacions Bluetooth ................................................................. 63
6.1.1. Annex nº 1: gattc_demo.c (GATT Client) ............................................................... 63
6.1.2. Annex nº 2: gatts_demo.c (GATT Server) ............................................................... 63
6.2. Annexos projecte comunicacions Wi-Fi ....................................................................... 63
6.2.1. Annex nº 3: tcp_main.c ............................................................................................ 63
6.2.2. Annex nº 4: tcp_perf.c .............................................................................................. 63
6.2.3. Annex nº 5: tcp_perf.h .............................................................................................. 63
6.2.4. Annex nº 6: TCP_Server.py ..................................................................................... 63
6.3. Annexos projecte actualització firmware de forma remota ....................................... 63
6.3.1. Annex nº 7: ota_main.c ............................................................................................ 63
6.4. Annexos projecte escriptura/lectura memoria no-volatil ........................................... 63
6.4.1. Annex nº 8: nvs_api.c ............................................................................................... 63
6.4.2. Annex nº 9: nvs_api.h .............................................................................................. 63
6.4.3. Annex nº 9: main.c ................................................................................................... 63
7. Bibliografia ................................................................................................................. 64
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
5
1. Introducció 1.1. Antecedents
Des de fa aproximadament una dècada la filosofia DIY (do it yourself) s’ha expandit
de manera exponencial entre tots els usuaris en infinitat de camps. Aquesta filosofia va sorgir
a partir d’un pensament anti-capitalista que rebutja la idea de comprar les coses que un
mateix necessita, sinó tot al contrari, fabricar-les, reparar-les o reutilitzar-les.
Si juntament amb aquesta filosofia s’uneixen l’abaratiment del hardware, la facilitat
d’accés al software de tercers i el llançament de plaques de desenvolupament aptes per a
qualsevol tipus d’usuaris, ens trobem amb la disposició de totes les eines per començar a
estudiar, dissenyar i desenvolupar tota mena de projectes.
En el camp de l’electrònica això ha suposat la creació de una comunitat d’usuaris que
comparteixen els seus coneixements a través d’internet per tal de assolir uns objectius cada
cop més complexes.
Partint d’aquí, neix la motivació de realitzar una petita contribució més en aquesta
gran comunitat i aportar coneixements per tal de ajudar-nos entre tots a progressar. Aquí és
on entra en joc el mòdul ESP32, llançat al mercat el gener de 2016 per la companyia
Espressif.
El predecessor del mòdul ESP32 és el ESP8266, el qual havia ocupat des de fa molt
de temps un paper important com a perifèric Wi-Fi en molts projectes, i el segueix ocupant.
No només com a perifèric, també pot treballar independentment a qualsevol placa de
desenvolupament, sempre i quan l’aplicació no requereixi més recursos dels quals el mòdul
pot proporcionar.
El nou mòdul ESP32 supera en tots els aspectes a l’antic, i des del primer moment és
va veure el potencial que tenia per ”Internet of things” entre moltes d’altres coses. El
problema és troba en la dificultat que suposa per a molts usuaris sortir de l’àmbit de confort
del ESP8266, degut a la quantitat de suport e informació de la qual es disposa, i passar a un
nou mòdul que resulta més complicat de programar i que no disposa de tants recursos als
quals recórrer.
Així doncs, arribats en aquest punt, sorgeix la necessitat de contribuir en la recerca
de les funcionalitats i eines de treball del mòdul per tal de facilitar la migració de tots els
usuaris, sense importar el nivell que tinguin.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
6
1.2. Objectius
L’Objectiu del treball, com hem comentat a l’apartat anterior, és profunditzar en les
característiques i programació del mòdul ESP32, no només per ajudar a la migració des de
l’ESP8266, sinó també per sortir de l’àmbit de Microchip, microcontroladors amb els quals
hem treballat en l’àmbit docent, i poder treballar amb un microcontrolador i unes eines de
software diferents.
Si be tots sabem que la majoria d’entorns de desenvolupament de software
comparteixen moltes característiques i estructures similars, cada placa te un hardware
diferent i te que ser configurat pertinentment. Així doncs, això suposa un repte, i un dels
objectius en segon pla d’aquest treball es resoldre els problemes que vagin sorgint durant la
creació i compilació del projectes. És important adquirir experiència a l’hora de buscar
informació a la documentació proporcionada pel fabricant, ja que és la font més precisa i
més fiable.
Deixant aquest punt clar, passem a definir quins seran els objectius principals del
treball, enfocats al mòdul ESP32.
En primer lloc es pretén realitzar un estudi del hardware de la placa per entendre
sobre que estem treballant i quines són totes les funcionalitats que inclou aquesta. Entendre
tot el que conté el mòdul ens permetrà tenir una visió més general de funcionament i saber
quins són els límits sobre el que podem fer en el moment de desenvolupar una aplicació.
En segon lloc passarem al software. La idea és fer una guia pas a pas des de zero per
a poder treballar amb l’ESP32, incloent totes les eines disponibles per programar la placa,
la instal·lació d’aquestes i la creació d’un projecte base a partir del qual partirem per a crear
l’aplicació especifica.
La millor manera de veure el funcionament de les coses són els exemples pràctics.
Així doncs, la idea és anar provant cadascuna de les funcionalitats de manera individual a
mesura que les anem veient. És important veure-les de manera individual per poder analitzar
el seu comportament. En el cas de comunicacions wifi i bluetooth podrem veure i testejar el
rang del que disposen i la intensitat de la senyal.
Finalment per tal d’apropar-nos el màxim possible a un cas real, l’objectiu serà
desenvolupar un conjunt de projectes amb tots els coneixements obtinguts. Arribats en
aquest punt serà interesant veure com desenvolupar un projecte degudament (tant en codi
com en organització d’aquest) per tal d’assegurar el seu funcionament indefinidament i uns
mínims d’optimització i tractat d’errors.
Pot ser interessant d’observar la convivència de més d’una funcionalitat de la placa
treballant al mateix temps, ja que el seu comportament podria variar, com per exemple, degut
a algun recurs compartit.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
7
1.3. Conceptes previs
1.3.1. Internet of things (IoT)
Actualment, dintre del sector de les noves tecnologies, és freqüent llegir l’abreviació
“IoT” en una gran quantitat d’articles, foros, documentació oficial, etc. Aquesta abreviació
prové de l’anglès (Internet of Things) i durant els últims anys l’interès de molts usuaris per
aquest concepte s’ha vist incrementat dràsticament.
Als anys 90, hi va haver el “boom” de l’internet comercial, connectant entre si els
ordinadors de les cases i oficines. En breu es va observar que el nombre de direccions IP no
seria suficient per albergar el nombre total de dispositius en funcionament, que anava
creixent ràpidament, i en conseqüència, es va implementar la versió 6 del protocol de
comunicació IP (IPv6) que permet donar una direcció a tots els essers humans del planeta i
als dispositius que els envolten.
El concepte d’internet de les coses va ser creat per Kevin Ashton al Auto-ID Center
de l’Institut Tecnologic de Massachusetts (MIT) el 1999, on es realitzaven investigacions en
el camp de la identificació per radiofreqüència en xarxa (RFID) i tecnologia amb sensors.
La idea sota d’aquest concepte és que qualsevol objecte disposi d’una direcció IP i
de la capacitat de connectar-se a internet, ja sigui per Wi-Fi o per ones de radio de baixa
freqüència, permetent així obtenir una recol·lecció massiva de dades per a ser posteriorment
processades en un servidor cloud.
L’Internet de les coses permetrà crear
una xarxa de dispositius interconnectats
entre si que permetran, entre altres coses, la
monitorització d’activitats del dia a dia, com
per exemple, entrenaments físics o
seguiments mèdics, la localització
geogràfica d’un objecte, consultar l’estat o
mesura d’un equip en qualsevol moment
amb el mínim esforç, control de qualsevol
dispositiu remotament, com poden ser,
sistemes domòtics, tablets, ordinadors,
coches, smart TVs, etc.
Així doncs, tot i que per algunes persones pot semblar una idea futurista, actualment
ens trobem envoltats d’un gran nombre de dispositius que ens mantenen connectats a la
xarxa. L’increment del nombre de dispositius IoT ha aportat, i seguirà aportant, moltes
millores al dia a dia de les persones, però també comporta un risc, la violació de la privacitat
dels usuaris, el qual comportarà la necessitat de millorar la seguretat en cadascun dels
dispositius IoT per assegurar la viabilitat d’aquests.
Figura 1, Diagrama IoT
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
8
1.3.2. Comunicacions Wireless
Tenint en compte que una de les característiques mes important del mòdul ESP32
és la capacitat de treballar al mateix temps amb Wi-Fi i Bluetooth, és interessant veure
prèviament una petita introducció a aquests dos mètodes de comunicació sense fils.
1.3.2.1. Bluetooth
El Bluetooth és una tecnologia d’intercanvi de dades wireless, la qual va ser
inventada el 1994 a l’empresa Ericsson per uns enginyers suecs, amb la finalitat de
solucionar el caòtic cablejat que en aquell temps acompanyava els ordinadors.
L’any 2007 es va crear el Bluetooth SIG (Special Interest Group), una companyia
privada sense ànims de lucre formada per més de 9.000 companyies. Els membres del SIG
dirigeixen el desenvolupament d’aquesta tecnologia a demés de integrar-la als productes que
cadascuna de les empreses que formen el SIG comercialitza. El SIG per si mateix no fabrica
ni ven productes directament però qualsevol empresa amb intenció de comercialitzar un be
o servei amb Bluetooth incorporat te que passar a formar part del SIG.
El principal us del Bluetooth és per a la comunicació de dispositius propers entre si,
ja que el rang de la senyal ha sigut durant molt de temps d’uns deu metres aproximadament,
fins a dia d’avui, on s’ha incrementat fins a cinquanta metres amb la nova versió. El rang
amb visió directe pot arribar a cent metres, però en la vida quotidiana és normal trobar parets
i objectes que interfereixen en la senyal.
Partint de la versió 1.0 (gairebé obsoleta) i passant per la versió 2.1 (possiblement la
més expandida per la facilitat amb la qual dos o més dispositius es poden enllaçar) el
Bluetooth ha anat evolucionant fins a arribar a la versió 4.2 amb BLE (Bluetooth Low
Energy), versió que incorpora el mòdul ESP32.
Així doncs tenint en compte que la quarta versió és amb la que nosaltres treballarem
anem a veure quines són les seves característiques principals.
Quan es va desenvolupar la versió 4.0 es van afegir un gran nombre de millores tant
en connectivitat com en el rang de la senyal, entre d’altres, però la que realment va
destacar sobre totes les altres va ser el protocol de baix consum, fent ideal aquesta versió
per a dispositius que requereixin més temps d’autonomia com poden ser els dedicats a
Internet of Things. La idea era arribar a un disseny que administres les connexions d’una
manera més intel·ligent, així doncs, l’objectiu ja no es centrava en l’enviament constant
d’informació, sinó que es focalitzava en l’enviament de petites trames i en posar el
dispositiu en mode sleep quan no es requerís realitzar ninguna tasca.
Aquesta generació de Bluetooth està dividida en tres grups: Bluetooth, Bluetooth
Smart i Bluetooth Smart Ready. La finalitat de cadascun d’ells és treballar en dispositius
amb funcionalitats diferents, i com veurem a continuació a la figura 1, no tots són
compatibles entre si.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
9
Figura 2, Compatibilitat Bluetooth 4.0
Figura 3, Classificació Bluetooth 4.0
La figura 1 mostra la compatibilitat de les tres versions i la figura 2 plasma la idea
que han volgut implementar amb aquestes tres versions de bluetooth.
El concepte es que cada dispositiu sigui equipat amb la versió de Bluetooth que ell
necessita, sense necessitat de sacrificar temps de funcionament per funcionalitats que no
aprofitarà. Així doncs els equips electrònics centrals que necessitin connectar-se a tot tipus
de dispositius per rebre i processar informació, com poden ser dispositius mòbils, tablets o
ordinadors, incorporaran la versió Smart Ready, la qual ofereix compatibilitat amb qualsevol
de les altres versions de Bluetooth. Els equips que realitzin funcions d’enviaments de grans
quantitats de dades a velocitats relativament altes, com pot ser la reproducció d’arxius
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
10
multimèdia en streaming, incorporaran la versió Bluetooth ER/BDR. Finalment tots els
aparells que realitzin petits enviaments de dades cada cert temps i que necessitin una llarga
duració de la bateria, com ho són els dispositius IoT, incorporaran la versió Bluetooth Smart,
compatible únicament amb Bluetooth Smart Ready.
El protocol Bluetooth BLE consta d’una Stack que està dividida en dos categories:
el controlador i el host. Cada categoria te una subcategoria que realitza una funció concreta.
Les dos subcategories que veurem a continuació són la de Generic Acces Profile (GAP) i la
de Generic Attribute Profile (GATT).
- Generic Acces Profile (GAP):
El Generic Acces Profile s’encarga de controlar les connexions i els advertisements
en el BLE, i defineix com un dispositiu pot estar, o no, visible per altres dispositius i com
poden interactuar entre ells.
El GAP defineix diversos rols pels dispositius, però el que hem de tenir clar és
bàsicament que disposarem de dispositius perifèrics i centrals. Els perifèrics són dispositius
de baixa potencia, recursos i consum que es comunicaran amb un dispositiu més potent. Els
centrals corresponen normalment a ordinadors, tables, telèfons mòbils, etc., els quals
processaran la informació rebuda pels perifèrics.
Hi ha dos maneres de transmetre informació a través de GAP, per “advertisements”
i per “scan response”. Cadascun d’ells pot enviar 31 bytes de dades. El funcionament és
simple, un dispositiu perifèric realitzarà advertisements amb petits camps de dades, com
poden ser el nom i la UUID (Universal Unic Identifier), que seran visible per qualsevol
dispositiu central. En el cas de que un d’aquests estigues interessat en rebre més informació
enviaria un “scan response request” i el perifèrics li contestaria amb un altre paquet amb més
dades.
Aquest és el sistema amb el que perifèric i central es connectarien entre si. El central
rebria el nom i la UUID d’un dispositiu Bluetooth (Advertising Data) i enviaria un paquet
de petició a la connexió (Scan Response Request), un cop el perifèric ha rebut la petició,
contestaria si es pot realitzar o no la connexió (Scan response Data).
Figura 4, Diagrama de procés d’advertisement
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
11
- Generc Attribute Profile (GATT):
El GATT defineix la manera amb que dos dispositius es poden connectar utilitzant
perfils, serveis i característiques. La comunicació es realitza mitjançant un protocol conegut
com ATT, que s’utilitza per emmagatzemar serveis, característiques i dades relacionades en
una taula utilitzant identificadors de 16-bits per a cada entrada. El GATT entra en joc un cop
s’ha establert la connexió entre dos dispositius, així doncs per a poder arribar en aquest punt,
hem hagut de passar prèviament pel GAP.
Un punt a tenir en compte amb el GATT és que les connexions són exclusives, és a
dir, un perifèric BLE només es pot connectar a un dispositiu central a la vegada. Un cop
perifèric i central es connecten el perifèric deixarà de realitzar advertisements, i per tant,
deixarà de ser visible per a tots els demés dispositius fins que no es finalitzi la connexió
existent.
Establir connexió és la única forma d’establir una comunicació bidireccional. Un
concepte important a entendre del GATT es la relació servidor/client. El perifèric o esclau
es coneix com a GATT server, i és el que conte les dades de cerca ATT i les definicions de
serveis i característiques, i el GATT client, és el que actua com a central o màster envia
peticions al servidor. Totes las transaccions són iniciades per el client. En el moment
d’establir connexió el perifèric suggerirà al dispositiu central un interval de connexió per
veure si hi ha dades disponibles.
Figura5, Intercanvi de dades Client – Servidor GATT
Les transaccions GATT en BLE es basen en
objectes d’alt nivell denominats Perfils, serveis i
característiques.
El perfil, per si mateix, no existeix dintre del
perifèric BLE, sinó que és un conjunt de serveis i
característiques predefinides per el Bluetooth SIG o
per el fabricant del perifèric.
Un exemple de perfil podria ser “estat mèdic”,
dintre del qual trobaríem diversos serveis anomenats
sistema nerviós, sistema digestiu, etc., i dintre de
cadascun d’aquests un grup de característiques, com
per exemple, totes les malalties o els símptomes que
afecten a cada sistema. Cada servei i característica
disposa d’un identificador UUID de 16 o 128 bits.
Figura 5, GATT Attributes
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
12
1.3.2.2. Wi-Fi
Avui en dia el Wi-Fi ocupa la davantera entre totes les tecnologies de comunicació
sense fils, sent aquesta la més utilitzada en dispositius electrònics com telèfons mòbils,
ordinadors, tablets, etc.
A principis dels 90 es van començar a utilitzar tecnologies Wireless per transmetre
informació entre equips, però va resultar caòtic, ja que cada fabricant utilitzava sistemes
completament diferents incomprensibles pels demés. Per solucionar això, a finals de la
dècada dels 90 un grup d’empreses van crear una associació anomenada WECA (Wireless
Ethernet Compatibility), la qual posteriorment passaria a dir-se Wi-Fi Alliance, la qual tenia
la finalitat de fomentar l’ús de la tecnologia Wi-Fi i d’estandarditzar el sistemes per
transmetre les dades per tal d’assegurar la compatibilitat entre dispositius.
La tecnologia Wi-Fi utilitza ones de radiofreqüència per enviar informació a través
de l’aire. D’aquesta forma l’any 2000 s’estableix la primera norma, la Wi.Fi 802.11b, la qual
utilitzava la banda 2,4 GHz i arriba fins a velocitats de 11 Mbps. Posteriorment van aparèixer
les normes 802.11a, 802.11g i 802.11n, cadascuna de les quals incorporava millores respecte
les anteriors fins arribar a una velocitat de transmissió de 108 Mbps amb la banda 2,4 GHz.
El Wi-Fi, a l’igual que l’Ethernet, és únicament una eina per connectar-nos a la xarxa.
La diferència que suposa la utilització d’una connexió wireless amb una cablejada és el
control d’equips que es poden connectar. Si be amb l’Ethernet es necessita estar físicament
connectat al router, amb el Wi-Fi qualsevol que es trobi dintre del rang de la xarxa s’hi pot
connectar. Així doncs, per tal de donar accés únicament als usuaris autoritzats, entra en joc
l’encriptació de la xarxa, de manera que només es podrà accedir a traves d’un password.
Protocol Autentificació Xifrat Seguretat Rendiment Complexitat
d’implementació
WEP Ninguna WEP Nula Alt Baixa
WPA-PSK-TKIP Handshake TKIP Acceptable Baix Baixa
WPA2-PSK-TKIP Handshake TKIP Acceptable Baix Baixa
WPA-PSK-AES Handshake AES Bona Normal Baixa
WPA2-PSK-AES Handshake AES Molt Bona Normal Baixa
WPA-MGT-TKIP Servidor TKIP Bona Baix Alta
WPA2-MGT-TKIP Servidor TKIP Molt Bona Baix Alta
WPA-MGT-AES Servidor AES Molt Bona Normal Alta
WPA2-MGT-AES Servidor AES La millor Normal Alta
Taula 1, Tipus d’encriptació xarxes Wi-Fi
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
13
Els protocols d’encriptació han anat evolucionant partint des del WEP de 64 bits
(protocol obsolet degut a la seva alta vulnerabilitat) fins arribar al protocol més segur
actualment, el WPA2-MGT-AES. Degut a la baixa complexitat d’implementació i la
seguretat que ofereix, el protocol més utilitzat en la majoria dels equips avui en dia és el
WPA2-PSK-AES.
Un cop tenim accés a la xarxa l’enviament d’informació entre màquines passa a ser
tasca dels protocols de comunicació a internet, com per exemple el protocols TCP o UDP,
els quals veurem i utilitzarem més endavant amb el mòdul ESP32.
Un punt important a tenir en compte dintre del Wi-Fi és l’sniffing d’informació, en
altres paraules, l’accés no autoritzat de tercers a la informació que estem enviant a través de
l’aire. Avui en dia es fàcil i barat implementar un dispositiu per robar informació que circula
per l’aire, així doncs, és molt important que la informació que circula a través del Wi-Fi vagi
sempre encriptada.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
14
2. Hardware del mòdul ESP32
El mòdul ESP8266 ha sigut durant un parell d’anys una de les millors opcions per a
incorporar comunicacions Wi-Fi a qualsevol dels nostres projectes. Des del seu llançament
Espressif ha intentat satisfer la creixent demanda que hi ha hagut, en gran part, dintre dels
desenvolupadors IoT, però a mesura que s’ha anat utilitzant, molts usuaris han anat
descobrint les limitacions que té i les millores que podria incorporar.
Així doncs, a petició d’un gran nombre de desenvolupadors, la companyia Espressif
va llançar el mòdul ESP32, el qual superava sobradament les característiques del seu
predecessor. L’ESP32 no és un substitut per l’ESP8266, sinó més aviat un germà gran d’una
gama molt més alta de mòduls SoC (System on Chip).
*SoC (System on Chip): Descriu la tendència d’integrar gran part de mòduls o components d’un
ordinador o qualsevol equip informàtic o electrònic en un únic circuit integrat o xip.
Taula 2, comparativa entre mòdul ESP8266 i ESP32.
Especificacións ESP8266 ESP32
MCU Xtensa Single-Core 32 bits
L106
Xtensa Dual-Core 32 bits LX6
600 DMIPS
Coprocessador LE No Sí, consum inferior 150uA
802.11 B/G/N Wi-Fi Sí, HT20 Sí, HT40
Bluetooth No v4.2 BR/EDR & BLE
Freqüència Típica 80 MHz 160 MHz
SRAM, ROM 160 kBytes, No 512 kBytes, 448 kBytes
Flash SPI Flash, fins a 4 MB SPI Flash, fins a 16 MB
GPIO 11 32
Hardware / Software PWM No / 8 canals 1 / 16 canals
SPI / I2C / I2S / UART 2 / 1 / 1 / 2 4 / 2 / 2 / 3
ADC, DAC 1 (10-bits), No 18 (12 bits), 2 (8 bits)
CAN No 1 (2.0)
Ethernet MAC Interference No 10/100 Mbps MAC
IR Sí Sí
Encriptació per hardware No (TLS 1.2 per software) Sí (AES, SHA, RSA, ECC)
Temporitzadors 3 4 (64 bits)
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
15
A part de les especificacions anteriors, el mòdul inclou sensors de temperatura,
capacitius i d’efecte Hall, a part d’encriptació flash, arrancada segura i la possibilitat de
consumir únicament 5 micro-ampers quan es troba en mode d’hivernació. Aquestes i moltes
altres especificacions es poden consultar en més detall a la pagina web del fabricant.
Anem a veure més en detall cadascuna de les parts que composen aquest sistema.
Figura 1, Diagrama de blocs funcionals
2.1. Processador
El nucli encarregat de processar totes les dades que proporcionen els perifèrics, i
responsable de moltes de les millores del ESP32, és el processador Cadence’s 32-bit
Tensilica Xtensa LX6, un dual-core MCU anunciat el gener de 2015 que va passar de
treballar a una velocitat de 80MHz als 240MHz actuals amb un rendiment de 600 DMIPS.
Per tal d’assegurar que es segueixen realitzant conversions ADC i càlculs basics
durant el mode “deep sleep” disposem d’un coprocessador ULP (Ultra Low Power)
dissenyat per implementar una simple maquina d’estats que accedeix a certs espais de
memòria i registres mentre els processos principals estan aturats.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
16
2.2. Memòria
Els processadors són complementats per una memòria ROM i una SRAM de més
capacitat que les anteriors, incrementant així la mida del firmware que gravarem al mòdul i
l’espai de memòria que aquest podrà utilitzar per a variables i altres recursos.
Memòria interna ROM (448 kB) Per l’arrancada i funcions del Core.
SRAM (520 kB) Per dades e instruccions.
RTC Slow SRAM
(8kB)
Per a que el processador ULP accedeixi durant el
mode deep-sleep.
RTC Fast SRAM
(8kB)
Per l’emmagatzemat de dades i el procés principal
de la CPU durant l’arrancada del RTC des de el
mode deep-sleep.
eFuse (1 kbit) 256 bits són utilitzats per el sistema i els restants
per aplicacions del client, incloent l’encriptació
flash i el chip-ID.
Embedded Flash
(0MB o 2MB)
L’ESP32-D2WD disposa de 2 MB de memòria
flash connectada via GPIO16/17, SD_CMD,
SD_CLK i SD_DATA_0/1. Els altres chips no
disposen de memòria flash.
Memòria
externa Flash &
SRAM
Els chips ESP32 sense embedded flash suporten l’ampliació fins a 4 x
16 MB de memòria flash QSPI i 8MB de memòria SRAM amb
hardware d’encriptació basat amb el protocol AES per protegir els
programes i les dades dels desenvolupadors.
Per a tenir una idea més clara sobre l’emmagatzematge, la família de la memòria
RAM inclou dos grups principals: memòria RAM estàtica (SRAM) i memòria RAM
dinàmica (DRAM). La diferència entre les dos és el temps que retenen la informació. La
primera la conserva tant de temps com el chip es mantingui alimentat. La segona manté les
dades durant períodes molt curt de temps (de milisegons), sempre i quan tinguem
alimentació. Llavors, quina utilitat te aquesta memòria?, gràcies a un mòdul hardware
anomenat controlador DRAM podem fer un refresc periòdic de les dades emmagatzemades
per tal mantenir-les durant tot el temps que necessitem emulant el comportament que
obtindríem utilitzant memòria estàtica. El motiu principal per combinar memòria estàtica i
dinàmica és el cost i el tems d’accés. Les memòries SRAM tenen un temps d’accés quatre
vegades major que les DRAM, però són molt més cares. Per això mateix cal tenir clares
quines són les especificacions temporals i econòmiques del projecte per tal d’utilitzar la
combinació idònia de memòria estàtica i dinàmica.
Taula 3, Enmagatzement mòdul ESP32
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
17
Per altra banda disposem d’un bloc de memòria de la família ROM que conté el
firmware que serà executat pel processador. La principal característica i el motiu pel qual
s’utilitza és la perpetuïtat de la informació, en altres paraules, la capacitat de mantenir les
dades tot i perdre l’alimentació. La memòria flash és una derivada de la memòria EEPROM
però amb una velocitat de funcionament major degut a la capacitat de treballar sobre sectors
en ves de sobre cada cel·la independentment.
2.3. Connectivitat Wireless & Ethernet
Les comunicacions sense fils entre dispositius es poden realitzar de manera dual o
individual a través de la tecnologia Bluetooth / Wi-Fi que incorpora el mòdul ESP32. Les
versions concretes són les següents:
o Wi-Fi: 802.11 b/g/n/e/i (802.11n @ 2.4 GHz fins a 150 Mbit/s
o Bluetooth: v4.2 BR/EDR & Bluetooth Low Energy (BLE).
El mòdul ESP32 esta especialment pensat per a projectes IoT que treballin amb
connectivitat Wireless, però la companyia Espressif el va dissenyar pensant en la possibilitat
d’utilitzar-lo en qualsevol tipus de sistema embbeded. Per això mateix podem realitzar una
connexió Ethernet a través de qualsevol dels pins EMAC i desenvolupar un firmware gràcies
a la completa API proporcionada pel fabricant.
2.4. Perifèrics
Els essers humans disposem des 5 sentits que ens permeten captar estímuls exteriors,
els quals posteriorment processem per a realitzar les accions corresponents. Si ens fixem en
la majoria d’equips o dispositius electrònics que s’han anat creant al llarg del temps, podem
extrapolar aquest funcionament, on la percepció dels estímuls exteriors són captats pels
perifèrics I/O, processats per la CPU i retornats a l’exterior a través dels perifèrics I/O altre
cop.
Així doncs, com en qualsevol dispositiu electrònic, el mòdul ESP32 disposa d’un
conjunt de perifèrics d’entrada / sortida que podem utilitzar segons les nostres necessitats.
Vegem en detall cadascun d’ells.
2.4.1. ADC & DAC (Analog to Digital & Digital to Analog Converter)
Un convertidor ADC s’encarrega de convertir senyals analògiques cap a digitals, i
de forma contrària, un convertidor DAC converteix les senyals digitals en analògiques. Tots
els estímuls que ens envolten són senyals analògiques amb magnituds diverses (força,
pressió, cabal, voltatge, intensitat, etc.), però els processadors únicament poden processar
informació en sistema binari (uns i zeros). Així doncs, per a poder comunicar les dos parts,
es necessari un interlocutor que tradueixi la informació d’un a l’altre. Aquí entren en joc els
conversos ADC i DAC.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
18
2.4.2. I2C (Inter-Integrated Circuit)
A mesura que la capacitat d’integració en chips i el nombre de blocs funcionals i
components va anar creixent, els dissenys de circuits integrats van començar a augmentar el
nombre de mòduls que incorporaven, i la comunicació entre ells d’una manera eficaç va
esdevenir un problema. En conseqüència, l’any 1982, Phillips Semiconductors va proposar
una norma de comunicació digital, on s’especificaven velocitats i nivells de tensió, i es va
anomenar Inter Integrated Circuit. Les especificacions han anat millorant durant els anys,
però les idees bàsiques segueixen sent les mateixes.
1. Protocol de dos fils de control, un per transmetre les dades (SDA) i l’altre pel rellotge
asíncron que indica quan llegir les dades (SCL). Quan sigui necessari també
s’incorporarà GND i 5V.
2. Cada dispositiu connectat al bus I2C disposa d’una direcció de 7bits. Així doncs, el
nombre de dispositius que es poden connectar és de 27 = 128. Restant les 16
direccions reservades a funcions especials queden disponibles 112 nodes.
3. Un dels dispositius del bus actuarà com a màster, i per tant, serà el que controlarà el
rellotge. Tots els altres seran esclaus.
4. Tenint en compte que es el màster el que controla el rellotge, no serà necessària una
velocitat estrictament definida.
5. El protocol és multi-màster, així doncs, el màster pot variar. Només pot haver un
màster treballant al mateix temps, i serà aquest el que proporcionarà el protocol
d’arbitratge i s’encarregarà de la detecció de coalicions.
2.4.3. UART (Universal Asynchronous Reciever / Transmiter)
El controlador UART és el component clau del sistema de comunicacions sèrie d’un
equip electrònic i s’encarrega bàsicament de convertir les dades de la forma seqüencial a la
paral·lela en cadascun dels terminals d’enllaç. La UART emissora agafa bytes d’informació
i envia els bits individualment de forma seqüencial. Una segona UART receptora torna a
empaquetar el conjunt d’informació per a poder ser tractat posteriorment.
La UART transmet les dades de manera asíncrona, el que significa que no hi ha una
senyal de clock per sincronitzar emissor i receptor. En substitució al clock, s’afegeixen
sentinelles per tal d’informar al receptor quan comença la trama i quan finalitza.
Quan la UART receptora detecta el bit d’inici, aquesta comença la lectura a una
freqüència especifica (baud rate). Aquesta freqüència és la de la velocitat de transmissió de
la informació expressada en bits per segon (bps).
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
19
2.4.4. CAN 2.0 (Controller Area Network)
El bus CAN és un protocol de comunicació sèrie desenvolupat per Bosch l’any 1982
per l’intercanvi d’informació entre unitats de control electròniques. Aquest sistema permet
compartir una gran quantitat d’informació entre les unitats reduint així el numero de sensors
utilitzats i el cablejat de la instal·lació elèctrica.
Es necessiten dos o més nodes (ECUs) en una xarxa CAN per a poder-se comunicar.
Tots els nodes estan comunicats amb els altres a través de dos parells trenats i han de tenir
com a mínim una unitat central de procés, un controlador CAN i un transceptor.
Les característiques principals del bus CAN són les següents:
- La informació circula a través de dos cables amb paquets de longitud limitada i una
estructura definida de camps que conformen el missatge.
- Un dels camps actua d’identificador del tipus de dades que transporta, la unitat de
control que ho transmet i la prioritat respecte els altres missatges.
- Totes les unitats del sistema poden ser emissores o receptores, sent variable la
quantitat d’unitats connectades al bus (sempre dintre d’uns límits).
- Si la situació ho requereix, un node pot sol·licitar a un altre una determinada
informació a través d’un dels camps de la trama.
- Tots els nodes introdueixen els missatges al bus sense mirar la disponibilitat
d’aquest. En el cas de que dos missatges col·lacionessin, serà la prioritat la que
decidirà quin s’emet i quin no.
- Sistema per assegurar la correcta recepció de la trama. Si un missatge presenta un
error, aquest és anul·lat i reenviat. De la mateixa manera, si una unitat del sistema
deixa de funcionar adequadament, emetrà un missatge i quedarà fora de servei sense
afectar al funcionament del bus i de totes les altres unitats.
2.4.5. SPI (Serial Peripheral Interface)
El bus SPI va ser desenvolupat a Motorola l’any 1980 i es basa en una arquitectura
master-slave. El màster pot iniciar la comunicació amb un o varis dels dispositius esclaus i
enviar o rebre informació d’ells, però els dispositius esclaus no poden comunicar-se entre si
directament.
S’utilitzen dos línies per a l’enviament de dades, una del màster als esclaus i l’altre
dels esclaus al màster , així doncs, la comunicació és Full-Duplex ja que el màster pot rebre
i enviar missatges simultàniament.
Un altre característica del SPI és que és un bus síncron, és a dir, el màster proporciona
una senyal de rellotge que manté a tots els dispositius sincronitzats. Addicionalment és te
que afegir una línia per a cada esclau connectat al sistema amb la finalitat d’indicar cap a
quin d’ells es realitza la comunicació.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
20
Figura 2, Diagrama connexió Bus SPI
2.4.6. I2S (Integrated Inter-IC Sound)
El bus I2S es tracta d’un bus sèrie utilitzat per interconnectar dispositius de so digital.
El principal us d’aquest bus és l’enviament de dades de so PCM entre els circuits integrats
d’un dispositiu electrònic.
El funcionament del bus I2S es basa en tres línies, una per a la transmissió de dades
per canals multiplexats (SD) ,un altre per la senyal de clock (SCK) i un tercera per la “word
selection” (WS). Tenint en comte que per la línia SD es transmeten les dades de dos canals
multiplexats, la línia WS serveix per indicar quin dels dos canals esta emetent. Un exemple
de la transmissió de dades en dos canals al mateix temps són els arxius de so en estèreo, on
la especificació I2S estableix que el canal esquerra s’emet quan la senyal de paraula (Word
Selection) es troba a nivell baix, i el canal dret emet quan es troba a nivell alt. El rellotge de
paraula te un cicle de treball del 50%.
Al tractar-se d’un protocol sèrie, si tenim intenció d’emetre so en una qualitat CD
(16 bits a 44100 Hz stereo) fa falta generar una senyal de rellotge de 1411200Hz.
Figura 3, Diagrama de temps d’una trama I2S
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
21
2.4.7. RMII (Reduced Media-Independent Interface)
La “media-independent interface” (MII) va ser definida originalment per a realitzar
comunicacions Ethernet entre la capa MAC (Media Acces Control) i la capa PHY (Physical
Layer) del model OSI a velocitats de 100Mbits/s.
L’estàndard RMII va ser desenvolupat per reduir el nombre el nombre de senyals que
es requereixen per connectar les dos capes. Les quatre coses que es van modificar per
aconseguir això van ser les següents:
- Els dos rellotges TXCLK i RXCLK van ser substituïts per un únic rellotge.
- La freqüència del rellotge va ser doblada de 25MHz fins 50MHz, mentre que les
direccions a les dades es van reduir de de 4 bits a dos bits.
- Les senyals RXDV (Receive data vàlid) i CRS (Carrier Sense) es van multiplexar en
una única senyal.
- Es va eliminar la senyal COL (Collision detect)
2.4.8. PWM (Pulse Width Modulation)
La modulació per ample de pols és una tècnica on és varia el cicle de treball d’una
senyal periòdica per tal d’enviar informació a través d’un canal de comunicació o gestionar
la potencia entregada a una carrega. El cicle de treball d’una senyal periòdica equival al
temps a nivell alt en funció del període.
El funcionament del PWM requereix d’un circuit amb unes parts ben diferenciades,
un comparador que farà la funció de nexe, dos entrades i una sortida. La primera entrada és
una senyal dent de serra que marcarà la freqüència de la senyal de sortida, i la segona entrada
serà una senyal continua que marcarà el cicle del treball del PWM.
Figura 4, Funcionament circuit PWM
La principal utilitat de la modulació per ample de pols és la gestió de potencia. Avui
en dia disposem d’una gran quantitat d’equips electrònics que requereixen bastanta
autonomia, i en conseqüència, la gestió de la energia s’ha convertit en un dels punts més
importants per a moltes companyies. Així doncs, el PWM permet variar la potencia
entregada a la carrega en funció de les seves necessitats millorant l’eficiència de l’equip. Un
exemple podria ser la refrigeració d’un ordinador en funció de la temperatura.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
22
2.5. Seguretat
Tal i com hem anomenat anteriorment, avui en dia existeix una gran preocupació per
mantenir la privacitat de cadascun dels usuaris. En conseqüència, la companyia Espressif ha
dotat el mòdul ESP32 de l’estàndard de seguretat IEEE 802.11 incloent els protocols de
seguretat WFA, WPA/WPA2 i WAPI.
A part, també disposem de la funció “boot secure”, la qual assegura que únicament
el nostre codi serà el que s’executarà el chip, i de la funció “flash ecryptation” la qual manté
la memòria flash codificada per protegir les dades que hi ha emmagatzemades. Cadascuna
d’aquestes funcions es pot utilitzar per separat o conjuntament però cal tenir en compte que
poden dificultar l’actualització del firmware remotament (OTA, Over The Aire firmware
update).
La tercera funcionalitat que inclou el mòdul és el sistema de seguretat via OTP (One-
Time Password) de 1024 bits, sistema el qual intenta solucionar un conjunt de deficiències
associades a les contrasenyes estàtiques tradicionals, com per exemple els “Atacs per
Replay”, on s’intercepta la informació entre dos dispositius i es retransmet suplantant la
identitat d’una de les dues parts. Els atacs per força bruta tampoc són viables, ja que cada
cop que es renova la contrasenya els intents per sobrepassar la contrasenya anterior no
serveixen per res.
Un inconvenient d’aquest sistema és que els essers humans no poden memoritzar
cadascuna de les possibles contrasenyes, i per tant, la seva utilització està limitada a
processos interns de la maquina o a l’ús d’algun dispositiu addicional que vagi indicant les
contrasenyes al usuari cada cop que es renova.
Finalment, el mòdul ESP32 incorpora hardware addicional per accelerar els
processos d’encriptació. Aquest hardware és bàsicament un coprocessador dissenyat
especialment per complementar la CPU i evitar que realitzi tasques d’alta intensitat
d’encriptació, desencriptació, compressió o descompressió millorant així l’eficiència del
sistema.
Els estàndards de xifrat amb els que treballa el hardware d’acceleració criptogràfica
que inclou l’ESP32 són els següents:
AES (Advanced Encryptation Standard)
SHA-2 (Secure Hash Algorithm 2)
RSA (Public-Key cryptosystem)
ECC (Elliptic Curve Cryptography)
RNG (Random Number Generator)
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
23
3. Desenvolupament software pel mòdul ESP32 3.1. Metodologia de l’enginyeria de software
Actualment existeixen un gran nombre d’eines a través d’internet destinades a compartir
software i col·laborar entre desenvolupadors per tal de resoldre dubtes, compartir opinions,
recursos, etc. Així doncs, moltes vegades ens trobarem amb la necessitat de partir de
projectes d’altres usuaris i viceversa, i per tant, és de gran importància tenir conceptes bàsics
sobre l’estructuració d’un projecte per tal de facilitar-nos la feina, tant a nosaltres mateixos,
com a futurs desenvolupadors que parteixin del nostre projecte.
“L’enginyeria del software és el procés formal de desenvolupament de software en el qual
les necessitats de l’usuari es tradueixen en requeriments, aquest es transformen en un disseny que
s’implementa en codi i es testeja, documenta i certifica pel seu us operatiu. Segons la definició del
IEEE l’enginyeria de software es defineix com a “(1) l’aplicació d’un mètode sistemàtic, disciplinat
i quantificable al desenvolupament, operació i manteniment de software és el que engloba l’aplicació
de l’enginyeria de software” i “(2) l’estudi dels mètodes de (1)”
Així doncs, anem a veure les 7 etapes que formen part d’una bona metodologia:
1- Anàlisis dels requeriments: En aquest apartat s’intenta especificar cadascuna de
les funcionalitats i intentant eliminar qualsevol ambigüitat que pugui tenir el
projecte.
2- Especificacions: És la tasca on s’especifica detalladament cadascun dels apartats
del software, indicant l’estructura, la funcionalitat, els resultats esperats i la
interacció amb els usuaris o altres sistemes.
3- Disseny i arquitectura: Determinar el funcionament de forma general de tot el
sistema a través d’un diagrama. Només es donaran petits detalls de caràcter
tecnològic importants per entendre la interconnexió i comunicació entre blocs,
però no es donaran detalls d’implementació de cadascun d’aquests.
4- Programació: Es tradueix el disseny anterior a codi. En aquest apartat ja es
possible observar resultats tangibles. Una mala realització dels apartats anteriors
pot esdevenir en la complicació i prolongació d’aquesta tasca.
5- Test: Consisteix en contrastar el funcionament del codi implementat amb les
pautes de funcionament especificades durant l’anàlisi dels requeriments.
Realitzar les proves de funcionament per blocs i per nivells pot ajudar a aïllar els
problemes i a disminuir considerablement el temps de resolució d’aquests.
6- Documentació: Un cop s’han finalitzat les proves del sistema és important
redactar una documentació completa, tant de funcionament com de manteniment.
Aquesta documentació ha d’englobar, des de comentaris en el codi pels enginyers
de software, com manuals de funcionament per a personal que no estigui
directament relacionat amb qualsevol enginyeria tecnològica.
7- Manteniment: El sector tecnològic progressà ràpidament, i per tant, és molt
important realitzar manteniments i actualitzacions per assegurar l’eficiència i
compatibilitat del sistema.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
24
Havent vist superficialment quina metodologia utilitzar per realitzar un projecte de
software, ens centrarem en l’apartat de programació, que és el que pretén tractar aquest
treball. Així doncs, l’objectiu és realitzar una guia per instal·lar tot l’entorn de treball que
posteriorment s’utilitzarà per desenvolupar software per l’ESP32.
3.2. ESP-IDF (Espressif IoT Development Framework)
A partir d’una rapida i simple guia veurem com utilitzar el framework de
desenvolupament d’aplicacions IoT proporcionat per Espressif, incloent la configuració
base, la compilació de l’ESP-IDF i la descàrrega del firmware a la placa.
L’objectiu de la companyia Esspresif era proporcionar els recursos hardware i
software per ajudar als desenvolupadors a plasmar les seves idees sobre qualsevol hardware
que incorpores l’ESP32, implementant fàcilment funcions de Wi-Fi, Bluetooth, Power
management, i moltes d’altres.
Per a poder desenvolupar les aplicacions necessitarem les següents eines de treball:
- Ordinador amb sistema operatiu Windows, Linux o MAC OS.
- Toolchain proporcionada per Espressif per compilar les aplicacions per l’ESP32.
- ESP-IDF, que bàsicament conte una API per l’ESP32 i uns scripts per treballar amb
la Toolchain. A continuació veurem com descarregar-los des de Github.
- Un editor de text per escriure els programes i treballar amb el projecte. (ex. Notepad,
Eclipse, etc.)
- Qualsevol de les plaques de desenvolupament que incorpori l’ESP32 i un cable
micro-usb per connectar-la a l’ordinador. En el nostre cas utilitzarem la placa ESP32
Core Board V2 / ESP32 DevKitC. Opcionalment també es pot utilitzar un
convertidor USB-UART per carregar el firmware directament per el PIN TX del
mòdul sense necessitat d’utilitzar cap placa de desenvolupament.
Figura 1, Desenvolupament d’aplicacions per l’ESP32
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
25
3.2.1. Instal·lació de la Toolchain proporcionada per Espressif.
El sistema operatiu que s’utilitzarà per realitzar la instal·lació serà Windows, però
també es pot seguir una guia similar on es realitza per Linux i MAC OS i que es pot trobar
a la pagina oficial d’ESP-IDF.
Els sistemes operatius del tipus Unix/Linux disposen d’una eina de gestió de
dependències anomenada “make” que és utilitzada per gestionar les dependències que
existeixen entre els fitxers que composen el codi font d’un programa, per tal de realitzar la
compilació d’aquests automàticament. Si bé la funció bàsica del “make” és determinar
quines parts del programa han de ser compilades i executar les comandes necessàries per a
fer-ho, també destaca per la portabilitat i facilitat d’us (a partir de comandes) en qualsevol
entorn de treball degut a una rapida instal·lació i configuració.
El sistema de gestió de dependències “make” llegeix les instruccions per generar el
programa o realitzar altres accions d’un fitxer makefile que es trobarà dintre del nostre
projecte. Les instruccions escrites en aquest fitxer s’anomenen dependències.
Windows, a diferencia de Linux, no disposa d’aquest gestor. Per tant, tindrem que
utilitzar un entorn GNU per Windows basat en Linux anomenat MSYS2. No és necessari
utilitzar aquest entorn tot el temps, sinó que es pot utilitzar Eclipse o qualsevol altre IDE ja
que resultarà més còmode i proporcionarà més eines de treball , però cal tenir en compte que
el gestor “make” serà el que estarà treballant en segon pla tot el temps.
Així doncs, primer que tot descarregarem el fitxer “Windows all-in-one toolchain &
MSYS” de la pagina web dl.espressif.com:
https://dl.espressif.com/dl/esp32_win32_msys2_environment_and_toolchain-20170330.zip
Un cop finalitzada la descarrega descomprimirem el fitxer al directori C:\ on és
crearà un director anomenat MSYS amb un entorn pràcticament preparat per començar a
treballar. Aquesta carpeta pot estar en qualsevol altre ruta sempre i quan es tingui present en
el moment de treballar.
Figura 2, Directori “Windows all-in-one toolchain & MSYS”
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
26
A continuació obrirem el terminal MSYS2 MINGW32 executant l’arxiu que
trobarem al directori “C:/msys32/mingw32.exe” i procedirem a descarregar l’API i les
llibreries especifiques per l’ESP32 que podem trobar al repositori de Github d’Espressif. Per
obtenir-lo tenim que navegar fins el directori on volem descarregar l’ESP-IDF a través de la
comanda “change directory (cd)” i el clonarem a través de la comanda git clone.
git clone --recursive https://github.com/espressif/esp-idf.git
És important escriure la comanda amb el “--recursive”, del contrari alguns submòduls
no es podrien descarregar. Durant el moment de la descarrega poden aparèixer alguns
missatges dient que no és un identificador vàlid (‘: not a vàlid identifier...), però no cal
preocupar-se ja que es tracta d’un error conegut que no afectarà de ninguna manera al
funcionament de l’ESP-IDF.
En el meu cas, estic utilitzant un directori que es diu “esp_workspace” on tindre
l’ESP_IDF i tots els projectes que vagi realitzant amb el mòdul. En el vostre cas podeu
utilitzar qualsevol altre ruta, simplement cal tenir-ho en compte en el moment d’escriure les
comandes.
Figura 3, Execució comanda “git clone”
La toolchain accedeix a l’ESP-IDF utilitzant una variable d’entorn anomenada
IDF_PATH. Per guardar en aquesta variable la direcció de l’ESP-IDF utilitzarem la
comanda “export”. Cadascú ha d’utilitzar el directori on tingui guardat l’ESP-IDF, en el meu
cas és el següent:
export IDF_PATH=“C:/esp_workspace/esp-idf"
Figura 4, Execució comanda “export”
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
27
Aquesta variable d’entorn es borra cada cop que es reinicia l’ordinador, i per tant,
tindrem que utilitzar la comanda anterior cada cop que obrim el terminal MSYS després
d’engegar l’ordinador. Si volem evitar fer això, podem crear un script dintre la carpeta
“C:/msys/etc/profile.d” que s’anomeni export_idf_path.sh el qual s’executarà, juntament
amb tots els scripts que estiguin dintre de la carpeta profile.d, cada cop que s’obri el terminal
MSYS. Dintre de l’arxiu export_idf_path.sh escriurem la comanda “export” anterior.
Figura 5, Directori “script” export_idf_path.sh
Per comprovar si s’ha realitzat correctament és pot tancar la consola i tornar-la a
obrir. Un cop estigui oberta podem utilitzar les comandes “printenv IDF_PATH” o
“$IDF_PATH” per veure el contingut de la variable i comprovar si la ruta que apareix
coincideix amb la escrita al script anterior.
Figura 6, Visualització variable d’entorn IDF_PATH per consola
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
28
3.3. Iniciar un projecte
Un cop hem instal·lat la toolchain i l’ESP-IDF, ja tenim disponibles totes les eines
de treball per començar a desenvolupar un projecte per l’ESP32. La companyia Espressif ha
desenvolupat un conjunt de projectes demostrant el funcionament de cadascuna de les
funcionalitats del mòdul ESP32, així doncs, tenim la possibilitat d’utilitzar qualsevol
d’aquests projectes com a base de la nostra aplicació o partir d’un projecte base
completament net i totalment configuràble.
Per començar un projecte, agafarem qualsevol dels exemples de l’ESP-IDF
(C:/esp_workspace/esp-idf/examples) i el copiarem a la nostre carpeta de projectes. En el
nostre cas, es la mateixa on tenim l’ESP-IDF (C:/esp_workspace). En el cas de que vulguem
partir d’un projecte des de zero, podem anar a la nostra carpeta de projectes a través de la
consola (cd C:/esp_workspace) i executar la següent comanda:
git clone https://github.com/espressif/esp-idf-template.git project_template
Aquesta comanda crearà una carpeta anomenada “project_template” on es copiarà el
projecte base que podem trobar el respositori de Github “esp-idf-template.git”. En el nostre
cas hem decidit utilitzar l’exemple “hello_world” ubicat a la carpeta “get_started” dintre
dels exemples de l’ESP-IDF (C:/esp_workspace/esp-idf/examples/get-started /hello_world).
3.3.1 Configurar el projecte (“make menuconfig”)
Un cop tinguem el nostre projecte copiat, anirem al seu directori a través de la
consola (cd C:/esp_workspace/hello_world) i executarem la comanda “make menuconfig”.
Si hem realitzat correctament tots els apartats anteriors sens obrirà una finestra de
configuració com la que podem veure a continuació.
Figura 7, Configuració del projecte (“make menuconfig”)
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
29
Aquesta finestra ens permetrà configurar qualsevol de les funcionalitats de la placa.
Primer que tot configurarem el port USB que estem utilitzant per descarregar el firmware a
l’ESP32. Per a fer-ho anirem a la opció “Serial flasher config” i canviarem el port on diu
“Default serial port”. En el nostre cas estem utilitzant el port COM14, però pot variar en
funció de cada usuari. El port USB on tenim connectada la placa es pot consultar a l’apartat
de “dispositius & impressores” del panell de control de Windows.
Figura 8, Configuració port USB de la placa
Si el nostre ordinador no detecta la nostre placa de desenvolupament possiblement
sigui perquè no tenim instal·lats els divers del convertidor USB-to-UART CP2102. Si
l’ordinador mateix no és capaç de trobar-los es poden descarregar i instal·lar manualment
des de la següent pàgina web.
https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers
Un cop tinguem configurat el port USB només faltarà guardar el canvis i sortir de la
finestra de configuració per a poder passar a carregar el firmware a la placa, però abans
d’això, anem a veure quines altres funcions poden ser configurades en aquesta finestra.
3.3.1.1. SDK tool configuration
En aquest apartat es configuren les eines que s’utilitzen per desenvolupar software
pel mòdul ESP32 (SDK, Software development Kit). En la majoria de casos no serà
necessari modificar ninguna de les dues opcions que podem trobar en aquest apartat. La
primera estableix la ruta del compilador “Xtensa GNU compiler collection (GCC)”, el qual
s’instal·la juntament amb la toolchain proporcionada per Espressif. La segona estableix
l’intèrpret de les comandes en llenguatge python.
Figura 9, SDK tool configuration
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
30
3.3.1.2. Bootloader configuration
L’ESP-IDF inclou un conjunt de funcions per tal de guardar i mostrar tot el que vagin
succeint durant el procés d’execució del programa, ja sigui simple informació, warnings o
errors. Tots els missatges s’aniran mostrant per la consola en color verd, si són missatges
d’informació, color groc, si són warnings, i color vermell si són errors.
En algunes ocasiones ens pot interessar mantenir la consola completament neta. Per
a poder realitzar això disposem d’una opció anomenada “Bootloader Log Verbosity (info)”
que ens permet triar entre 5 opcions que gestionen els missatges que es mostren per consola.
La opció per defecte és la de “Info”, però si es vol mantenir la consola neta hem de
seleccionar “No output”.
Figura 10, Bootloader log verbosity
3.3.1.3. Security features:
Tal i com vam comentar a l’apartat de hardware, el mòdul ESP32 disposa de dos
sistemes de seguretat que es poden utilitzar individualment o de manera dual. Aquest dos
modes són els de “Secure Boot” i “Flash encryption” i es poden activar des del make
menuconfig. Abans d’activar qualsevol dels dos modes és important llegir atentament la
documentació proporcionada per Espressif per saber quins seran els efectes sobre el mòdul
i sobre la nostre aplicació.
Figura 11, Security features configuration
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
31
3.3.1.4. Serial flasher configuration:
En aquest apartat principalment configurarem al port USB que estem utilitzant per
carregar el firmware a la placa, però disposem de moltes altres funcions relacionades amb el
port serie que poden ser adaptades a les nostres necessitats.
- Default Baud Rate: Aquí especifiquem el “baud rate” que s’utilitza mentre ens
comuniquem amb el mòdul ESP32. El “baud rate” determina la velocitat amb la qual
les dades s’envien a través del port sèrie. Podem ajustar el valor segons les nostres
necessitats, amb la única condició que els dos dispositius que es comuniquen
treballin amb el mateix “baud rate”. Rarament trobarem dispositius que treballin a
velocitats superiors a 115200 bps.
- Use compressed upload: Aquesta opció permet enviar les dades comprimides
utilitzant zlib, deixant que la memòria ROM del chip ESP32 vagi descomprimint les
dades a mesura que es van flashejant.
- Flash SPI mode / speed / size: En aquestes tres opcions podem triar el mode amb el
que es realitza el l’SPI flash, la velocitat i la mida en megabytes. El mode per defecte
és el de “Dual I/O Fast Read”, el qual utilitza dos pins SPI per realitzar la
lectura/escriptura, i en conseqüència només necessita la meitat de cicles de rellotge
en comparació al mode SPI estàndard.
- Detect flash size when flashing bootloader: Si aquesta opció està activada, quan es
realitzi la comanda “make flash” detectarà automàticament la mida de la flash
actualitzarà el bootloader.
- Before & after flashing (Reset to bootloader): L’opció per defecte reinicia el
mòdul ESP32 abans i després de realitzar el flashejat. El reset automàtic depèn de
les senyals RTS y DTR que es connecten des del port sèrie al ESP32. Moltes plaques
de desenvolupament ja incorporen aquesta connexió internament.
- “make monitor” baud rate: En aquesta opció podem configurar el “baud rate” que
s’utilitzarà al executar la comanda “make monitor”, la qual mostra per consola la
informació que retorna al programa que s’està executant a través del port sèrie.
Per activar o desactivar les funcions que tenen les claus “[ ]” només tenim que
prémer la tecla “Y” de Yes o la ”N” de No. Les funcions que es troben actives són les que
tenen l’asterisc ([*]), en cas contrari, si la funció està desactivada es veuran les claus buides
([ ]).
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
32
Figura 12, Serial flasher configuration
3.3.1.5. Partition table:
La memòria flash d’un mòdul ESP32 pot allotjar més d’una aplicació, al igual que
diversos tipus de dades, com poden ser dades de configuració, arxius del sistema,
emmagatzemen de paràmetres, etc. Així doncs la taula de particions determina cadascuna de
les parts amb la que es dividirà la memòria flash. Aquesta ocupa 0xC00 bytes i el nombre
màxim de particions que pot albergar és de 95. La taula de particions s’emmagatzema de la
direcció 0x8000 de la memòria flash, però no necessàriament ha de començar a la direcció
0x8000.
La manera més simple d’utilitzar la taula de particions és triant una de les dos opcions
predefinides a la finestra de configuració del “make menuconfig”. La primera opció és la de
“Single factory app, no OTA” i la segona és la de “Factory app, two OTA definitions”. La
que s’utilitza per defecte és la primera, ja que en la majoria de casos no s’utilitza la
funcionalitat OTA, però més endavant veurem la seva utilitat a través d’un exemple pràctic.
OTA són les sigles de “Over The Air” i serveix per actualitzar el firmware de la placa de
manera remota sense necessitat de connectar-se a la placa físicament.
Figura 13, Partition table configuration
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
33
Per a poder veure un resum de la taula de particions a través de la consola podem
executar la comanda “make partition_table”. A continuació podem veure un exemple pels
dos casos predefinits a la finestra de configuració.
Figura 14, Taula de particions pel mode “Single factory app, no OTA”
Figura 15, Taula de particions pel mode “Factory app, two OTA definitions”
Com podem observar en els dos casos tenim tres particions en comú, la “factory”,
que seria la nostra aplicació, allotjada a la direcció 0x10000, i després dos particions més
per la memòria no-volàtil i per les inicialitzacions de la capa física.
Amb la segona configuració tenim tres particions més relacionades amb l’OTA, una
per les dades, i dos per aplicacions. En el primer cas, el bootloader executa per defecte
l’aplicació allotjada a la partició “factory”, però en el segon cas disposem de tres particions
d’aplicació (factory, ota_0 i ota_1). El bootloader, abans d’executar la partició “factory”,
consulta si hi ha alguna cosa a les particions OTA, i si es així, executa allò.
Opcionalment, si ninguna de les dues opcions proporcionades per defecte s’adapten
a les nostres necessitats, tenim una tercera opció anomenada “Custom partition table CVS”
que ens permetrà personalitzar la taula de particions. Per a fer-ho tindrem que crear un fitxer
CVS on escriurem la taula de particions personalitzada amb el mateix format que hem vist
abans. Aquest fitxer el guardarem al directori del projecte. Finalment, només tindrem que
executar la comanda “make menuconfig”, anar a “Partition table”, “Custom partition table
CVS”, i introduir el nom del fitxer on diu “Custom partition CSV file”.
Figura 16, Format per taula de particions personalitzada
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
34
El format que s’ha d’utilitzar per escriure la taula de particions al fitxer CSV és el
que es veu a la imatge anterior, però hem de tenir en compte un conjunt de pautes que ens
poden servir d’utilitat.
1. Els espais en blanc i les línies que comencen amb el símbol “#” (comentaris)
seran ignorades quan es processi el fitxer.
2. Cadascuna de les línies del fitxer sense comentar equivaldrà a una partició.
3. Únicament s’utilitza la direcció de la primera partició per allotjar totes les demés.
Així doncs, on acaba una partició comença la següent, independentment de la
direcció que consti al fitxer CSV.
3.3.1.6. Compiler options:
Les dues opcions que podem trobar en aquest apartat són les de “Optimization
Level” i “Assertion Level”. En la majoria de casos no serà necessari modificar ninguna
d’aquestes dues característiques del compilador ja que les que venen per defecte permeten
treballar correctament amb totes les funcionalitats del mòdul ESP32.
Figura 17, Compiler options configuration
3.3.1.7. Component configuration:
Possiblement un dels apartats més importants de la finestra de configuració on
podrem activar/desactivar i configurar moltes de les funcionalitats de la placa com poden
ser el Bluetooth, el Wi-Fi, l’Ethernet, AWS IoT, etc. A demés també podrem modificar la
configuració especifica del mòdul ESP32, com poden ser la freqüència de la CPU, el
watchdog i l’RTC clock entre moltes d’altres. Moltes vegades es comet l’error
d’implementar funcionalitats en codi però no activar-les a la finestra de configuració. El
resultat és intentar fer funcionar, per exemple, el Bluetooth, sense que aquest estigui
activat en hardware.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
35
Figura 18, Component configuration
3.3.2. Carregar el projecte a la placa (“make flash”)
Havent vist quines són les funcionalitats que podem configurar a través del “make
menuconfig”, anem a reprendre la tasca de carregar el projecte a la placa. Així doncs, si ja
tenim el port USB configurat, només tindrem que sortir de la finestra de configuració i
guardar els canvis. Un cop sortim de la finestra de configuració tornarem a la consola
MSYS, on escriurem la comanda “make flash” per compilar el projecte i carregar-lo.
Figura 19, Execució comanda “make flash”
Si el procediment finalitza correctament veurem que es mostra per pantalla el
missatge “Build Succesful”. Per a poder veure el que va succeint durant l’execució del codi
podem executar la comanda “make monitor”.
A part de los comandes vistes fins ara, també podem executar les comandes “make”
o “make all” per compilar el projecte sense flashejar-lo, o “make clean” si volem tornar a
recompilar tot el projecte des de zero, ja que quan executem les comandes “make”, “make
all” i “make flash” només es compilen el arxius que s’hagin modificat evitant recompilar
totes les altres parts. També disposem de la comanda “make erase_flash” que ens permet
borra tot el contingut de la memòria flash i la comanda “make printf_flash_cmd” per
mostrar per consola les adreces de la descarrega.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
36
3.4. Eclipse IDE.
Eclipse es una plataforma de desenvolupament dissenyada per ser ampliada de
manera indefinida a través de plug-ins. Eclipse en si no treballa amb un únic llenguatge de
programació, sinó que es un IDE genèric. En el nostre cas utilitzarem una extensió per
treballar en llenguatge C o C++. Aquest entorn de treball proporciona eines de gran utilitat
per a gestionar espais, escriure, llegir, executar i depurar aplicacions. En moltes ocasions
treballar en un entorn de treball intuïtiu i estructurat reduirà el temps de resolució dels
problemes i ens permetrà tenir una visió més general del projecte.
3.4.1. Descarregar & Configurar Eclipse IDE.
El primer pas serà descarregar la ultima versió de l’Eclipse IDE per a C/C++. En el
meu cas vaig utilitzar la versió “Neon” (ultima versió en el seu moment), però actualment ja
està disponible la versió “Oxigen”. Des dels següents enllaços podem descarregar cualsevol
de les dues versions d’Eclipse:
Eclipse Neon:
https://www.eclipse.org/downloads/download.php?file=/oomph/epp/neon/R3/eclipse-inst-win64.exe
Eclipse Oxigen:
https://www.eclipse.org/downloads/download.php?file=/oomph/epp/oxygen/R/eclipse-inst-win64.exe
Un cop finalitzada la instal·lació executarem el programa. Abans d’entrar a l’entorn
de treball d’Eclipse s’obrirà una finestra per indicar el directori del workspace que
utilitzarem. En el nostre cas hem utilitzat la carpeta creada a l’apartat anterior on ja teníem
el nostre primer projecte (C:/esp_workspace), però es pot utilitzar qualsevol altre carpeta.
Figura 1, Configuració workspace Eclipse
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
37
Finalment, s’obrirà una pagina de benvinguda on podrem veure un conjunt d’opcions
bàsiques com poden ser la creació d’un nou projecte en C o C++, guies bàsiques sobre el
funcionament d’Eclipse, importar projectes existents, novetats de la nova versió, etc.
3.4.2. Importar projecte a Eclipse
Abans d’importar el projecte a Eclipse hem d’estar segurs que aquest funciona
correctament a través de la consola MSYS, ja que com hem dit abans, tot i canviar l’entorn
de treball, el projecte seguirà funcionant a través del “GNU make” i els fitxers makefile.
Per importar un projecte tenim dues opcions, a través de l’eina “import” o copiant el
projecte al workspace d’Eclipse i creant un projecte nou (File / New / C Project) amb el
mateix nom. Si utilitzem el segon mètode, quan es creï el projecte nou l’Eclipse
automàticament detectarà que ja existeix un projecte amb aquell nom al workspace i
l’importarà, però al crear el projecte hem de seleccionar el “Project Type” i la “Toolchain”
correctament (Project Type: Makefile Project / Empty Project; Toolchain: Cross GCC).
Al següent exemple podem apreciar que ens surt una notificació triangular amb una
exclamació indicant que ja existeix un projecte amb aquest nom al workspace.
Figura 2, Configuració al crear un nou projecte en Eclipse
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
38
Els dos sistemes serveixen per importar qualsevol dels nostres projecte a Eclipse,
però la manera més correcte de fer-ho, i la que utilitzarem en aquesta guia, és a través de
l’eina “Import”.
Així doncs, per importar el nostre projecte anirem a “File / Import” i s’obrirà una
finestra on tindrem que seleccionar el tipus de projecte que volem importar. Seleccionarem
la opció “Existing Code as Makefile Project” dintre del desplegable “C/C++” i clicarem a
“Next”. A la següent finestra introduirem el nom que volem que tingui el nostre projecte i el
directori on es troba el projecte que volem importar. La toolchain que utilitzarem és la “Cross
GCC”.
Figura 3, Importar projecte a Eclipse
Figura 4, Importar projecte a Eclipse
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
39
3.4.3. Configurar les variables d’entorn del projecte.
Ara passarem a configurar les variables d’entorn, que indicaran a l’Eclipse la ruta de
la toolchain i de l’ESP-IDF. Clicarem sobre el nom del projecte amb el boto dret del ratolí i
anirem a propietats. A la finestra que se’ns obrirà anirem on diu “C/C++ Build” i clicarem
sobre la opció “Environment”. Per afegir una variable d’entorn nomes tindrem que prémer
el boto “Add” i se’ns obrirà una finestra on afegirem el nom i el valor de la variable. Les
variables d’entorn que tenim que afegir al projecte són les següents:
Variable VALUE
V 1
IDF_PATH C:/esp_workspace/esp-idf
PATH C:\msys32\usr\bin;C:\msys32\mingw32\
bin;C:\msys32\opt\xtensa-esp32-elf\bin
Taula 4, Variables d’entorn Eclipse
Si alguna de les variables d’entorn ja existeix simplement tindrem que canviar el seu
contingut. La variable IDF_PATH conte la ruta a l’ESP-IDF, que en el nostre cas, es troba
al directori “C:/esp_workspace/esp-idf”, però cadascú ha de posar la ruta on hagi guardat la
carpeta de l’ESP-IDF.
Figura 5, Configuració variables d’entorn Eclipse
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
40
3.4.4. Configurar les variables de compilació del Projecte.
Ara passarem a configurar les variables de compilació. Clicarem on diu “C/C++
Build” i des-seleccionarem la opció “Use default build command”. On diu “Build command”
escriurem una de les dos rutes següents. És completament indiferents quina de les dos
utilitzem.
bash ${IDF_PATH}/tools/windows/eclipse_make.sh
python ${IDF_PATH}/tools/windows/eclipse_make.py
Figura 6, Configuració Build command
A continuació desplegarem el menú “C/C++ General” i clicarem on diu
“Preprocessor Include Paths”. Dintre d’aquesta opció seleccionarem la opció “CDT Cross
GCC Built-in Compiler Settings” i afegirem el següent valor on diu “Command to get
compilar specs”:
xtensa-esp32-elf-gcc ${FLAGS} -E -P -v -dD "${INPUTS}”
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
41
Figura 7, Configuració variables de compilació CDT Cross GCC Build-in
Al mateix lloc on hem configurat la variable anterior seleccionarem la opció “CDT
GCC Built output Parser” i afegirem el següent valor on diu “Command to get compilar
specs”:
xtensa-esp32-elf-(g?cc)|([gc]\+\+)|(clang)
Figura 8, Configuració variables de compilació CDT GCC Build
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
42
Finalment premerem on diu “Apply” per aplicar els canvis i tancarem la finestra. Un
cop haguem configurat totes les variables d’entorn i del compilador ja podrem passar a
compilar el projecte. Els errors i warnings del projecte no es solucionaran fins que no
realitzem el “Build Project”, però abans d’això, hem d’anar al directori del projecte a traves
de la consola MSYS i executar la comanda “make menuconfig” per configurar l’ESP-IDF.
Si no és realitza el “make menuconfig” l’ESP-IDF demanarà la configuració de cada
paràmetre a través de comandes per consola, però l’Eclipse no suporta aquest sistema
d’entrada, i en conseqüència, derivarà en un error de compilació. Així doncs, l’única
alternativa és configurar l’ESP-IDF través de la consola i tornar a Eclipse per compilar el
projecte.
Si el projecte ja ha sigut compilat de manera externa a través de la consola o qualsevol
altre sistema seria convenient realitzar un “Clean Project” abans de compilar-lo amb
l’Eclipse per evitar possibles errors amb els fitxers que ja estaven compilats. Així doncs,
tenint clar aquests punts, clicarem amb el boto dret del ratolí sobre el nom del projecte i
seleccionarem la opció “Build Project”.
Figura 9, Compilació del projecte des de Eclipse
3.4.5. Solucionar errors de dependències
Al finalitzar la compilació del projecte possiblement apareguin errors informant que
no es poden trobar alguns fitxers o directoris. Per a solucionar aquests errors de dependències
tenim que incloure manualment les rutes de tots els “header files” que inclogui el nostre
projecte. Eclipse ens indica quins fitxers no ha trobat amb l’interrogant groc.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
43
Figura 10, Errors de dependències Eclipse
Per incloure els fitxers .h anirem a les propietats del projecte, desplegarem el menú
“C/C++ General” i clicarem on diu “Paths and Symbols”. Per afegir cadascuna de les
dependències clicarem on diu “Add” i escriurem els següents directoris:
${IDF_PATH}/components/esp32/include
${IDF_PATH}/components/newlib/include
${IDF_PATH}/components/freertos/include
${IDF_PATH}/components/nvs_flash/include
${IDF_PATH}/components/driver/include
${IDF_PATH}/components/log/include
On diu “Languages” tenim que seleccionar “GNU C”, que es el que nosaltres estem
utilitzant. La majoria de projectes sempre utilitzaran les 6 dependències mostrades.
Addicionalment, cada usuària haurà d’afegir els directoris pertinents en funció dels
components que utilitzi en el seu projecte. En el nostre cas hem afegit tots els que
necessitàvem per fer funcionar el Bluetooth.
${IDF_PATH}/components/bt/include
${IDF_PATH}/components/bt/bluedroid/include
${IDF_PATH}/components/bt/bluedroid/stack/include
${IDF_PATH}/components/bt/bluedroid/bta/include
${IDF_PATH}/components/bt/bluedroid/api/include
${IDF_PATH}/components/bt/bluedroid/device/include
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
44
Figura 11, Configuració fitxers capçalera projecte Eclipse
3.4.6. Carregar projecte a l’ESP32 des de l’Eclipse.
Finalment, només faltarà configurar les “targets” per a poder carregar el firmware a
la placa. Per a realitzar això crearem una “target” i l’anomenarem “flash”. Un cop estigui
creada farem clic dret sobre el seu nom i li donarem a “Build target” per flashejar el firmware
a la placa. Podem crear “targets” equivalents a cadascuna de les comandes vistes a l’apartat
de l’ESP-IDF ( “make flash”, “make all”, make “clean”, etc.)
Figura 12, Creació “targets” Eclipse
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
45
3.5. Estructurar un projecte
Si busquem informació a través d’internet ens adonarem que la majoria de projectes amb els
que treballen els usuaris de l’ESP32 segueixen la mateixa estructura i són projectes
relativament petits que implementen algunes funcionalitats conjuntament però sense arribar
a ser projectes de software excessivament complexes.
Així doncs, ens podem trobar en diverses situacions que derivin en la necessitat de
modificar aquesta estructura. Un exemple molt clar seria l’increment de la complexitat d’un
projecte arribant a la necessitat de dividir la API segons la seves funcionalitats i els diferents
nivell del model OSI.
En aquest apartat veurem com es compila l’ESP-IDF i entendre el concepte de
“components” amb l’objectiu d’organitzar un nou projecte amb l’ESP-IDF.
Un project d’ESP-IDF es pot veure com un conjunt de components. Per exemple, en
un servidor web que mostra la humitat podríem trobar els següent components:
Llibrerias base per l’ESP32.
Controladors Wi-Fi & Sensor d’humitat.
TCP/IP Stack.
Sistema operatiu FreeRTOS.
Servidor Web.
Codi principal de l’aplicació.
L’ESP-IDF fa que aquests components siguin explícits i configurables. Per realitzar
això, quan es compila un projecte, l’entorn de compilació busca tots els components dintre
dels directoris de l’ESP-IDF, dels directoris del projecte i opcionalment dels directoris dels
components personalitzats. A continuació, permet a l’usuari configurar cadascun d’aquest
components i finalment el procés de compilació compila el projecte.
Els components (component.mk) són peces modulars amb el seu propi codi que es
compilen en biblioteques estàtiques (arxius .a) i s’enllacen a una aplicació. Alguns d’ells són
proporcionats per l’ESP-IDF i altres provenen d’altres fonts.
L’estructura estàndard d’un projecte ESP-IDF és la següent:
Figura 13, Estructura estàndard projecte ESP-IDF
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
46
- “Makefile”: L’arxiu makefile estableix la variable PROJECT_NAME i
opcionalment es pot utilitzar per definir qualsevol de les altres variables del projecte.
També inclou l’arxiu makefile $(IDF_PATH)/make/project.mk que implementa la
resta del sistema de compilació de l’ESP-IDF.
- “sdkconfig”: Aquest arxiu és creat o actualitzat quan s’executa la comanda “make
menuconfig” i conte la configuració de tots els components del projecte.
- “components” (opcional): Aquesta carpeta conte els components del projecte.
Teòricament un projecte no hauria d’incloure components personalitzats d’aquesta
tipus, però pot ser interesant per estructurar codi reutilitzable o incloure components
de tercers que no formes part de l’ESP-IDF.
- “main”: La carpeta “main” és un directori que conte tot el codi font del projecte i
s’interpreta com un pseudo-component. El nom per defecte d’aquesta carpeta és
“main”, però la variable SRCDIRS es pot modificar per a que el compilador busqui
els components en altres directoris.
- “Build”: Aquest directori es crea després de compilar el projecte i conte tots els
fitxer objecte, llibreries i fitxers binaris del projecte.
Tots directoris de components disposen d’un fitxer “component.mk”. Cadascun
d’aquests fitxers pot contenir variables per controlar el procés de compilació del component
i la seva integració dintre del projecte. A demés, cada component pot incloure un arxiu
“kconfig” que defineixi les seves opcions de configuració i que sigui configurat a través de
la configuració del projecte. Alguns components poden incloure arxius “Kconfig.projbuild”
i “Makefile.projbuild” amb l’objectiu de sobre-escriure algunes parts del projecte.
A continuació podem veure quines són les variables del projecte que podem utilitzar:
- PROJECT_PATH: Aquesta variable conte el nom del projecte. Algunes de les
altres variables del projecte es basen en aquesta. El nom del projecte no pot tenir
espais.
- BUILD_DIR_BASE: En aquesta variable guardarem el directori de compilació on
es guardaran tots els objectes / llibreries / binaris del projecte. Per defecte es troba a
$(PROJECT_PATH)/Build.
- COMPONENT_DIRS: Aquesta variable conte els directoris on buscar els
components. Per defecte conte els següents directoris: $(IDF_PATH)/components,
$(PROJECT_PATH)/components i la variable EXTRA_COMPONENT_DIRS.
- EXTRA_COMPONENT_DIRS: Llista opcional dels directoris addicionals on
buscar components del projecte. Normalment aquesta variable conte el directori de
més alt nivell, on es poden trobar subdirectoris que contenen components.
- COMPONENTS: La llista de components per compilar al projecte. Per defecte
trobarem tots els directoris que podem trobar a la variable COMPONENT_DIRS.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
47
- SRCDIRS: En aquesta variable s’especifica on podem trobar “pseudo-components”
específics del projecte, com per exemple el directori “main”. La diferencia entre
especificar els directori aquí o fer-ho a la variable EXTR_COMPONENT_DIRS és
que els directoris SRCDIRS són components directament (podem trobar un fitxer
component.mk al seu interior), en canvi, la variable EXTRA_COMPONENT_DIRS
conte directoris, que al mateix temps, contenen altres directoris amb arxius
component.mk al seu interior.
Anem a veure un exemple on es modifiquen algunes d’aquestes variables. Primer
que tot modificarem el fitxer “makefile” que podem trobar al directori del projecte per
canviar el nom a la carpeta “main”. L’anomenarem “source”.
Figura 14, Fitxer “makefile” projecte ESP-IDF
Com podem veure hem modificat les variables PROJECT_NAME, on guardem el
nom del nostre projecte, i la variable SRCDIRS, on indiquem el directori principal on podem
trobar el codi Font del nostre projecte.
Dintre del nostre projecte hem creat diverses carpetes simulant la distribució que
podria tenir un projecte. Com podem veure, dintre del directori “source” hem afegit carpetes
per organitzar els fitxers fonts en funció de cada funcionalitat deixant visible únicament el
fitxer font “main.c” i els fitxers “component.mk” i “Kconfig.projbuild”.
Figura 15, Exemple estructura d’un projecte
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
48
Si distribuïm els fitxers fonts entre diferents carpetes sense modificar l’arxiu
“component.mk” el compilador només serà capaç de trobar el “main.c”. Per tant, tenim que
modificar el fitxer “component.mk” indicant on es troba tot el codi font de la següent
manera:
Figura 16, Fitxer “component.mk” projecte ESP-IDF
La variable COMPONENT_ADD_INCLUDEDIRS conte les rutes, relatives al
directori del component, on podem trobar els fitxers capçalera del projecte. La variable
COMPONENT_SRCDIRS conte les rutes on és buscaran els fitxers font (*.c, *.cpp, *.s).
A part de les variables del projecte disposem d’un conjunt de variables especifiques
pels fitxers “component.mk” que ens permetran configurar-los totalment en funció de les
nostres necessitats. Totes les variables es poden consultar a la pagina web oficial de l’ESP-
IDF on s’explica detalladament la seva funció i on es defineixen.
4. Projectes demostratius
En aquest apartat s’han desenvolupat un conjunt de projectes tractant quatre de les
funcionalitats bàsiques que podria incorporar un projecte industrial amb l’ESP32. Els
projectes han estat implementats en llenguatge C partint de la API i els exemples
proporcionats per el fabricant.
Espressif disposa d’una API molt complerta, per a qualsevol de les funcionalitats del
mòdul ESP32. Cadascuna de les funcions, Macros o definicions que s’utilitzen als projectes
es poden consultar a la guia de programació de l’ESP-IDF (ESP-IDF Programming Guide),
on s’explica detalladament la seva configuració i funcionalitat.
4.1. Comunicacions Bluetooth (GATT client & GATT server)
En aquest apartat s’han desenvolupat dos projectes per establir comunicacions entre
dos mòduls ESP32 a través de Bluetooth. Els projectes que s’han utilitzat com a base són els
de “GATT client” i “GATT server” que podem trobar a la carpeta d’exemples de l’ESP-IDF
(esp-idf/examples/Bluetooth).
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
49
Per posar en funcionament aquest projecte necessitarem dos mòduls ESP32. En un
carregarem el projecte “GATT_client” i a l’altre carregarem el projecte “GATT server” que
trobarem als annexes. L’objectiu és observar les comunicacions a través del Bluetooth. Així
doncs hem implementat un servidor i un client que es comuniquin entre si a través d’un
protocol GATT de manera indefinida. Durant la comunicació es mostrarà la intensitat de la
senyal (RSSI) per a poder observar els rang del qual disposa el mòdul ESP32.
El client escriurà un valor de dos bytes en hexadecimal a través de la característica
d’escriptura. El servidor rebrà aquest valor, l’incrementarà una unitat i el retornarà quan el
client realitzi la petició a través de la característica de lectura. Així doncs, durant l’execució
del projecte el client anirà escrivint valors des de el nombre 1 fins el 9 progressivament, i el
servidor retornarà cada valor incrementat una unitat. Cada deu lectures / escriptures es
mostrarà un recompte d’enviaments i d’errors, i seguidament es tallarà la connexió per
tornar-se a connectar i tornar a realitzar el mateix procés. Si durant el procés separem els
mòduls veurem que la intensitat de la senyal va disminuint.
Aquestes projectes es van desenvolupar en la versió 2.0 de l’ESP-IDF però han sigut
adaptats a la versió 2.1. Així doncs, no funcionaran amb ninguna de les versions anteriors, a
no ser que es realitzin els canvis pertinents. Degut a l’adaptació entre versions, durant
l’execució apareixeran uns missatges d’informació que es poden desactivar des de la
configuració del projecte (“make menuconfig”). Si únicament volem desactivar els
missatges vermells que apareixen en cada lectura podem comentar la funció
“LOG_INFO("%s unformat.len = %d ", __FUNCTION__, p_src->p_value-
>unformat.len);” que trobarem al fitxer de l’ESP-IDF anomenat “btc_gatt_util.c”.
Si no disposem de dos mòduls ESP32, podem realitzar una proba similar del
funcionament del Bluetooth amb el projecte “GATT Server” i el nostre smartphone. Amb
l’aplicació gratuïta “nRF Connect” de la companyia “Nordic Semiconductors” podrem
detectar el mòdul ESP32 i veure la intensitat de senyal (RSSI) en directe. Amb aquesta
aplicació també podrem escriure i llegir valors de les característiques del servidor GATT
observant així el funcionament d’aquest protocol i de la API Bluetooth.
Distancia (m) 0m 2m 5m 10m 15m
RSSI (dBm) -26dBm -65dBm -72dBm -80dBm -89dBm
Taula 5, Rang senyal Bluetooth mòdul ESP32.
El mòdul en visió directe pot arribar fins els 150 -200 metres, però en la vida real és
normal trobar objectes que interfereixin a la senyal, fent molt difícil arribar a comunicar-se
a tant llargues distancies. Les mesures anteriors s’han realitzat dintre d’una casa amb
parets d’obra normals i corrents.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
50
Comunicacions Bluetooth entre dos mòduls ESP32.
Figura 1, Consola GATT Server (Perifèric)
Figura 2, Consola GATT Client (Central)
A la figura del GATT Client podem observar com es van realitzant les lectures /
escriptures. Un cop finalitzen els deu enviaments es desconnecta i es posa a escanejar.
Quan detecta el dispositiu mostra per pantalla el seu RSSI (RSSI Client: -68dBm) i es
torna a connectar a ell per repetir el procés.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
51
Comunicacions Bluetooth entre un mòdul ESP32 i un smartphone.
Figura 3, Aplicació nRF Connect (Client)
Com podem veure la aplicació nRF Connect actua com a dispositiu central i pot
detectar i connectar-se al mòdul ESP32. Si enviem un byte a través de la característica de
lectura podrem veure pel port sèrie de l’ESP32 com arriba el mateix valor. En el nostre cas
hem enviat el valor 0x03, però també podem enviar “strings”.
Figura 4, Consola GATT Server (Perifèric)
Tal com podem observar a la imatge anterior ens apareix la MAC del nostre
dispositiu mòbil i el valor que hem enviat des de la característica d’escriptura.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
52
4.2. Comunicacions Wi-Fi (Protocol TCP)
L’objectiu d’aquest projecte és veure els diferents modes de configuració del Wi-Fi
i implementar una aplicació que mantingui una comunicació constant entre l’ordinador i el
mòdul ESP32 a través d’un protocol TCP.
Mode Station (STA): Aquest mode és amb el que treballen per defecte la gran
majoria de dispositius electrònics que ens envolten. Quan un dispositiu esta
configurat com “Station”, realitza la funció d’un client que es connecta a un
servidor, sent el servidor les diferents xarxes wifi que detecta el dispositiu.
Mode Acces Point (AP): Quan un dispositiu treballa en “acces point” bàsicament
està creant una xarxa Wi-Fi a la qual ens podem connectar. Un router realitzaria la
funció de “acces point”, i els diferents dispositius que es connecten (ordinadors,
smartphones, tables, etc.) actuarien com “Stations”.
Així doncs, un com s’ha establert la connexió entre “acces point” i “Station” les
comunicacions es realitzen a través d’un protocol TCP seguint una topologia servidor –
client. Qualsevol de les dues parts de la connexió pot treballar com a servidor (esclau) o
com a client (master). Abans de carregar el projecte a l’ESP32 tindrem que configurar
aquests paràmetres, entre d’altres, a través de la comanda “make menuconfig”.
Figura 5, configuració Wi-Fi mode “Station”
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
53
Figura 6, configuració Wi-Fi mode “Acces Point”
Podem observar que en funció del mode que triem haurem de configurar uns
paràmetres o uns altres. En el mode “station” serà necessari indica si treballem com a
servidor o com a client, si enviarem o rebrem informació, la SSID i el password de la xarxa
a la que ens volem connectar (Despatx63, Despatx63..), el port a través del qual realitzarem
la comunicació (4567), la direcció IP del servidor (192.168.61.105) i la mida del paquet que
enviarem (1460). En el mode “acces point” tindrem que indicar el nom que tindrà la nostra
xarxa (ESP32_WIFI) i la contrasenya per connectar-se (1234567890). Si volem realitzar la
comunicació entre dos mòduls ESP32 hem de tenir en compte que si un treballa en AP,
l’altre haure de treballar en “STA”, a no ser que els dos estiguin connectats al mateix AP.
De la mateixa manera, si un treballa com a servidor l’altre treballarà com a client, i si un
envia informació, l’altre haure de rebre-la.
Així doncs, aquest projecte ha estat desenvolupat per comunicar de manera
indefinida l’ESP32 i un ordinador, que es troben connectats a un mateix AP, enviant i rebent
trames. El funcionament és simple, l’ESP32 envia trames a un servidor que retorna
exactament la mateixa trama que ha rebut. Les trames que es van enviant contenen
l’abecedari en majúscules. L’ESP32 comprova que la trama enviada i la rebuda coincideixin
i realitza un seguiment del numero d’enviaments i d’errors. A demés, aquest mostrarà per
consola cada cert temps els bytes per segon i el valor RSSI de la senyal. El servidor envia
una de cada deu trames malament per comprovar que el mòdul ESP32 detecta els errors
correctament. El servidor s’implementarà en llenguatge python i s’allotjarà al ordinador. Per
fer funcionar aquest exemple només cal seguir els següents passos:
1. Copiar el projecte tcp_perf de la carpeta d’exemples de l’ESP-IDF (esp-
idf/examples/performance/tcp_perf) al nostre workspace.
2. Reemplaçar els fitxers “tcp_main.c”, “tcp_perf.c” i “tcp_perf.h” pels que
trobarem als annexes.
3. Anar al directori del projecte (cd C:/esp_workspace/tcp_perf) a través de la
consola, executar la comanda “make menuconfig” i introduir la següent
configuració.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
54
Figura 7, configuració projecte comunicacions Wi-Fi
On diu “WiFi SSID” i “WiFi Password” s’han d’introduir els paràmetres de la
xarxa Wi-Fi que utilitzareu, i on diu “TCP server ip” heu d’introduir la direcció IP del
vostre ordinador. Per conèixer la direcció IP només cal executar la comanda “ipconfig” a la
consola de Windows i copiar la direcció IPv4.
4. Un cop tinguem configurat el projecte el carregarem a la placa i
visualitzarem l’execució amb la comanda “make flash monitor”.
5. Copiarem el codi anomenat “tcp_project.py” dels annexes i l’executarem
amb qualsevol IDE de python. En el meu cas he utilitzat PyCharm.
6. Finalment podrem observar, tan a la consola MSYS com al PyCharm
l’enviament de tramés entre els dos dispositius.
Figura 8, Consola del servidor Python
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
55
Figura 9, Consola mòdul ESP32
Com podem apreciar a la imatge anterior es van enviant trames amb totes les lletres
de l’abecedari en majúscules i es van contant el nombre d’enviaments i el nombre d’errors.
Com ja hem comentat, cada 10 errors introduïm un error expressament per veure que
funciona correctament.
Tant el codi de l’ESP32 com el del servidor han estat desenvolupats per suportar
qualsevol tipus de desconnexió. Així doncs, si algun dels dispositius es desconnecta, l’altre
es quedarà en espera fins que es recuperi la connexió. Per exemple, si parem l’execució del
codi Python o desconnectem el cable Ethernet, l’ESP32 és quedarà en mode espera fins
que el servidor torni a estar disponible.
Figura 10, Codi del servidor Python
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
56
4.3. Actualització firmware de forma remota (OTA, Over the aire)
Una funcionalitat interessant del mòdul esp32 és la capacitat d’actualitzar el
firmware de manera remota sense necessitat de connectar-se físicament a la placa. Aquesta
funcionalitat es molt important si el nostre hardware es troba en una localització de difícil
accés o simplement si disposem de un gran nombre de mòduls per actualitzar, ja que seria
ineficient anar un per un.
El funcionament d’aquest exemple és simple. És creen tres particions a la “Partition
table” anomenades “Factory app”, “OTA_0” i “OTA_1” (la partició “Factory app” és on es
grava per defecte el firmware quan el carreguem a la placa). Quan reiniciem la placa
s’executa un “bootloader” que comprova cadascuna de les tres particions. Si no troba res a
les particions OTA, executarà el firmware de la partició “Factory app”, però si troba alguna
cosa, s’executaran primer les particions OTA.
Així doncs, inicialment les particions OTA estaran buides. Quan s’hagi d’actualitzar
el firmware, la partició “Factory app” descarregarà el fitxer binari, el guardarà a la primera
partició “OTA_0” i reiniciarà la placa. Un cop reiniciada, el bootloader detectarà que una de
les particions OTA conté un firmware i l’executarà.
El firmware que es descarrega mai es podrà guardarà a la mateix partició que s’està
executant, per això mateix, disposem de dos particions OTA que s’aniran alternant amb cada
actualització. El “bootloader” detectarà quina de les dos particions s’ha actualitzat i
l’executarà al reiniciar la placa.
Figura 11, Diagrama de funcionament projecte OTA
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
57
Per fer funcionar aquest projecte seguirem els següents passos:
1. Copiar el projecte OTA que trobarem a la carpeta d’exemples de l’ESP-IDF (esp-
idf/examples/System/ota) al nostre workspace.
2. Executarem la comanda “make menuconfig” per realitzar la configuració del
projecte. La taula de particions ja ve configurada per defecte, però podem observar
que la opció que està seleccionada és la de “Factory app, two OTA definitions”.
Nosaltres només tindrem que configurar l’apartat “Example configuration”.
Figura 12, configuració projecte OTA
Els paràmetres de la xarxa Wi-Fi es configuren com a l’exemple anterior. Per
realitzar la descarrega del firmware, ho farem des de un servidor ubicat al nostre ordinador,
així doncs, tenim que indicar quina és la direcció IP del nostre ordinador. El port que
utilitzem és indiferent sempre i quan coincideixi amb el que esteu utilitzant per el servidor.
El paràmetre “HTTP GET Filename” indica el nom del fitxer binari del firmware. En el
nostre cas hem utilitzat el fitxer “hello_world.bin”
3. Crearem un servidor a l’ordinador des de on l’ESP32 es descarregarà el firmware.
Per a realitzar això obrirem una nova consola MSYS i anirem fins el directori on està
el firmware que volem descarregar (cd C/esp_workspace/hello_world/build). Si no
disposeu d’aquest projecte, copieu-lo dels exemples de l’ESP-IDF i compileu-lo. Un
cop ens trobem al seu directori executarem la següent comanda:
Python –m SimpleHTTPServer 8070
Com podem veure, el port coincideix amb el que hem introduït a la configuració.
Aquesta comanda crea un servidor del directori on ens trobem. Per veure si s’ha
realitzat correctament podem anar al navegador i introduir la següent URL:
localhost:8070, on podrem veure i descarregar tots els fitxers del directori on hem
executat la comanda.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
58
Figura 13, Servidor HTTP del directori “workspace/hello_world/build”
4. Finalment executarem la comanda (a la consola del projecte, no la del servidor)
“make flash monitor” per compilar i carregar el firmware a la placa.
Figura 14, Execució projecte OTA (Descarrega del nou firmware)
Com podem apreciar a la imatge anterior es descarrega la imatge del nou firmware
en parts i les va gravant a la partició OTA de la memòria flash. Quan finalitzi es reiniciarà
la placa i s’executarà el nou firmware. El projecte hello_world (firmware nou que hem
descarregat) únicament mostra per consola “hello_world” i reinicia la placa cada 10 segons.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
59
Figura 15, Execució projecte OTA (execució del nou firmware)
Si en algun moment volem tornar a executar el projecte des de zero hem d’executar
la comanda “make erase_flash” per eliminar el contingut de les particions OTA.
La versió 2.0 i les versions anteriors de l’ESP-IDF tenien un problema de
funcionament amb el projecte OTA que impedeix que finalitzi la descarrega del firmware
correctament. La solució a aquest error s’ha solucionat amb la versió 2.1 de l’ESP-IDF. Si
no voleu actualitzar la versió de l’ESP-IDF es pot utilitzar el codi adjuntat als annexes que
soluciona aquest problema.
Figura 16, Error projecte OTA solucionat amb la versió 2.1
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
60
4.4. Escriptura / Lectura memòria no-volatil (NVS)
En moltes ocasions ens interessarà guardar un conjunt de dades de manera
permanentment sense preocupar-nos per si el mòdul ESP32 perd l’alimentació. Així doncs,
aquí entren en joc les funcions d’escriptura i lectura en memòria no-volàtil.
En aquest apartat veurem com guardar una estructura de dades bastant simple en
memòria no-volàtil. A la carpeta d’exemples disposem de dos projectes que implementen
aquesta funcionalitat. El primer exemple és diu “nvs_rw_value” i serveix per guardar un
byte en NVS (Non-volatile Storage). El segon exemples serveix per guardar un conjunt de
dades de mida ajustable.
Partint del segon exemples, s’ha creat una petita API que es pugui afegir
addicionalment a qualsevol dels projectes que s’implementin. Així doncs, disposarem dos
fitxers anomenats “nvs.c” i “nvs.h” que podrem utilitzar per guardar i llegir una estructura
en memòria no volatil. Les funcions que s’han creat són les següents:
esp_err_t read_nvs_wifistruct(nvs_struct *test_struct);
esp_err_t write_nvs_wifistruct(nvs_struct *test_struct);
esp_err_t erase_non_volatil_storage();
void nvs_init();
El tipus d’estructura està definit al fitxer nvs.h i pot ser modificada a conveniència
de cada projecte. Si es modifica l’estructura s’ha de modificar la funció de lectura
“read_nvs_wifistruct” per a que aquesta guardi correctament cada variable al llegir-les de la
memòria no-volàtil.
Per veure un exemple pràctic s’ha creat un fitxer “main.c” on s’executen les funcions
de l’API que s’ha creat. Així doncs, copiarem un projecte qualsevol dels exemples de l’esp-
idf al nostre workspace i substituirem els fitxers de codi que trobarem al directori “main”
pels tres fitxer del annexes (“nvs.c”, “nvs.h” i “main.c). En el nostre cas hem utilitzat el
projecte “blink” (esp-idf/examples/get-started/blink).
Figura 17, Exemple d’utilització API en projecte
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
61
Com podem observar a la imatge anterior, hem substituït el fitxer “blink.c” pels
nostres fitxer. El codi escrit al fitxer “main.c” crea una variable del tipus de la estructura
“nvs_struct” que posteriorment serà inicialitzada. El primer pas que es realitza és inicialitzar
la memòria no-volàtil. A continuació s’inicialitza l’estructura i és guarda en NVS. Finalment
s’executa la funció per llegir el contingut de la memòria no-volàtil i es comprova que
coincideix amb els valors de la inicialització. La funció “read_nvs_wifistruct” mostra per
consola totes el que llegeix de la NVS.
Figura 18, Fitxer “main.c” projecte NVS
Figura 19, Lectura memòria no volàtil
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
62
5. Conclusions
Com ja sabem, el sector de les noves tecnologies està en constant desenvolupament.
Així doncs, la feina d’un enginyer electrònic és aprendre i millorar constantment al mateix
temps que el sector va progressant.
Amb aquest projecte he tingut la oportunitat de tractar un conjunt de temes amb els
que no havia treballar i aprendre sobre el seu funcionament. Els coneixements i conclusions
que he pogut extreure són els següents.
Comprensió de totes les funcionalitats que incorpora el mòdul ESP32, així com
estudi del hardware que el composa.
Comprensió del funcionament de les comunicacions Wi-Fi i Bluetooth així com la
implementació d’alguns exemples pràctics.
Metodologia de desenvolupament software estructurada.
Comprensió del funcionament i l’estructuració d’un projecte basat en l’Internet of
Things Development Framework d’Espressif (ESP-IDF).
Comprensió de la API proporcionada per Espressif.
Configuració i desenvolupament de software per l’ESP32 sobre l’entorn MSYS.
Configuració i desenvolupament de software per l’ESP32 sobre l’entorn Eclipse IDE
per C i C++.
Resolució dels errors a mesura que anaven apareixent, millorant les habilitats per
buscar informació en fonts oficials del fabricant.
El desenvolupament d’aquest projecte juntament amb les pràctiques m’ha servit per
apreciar les diferencies que hi ha entre l’àmbit laboral i el docent. La feina d’un enginyer és
aprendre constantment i solucionar totes les dificultats que van apareixent durant el transcurs
d’un projecte. Ha sigut interessant poder aplicar i ampliar els coneixement obtinguts a les
assignatures d’informàtica industrial I i II així com contribuir en el procés d’integració i
desenvolupament del mòdul ESP32.
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
63
6. Annexos 6.1. Annexos projecte comunicacions Bluetooth
6.1.1. Annex nº 1: gattc_demo.c (GATT Client)
6.1.2. Annex nº 2: gatts_demo.c (GATT Server)
6.2. Annexos projecte comunicacions Wi-Fi 6.2.1. Annex nº 3: tcp_main.c
6.2.2. Annex nº 4: tcp_perf.c
6.2.3. Annex nº 5: tcp_perf.h
6.2.4. Annex nº 6: TCP_Server.py
6.3. Annexos projecte actualització firmware de forma remota 6.3.1. Annex nº 7: ota_main.c
6.4. Annexos projecte escriptura/lectura memoria no-volatil 6.4.1. Annex nº 8: nvs_api.c
6.4.2. Annex nº 9: nvs_api.h
6.4.3. Annex nº 9: main.c
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
64
7. Bibliografia
Referencia: Jesús Macias, SOLIDGEAR Group, BLUETOOTH BLE: el conocido
desconocido [en línia]. Actualitzada: 24 maig 2017. [Data de consulta: 5 agost 2017].
<https://solidgeargroup.com/bluetooth-ble-el-conocido-desconocido?lang=es>
Referencia: Bluetooth SIG, What is bluetooth [en línia]. Actualitzada: -- 2017.
[Data de consulta: 5 agost 2017].
< https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works>
Referencia: PunchThrough, How GAP and GATT works [en línia]. Actualitzada:--.
[Data de consulta: 6 agost 2017].
<https://punchthrough.com/bean/docs/guides/everything-else/how-gap-and-gatt-
work/#how-do-gap-and-gatt-differ->
Referencia: Wikipedia the free encyclopedia, Wi-Fi [en línia]. Actualitzada: 1 septembre
2017. [Data de consulta: 6 agost 2017].
< https://en.wikipedia.org/wiki/Wi-Fi>
Referencia: Wikipedia the free encyclopedia, Wireless security [en línia]. Actualitzada: 29
agost 2017. [Data de consulta: 7 agost 2017].
< https://en.wikipedia.org/wiki/Wireless_security>
Referencia: Espressif, ESP32 Overview & Resources [en línia]. Actualitzada: -- 2017.
[Data de consulta: 9 agost 2017].
< http://espressif.com/en/products/hardware/esp32/overview>
Referencia: esp32.net, the INTERNET of THING with ESP32[en línia]. Actualitzada: 28
agost 2017. [Data de consulta: 9 agost 2017].
< http://esp32.net/>
Referencia: Wikipedia the free encyclopedia, I2C [en línia]. Actualitzada: 29 agost 2017.
[Data de consulta: 10 agost 2017].
<https://en.wikipedia.org/wiki/I%C2%B2C>
Referencia: Wikipedia the free encyclopedia, CAN bus [en línia]. Actualitzada: 28 agost
2017. [Data de consulta: 12 agost 2017].
<https://en.wikipedia.org/wiki/CAN_bus>
Referencia: Wikipedia the free encyclopedia, I2S [en línia]. Actualitzada: 11 agost 2017.
[Data de consulta: 12 agost 2017].
< https://en.wikipedia.org/wiki/I%C2%B2S>
Referencia: Wikipedia the free encyclopedia, Media-independent Interface [en línia].
Actualitzada: 4 agost 2017. [Data de consulta: 13 agost 2017].
< https://en.wikipedia.org/wiki/Media-independent_interface>
Referencia: Wikipedia the free encyclopedia, Software engineering [en línia].
Actualitzada: 28 agost 2017. [Data de consulta: 13 agost 2017]. <https://en.wikipedia.org/wiki/Software_engineering>
Comunicacions sense fils amb el mòdul ESP32: Anàlisi, disseny e implementació
65
Referencia: Wikipedia the free encyclopedia, Software engineering [en línia].
Actualitzada: 28 agost 2017. [Data de consulta: 13 agost 2017]. <https://en.wikipedia.org/wiki/Software_engineering>
Referencia: esp-idf.readthedocs.io, ESP-IDF programming guide [en línia].
Actualitzada:--. [Data de consulta: 15-25 agost 2017]. < https://esp-idf.readthedocs.io/en/latest/>
Referencia: Github, espressinf esp-idf repostery[en línia].
Actualitzada:29 agost 2017. [Data de consulta: 15-25 agost 2017]. < https://github.com/espressif/esp-idf>