14.5. Conclusion¶

Vous avez parcouru le cycle de vie d’une caméra passant d’un script d’établi fonctionnel à un produit livré :

Versions de micrologiciel personnalisées – l’environnement de développement, la construction de l’image du micrologiciel à partir des sources, sa programmation sur une caméra, et le parcours de débogage depuis VS Code Cortex-Debug jusqu’à gdbrunner en ligne de commande lorsque quelque chose ne va pas du côté du micrologiciel.
Livraison de l’application – l’intégration du code applicatif dans le micrologiciel via des modules gelés, l’intégration des ressources dans une image ROMFS, et l’ordre de recherche qui détermine quelle copie d’un fichier l’environnement d’exécution charge réellement au démarrage. La répartition qui en découle : boot.py pour la configuration de l’environnement avant le REPL, main.py comme point d’entrée de l’application, le main.py gelé pour le point d’entrée et ROMFS pour tout le reste.
Renforcement pour la production – la bibliothèque logging écrivant dans un chemin connu, un machine.WDT alimenté une fois par itération de la boucle principale, un try / except de haut niveau qui transforme les plantages en événements journalisés au lieu de réinitialisations, une hygiène du système de fichiers qui maintient des opérations rapides à mesure que l’application accumule des enregistrements sur le terrain pendant des mois, et – lorsque le produit l’exige – la protection contre la lecture de la mémoire flash.
Contenu avancé – les certificats TLS pour les caméras qui doivent s’authentifier auprès de services réseau et en chiffrer le trafic.

Une caméra livrée dispose de tout cela : son code applicatif s’exécute depuis l’image du micrologiciel, son chien de garde est alimenté une fois par itération de la boucle principale, son journal atterrit dans un répertoire daté sur la carte SD, et – lorsque le produit l’exige – sa mémoire flash a été verrouillée contre la lecture.

14.5.1. Où aller à partir d’ici¶

La production est le dernier chapitre du tutoriel. À partir d’ici, la documentation se scinde en matériel de référence :

La référence des bibliothèques est la vue alphabétique « quel est le nom exact de cet appel » de chaque module exposé par la caméra – machine, logging, os, csi, image, ml, et le reste.
Les pages de référence rapide par carte couvrent les spécificités de chaque caméra de la gamme de produits OpenMV – brochages, bus montables, identifiants de carte, disponibilité des périphériques et les petites différences qui comptent lorsque l’application doit s’exécuter sur une pièce particulière.
Les pages de référence des capteurs et les pages de référence des shields couvrent les capteurs d’image individuels et les shields additionnels qu’une caméra peut embarquer – les spécifications par pièce, les brochages et les notes dont l’application a besoin lors du choix des capteurs et des shields pour une conception.
La référence du langage MicroPython couvre le langage lui-même – les différences de syntaxe par rapport à CPython, les spécificités d’implémentation qui comptent lorsqu’un script évolue entre les deux, et la référence de l’assembleur inline pour le cas rare où Python est trop lent.

Le tutoriel est le chemin allant de « j’ai une nouvelle caméra en main » à « j’ai livré un produit ». À partir d’ici, la caméra n’est qu’un élément d’un système plus vaste dont l’application est responsable, et le travail relève de l’application elle-même.