Témakör:
Az IoT-eszközök kulcsa: a firmware-módosítás rugalmassága
Megjelent: 2018. szeptember 13.
Az IoT-eszközökről – különösen, ha a hosszú ideig működő tápellátásuk megoldott – gyakran mondjuk, hogy „helyezd el és felejtsd el” – hiszen életük hátralevő részében „csak” az eredeti funkciójukat, az adatszolgáltatást kell elvégezniük – lehetőleg anélkül, hogy újra és újra fel kellene keresnünk őket. A gyakorlatban azonban ma már semmit sem tervezhetünk meg évekre előre: az üzemidő alatt hibák derülhetnek ki és változhatnak a felhasználói követelmények is. Emiatt (is) rendkívül fontos, hogy az IoT-eszközök működtető programját, paramétereit – tehát a firmware-jét – az eszköz felkeresése nélkül lehessen hatékonyan módosítani.
Manapság az Internet of Things (IoT) eszközök gyors térnyerése figyelhető meg a piacon a háztartási gépektől az elektromedikai eszközökön át a gépjárművekig. A gyártóknak meg kell tartaniuk versenyelőnyüket a versenytársakkal szemben, és ehhez az innovációk befogadására és alkalmazására való képességen kívül arra is szükség van, hogy ezeket az új technológiákat rugalmasan lehessen bevezetni a már működő termékekben is.
A rugalmasságot a tervezőknek eleve be kell építeniük a termékeikbe, hogy a fejlődő IoT-ökoszisztémához, annak új funkcionalitásaihoz és változó szabályozásaihoz alkalmazkodni tudjanak. A firmware tartalmának módosíthatósága nem csak a felhasználói környezetben való elhelyezéskor képes megteremteni a beállíthatóság lehetőségét, hanem új funkciókkal és képességekkel képes felruházni a már letelepített készülékeket, valamint javítani a működés során felmerült problémákat. A firmware kód tárolására általánosan használt eszköz valamilyen kikapcsoláskor nem törlődő (például NOR flash) tároló, annak újraprogramozhatósága és megbízhatósága miatt. Azáltal, hogy átírjuk az eszköz firmware kódjának egy részét, amely az eszköz nem törlődő tárolójában helyezkedik el, a gyártók könnyedén képesek frissíteni termékük képességeit. Amikor a firmware frissítés szempontjait vizsgáljuk, három fontos dologra kell ügyelnünk:
- melyik és milyen terjedelmű kódrészletet kell módosítanunk,
- milyen gyakran kell módosítanunk és végül,
- mennyi idő áll rendelkezésre ennek végrehajtására.
Melyik és milyen terjedelmű kódrészletet kell módosítanunk?
Azt a kérdést, hogy melyik és milyen terjedelmű kódrészlete(ke)t kell majd módosítanunk, már az IoT-eszköz kezdeti tervezési fázisa során figyelembe kell vennünk. A módosítható kódrészletet a NOR flashmemória egy e célra elkülönített részében kell tárolnunk, elválasztva a nem módosítható kódrészletek tárolójától. A NOR flash bármelyik részének módosítása azzal kezdődik, hogy törölni kell a memóriának a módosításra kijelölt részletét, és csak ezt követően írhatjuk a helyére az új információt. A NOR flash részekre osztott szervezésű, amely részleteket különféle méretű szektoroknak és blokkoknak nevezzük. A NOR flash eszközök, mint amilyen például a Silicon Storage Technology SuperFlash® technológiával készült SST26VF064B (64 Mbit vagy 64 Mb) tárolója is, egyforma, 4 kB-os szektorokra vannak osztva, amelyek egymástól függetlenül törölhetők és újraprogramozhatók (4 kB = 4×1024×8 bit = 32 768 bit). Ezek további, nagyobb, 8 kB-os, 32 kB-os vagy 64 kB-os blokkokba szervezhetők, amelyek ugyancsak egy egységként törölhetők. Így tehát egy 8 kB-os blokk két szektorból, egy 32 kB-os blokk 8 szektorból, és egy 64 kB-os blokk 16 szektorból áll. Az 1. ábra az SST26VF064B szervezését mutatja 8 kB-os, 32 kB-os és 64 kB-os blokkok esetén. Minden egyes blokk önállóan, a többitől függetlenül védhető is az akaratlan vagy rosszhiszemű felülírás ellen. Mielőtt tehát bármilyen felülírást valósítanánk meg a flashmemória bármely tetszőleges részén, a módosítani kívánt blokk írásvédelmét fel kell oldani, és ezzel engedélyezni annak törlését és újraírását. A módosítás befejeztével okos dolog visszaállítani a módosított memóriablokk(ok) írásvédelmét, hogy megelőzzük a tartalom szándékolatlan törlését és/vagy felülírását. Az, hogy a firmware módosítható részének tárolására szektorokba és blokkokba szervezett memóriarész szolgál, elegendő flexibilitást nyújt ahhoz, hogy akár korlátozott, akár jelentős méretű, lényeges képességeket hordozó kódrészleteket módosíthassunk. Mivel a módosítás végrehajtási sebességét a módosítandó szektorok és blokkok száma határozza meg, jól tesszük, ha a flexbilitás kérdését a törlések és újraírások végrehajtásához szükséges idővel együttesen kezelve mérlegeljük a firmware módosítható részének megszervezése során. A 2. ábrán egy példa látható arra, hogyan érdemes a flashmemóriát felosztani módosítható és nem módosítható részekre. A nem módosítható kódrészleteket, mint például a programbetöltésért felelős (boot) kódot írásvédett programterületen érdemes tárolni.
A firmware módosítható részeit – amelyek például az eszköz képességeit és funkcióit írják le – a flexibilitás követelményétől függően kisebb vagy nagyobb blokkokban célszerű elhelyezni. A módosítható tárgykódrészletek (image fájlok) tárolására nagyobb, a módosítható változók és paraméterek tárolására pedig kisebb terjedelmű kódrészletek használatát érdemes megfontolni.
1. ábra Az SST26VF064B memória szervezése (memóriatérképe) 8 db 8 kB-os, 2 db 32 kB-os és 16 db 64 kB-os blokkot tartalmaz
Milyen gyakran módosítunk?
Hogy milyen gyakran kívánjuk módosítani a firmware kódot, főképpen az korlátozza, hogy a flashmemória élettartama korlátozott. A SuperFlash technológiájú memóriáknál, mint például az SST26VF064B esetében is, névlegesen 100 000 ciklusnyira van korlátozva egy adott szektor megbízható törlési/írási felhasználásának száma. Az a lehetőség, hogy egy firmware-t 100 ezer alkalommal lehet módosítani, soknak tűnik, de vegyük figyelembe, hogy sok IoT-eszköz a gyűjtött adatokat a NOR flashmemóriában tárolja, így ezt kell figyelembe vennünk, amikor az eszköz élettartamát meghatározó ciklusszámot kiszámítjuk. Emiatt elegendő számú szektort kell kiosztani a memóriában annak megfelelő hosszúságú élettartama érdekében.
2. ábra A memória felosztása nem módosítható (pl. boot) és módosítható (pl. funkciókat és képességeket, programképfájlokat és paraméterváltozókat tartalmazó) részekre
Tegyük ezt érthetővé egy példa segítségével. Tételezzük fel, hogy az IoT eszköz 16 bájtnyi adatot gyűjt és tárol minden egyes ciklusban, és mindezt az eszköz teljes élettartama alatt 100 milliószor kell végrehajtani. Az ehhez szükséges szektorok számát az alábbiak szerint számíthatjuk ki:
1 szektor = 4 kB
1. táblázat Flash utasításszekvencia az 1, 2 és 4 Mbájtnyi tárterület módosításához
Tételezzük fel, hogy minden újabb 16 bájtnyi adatot címfolytonosan az előző 16 bájt után írjuk egészen addig, míg a szektor végére nem érünk (például 0 × 000F – 0000F, majd 0 × 0010 – 0 × 001F, ezt követően 0 × 0020 – 0 × 002F stb.). Mivel 4 kB/16 bájt = 256, ez az a szám, ahány 16 bájtos adatot be tudunk írni egy szektorba, mielőtt a végére érnénk. Ekkor lehet törölni a szektort. A szektor élettartama 100 000 törlési/írási ciklus. Eszerint, ha egy szektorba 256 adatot írhatunk 100 ezer alkalommal, 25 600 000 adatot írhatunk bele, mielőtt annak élettartama letelik.
Ha tehát az alkalmazástól 100 millió adat beolvasását és tárolását várjuk el, az ehhez szükséges szektorok számát úgy kell meghatároznunk, hogy a gyűjtendő adatok számát osztjuk az adatoknak azzal a számával, amely egyetlen szektor teljes élettartamát kihasználja.
100 000 000 / 25 600 000 = 3,9
Ha tehát az alkalmazást 100 millió 16 bájtos adat begyűjtésére és tárolására alkalmas módon kívánjuk megtervezni, négy szektort kell kijelölnünk arra, hogy kiszolgálja az alkalmazás teljes tervezett élettartamát[1]. Az IoT-eszközök tervezőinek tehát hasonló számításokat kell elvégezniük az elégséges számú blokkok és szektorok számának meghatározására az adatgyűjtési követelmények ismeretében, nehogy beleütközzenek a NOR flash tárolóelemeik élettartamkorlátaiba.
2. táblázat Az SST26VF064B SuperFlash és egy hagyományos flashmemória törlési és programozási idői
A módosítások sebessége
Egy módosítás sebességét a törlést és újraírást igénylő szektorok és blokkok számának ismeretében lehet kiszámítani. Tegyük fel, hogy 1 Mbájtos, 2 Mbájtos vagy 4 Mbájtos firmware kódot (programot és/vagy adatot) kell újraprogramozni, amelyek az SST26VF064B típusú SuperFlash-tároló egymást követő, 64 kbájtos blokkjaiban vannak tárolva. A kód vagy adat lehet tetszőleges firmware kód, például lefordított programkód (image fájl) vagy egyéb adat, amely módosításra, frissítésre szorul. A módosítás egy adott utasításszekvencia hatására történik, amelyet a flashmemóriának kell végrehajtania. Az utasítássorozat a módosítani kívánt blokkok írásvédelmének feloldásával kezdődik. Ezután töröljük a módosítani kívánt blokkokat, programozzuk azokat a módosított tartalommal, végül pedig helyreállítjuk az érintett blokkok írásvédelmét. Az SST26VF064B flasmemória esetén szükséges utasításszekvenciákat az 1. táblázatban mutatjuk be attól függően, hogy 1, 2 vagy 4 Mbájtos memóriaterületet kívánunk módosítani. A táblázatból könnyen belátható, hogy a két legjelentősebb időigényű feladatrész a törlés és az újraprogramozás. Az SST26VF064B alkatrész SuperFlash technológiát használ, amelynek kiválóak a törlési tulajdonságai.
3. táblázat A módosítás időszükséglete 1/2/4 Mbájt memóriaterület módosításához, SuperFlash technológiájú tároló esetén
A 2. táblázatban a SuperFlash technológiájú memóriák adatait hasonlítjuk össze a hagyományos felépítésű flashtárolókéval.
A SuperFlash technológiának a hagyományoshoz képest fölényesen jobb törlési tulajdonságai rendkívül hatásosan csökkentik a memória tartalommódosításának időszükségletét. Az SST26VF064B maximális órafrekvenciája 104 MHz, maximális szektortörlési ideje 25 ms, éppúgy, mint a maximális blokktörlési idő. A maximális memórialap- írási idő pedig 1,5 ms. Ezenkívül egy 12 ns-os késleltetést is alkalmazni kell a 104 MHz-es órafrekvenciájú flashmemória működését vezérlő utasítások között (ez az a minimális idő, amíg a CE vezérlőjelet magas szinten kell tartani). Felhasználva az 1. táblázatban bemutatott utasításokat, a 2. táblázatból kiolvasott programozási és törlési idők ismeretében az 1, 2, és 4 Mbájtos tárolóterület tartalmának módosításához szükséges időket SuperFlash technológiájú tárolónál a 3., hagyományos flashtárolóknál pedig a 4. táblázat mutatja. Az ehhez hasonló számításokat feltétlenül el kell végezni az IoT-eszközök tervezőinek annak érdekében, hogy a flash tartalommódosítások időszükségletéről fogalmat alkothassanak annak érdekében, hogy minimálisra csökkentsék azt az időkiesést, amit az IoT-eszköz a flashmemória tartalommódosítására fordít.
4. táblázat A módosítás időszükséglete 1/2/4 Mbájt memóriaterület módosításához, hagyományos technológiájú flashtároló esetén
Összefoglalás
Az IoT eszközöket tervező mérnököknek rugalmasságot kell biztosítaniuk az alkalmazáskód és az adatok módosításának elvégzéséhez. Milyen és mennyi memóriatartalmat kell módosítani, milyen gyakran és milyen sebességgel – ezek is azon problémák közül valók, amelyeket az IoT eszköz tervezése során meg kell oldanunk. A kikapcsoláskor nem törlődő memória kiválasztása befolyásolja ezeknek a problémáknak a magoldását és kritikus szerepet játszik az időzítésnek és a program módosítási sebességének meghatározásakor.
Szerző: Hardik Patel, vezető alkalmazástechnikai mérnök – Microchip Technology, Inc
www.microchip.com