Slik utføres OTA-oppdateringer (Over-the-Air) ved hjelp av ESP32-mikrokontrolleren og dens ESP-IDF

Designere av IoT-produkter (Internet of Things) må kontinuerlig evaluere plattform- og komponentutvalg med sikte på å redusere kostnader og strøm, samtidig som de forbedrer ytelsen og akselererer utformingen av tilkoblingsapplikasjoner. Det er for øyeblikket ganske mange løsninger å velge mellom, men designere står overfor utfordringen med å utføre trådløse, OTA-oppdateringer for å holde enhetens firmware (fastvare) oppdatert når den er tatt i bruk.

Nøkkelen er å se på tilgjengelige plattformer for å se hvilke ekstra verktøy og støtte de kommer med for å støtte OTA-oppdateringer. Slik støtte kan forenkle prosessen kraftig, men kan trenge litt oppmerksomhet på forhånd.

Denne artikkelen tar for seg OTA sine grunnleggende prinsipper og hvorfor det er en kritisk funksjon som nesten alle IoT-systemer må støtte, til tross for utfordringene utviklerne står overfor. Den bruker daEspressif -systemer 'ESP32 Bluetooth og Wi-Fi-aktivert mikrokontroller, med tilhørende moduler, sett og ESP IoT Development Framework (ESP-IDF), for å vise hvordan du oppretter en OTA-partisjon og bruker otatool.py-skriptet til å utføre en fastvareoppdatering mens et program fortsatt er løping.

Introduksjon av OTA-oppdateringer

Kjernefokuset for de fleste utviklingsteamene er å implementere sine produktspesifikke funksjoner, det vil si forretningslogikken som differensierer produktet deres. Alle IoT-produkter har imidlertid et basisfunksjonssett som må distribueres, konfigureres og vedlikeholdes gjennom hele enhetens levetid. Sikkerhetsoppdateringer er et godt eksempel. Gitt behovet for å utføre disse oppdateringene, er oppstartslasteren (bootloaderen) eller OTA-oppdateringen (noen ganger bare kalt OTA) en viktig, men lett oversett funksjon ved evaluering av en egnet utviklingsplattform.

OTA gir ingeniører muligheten til å eksternt vedlikeholde og oppgradere sine produkter som svar på både tekniske og forretningsmessige krav uten å måtte sende vedlikeholdspersonell til enheten eller la sluttkunden aktivt gjøre noe med enheten for å oppdatere den. I stedet kan alle disse kostnadene fjernes ved å la enhetene stille oppgradere firmwaren i bakgrunnen, eller i operasjonell «nedetid», som midt på natten.

OTA-arkitekturer kan komme i mange forskjellige former og konfigurasjoner, fra skreddersydde løsninger hele veien gjennom skyleverandørleverte standardimplementasjoner. Et typisk arkitektonisk eksempel kan ses i figur 1.

Figur 1: En OTA-arkitekturoversikt som viser et eksempel på en prosess for oppdatering av applikasjons firmware ute i felt, på utplasserte enheter. (Bildekilde: Beningo Embedded Group)

I dette eksemplet bruker en OEM Amazon Web Services (AWS) IoT Core til å laste opp nye firmwareversjoner, og bruker deretter de innebygde jobbfunksjonene til å distribuere oppdateringer til enheter som befinner seg ute i felten. Dette er bare ett av mange eksempler, og nesten alle nettskyleverandører har en lignende løsning.

Det er mange alternativer innen mikrokontrolle som støtter OTA tilgjengelig i dag. En populær mikrokontroller for både lavprissystemer og blant produsenter er ESP32. Det er flere grunner til at ESP32 har vært så populær, inkludert:

• Den har en integrert mikrokontroller med Wi-Fi/Bluetooth-sertifiseringsmoduler tilgjengelig.
• Den er lavkost
• Åpen kildekode-utviklingsmiljø og programvarerammer som ESP-IDF og ESP Audio Development Framework (ESP-ADF)
• Mange eksisterende applikasjoneksempler er fritt tilgjengelige på nettet

Velge en ESP32-modul for OTA-testing

Det finnes flere forskjellige ESP32-moduler og utviklingskort som brukere kan kjøpe for å gå gjennom OTA-eksemplene. Ta for eksempel Adafruit 3405 ESP32 Huzzah Feather-kort (figur 2). Dette er et billig utviklingskort som inkluderer alle kretsene for å programmere en ESP32 og drive den via en USB-kontakt.

Figur 2: 3405 Huzzah Feather Board inneholder en ESP32 WROOM-32D-sertifisert Wi-Fi/Bluetooth-modul med 4 Mbyte blits. Kortet inneholder all maskinvare som er nødvendig for å programmere og kommunisere med modulen gjennom USB. (Bildekilde: Adafruit)

I kjernen av 3405 er enESP32-WROOM-32D-modul som kommer med 4 MB flash, Wi-Fi, Bluetooth og et komplett periferiutstyr for nesten alle applikasjoner.

Et annet utviklingskort som kan brukes, er Espressif SystemsESP32-LYRATD-SYNA-lydkort (figur 3). Dette utviklingskortet inkluderer ESP32-WROVER-B-modulen.

Figur 3: ESP32-LYRATD-SYNA-kortet inneholder en ESP32 WROVER-B-sertifisert Wi-Fi/Bluetooth-modul med 4 Mb blits. I tillegg til å gjøre det mulig for designere å programmere og kommunisere med modulen via USB, har den også kretsene som trengs for å utvikle lydapplikasjoner. (Bildekilde: Espressif Systems)

ESP32-LYRATD-SYNA-modulen har også 4 Mbyte blits, samt alle kretsene for lydapplikasjoner. Kortet inkluderer en lydkodek, en lydforsterker og hodetelefon- og høyttalerplugger for å teste ut en lydapplikasjon.

Et siste utviklingskort som kan brukes til OTA-testing, er Espressif ESP32-S2-SAOLA-1RI-utviklingskortet (figur 4). Når det kommer til utviklingskort, er dette det minst kostbare. Kortet inneholder en ESP32-Wrover-modul sammen med kretsene for å programmere brikken. Det er ingen andre dikkedarer enn det faktum at den inneholder stifter som gjør at den enkelt kan legges i et koblingsbrett / prototypekort (breadboard) for testing.

Figur 4: ESP32-S2-SAOLA-1RI, basert på Wrover-modulen, er et bart utviklingskort som er billig, men inkluderer nok kretser til å programmere den innebygde modulen. (Bildekilde: Espressif Systems)

Det spesifikke kortet valgt for testing spiller ikke så stor rolle fordi hver ESP32-modul utnytter ESP-IDF. Dette rammeverket er utformet for å lette programvareutviklingsaktiviteter for utviklere ved å inkludere drivere, mellomvare, en RTO, og – viktigst i forbindelse med denne artikkelen – oppstartslastere (bootloaders), og OTA-biblioteker.

Oppstartslasteren (bootloaderen) lar utviklere utnytte OTA-oppdateringer og partisjonere minnet for å oppdatere firmware mens den primære applikasjonen fortsatt kjører, noe som bidrar til å minimere nedetid. Oppsettet for oppstartslasteren (bootloaderen) kan virke komplisert i begynnelsen, men det er enkelt hvis det styres riktig.

Arbeidsflyten for OTA-utvikling

Arbeidsflyten for OTA-utvikling for ESP32 vil variere litt basert på forretningsbehov og produktkomponentvalg. For eksempel vil et team som utnytter AWS sannsynligvis bruke AWS komme i gang-guider og eksempler for å få ESP32 OTA-løsningen til å fungere. Et selskap som derimot tilpasser sin egen løsning, vil sannsynligvis utnytte ESP32-dokumentasjonen. I denne artikkelen skal vi se på brikkene på ESP32-nivå og ikke i skyen. Grunnen er at disse brikkene er generiske og gjelder for OTA med ESP32, uavhengig av hvilken nettskyleverandør eller løsning som brukes.

Generelt sett innebærer prosessen for å sette opp en OTA-oppdatering på ESP32 følgende trinn:

1. Konfigurer partisjonstabellen ESP32
2. Last ned firmware som støtter OTA
3. Utvikle et verktøy for å fungere som en server og pushe ut (automatisk distribusjon via nett) ny firmware
4. Last ned den nyeste firmwaren på ESP32
5. Bytt til den nye applikasjonen

Dette er åpenbart den forenklede tilnærmingen. Utviklere bør se på figur 1 igjen for å få en oversikt over den generelle prosessen for oppdatering av firmware. Denne prosessen kan være ganske innviklet, så det er tilrådelig å utnytte de eksisterende ESP32 OTA-eksemplene som finnes på GitHub. Disse eksemplene gir flere kritiske eksempler som:

• HTTPS OTA
• Native OTA
• Simple OTA
• OTA-verktøy (eksempel på pytonskript)

Figur 5 viser prosesstrinnene for distribusjon og oppdatering. En utvikler må først utføre trinnene i rødt for å distribuere OTA-løsningen til ESP32-modulen. Trinnene i oransje er neste og utføres for å lette en OTA-oppdatering.

Figur 5: Espressif Systems OTA-oppdateringseksempler på GitHub gir utviklere flere enkle eksempler for å få ESP32 til å utføre OTA-oppdateringer. (Bildekilde: Espressif Systems)

Konfigurere en ESP32 -applikasjon for OTA

ESP32 inneholder en partisjonstabell som beskriver hvilken type data som befinner seg på mikrokontrolleren og hvor den bor. En standard ESP32-partisjonstabell ser for eksempel omtrent ut som tabell 1:

Tabell 1: En standard ESP32-partisjonstabell som viser datatypen og hvor den er plassert på mikrokontrolleren. (Tabellkilde: Beningo Embedded)

Der er fabrikkapplikasjon og deretter en seksjon for NVS-biblioteket og initialiseringsdata for det fysiske laget (PHY). For å bruke OTA-funksjonaliteten, må denne tabellen oppdateres slik at det er minneplasseringer spesifisert for OTA-oppdateringsfirmware, i tillegg til den primære applikasjonen (fabrikkapplikasjonen). For OTA er det vanligvis to partisjoner som er tildelt for oppdateringer. En for den aktive oppdaterte firmwaren, og en for firmwaren som lastes ned og som vil bli den nyeste versjonen. Dette gjør at fabrikkapplikasjonen kan forbli intakt. En oppdatert OTA-partisjonstabell vil se omtrent ut som tabell 2.

Tabell 2: Typisk ESP32-oppdatert OTA-partisjonstabell. (Tabellkilde: Beningo Embedded)

Som vist, finnes det nå en ota_0 og en ota_1 applikasjonsseksjon som er på 1 Mb størrelse, i tillegg til en dataseksjon (otadata) som er RAM-tildelt for oppdateringsprosessen. Denne tabellen kan endres og oppdateres av utvikleren for å passe til applikasjonen.

For å kjøre OTA-eksemplet, er det et enkelt sett med instruksjoner som er oppført på GitHub under «Slik bruker du eksemplene»-delen. Dette beskriver hvordan du bygger og programmerer applikasjonen.

Det er også otatool som kan brukes til å oppdatere firmware. Dette skriptet brukes vanligvis til å:

• Les, skriv og slett OTA-partisjonene
• Bytt omstartspartisjoner
• Bytt til fabrikkpartisjonen

Eksempelskriptet kan kjøres ved bare å kjøre eksemplet i en terminal ved hjelp av kommandoen:

./otatool_example.sh

Eller ved hjelp av Python:

python otatool_example.py

Når det kommer til å konfigurere ESP32 for OTA, er det et kritisk trinn å sørge for at partisjonene er satt opp.

Tips og triks for bruk

EPS32 OTA -løsningen kan akselerere og forenkle en utviklers løsning for firmwareoppdatering. For å unngå at løsningen blir en utviklingsbelastning, er det flere «tips og triks» som bør tas i betraktning:

• Om mulig kan du utnytte et eksisterende OTA-rammeverk som følger med selskapets nettskyleverandør. Dette kan dramatisk forenkle utvikling og integrering.
• Bruk et billig utviklingskort for å teste OTA-funksjoner og oppstartslastere (bootloaders). ESP32 har flere alternativer, og det kan ta litt eksperimentering for å bestemme hvilken som er best for den aktuelle applikasjonen.
• For tilpassede løsninger kan du utnytte ESP32 OTA-eksemplene på GitHub.
• For applikasjoner der produktet fungerer som Wi-Fi-ruteren eller hub-en, bør du vurdere å laste ned firmwareimaget til eksternt minne og utføre en oppdatering fra en masselagringsenhet.
• Bruk litt tid på å gå gjennom ESP32-dokumentasjonen på partisjonstabeller. Dette er litt annerledes enn den typiske mikrokontroller-implementeringen.
• Av sikkerhetsgrunner er det best å deaktivere tilbakeføring (rollback) av applikasjoner. Hvis programmet kan rulle tilbake til tidligere versjoner, kan potensielle angripere potensielt pushe ut (automatisk distribusjon via nett) en versjon med en kjent utnyttelse og utsette systemet for risiko.

Utviklere som følger disse «tips og triks» vil finne at de sparer ganske mye tid og sorg når de prøver å utnytte ESP32, eller en hvilken som helst annen OTA -løsning, etter behov.

Konklusjon

OTA-oppdateringer er en kritisk funksjon for et økende antall IoT og innebygde systemer. Utviklere må få et godt grep om hvordan de kan gjøre det effektivt for å spare tid på forhånd under design- og utviklingsprosessen, samt etter at produktet er sendt.

Den trådløse ESP32-mikrokontrolleren har funnet veien inn i et bredt spekter av enheter, og som vist har den en ferdig OTA-løsning. Ved å utnytte ESP-IDF og tilhørende moduler og plattformer, samt bruke noen erfaringsbaserte tips og triks, kan utviklere dramatisk korte ned på designtiden, samt få sin egen OTA-løsning i gang.