STM32 — Erste Schritte

Dies ist das Embedded-Gegenstück zum Quickstart: ein vollständig durchgearbeitetes Beispiel, das ein frisches Embedded-Projekt zu einer generierten STM32-.ioc (der CubeMX-Projektdatei) führt, die in Ihr Repository committet wird. Es nutzt die Pin-Planungs-Oberfläche von Subaya (suya arch), die von einer Headless-CubeMX-Engine in der Cloud gestützt wird.

Sie müssen CubeMX nicht lokal installiert haben — die maßgebliche Validierung und Code- generierung laufen auf dem Backend von Subaya.

1. Ein Embedded-Projekt erstellen

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

2. Einen Pin-Plan erstellen

Ein Pin-Plan erfasst den MCU/das Board, die Pin-Zuweisungen, die Peripherie- konfigurationen und die Absicht des Taktbaums. Beginnen Sie ihn von einem Dev-Board aus (der Board-Kontrakt liefert Ihnen die Pins für LED, Taster und virtuellen COM-Port kostenlos) oder von einem nackten MCU-Bauteil aus:

# 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

Pläne auflisten und einsehen:

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

3. Pins zuweisen und Peripherie konfigurieren

# 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. Validieren

suya arch validate --plan <plan-id>

Dies führt eine strukturelle Validierung aus; die Headless-CubeMX-Engine auf dem Backend ist die maßgebliche Prüfung.

5. Die .ioc generieren und committen

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

Ohne --wait reiht generate den Lauf ein und liefert eine Run-ID zurück, die du mit generate-status abfragst. Prüfe status, bevor du dem Ergebnis vertraust: resolved heißt, die Headless-CubeMX-Engine ist tatsächlich gelaufen; unresolved heißt, sie ist es nicht — die .ioc ist dann deine Absicht, kein von der Engine validiertes Artefakt — und reason nennt den Grund, meist dass für diese MCU-Familie noch kein CubeMX-Image gebaut ist.

Die .ioc landet in Ihrem GitHub-Repository, bereit, um in STM32CubeMX geöffnet zu werden oder weitere Codegenerierung anzustoßen.

Den Plan prüfen

Rendern Sie den Plan in ein Prüfdokument und durchlaufen Sie damit den Review-Prozess wie mit jedem anderen Design-Artefakt:

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

Nächste Schritte

• Tools & CubeMX — wie Cloud-Toolchains und CubeMX verdrahtet sind.
• CLI: arch — die vollständige suya arch-Referenz.