ESP-IDF v4.4.2 prechod na v5.2

ESP-IDF v4.4.2 prechod na v5.2
pridal deadawp 5.11. 2024 o 20:16 (naposledy upravené 6.11. 2024 o 11:10)

ESP-IDF je IoT Development Framework od Espressif Systems. Ide o framework, ktorý je navrhnutý pre mikrokontroléry ESP32 a nízkoúrovňové programovanie. Samotné funkcie frameworku využíva aj napríklad Arduino Core pre ESP32. Je však pravdou, že funkcionalita, ktorú je možné použiť je vždy skôr dostupná vo frameworku ESP-IDF, ako v Arduino Core (Wiring), ktoré povinne používa toto API.

Osobne som s ESP-IDF začal používať ešte počas štúdia na TUKE v súvislosti s diplomovou prácou. Toho času existovala okolo roku 2019 posledná release verzia v3.3.X na ktorej som začal. Neobsahovala však ešte podporu funkcionality Secure Boot a tak som musel ešte nejaký ten mesiac počkať do vydania verzií v4.0, resp. v4.1 a vo finále som vtedy skončil na verzii v4.2. Používal som vtedy aj nástroje ESPTOOL bundlu, konkrétne esptool.py (práca s flash pamäťou), espefuse.py (práca s efuses) a espsecure.py (kryptografické operácie) a tiež funkcionality OTA s distribúciou firmvéru cez externú webaplikáciu, kde sa zároveň overovalo aj číslo verzie existujúceho a nového firmvéru v .bin formáte. Tento firmvér bol aj podpísaný a jedine taký vôbec mikrokontróler spustil.

Každá z verzií ESP-IDF mala svoje špecifiká, build systém fungoval najprv na GNU Make najmä pred verziou v4, čomu odpovedali aj iné príkazy, ktoré s frameworkom súviseli, keďže sa pre všetko používal nástroj make. Neskôr bol už build systém CMake a aj obsluha bola podobná tomu, ako ju poznáme dnes s nástrom idf.py s ktorým je možné zavolať mnohé funkcie. ESP-IDF sa neustále rozširuje, čo je vidieť aj vo funkciách menuconfigu, kde stále pribúdajú nové funkcionality pre komplexnú konfiguráciu projektu.

Posledný projekt, ktorý som na ESP-IDF vyvíjal bola funkcionalita senzorového uzla, ktorý bol postavený na ESP32 (DevKit so štadnradným WROOM procesorom) a ultrazvukovom senzore HC-SR04, respektíve JSN-SR04T. Toho času som používal ESP-IDF v4.2, následne v4.4.2, ktoré malo oficiálny release v Decembri 2020, resp. druhá verzia v Auguste 2022. Na tejto verzii boli založené aj verzie Arduino Core 2.0.X. S verziou ESP-IDF súvisí aj jeho podpora, ktorá je 30 mesiacov od vydania hlavnej release verzie teda napr. v4.2, v4.4, počas ktorej bude dostávať updaty, security fixy a podobne, čo sú vlastne tie podverzie.

Doba ale pokročila, prišlo Arduino Core 3 a tiež aj ESP-IDF v5. Je dôležité poznamenať, že Espressif Systems vyvíja aj viacero verzií ESP-IDF súčasne. Napríklad existovali hlavné release verzie ESP-IDF v4.2 alebo v4.4. a každá z týchto verzií dostávala bugfixy a updaty samostatne, teda v4.4 nevychádzala z v4.2. Z toho dôvodu sme mali podverzie v4.4.1 a podobne a boli vyvíjané v rovnakom období. Rovnako to funguje aj v ESP-IDF v5., napríklad v5.1.5 je bugfixom verzie v5.1 a vyšiel v Októbri 2024. Aj v súčasnosti sa stále vyvíjajú niektoré verzie v4.

Vo Februári 2024 som si inštaloval ESP-IDF na čistý disk pri reinštalácii Windowsu. Toho času mi inštalačný nástroj IDF Tools ponúkol poslednú release verziu v5.2, ktorú som si nainštaloval. Verzie 5 sú známe aj tým, že prinášajú aj podporu ESP kontrolérov s podporou WiFi 6, ktoré sú založené už aj na RISC-V architektúre, napr. ESP32-C6 je veľmi zaujímavým adeptom pre budúce projekty s WiFi 6 a podporou TWT, ale aj na podporou Zigbee, či Thread.

Chcel som teda updatovať projekt z pôvodného ESP-IDF v4.4.2 na ESP-IDF v5.2. Začať som nemohol inak, ako nakopírovaním projektu priamo do zložky examples vo frameworku pod hlavnejšiu zložku napr. system. Všetky moje projekty mali definované meno priečinka, ktoré sa zhodovalo s menom projektu a zároveň som dbal nato, aby sa názov nezhodoval s ukážkovým programom vo frameworku.

K discpozícii som mal celkom 3 programy, ktoré používali rovnaký kód, čo sa týkalo obsluhy senzora, líšili sa len v ďalšej, doplnkovej funkcionalite:

Offline tester - program, ktorý meria každých 5 sekúnd vzdialenosť cez ultrazvukový senzor
HTTP request - meranie raz za 300 sekúnd, HTTP POST request s dátami
HTTPS request - meranie raz za 300 sekúnd, HTTPS POST request s dátami

Dôležité je poznamenať pár vecí. HTTP a HTTPS request využívajú WiFi údaje zadané cez MENUCONFIG a tiež využívajú FreeRTOS s Queues, kedy HTTP / HTTPS task čaká, kým sa vykoná meranie, čo do fronty Queue zašle dáta. Dovtedy task čaká a ak request prebehne, hodnotu z Queue odstráni, prípadne opakuje request. HTTPS program využíval CA cert bundle, ktorý je vstavený v ESP-IDF, čo je vlastne obsah všetkých verejných Root CA certifikátov.

Začal som teda s Offline testerom, čo je program s najmenšou funkcionalitou a obsluhuje len ultrazvukový snímač. Kompilácia sa nepodarila z dôvodu nesprávneho dátového typu, kedy som používal formátovací reťazec %d na premennú, ktorá mala dátový typ uint_32. Skoršia verzia ESP-IDF to tolerovala, novšia už nie. Bolo tak nutné zmeniť na %ld. Taktiež sa tu vyskytoval aj warning k hlavičkovému súboru "driver/dac.h", ktorý je už zastaraný a bolo ho nutné nahradiť jedným hlavičkovým súborom z troch, ktoré sám framework ponúkol. Rozhodol som sa pre "driver/dac_oneshot.h".

Ďaľšou chybou bolo, že program využíva funkcie gpio_pad_select_gpio(), čo je už funkcionalita v ESP-IDF 5 zjednotená v príkaze gpio_set_direction, ktorý sa tu využíval ako sekundárny. Bolo tak len nutné odstrániť prvý príkaz. Program bolo už možné skompilovať a nahrať do mikrokontroléra. Štandardne sa nastavil aj target na použitý mikrokontróler a nebolo potrebné architektúru nastavovať manuálne. Cez idf.py monitor som si otvoril Serial monitor, ale stále mi senzor meral 0 cm. Zapojenie bolo dobré, avšak neuvedomil som si, že používam HY-SRF05 a nie HC-SR04. Žiaľ HY nemá v láske 3V3 napájanie a nefungoval správne. Po zapojení napájania Vcc na 5V už bežal spoľahlivo a mikrokontróler ukazoval správnu vzdialenosť.

Potrebné súčasti z časti ultrazvukového senzora som nakopíroval aj do sekundárneho projektu s HTTP requestom. Tento projekt odosiela raz za 5 minút údaje o výške hladiny vody na web rozhranie: https://arduino.clanweb.eu/studna_s_prekladom. V prípade toho programu bolo nutné ešte na dvoch miestach zmeniť formátovací reťazec %d na %ld pre premennú. Inak celý program HTTP requestu bol úplne bez zmeny v porovnaní s verziou z frameworku ESP-IDF 4.4.2.

HTTPS request zdroják vyžadoval viacero zmien, ale neboli až také zásadné, ktoré by významne ovplyvnili program. Zmenili sa názvy hlavičkového súboru s preddefinovanými certifikátmi certifikačných autorít (CA). Pribudla podpora aj pre TLS 1.3 spojenia, ktoré sa musí zapnúť príslušným makrom. V autorizačnom móde mbedTLS knižnice je už na základe example kódu autorizácia vyžiadaná, vo verzii v4.4.2 bola voliteľná, ide o jeden z parametrov funkcie. Následne sú ešte zmenené aj názvy niektorých súborov, najmä tých, ktoré pracujú s komponentami, či sdkconfig, ktorý teraz existuje aj s príponom .ci.

Každý z firmvérov som bol schopný rozchodiť a vykompilovať. Rozdiel v pamäťových nárokoch som neskúmal. Každý firmvér bežal asi 30 minút a všetko sa zdalo byť v poriadku, žiadny pád aplikácie, či nedostatok pamäte. Aj z tohto pohľadu sa release v5.2 ESP-IDF javí ako jedna z dobrých volieb.

Ako vidíte, ESP-IDF sa vyvíja v logike, aby bol ľahší prechod aj zo straších verzií ESP-IDF. Funkcie sa nemenia, sedí aj počet ich parametrov a sporadicky sú nejaké zmeny, ktoré ale je možné vyriešiť behom pár minút. S TLS 1.3 sa až tak často zatiaľ nestretnete. Drvivá väčšina webov beží na TLS 1.2. Toto riešenie pre HTTPS request s kryptografickou knižnicou mbedTLS používa bundle s dostupnými Root CA certifikátmi, čo sú tie najväčšie certifikačné autority. Nájdete tam DigiCert, ISRG Root X1 a mnohé iné... Myslím ale, že ak by ste do zoznamu použili aj self-signed certifikát, ktorý by ste si sami vygenerovali, či už na báze RSA, alebo ECC kľúča, zrejme by ho framework dokázal automatizovane nasadiť, i keď, netestoval som.

Rozhranie pre otestovanie HTTP konektivity a vizualizáciu dát z HTTP programu:
https://arduino.clanweb.eu/studna_s_prekladom