From graph to firmware — flowRS tutorial

Older IDE Filmed on the IDE as it was in late August 2026. The editor has changed since, so some screens look different. It shows the August IDE's Deploy level scaffolding a firmware project. The Code view's Embassy and RTIC lowering and the simulated-STM32F4 check described below came after it. The written walkthrough is current.

Lower a graph of embedded nodes to a no_std Embassy or RTIC app, and check the RTIC build against the page's own run on a simulated STM32F4.

Walkthrough

Build the graph from the embedded nodes (GPIO in and out, PWM, delay, the timer, the ADC and an ADC capture, an SPI transfer, I2C read and write, UART read and write), with logic.not between them where you need it. In the page they drive a simulated in-memory board, so the graph runs as you draw it.
To filter what you measure, add the fixed-size frame DSP nodes: samples from bytes, a FIR, a biquad cascade, a moving statistic (mean, RMS, min, max, variance) and decimate. Each works on a frame whose length is known when the program is generated, in f32, in the same order of operations in the page and on the board, so the page shows the board's answer to the bit.
Open the Code view and choose Embassy or RTIC. The same graph is lowered to a no_std application over flowrs-hal's traits, beside a Board trait that names exactly the pins and peripherals it uses; implementing Board over your chip's HAL is the part you write.
A node these targets cannot lower is not skipped. The Code view lists each one under "Refused by the embassy target" (or the rtic target), with its type and the reason, and generates nothing until the whole graph lowers.
Open "Cargo.toml needs" for the crate the app lives in: the executor, cortex-m, cortex-m-rt and flowrs-hal, plus your chip's HAL.
With RTIC selected, press "Run on simulated STM32F4 (PIL)". The server builds the app for an STM32F4, runs it on a simulated one, runs the graph in the page's interpreter with the same inputs, and compares every output pin and the bytes on UART, I2C and SPI. The table shows each pin in both runs and whether they agree.
The Forge level is the other way to an image: it cross-compiles an application body you write against a vetted board skeleton, and checks that body before it builds. Its "Fill from the graph" handles only delays so far.
Where the edge is: no image from either path has been flashed to a physical board by flowRS's own tests. The image comes from a real cross-compiling toolchain, and the check that it behaves is the simulated STM32F4.

What you take away

You can lower a graph to a no_std Embassy or RTIC app, check an RTIC build against the page's run on a simulated STM32F4, and say which parts have not met a physical board yet.