14.2. Leverera applikationen

Ett fungerande skript på arbetsbänken och en levererad produkt är inte samma sak. En kamera som går ut i fält måste köra på egen hand så länge produkten är installerad – månader, år – utan någon operatör vid konsolen, utan någon IDE ansluten, och utan någon Python-expert i närheten när något slutar fungera. Sidorna i det här avsnittet beskriver vad som förändras med applikationen när målet är en levererad produkt i stället för en skrivbordsdemo.

14.2.1. En checklista före leverans

Innan en kamera lämnar arbetsbänken är detta den korta listan över saker som bör vara sanna:

  • Applikationskoden finns i bygget, inte på filsystemet. Frysta moduler och en ROMFS-avbild täcker kod och tillgångar. Lagring på flashminne och SD-kort är endast till för körningstillstånd och loggfiler. Slutanvändaren kan inte redigera, ta bort eller ersätta applikationen utan att flasha om.

  • En watchdog körs kontinuerligt. machine.WDT startas högst upp i main.py och matas en gång per iteration av huvudloopen. Varje hängning längre än den konfigurerade tidsgränsen orsakar en maskinvaruåterställning och kameran kommer upp igen.

  • Applikationen loggar till en återställningsbar destination. Biblioteket logging skriver poster med en nivå, en tidsstämpel och en destination som fältet kan återställa från SD-kortet. print() är endast för utvecklingstillfället – dess standarddestination är USB-stdout, som ingen levererad produkt läser.

  • Flashminne och SD behandlas som om de kan fela. Internt flashminne håller små poster med fast storlek (konfiguration, senast kända kalibrering); SD håller skrymmande filer med varierande storlek (bildtagningar, loggfiler); operationer på endera är inkapslade i felhantering, och applikationen har en definierad reservlösning när endera är otillgänglig.

14.2.2. Baka in applikationen i bygget

Två kompletterande mekanismer lägger filer i avbilden av den fasta programvaran: