Chaînes d'outils cloud et CubeMX

Les outils qui nécessitent normalement une station de travail puissante et un enchevêtrement de licences s’exécutent plutôt sur le backend de Subaya. Vous les pilotez via la CLI et ne payez que pour les secondes de calcul que vous utilisez.

Outils hébergés dans le cloud

Les outils lourds s’exécutent sur le backend de Subaya, pas sur votre ordinateur portable :

• Quartus — synthèse FPGA Intel/Altera.
• RyuSim — le simulateur SystemVerilog de Subaya.
• Renode — émulation de systèmes embarqués.
• BitCrucible — pont de validation matérielle.
• CubeMX headless — le moteur de validation et de génération de code faisant autorité derrière la surface de pin-planning embarqué de Subaya.

Vous n’installez jamais ces outils localement — le backend est l’environnement faisant autorité. Voir Facturation et utilisation pour le fonctionnement du calcul facturé à l’usage.

Pin-planning embarqué avec suya arch

Pour les projets embarqués (p. ex. STM32), Subaya expose une surface de pin-planning adossée au moteur CubeMX headless. Un pin-plan capture le MCU/board, les affectations de pins, les configurations de périphériques et l’intention de l’arbre d’horloge, et génère un fichier de projet CubeMX .ioc.

Pour un exemple complet et détaillé, voir Prise en main STM32.

Créer un pin-plan

Démarrez un plan à partir d’une carte de développement prise en charge (le contrat de carte vous fournit gratuitement les pins de la LED, du bouton et du 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

Listez et inspectez les plans :

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

Définir des pins

Affectez un signal à une pin physique :

suya arch pin set --plan <plan-id> --pin PA5 --signal GPIO_Output --label LED

Configurer les périphériques

Définissez le mode et les paramètres d’un périphérique :

suya arch peripheral configure --plan <plan-id> --peripheral USART2 --mode Asynchronous

Définir l’intention d’horloge

Exprimez l’intention des nœuds de l’arbre d’horloge :

suya arch clock set --plan <plan-id> ...

Supprimer une intention

Chaque affectation a son inverse, pour les cas où une broche change de place ou a été mal saisie :

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

Valider

Exécutez une validation structurelle. Le moteur CubeMX headless sur le backend est la vérification faisant autorité :

suya arch validate --plan <plan-id>

Générer et committer le .ioc

Générez le .ioc à partir du plan, puis committez-le dans le dépôt connecté :

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 arrive dans votre dépôt GitHub, prêt à être ouvert dans STM32CubeMX ou à piloter une génération de code ultérieure.

Étapes suivantes

• Prise en main STM32 — l’exemple complet et détaillé.
• CLI : arch — la référence complète de suya arch.