14.2. Az alkalmazás szállítása¶
Egy működő szkript a munkaasztalon és egy szállított termék nem ugyanaz. Egy kamera, amely terepre kerül, addig kell hogy önállóan működjön, ameddig a termék telepítve van – hónapokig, évekig – anélkül hogy operátor lenne a konzolnál, IDE lenne csatlakoztatva, vagy Python-szakértő lenne a közelben, amikor valami leáll. Az ebben a szakaszban lévő oldalak azt tárgyalják, mi változik az alkalmazásban, amikor a cél a szállított termék, nem pedig az asztali demó.
14.2.1. Indulás előtti ellenőrzőlista¶
Mielőtt egy kamera elhagyja a munkaasztalt, ez azoknak a dolgoknak a rövid listája, amelyeknek igaznak kell lenniük:
Az alkalmazás kódja a buildben van, nem a fájlrendszeren. A befagyasztott modulok és egy ROMFS-kép lefedik a kódot és az eszközöket. A flash és az SD-kártya tárhelye csak a futásidejű állapotnak és a naplófájloknak való. A végfelhasználó nem tudja szerkeszteni, törölni vagy lecserélni az alkalmazást újraflashelés nélkül.
Egy watchdog folyamatosan fut. A
machine.WDTamain.pytetején indul el, és fő ciklus iterációnként egyszer kapja meg az etetést. Bármely, a beállított időkorlátnál hosszabb akadás hardveres resetet okoz, és a kamera újraindul.Az alkalmazás egy helyreállítható célhelyre naplóz. A
loggingkönyvtár olyan rekordokat ír, amelyek szintet, időbélyeget és egy olyan célhelyet tartalmaznak, amelyet a terepen az SD-kártyáról vissza lehet nyerni. Aprint()csak fejlesztési idejű – alapértelmezett célhelye a USB stdout, amelyet egyetlen szállított termék sem olvas.A flash és az SD kezelése úgy történik, hogy meghibásodhatnak. A belső flash memória kis, fix méretű rekordokat tárol (konfiguráció, utoljára ismert kalibráció); az SD nagy, változó méretű fájlokat tárol (képfelvételek, naplófájlok); a bármelyiken végzett műveletek hibakezelésbe vannak csomagolva, és az alkalmazásnak van meghatározott tartalék-megoldása arra az esetre, ha bármelyik nem elérhető.
14.2.2. Az alkalmazás belesütése a buildbe¶
Két, egymást kiegészítő mechanizmus helyez fájlokat a firmware-képbe: