14.5. Riepilogo

Hai percorso il ciclo di vita di una cam che passa da uno script funzionante sul banco di lavoro a un prodotto spedito:

  • Build firmware personalizzate – l’ambiente di sviluppo, la compilazione dell’immagine firmware dai sorgenti, la sua programmazione su una cam e il percorso di debug da VS Code Cortex-Debug allo strumento da riga di comando gdbrunner quando qualcosa non va sul lato firmware.

  • Spedire l’applicazione – incorporare il codice dell’applicazione nel firmware tramite moduli congelati, incorporare le risorse in un’immagine ROMFS e l’ordine di ricerca che determina quale copia di un file il runtime carica effettivamente all’avvio. La suddivisione che ne deriva: boot.py per la configurazione dell’ambiente pre-REPL, main.py come punto di ingresso dell’applicazione, main.py congelato per l’ingresso e ROMFS per tutto il resto.

  • Irrobustimento per la produzione – la libreria logging che scrive su un percorso noto, un machine.WDT alimentato una volta per iterazione del ciclo principale, un try / except di livello superiore che trasforma i crash in eventi registrati invece che in reset, l’igiene del filesystem che mantiene veloci le operazioni sui file man mano che l’applicazione accumula record nel corso dei mesi sul campo e – quando il prodotto lo richiede – la protezione dalla lettura della flash.

  • Materiale avanzato – certificati TLS per le cam che devono autenticarsi presso servizi di rete e cifrarne il traffico.

Una cam spedita ha tutto questo predisposto: il suo codice applicativo viene eseguito dall’immagine firmware, il suo watchdog viene alimentato una volta per iterazione del ciclo principale, il suo log finisce in una directory con data sulla scheda SD e – quando il prodotto lo richiede – la sua flash è stata bloccata contro la lettura.

14.5.1. Dove andare da qui

La produzione è l’ultimo capitolo del tutorial. Da qui la documentazione si dirama in materiale di riferimento:

  • Il riferimento delle librerie è la vista in ordine alfabetico «qual è il nome esatto di questa chiamata» di ogni modulo che la cam espone – machine, logging, os, csi, image, ml e gli altri.

  • Le pagine di riferimento rapido per scheda coprono le specificità di ogni cam della linea di prodotti OpenMV – piedinature, bus montabili, ID delle schede, disponibilità delle periferiche e le piccole differenze che contano quando l’applicazione deve approdare su una parte specifica.

  • Le pagine di riferimento dei sensori e le pagine di riferimento degli shield coprono i singoli sensori di immagine e gli shield aggiuntivi che una cam può montare – le specifiche per parte, le piedinature e le note di cui l’applicazione ha bisogno quando sceglie sensori e shield per una build.

  • Il riferimento del linguaggio MicroPython copre il linguaggio stesso – le differenze di sintassi rispetto a CPython, le specificità di implementazione che contano quando uno script si trova a cavallo dei due e il riferimento dell’assembler inline per il raro caso in cui Python sia troppo lento.

Il tutorial è il percorso da «ho una nuova cam tra le mani» a «ho spedito un prodotto». Da qui la cam è un pezzo di un sistema più ampio di cui l’applicazione è responsabile, e il lavoro è quello dell’applicazione stessa.