Hogyan végezhetünk Over-the-Air (OTA) frissítéseket az ESP32 mikrovezérlő és hozzátartozó ESP-IDF használatával?

By Jacob Beningo

Contributed By DigiKey's North American Editors

A dolgok internetére (IoT) épülő termékek tervezőinek folyamatosan mérlegelniük kell a platform- és alkatrészválasztást a költségek és az energiafelhasználás csökkentése, valamint a hatékonyság javítása és az összekapcsolhatósági alkalmazások tervezésének felgyorsítása érdekében. Jelenleg elég sok megoldás közül választhatnak, de a telepített eszközök esetében meg kell oldaniuk azt a problémát, hogy vezeték nélküli, ún. over-the-air (OTA) frissítéseket hajtsanak végre az eszköz firmware-ének naprakészen tartásához.

Ennek kulcsa, hogy megnézzük, milyen további eszközökkel és támogatással számolhatnak, amelyek lehetővé teszik az OTA-frissítéseket. Az ilyen háttértámogatás nagymértékben leegyszerűsítheti a folyamatot, de előzetesen némi odafigyelést igényelhet.

Ez a cikk az OTA alapjait tárgyalja, valamint azt, hogy a fejlesztőkkel szembeni kihívások ellenére ez miért egy olyan kritikus funkció, amelyet szinte az összes IoT-rendszernek támogatnia kell. Ezután az Espressif Systems ESP32 Bluetooth- és Wi-Fi-kompatibilis mikrovezérlője, a hozzá tartozó modulok, készletek és az ESP IoT Development Framework (ESP-IDF) segítségével bemutatja, hogy hogyan lehet OTA partíciót létrehozni, illetve az otatool.py szkript használatával elvégezni a firmware frissítését, miközben az alkalmazás még fut.

Az OTA-frissítések alapjai

A legtöbb fejlesztőcsapat fő célkitűzése a termékspecifikus funkciók, azaz a terméküket másoktól megkülönböztető üzleti logika megvalósítása. Azonban minden IoT-terméknek van egy alap funkciókészlete, amely az eszköz teljes élettartama alatt telepítést, konfigurálást és karbantartást igényel. Jó példa erre a biztonsági frissítések szükségessége. Tekintettel arra, hogy ezeket a frissítéseket el kell végezni, egy megfelelő fejlesztési platform eldöntésekor annak fontos, de könnyen figyelmen kívül hagyható tulajdonsága, hogy az képes-e a rendszerbetöltő frissítésére illetve firmware OTA-frissítésre (FOTA, vagy néha csak OTA).

Az OTA lehetővé teszi a mérnökök számára, hogy a műszaki és üzleti igényeknek megfelelően termékeiket távolról karbantarthassák és frissíthessék anélkül, hogy karbantartó személyzetet kellene küldeni az eszközhöz, vagy a végfelhasználónak aktívan tennie kellene valamit az eszközzel annak frissítése érdekében. Ehelyett mindezek a költségek megszüntethetők, ha az eszközök firmware-ét háttérben vagy üzemszünetben, például az éjszaka közepén csendben frissíthetik.

Az OTA-architektúrák számos különböző formában és konfigurációban létezhetnek, az egyedi megoldásoktól kezdve egészen a felhőszolgáltató által biztosított standard megvalósításokig. Egy tipikus architektúra példája látható az 1. ábrán.

Kép – egy OTA-architektúra áttekintő diagramja, amely az alkalmazás firmware-ének frissítési folyamatát mutatja be példaként1. ábra: Egy OTA-architektúra áttekintése, amely terepen telepített eszközökön futó alkalmazás firmware-ének frissítési folyamatára mutat példát. (Kép: Beningo Embedded Group)

Ebben a példában egy eredeti berendezésgyártó az Amazon Web Services (AWS) IoT Core szolgáltatását használja az új firmware-verziók feltöltésére, majd a beépített Job funkciók segítségével telepíti a frissítéseket a terepen lévő eszközökre. Ez csak egy példa a sok közül, és szinte minden felhőszolgáltató rendelkezik hasonló megoldással.

Ma már számos olyan mikrovezérlő áll rendelkezésre, amely támogatja az OTA-t. Egyik ilyen népszerű eszköz mind az olcsó rendszerek, mind a gyártók körében az ESP32. Népszerűségének számos oka van, ezek egyebek mellett:

  • integrált mikrovezérlővel és Wi-Fi/Bluetooth kompatibilis modulokkal rendelkezik;
  • alacsony költség;
  • nyílt forráskódú fejlesztőkörnyezet és szoftver keretrendszerek, például az ESP-IDF és az ESP Audio Development Framework (ESP-ADF);
  • számos meglévő alkalmazási példa szabadon elérhető a világhálón.

ESP32 modul kiválasztása OTA-teszteléshez

Több különböző ESP32 modul és fejlesztői kártya áll rendelkezésre, amelyeket a felhasználók megvásárolhatnak az OTA-példák megismeréséhez. Vegyük például az Adafruit 3405 ESP32 Huzzah Feather kártyát (2. ábra). Ez egy olcsó fejlesztői kártya, amely tartalmazza az ESP32 programozásához szükséges összes áramkört és egy USB csatlakozón keresztül táplálja a modult.

Kép – az Adafruit 3405 Huzzah Feather Board2. ábra: A 3405 Huzzah Feather Board egy ESP32 WROOM-32D 4 MB flash memóriával rendelkező, tanúsítottan Wi-Fi/Bluetooth kompatibilis modult tartalmaz. A kártyán a modul programozásához és az USB-n keresztüli kommunikációhoz szükséges összes hardver megtalálható. (Kép: Adafruit)

A 3405 magja egy ESP32-WROOM-32D modul, amely 4 MB flash memóriát, Wi-Fi-t, Bluetooth-t és egy szinte bármilyen alkalmazáshoz használható teljes perifériakészletet tartalmaz.

Egy másik használható fejlesztői kártya az Espressif Systems ESP32-LYRATD-SYNA jelű audiokártyája (3. ábra). Ez az ESP32-WROVER-B modult tartalmazza.

Kép – az Espressif Systems ESP32-LYRATD-SYNA kártyája3. ábra: Az ESP32-LYRATD-SYNA kártya alapja egy ESP32 WROVER-B, 4 MB flash memóriával ellátott, tanúsítással rendelkező Wi-Fi/Bluetooth modul. Amellett, hogy lehetővé teszi a tervezők számára a modul USB-n keresztüli programozását és a kommunikációt, rendelkezik az audio alkalmazások fejlesztéséhez szükséges áramkörökkel is. (Kép: Espressif Systems)

Az ESP32-LYRATD-SYNA modul szintén 4 MB flash memóriával, valamint az audio alkalmazásokhoz szükséges összes áramkörrel is rendelkezik. A kártya egy audiokodeket, egy audioerősítőt, valamint fejhallgató- és hangszóró-csatlakozókat tartalmaz egy audioalkalmazás teljes körű teszteléséhez.

Az OTA-teszteléshez használható utolsóként bemutatott fejlesztői kártya az Espressif ESP32-S2-SAOLA-1RI jelű terméke (4. ábra). A fejlesztői kártyák közül ez a legolcsóbb. Egy ESP32 Wrover modult tartalmaz a chip programozásához szükséges áramkörök mellett. Egyszerűen csak azokkal a kivezetésekkel rendelkezik, amelyek lehetővé teszik, hogy könnyen csatlakoztatható legyen a deszkamodellhez tesztelés céljából.

Kép – a Wrover modulon alapuló Espressif Systems gyártmányú ESP32-S2-SAOLA-1RI4. ábra: A Wrover modulon alapuló ESP32-S2-SAOLA-1RI eszköz egy olyan alap fejlesztői kártya, amely olcsó, ugyanakkor tartalmazza a kártyán levő modul programozásához szükséges áramköröket. (Kép: Espressif Systems)

A teszteléshez kiválasztott konkrét kártya nem különösebben érdekes, mivel minden ESP32 modul az ESP-IDF-et használja. Ezt a keretrendszert úgy tervezték, hogy megkönnyítse a szoftverfejlesztési tevékenységet azáltal, hogy illesztőprogramokat, köztes szoftvereket, RTOS-t, és – ami e cikk szempontjából fontos – rendszerbetöltőket és OTA-könyvtárakat tartalmaz.

A rendszerbetöltő lehetővé teszi a fejlesztők számára, hogy kihasználják az OTA-frissítéseket és particionálják a memóriát a firmware frissítéséhez, miközben az elsődleges alkalmazás még fut, ami segít minimalizálni az állásidőt. A rendszerbetöltő beállítása elsőre bonyolultnak tűnhet, de megfelelő útmutatással egyszerű.

Az OTA-fejlesztés munkafolyamata

Az ESP32 OTA-fejlesztés munkafolyamata az üzleti igények és a termékkomponensek kiválasztása alapján némileg változik. Például egy AWS-t használó csapat valószínűleg az AWS bevezető útmutatóit és példáit fogja használni az ESP32 OTA-megoldás működőképessé tételéhez. Egy, a saját megoldását testre szabó vállalat azonban valószínűleg az ESP32 dokumentációjára fog támaszkodni. Ebben a cikkben az ESP32 és nem a felhő szintjén fogjuk megvizsgálni az egyes elemeket. Ennek oka, hogy ezek az elemek általánosak, és az ESP32 OTA folyamatára vonatkoznak, függetlenül attól, hogy melyik felhőszolgáltatót vagy megoldást használják.

Általánosságban elmondható, hogy egy OTA-frissítés beállítása az ESP32-n a következő lépésekből áll:

  1. az ESP32 partíciós tábla konfigurálása;
  2. az OTA-t támogató firmware letöltése;
  3. egy kiszolgálóként működő és az új firmware-t beíró eszköz kifejlesztése;
  4. a legújabb firmware letöltése az ESP32-re;
  5. átváltás az új alkalmazásra.

Nyilvánvaló, hogy ez egy egyszerűsített megközelítés. A fejlesztőknek érdemes újra megnézniük az 1. ábrát a firmware frissítés teljes folyamatának áttekintéséhez. Ez a folyamat elég bonyolult lehet, ezért célszerű felhasználni a GitHub-on megtalálható ESP32 OTA-példákat. Számos kritikus példa áll rendelkezésre, például:

  • HTTPS OTA;
  • Native OTA;
  • Simple OTA;
  • OTA Tool (python példa szkriptek).

Az 5. ábrán a telepítési és frissítési folyamat lépései láthatók. A fejlesztőnek először a piros színnel jelölt lépéseket kell végrehajtania az OTA-megoldás ESP32 modulra telepítéséhez. Ezt követik a narancssárga színnel jelölt lépések az OTA-frissítés megkönnyítése érdekében.

Kép – az Espressif Systems OTA-frissítési példáinak diagramja5. ábra: Az Espressif Systems OTA-frissítési példái, amelyek megtalálhatók a GitHub-on, számos egyszerű megoldást kínálnak a fejlesztőknek az ESP32 OTA-frissítésének végrehajtásához. (Kép: Espressif Systems)

ESP32 alkalmazás konfigurálása OTA-hoz

Az ESP32 tartalmaz egy partíciós táblát, amely leírja, hogy milyen típusú adatok, és hol találhatók a mikrovezérlőben. Egy standard ESP32 partíciós tábla például az 1. táblázathoz hasonlóan néz ki:

Kép – a standard ESP32 partíciós tábla1. táblázat: Standard ESP32 partíciós tábla, ahol láthatók az adatok típusai és helyei a mikrovezérlőben. (Táblázat: Beningo Embedded)

A táblázat tartalmazza a gyári alkalmazást, majd egy részt az NVS könyvtárnak, és a fizikai réteg (PHY) inicializálási (init) adatait. Az OTA-funkció használatához ezt a táblázatot frissíteni kell, hogy az elsődleges (gyári) alkalmazáson kívül az OTA-frissítő firmware számára is legyenek kijelölt memóriahelyek. Az OTA esetében általában két partíciót különítenek el a frissítések részére. Egyet az aktív frissített firmware-hez, egyet pedig a letöltés alatt álló firmware-hez, utóbbi lesz a legújabb verzió. Ilyen módon a gyári alkalmazás érintetlen maradhat. Egy frissített OTA partíciós tábla a 2. táblázathoz hasonlóan nézne ki.

Kép – egy tipikus ESP32 frissített OTA partíciós tábla2. táblázat: Tipikus ESP32 frissített OTA partíciós tábla. (Táblázat: Beningo Embedded)

Amint látható, most van egy ota_0 és egy ota_1 programrész, amely 1 MB méretű, valamint egy adatrész (otadata), amely a frissítési folyamat számára kiosztott RAM. Ezt a táblázatot a fejlesztő az alkalmazás igényeinek megfelelően módosíthatja és frissítheti.

Az OTA-példa futtatásához egyszerű utasításkészlet áll rendelkezésre, amely a GitHub-on a „Hogyan használjuk a példákat” rész alatt megtalálható. Ez ismerteti az alkalmazás létrehozásának és programozásának módját.

Létezik továbbá az otatool, amely a firmware frissítésére használható. A szkript tipikus felhasználási területei:

  • az OTA-partíciók olvasása, írása és törlése;
  • boot partíció váltása;
  • átváltás a gyári partícióra.

A példaszkript egyszerűen futtatható a terminálban a következő paranccsal:

./otatool_example.sh

Vagy Python használatával:

python otatool_example.py

Az ESP32-nek OTA-funkcióra való konfigurálásakor kiritikusan fontos meggyőződni a partíciók helyes beállításáról.

Tippek és trükkök a használathoz

Az EPS32 OTA-megoldás képes felgyorsítani és egyszerűsíteni a fejlesztők firmware-frissítési megoldásait. Annak érdekében, hogy a megoldás ne akadályozza a fejlesztést, számos „tippet és trükköt” kell szem előtt tartani:

  • Lehetőség szerint ki kell használni a cég felhőszolgáltatójához tartozó meglévő OTA-keretrendszert. Ez rendkívüli módon leegyszerűsítheti a fejlesztést és az integrációt.
  • Célszerű olcsó fejlesztői kártya használata az OTA-képességek és a rendszerbetöltők teszteléséhez. Az ESP32 többféle lehetőséggel rendelkezik és némi kísérletezést igényelhet annak meghatározása, hogy melyik a legjobb az adott alkalmazáshoz.
  • Egyedi megoldásokhoz célszerű a GitHub-on található ESP32 OTA-példák használata.
  • Olyan alkalmazások esetében, ahol a termék Wi-Fi router vagy hub szerepét tölti be, érdemes megfontolni a firmware image külső memóriába való letöltését, majd a frissítés külső memóriából történő végrehajtását.
  • Szánjon időt az ESP32 partíciós táblákra vonatkozó dokumentációjának átnézésére. Némi eltérés tapasztalható a tipikus mikrovezérlős megvalósítástól.
  • Biztonsági okokból legjobb letiltani az alkalmazás visszaállítását. Ha az alkalmazás vissza tud állni korábbi verziókra, akkor a potenciális támadók ismert biztonsági rést tartalmazó verziót tölthetnek be és veszélyeztethetik a rendszert.

Az ezen „tippeket és trükköket” megfogadó fejlesztők sok időt fognak megtakarítani és sokkal kevesebb problémába fognak ütközni, amikor megkísérelik az ESP32 vagy bármely más OTA-megoldás használatát.

Összegzés

Az OTA-frissítések kritikus fontosságúak egyre több IoT- és beágyazott rendszer esetében. A fejlesztőknek jól kell ismerniük, hogyan hajthatják ezt végre hatékonyan, hogy időt takarítsanak meg a tervezési és fejlesztési folyamat során, valamint a termék leszállítása után.

Az ESP32 vezeték nélküli mikrovezérlő számos eszközben megtalálta a helyét és mint látható, kész OTA-megoldással rendelkezik. Az ESP-IDF, illetve a kapcsolódó modulok és platformok kihasználásával, valamint néhány tapasztalaton alapuló tipp és trükk alkalmazásával a fejlesztők jelentősen csökkenthetik a tervezési időt és beüzemelhetik, majd használhatják saját OTA-megoldásukat.

DigiKey logo

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of DigiKey or official policies of DigiKey.

About this author

Image of Jacob Beningo

Jacob Beningo

Jacob Beningo is an embedded software consultant. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees, including a Masters of Engineering from the University of Michigan.

About this publisher

DigiKey's North American Editors