14.2. De applicatie verzenden¶

Een werkend script op de werkbank en een verzonden product zijn niet hetzelfde. Een cam die het veld in gaat, moet zelfstandig draaien zolang het product geïnstalleerd is – maanden, jaren – zonder operator aan de console, zonder aangesloten IDE en zonder Python-expert in de buurt wanneer er iets niet meer werkt. De pagina’s in dit gedeelte behandelen wat er verandert aan de applicatie wanneer het doel een verzonden product is in plaats van een bureaudemo.

14.2.1. Een pre-flight checklist¶

Voordat een cam de werkbank verlaat, is dit de korte lijst van dingen die waar zouden moeten zijn:

Applicatiecode zit in de build, niet op het bestandssysteem. Frozen modules en een ROMFS-image dekken code en assets. Flash- en SD-kaartopslag zijn alleen voor runtime-status en logbestanden. De eindgebruiker kan de applicatie niet bewerken, verwijderen of vervangen zonder opnieuw te flashen.
Een watchdog draait continu. machine.WDT wordt bovenaan main.py gestart en eenmaal per hoofdlus-iteratie gevoed. Elke hang die langer duurt dan de geconfigureerde time-out veroorzaakt een hardware-reset en de cam komt weer omhoog.
De applicatie logt naar een herstelbare bestemming. De logging-bibliotheek schrijft records met een niveau, een tijdstempel en een bestemming die het veld vanaf de SD-kaart kan herstellen. print() is alleen voor ontwikkeltijd – de standaardbestemming is USB-stdout, die geen enkel verzonden product leest.
Flash en SD worden behandeld als faalbaar. Het interne flashgeheugen houdt kleine records met vaste grootte vast (configuratie, laatst bekende kalibratie); SD houdt omvangrijke bestanden met variabele grootte vast (afbeeldingsopnamen, logbestanden); operaties op beide worden omhuld met foutafhandeling, en de applicatie heeft een gedefinieerde terugvaloptie wanneer een van beide niet beschikbaar is.

14.2.2. De applicatie in de build inbakken¶

Twee complementaire mechanismen plaatsen bestanden in de firmware-image: