13.1.14. Dépôts tiers#

L’EDI fournit les propres cartes, micrologiciels, exemples, modèles d’apprentissage automatique et stubs d’éditeur d’OpenMV, mais il peut également charger les mêmes types de contenu provenant d’autres sociétés : une carte construite par un partenaire, le micrologiciel qui s’exécute dessus, des exemples et des modèles adaptés, et la complétion du code pour les API ajoutées par le micrologiciel. Ceux-ci arrivent sous la forme third-party repositories : dossiers de contenu que l’EDI fusionne avec le sien et reste à jour.

Cette page a deux publics. La majeure partie est destinée à la personne qui installe et gère un référentiel publié par quelqu’un d’autre. La dernière section, authoring a repository, est destinée à celle du fournisseur.

13.1.14.1. La page des référentiels tiers#

Tout est géré depuis Édition → Préférences → OpenMV → Dépôts tiers. Le tableau répertorie chaque référentiel installé et, pour chacun, son nom d’affichage, son identifiant court, qu’il s’agisse de Built-in ou User, la version installée de chaque type de contenu qu’il fournit (micrologiciel, exemples, modèles, stubs) et l’URL à partir de laquelle il est mis à jour.

Built-in signifie que le référentiel a été placé dans le propre répertoire de l’application par un programme d’installation fourni par le fournisseur, de la même manière qu’un package de pilotes ajoute des fichiers à un programme. User signifie que vous l’avez installé vous-même à partir d’une URL. La seule différence pratique est que vous ne pouvez pas supprimer un référentiel intégré de l’EDI – il est supprimé en désinstallant tout ce qui l’y a mis – le bouton Supprimer est donc désactivé pour celui-ci.

13.1.14.2. Installer un référentiel#

L’installation à partir de l’URL demande l’adresse du config.json d’un référentiel - le petit fichier manifeste publié par le fournisseur - et installe tout ce vers quoi il pointe. Collez l’URL que le fournisseur vous a fournie ; l’EDI télécharge le manifeste, récupère le micrologiciel, les exemples, les modèles et les stubs qu’il répertorie, et vérifie chaque téléchargement. L’installation, la suppression et la mise à jour d’un référentiel prennent toutes effet après un redémarrage, l’EDI propose donc de redémarrer une fois l’installation terminée.

Un fournisseur peut également distribuer un référentiel en tant qu’installateur qui le dépose directement dans le répertoire de l’application, auquel cas il est simplement présent sous la forme d’une ligne Built-in la première fois que vous ouvrez la page – rien à installer.

13.1.14.3. Garder les référentiels à jour#

Un référentiel contenant une URL de mise à jour est vérifié à chaque lancement de l’EDI. Lorsqu’un contenu plus récent est disponible, l’IDE vous indique quoi (répertoriant chaque référentiel et les versions impliquées) et propose de l’installer, le tout dans une seule invite. La vérification des mises à jour exécute la même vérification à la demande.

13.1.14.4. Priorité et remplacements#

Les référentiels sont une liste ordonnée, la priorité la plus élevée en haut, et Move Up et Move Down réorganisent celui sélectionné. L’ordre n’a d’importance que lorsque deux sources fournissent la chose same : une carte avec le même identifiant USB, ou un exemple, un modèle ou un stub portant le même nom. Lorsque cela se produit, l’entrée la plus élevée l’emporte et chaque référentiel l’emporte sur le contenu intégré d’OpenMV. C’est délibéré : c’est ainsi qu’un fournisseur fournit son propre firmware pour une carte qui partage l’identifiant USB d’une carte OpenMV, en remplaçant le firmware d’origine que l’IDE proposerait autrement, ou en remplaçant un exemple d’origine par un exemple écrit pour son matériel.

Étant donné qu’un remplacement modifie silencieusement l’action d’un nom familier, la page n’en cache jamais un. Le panneau d’avertissements de remplacement répertorie tous les remplacements en vigueur (quel tableau, exemple, modèle ou stub du référentiel remplace lequel) et la même liste apparaît une fois sous forme de message la première fois qu’un référentiel est consulté. Si une carte, un exemple ou un modèle ne se comporte pas comme le décrit la documentation d’OpenMV, ce panneau est le premier endroit à consulter.

13.1.14.5. Ce qu’offre un référentiel#

Les quatre types de contenu apparaissent chacun à leur place habituelle dans l’EDI, donc une fois qu’un référentiel est installé, il n’y a rien de nouveau à apprendre :

  • Boards and firmware. La carte d’un référentiel se comporte exactement comme une carte OpenMV : elle est reconnue lors de la connexion, son type s’affiche dans la barre d’état et ses mises à jour de micrologiciel via l’EDI, y compris le chemin d’installation de la dernière version de développement. Voir Mises à jour et récupération du micrologiciel.

  • Examples. Les exemples d’un référentiel apparaissent dans Fichier → Exemples, fusionnés dans l’arborescence des catégories : un exemple dans une catégorie que le fournisseur a nommée de la même manière qu’une catégorie OpenMV se trouve à côté de celles d’OpenMV, et une nouvelle catégorie devient son propre sous-menu. Ils sont filtrés selon les conseils qu’ils prennent en charge, comme n’importe quel exemple. Voir Scripts, exemples et le dossier de documents.

  • Models. Les modèles d’un référentiel apparaissent dans le Model Zoo, fusionnés dans l’arborescence du navigateur de la même manière, avec les propres descriptions du fournisseur.

  • Stubs. Un référentiel peut expédier .pyi fichiers stub, de sorte que le editor offre la complétion, les signatures et la documentation pour les fonctions ajoutées par son micrologiciel - la même complétion que vous obtenez pour les propres modules d’OpenMV, pour l’API personnalisée d’un fournisseur.

13.1.14.6. Création d’un référentiel#

Un référentiel est un dossier nommé en l’honneur du fournisseur, contenant un manifeste config.json et un sous-dossier pour chaque type de contenu qu’il fournit :

acme/
  config.json
  firmware/
    settings.json                 board descriptions
    ACME_CAM1/                    one folder per board, named by boardFirmwareFolder
      firmware.bin
      romfs0.img
  firmware.version
  examples/
    index.csv                     which examples show for which board / sensor
    01-Getting-Started/           numbered category folders, same as OpenMV's
      hello_acme.py
      read_sensor.py
    02-Acme-Widgets/
      spin_widget.py
  examples.version
  models/
    index.csv                     which models show for which board
    acme/                         a group; its index.html + image describe it
      index.html
      image.jpg
      person_detector/            one folder per model
        person_detector.tflite
        person_detector.txt       class labels
  models.version
  stubs/
    acme_hal.pyi                  a module the firmware adds
    csi.pyi                       overrides OpenMV's to add methods
  stubs.version

Le nom du dossier est l’identifiant du référentiel : lettres minuscules, chiffres, - et _, commençant par une lettre. Chaque dossier de pièces est facultatif ; expédiez uniquement ce que vous avez. À côté de chaque dossier de pièces se trouve un fichier <part>.version contenant une seule chaîne de version (1.2.0) que l’EDI utilise pour décider quand une mise à jour est plus récente.

13.1.14.6.1. Le manifeste#

config.json nomme le référentiel et, pour chaque partie, pointe vers une archive téléchargeable :

{
  "name": "acme",
  "displayName": "Acme Robotics",
  "homepage": "https://acme.example",
  "configUrl": "https://acme.example/openmv/config.json",
  "firmware": {
    "release":     { "version": "1.2.0", "url": "https://acme.example/acme-fw-1.2.0.zip", "sha256": "..." },
    "development": { "version": "dev-20260701", "url": "https://acme.example/acme-fw-dev.zip", "sha256": "..." }
  },
  "examples": { "release": { "version": "1.1.0", "url": "https://acme.example/acme-examples-1.1.0.zip", "sha256": "..." } },
  "models":   { "release": { "version": "1.0.0", "url": "https://acme.example/acme-models-1.0.0.zip", "sha256": "..." } },
  "stubs":    { "release": { "version": "1.0.0", "url": "https://acme.example/acme-stubs-1.0.0.zip", "sha256": "..." } }
}

name doit correspondre au nom du dossier. configUrl est l’adresse à laquelle ce même fichier est hébergé ; l’EDI le récupère pour vérifier les mises à jour, donc omettez-le uniquement pour un référentiel qui ne sera jamais mis à jour. Chaque partie dispose d’un canal release et le micrologiciel peut également avoir un canal development utilisé par l’installation de la dernière version de développement. Les valeurs de la version version sont comparées sous forme de nombres, donc une valeur plus élevée est proposée en tant que mise à jour ; les versions de développement sont comparées uniquement pour les modifications. Le sha256 est facultatif mais est vérifié lorsqu’il est présent.

Chaque url pointe vers un .zip (zip uniquement). Une archive contient exactement one top-level folder, et l’EDI installe le contents de ce dossier en tant que pièce - donc l’archive du micrologiciel est conditionnée comme ceci :

acme-fw-1.2.0.zip
  acme-firmware/           one wrapping folder; its name does not matter
    settings.json
    ACME_CAM1/
      firmware.bin
      romfs0.img

et décompresse dans le dossier firmware/ indiqué précédemment. Les exemples, modèles et archives de stubs sont regroupés de la même manière : un dossier d’emballage contenant ce qui se trouverait à l’intérieur de examples/, models/ ou stubs/. Le nom du dossier d’encapsulage est ignoré ; ce qui compte c’est qu’il y en ait exactement un. Le fait de compresser les fichiers à la racine de l’archive sans dossier d’encapsulage, ou de les envelopper dans plusieurs dossiers, ne sera pas installé. Le moyen le plus simple de bien faire les choses est de compresser le dossier lui-même : sélectionnez acme-firmware et compressez-le, plutôt que de sélectionner son contenu.

13.1.14.6.2. Tableaux, exemples, modèles et talons#

firmware/settings.json utilise le même format de description de carte que le micrologiciel fourni par l’IDE ; ajoutez une entrée boards pour chacun de vos tableaux. Quelques règles sont spécifiques aux cartes tierces : boardFirmwareFolder doit être unique (il n’est pas encore utilisé par OpenMV ou un autre fournisseur, car il nomme le dossier dans lequel se trouvent vos binaires), chaque carte doit porter son propre firmware_version (c’est ce qui pilote l’invite de mise à jour lors de la connexion), et une carte peut définir boardFirmwareFolderAlias sur le nom du dossier du micrologiciel d’une carte OpenMV pour hériter des exemples et des modèles de cette carte - la trappe de secours. pour une carte compatible avec le firmware d’une carte OpenMV. La réutilisation des identifiants du chargeur de démarrage OpenMV est attendue (ils portent les pilotes Windows signés) ; un identifiant d’application qui entre en collision avec un tableau intégré remplace ce tableau, comme le signale le panneau Remplacer les avertissements.

Les exemples sont placés dans des dossiers de catégories numérotés comme ceux d’OpenMV (01-Getting-Started) ; une catégorie que vous nommez de la même manière qu’une catégorie OpenMV s’y entrelace, et un nouveau nom devient sa propre section de menu. Un modèle est un dossier contenant son .tflite et un .txt correspondant d’étiquettes de classe, regroupés sous un dossier dont le index.html (et une image facultative) est la description affichée à côté de lui dans le zoo modèle. examples/index.csv et models/index.csv sont les mêmes fichiers de filtre de carte et de capteur que ceux utilisés par OpenMV, comparés à vos exemples et chemins de modèle, et décidez lequel des vôtres s’affichera pour quelle carte. Les talons sont des fichiers .pyi ordinaires ; l’EDI remet son dossier au serveur de langue afin qu’il soit résolu aux côtés d’OpenMV, et un stub nommé pour un module existant (csi.pyi) remplace l’achèvement de ce module.

13.1.14.6.3. Publication et mise à jour#

Pour publier, hébergez le config.json et les archives auxquelles il fait référence sur des URL stables et donnez aux utilisateurs l’URL config.json à partir de laquelle effectuer l’installation. Partout où des fichiers simples via HTTPS fonctionnent : un serveur Web, un magasin d’objets ou un hôte de code. Pour envoyer une mise à jour, téléchargez de nouvelles archives, modifiez les valeurs version concernées dans le config.json hébergé, et la prochaine fois que l’IDE de chaque utilisateur se lance, il propose la mise à jour. Les utilisateurs qui ont installé le référentiel via un programme d’installation obtiennent les mises à jour de la même manière, à condition que le config.json installé porte un configUrl.

13.1.14.6.4. Hébergement sur GitHub#

GitHub est un hôte pratique, et l’IDE le récupère de la même manière qu’il récupère ses propres ressources. Il y a deux pièces à placer : le manifeste et les archives.

Conservez le config.json dans un référentiel et donnez aux utilisateurs son URL raw : l’adresse à laquelle le fichier est servi directement, et non la page GitHub qui l’affiche. Le bouton Raw sur le fichier l’affiche ; il a la forme

https://raw.githubusercontent.com/<user>/<repo>/<branch>/config.json

Cette URL brute est ce qu’un utilisateur colle dans Installer à partir de l’URL et ce que vous mettez dans le propre configUrl du manifeste afin que l’IDE la récupère pour vérifier les mises à jour. Le pointer sur une branche (main) signifie que pousser un nouveau commit publie le changement ; le pointer vers une balise épingle les utilisateurs vers une version fixe à la place.

Hébergez les archives .zip sous release assets plutôt que de les valider : les versions sont conçues pour les téléchargements binaires, donc un ensemble de micrologiciels de plusieurs mégaoctets y appartient, pas dans l’historique du référentiel. Attachez chaque archive à une version de GitHub et utilisez son URL de téléchargement, qui a la forme

https://github.com/<user>/<repo>/releases/download/<tag>/acme-fw-1.2.0.zip

dans les champs url du manifeste, chacun avec le sha256 de l’archive. Envoyer une mise à jour consiste alors à : attacher les nouvelles archives à une version, modifier config.json pour les pointer et modifier les versions, et valider. L’EDI récupère la modification lors de son prochain lancement (le fichier brut est servi via un cache qui s’actualise quelques minutes après le push).