Skip to content
Subaya

STM32 getting started

This is the embedded counterpart to the Quickstart: a full worked example that takes a fresh embedded project to a generated STM32 .ioc (the CubeMX project file) committed to your repo. It uses Subaya’s pin-planning surface (suya arch), which is backed by a headless CubeMX engine in the cloud.

You don’t need CubeMX installed locally — the authoritative validation and code generation run on Subaya’s backend.

1. Create an embedded project

Section titled “1. Create an embedded project”
Terminal window
suya project create --name blinky --workspace <workspace-id> --type embedded
suya repo create --installation <installation-id>   # back it with Git

2. Create a pin-plan

Section titled “2. Create a pin-plan”

A pin-plan captures the MCU/board, pin assignments, peripheral configs, and clock-tree intent. Start it from a dev board (the board contract gives you the LED, button, and virtual-COM-port pins for free) or from a bare MCU part:

Terminal window
# 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

List and inspect plans:

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

3. Assign pins and configure peripherals

Section titled “3. Assign pins and configure peripherals”
Terminal window
# 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. Validate

Section titled “4. Validate”
Terminal window
suya arch validate --plan <plan-id>

This runs a structural validation; the headless CubeMX engine on the backend is the authoritative check.

5. Generate and commit the .ioc

Section titled “5. Generate and commit the .ioc”
Terminal window
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

Without --wait, generate enqueues the run and returns a run id to poll with generate-status. Check status before trusting the result: resolved means the headless CubeMX engine actually ran; unresolved means it did not — the .ioc is your intent, not an engine-validated artifact — and reason says why, most often that no CubeMX image is baked yet for that MCU family.

The .ioc lands in your GitHub repo, ready to open in STM32CubeMX or drive further code generation.

Review the plan

Section titled “Review the plan”

Render the plan into a review document and run it through review like any other design artifact:

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

Next steps

Section titled “Next steps”