14.2. Distribuire l’applicazione¶
Uno script funzionante sul banco e un prodotto distribuito non sono la stessa cosa. Una cam che va sul campo deve funzionare da sola per tutta la durata dell’installazione del prodotto – mesi, anni – senza un operatore alla console, senza un IDE collegato e senza un esperto Python nelle vicinanze quando qualcosa smette di funzionare. Le pagine di questa sezione illustrano cosa cambia nell’applicazione quando l’obiettivo è un prodotto distribuito anziché una demo da scrivania.
14.2.1. Una checklist pre-volo¶
Prima che una cam lasci il banco, questo è il breve elenco di cose che dovrebbero essere vere:
Il codice dell’applicazione è nella build, non sul filesystem. I moduli congelati e un’immagine ROMFS coprono codice e asset. L’archiviazione su flash e su scheda SD è riservata solo allo stato di runtime e ai file di log. L’utente finale non può modificare, cancellare o sostituire l’applicazione senza riflashare.
Un watchdog gira di continuo.
machine.WDTviene avviato all’inizio dimain.pye alimentato una volta per ogni iterazione del loop principale. Qualsiasi blocco più lungo del timeout configurato provoca un reset hardware e la cam si riavvia.L’applicazione registra i log in una destinazione recuperabile. La libreria
loggingscrive record con un livello, un timestamp e una destinazione che sul campo può essere recuperata dalla scheda SD.print()è solo per la fase di sviluppo – la sua destinazione predefinita è lo stdout USB, che nessun prodotto distribuito legge.Flash e SD sono trattate come soggette a guasti. La flash interna contiene piccoli record a dimensione fissa (configurazione, ultima calibrazione nota); la SD contiene file voluminosi e di dimensione variabile (acquisizioni di immagini, file di log); le operazioni su entrambe sono avvolte nella gestione degli errori, e l’applicazione ha un fallback definito quando una delle due non è disponibile.
14.2.2. Integrare l’applicazione nella build¶
Due meccanismi complementari inseriscono i file nell’immagine del firmware: