Démarrage avec STM32

Voici l’équivalent embarqué du Démarrage rapide : un exemple détaillé complet qui amène un nouveau projet embarqué jusqu’à un .ioc STM32 généré (le fichier de projet CubeMX) commité dans votre dépôt. Il utilise la surface de planification des broches de Subaya (suya arch), adossée à un moteur CubeMX headless dans le cloud.

Vous n’avez pas besoin d’avoir CubeMX installé localement — la validation faisant autorité et la génération de code s’exécutent sur le backend de Subaya.

1. Créer un projet embarqué

suya project create --name blinky --workspace <workspace-id> --type embedded
suya repo create --installation <installation-id>   # back it with Git

2. Créer un pin-plan

Un pin-plan capture le MCU/la carte, les affectations de broches, les configurations de périphériques et l’intention de l’arbre d’horloge. Démarrez-le à partir d’une carte de développement (le contrat de carte vous fournit gratuitement les broches de LED, de bouton et de port COM virtuel) ou à partir d’un composant MCU nu :

# From a supported dev board
suya arch pin-plan create --board NUCLEO-L433RC-P

# …or from a bare MCU part
suya arch pin-plan create --mcu STM32F407VGTx

Lister et inspecter les plans :

suya arch pin-plan list
suya arch pin-plan show --plan <plan-id>

3. Affecter les broches et configurer les périphériques

# Pin a signal to a physical pin
suya arch pin set --plan <plan-id> --pin PA5 --signal GPIO_Output --label LED

# Configure a peripheral (mode + params)
suya arch peripheral configure --plan <plan-id> --peripheral USART2 --mode Asynchronous

# Express clock-tree intent
suya arch clock set --plan <plan-id> ...

# Every assignment has an inverse — use it when a pin moves or was mistyped
suya arch pin rm         --plan <plan-id> --pin PA5
suya arch peripheral rm  --plan <plan-id> --peripheral USART2
suya arch clock rm       --plan <plan-id> --node SYSCLK
suya arch pin-plan rm    --plan <plan-id>          # delete the whole plan

4. Valider

suya arch validate --plan <plan-id>

Cela exécute une validation structurelle ; le moteur CubeMX headless sur le backend est la vérification faisant autorité.

5. Générer et commiter le .ioc

suya arch generate --plan <plan-id> --wait  # run headless CubeMX, print the resolved .ioc
suya arch generate-status --run <run-id>    # poll a run started without --wait
suya arch ioc commit                        # generate + commit the .ioc to the connected repo

Sans --wait, generate met l’exécution en file et renvoie un identifiant de run à interroger avec generate-status. Vérifiez status avant de vous fier au résultat : resolved signifie que le moteur CubeMX headless a réellement tourné ; unresolved signifie que non — le .ioc est alors votre intention, pas un artefact validé par le moteur — et reason en donne la cause, le plus souvent qu’aucune image CubeMX n’est encore construite pour cette famille de MCU.

Le .ioc atterrit dans votre dépôt GitHub, prêt à être ouvert dans STM32CubeMX ou à piloter une génération de code ultérieure.

Relire le plan

Rendez le plan dans un document de revue et faites-le passer par la revue comme tout autre artefact de conception :

suya arch pin-plan review-doc --plan <plan-id>
suya review create <document-id>

Étapes suivantes

• Outils et CubeMX — comment les chaînes d’outils cloud et CubeMX sont câblées.
• CLI : arch — la référence complète de suya arch.