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


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


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.


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.


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


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.


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


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


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


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


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.


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)


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.


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


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.


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).


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ó.


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


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.


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)


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.


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


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”

https://dl.espressif.com/dl/esp32_win32_msys2_environment_and_toolchain-20170330.zip


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”

https://github.com/espressif/esp-idf.git


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


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”)


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

https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers


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


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

([ ]).


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


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


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.


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.


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

https://www.eclipse.org/downloads/download.php?file=/oomph/epp/neon/R3/eclipse-inst-win64.exe

https://www.eclipse.org/downloads/download.php?file=/oomph/epp/oxygen/R/eclipse-inst-win64.exe


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


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


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


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}”


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


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.


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


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


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


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.


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


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).


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.


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.


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.


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”


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ó.


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


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


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


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.


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.


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


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


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


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.


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


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:--.


<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.


< 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.


<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.


< 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>

https://solidgeargroup.com/bluetooth-ble-el-conocido-desconocido?lang=es

https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works

https://punchthrough.com/bean/docs/guides/everything-else/how-gap-and-gatt-work/#how-do-gap-and-gatt-differ-

https://punchthrough.com/bean/docs/guides/everything-else/how-gap-and-gatt-work/#how-do-gap-and-gatt-differ-

https://en.wikipedia.org/wiki/Wi-Fi

https://en.wikipedia.org/wiki/Wireless_security

http://espressif.com/en/products/hardware/esp32/overview

http://esp32.net/

https://en.wikipedia.org/wiki/I%C2%B2C

https://en.wikipedia.org/wiki/CAN_bus

https://en.wikipedia.org/wiki/I%C2%B2S

https://en.wikipedia.org/wiki/Media-independent_interface

https://en.wikipedia.org/wiki/Software_engineering


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>

https://en.wikipedia.org/wiki/Software_engineering

https://esp-idf.readthedocs.io/en/latest/

https://github.com/espressif/esp-idf

Marc Lázaro Martí COMUNICACIONS SENSE FILS AMB EL MÒDUL...

Documents

Transcript of Marc Lázaro Martí COMUNICACIONS SENSE FILS AMB EL MÒDUL...