Firmware
Trellis Firmware
The Base runs Trellis, a control runtime for microcontrollers that sits between bare-metal C and an RTOS. You describe the machine; Trellis checks it, configures the chip and runs it the same way every time. It will be released as open source under the Apache License 2.0.
Four things at once
Most microcontroller work comes down to doing four things at once: read a sensor, debounce a button, drive a display, talk to a chip. Bare-metal C turns that into interrupt soup. An RTOS answers it with threads, priorities and locks, which is heavy machinery for what is really a multiplexing problem.
Trellis multitasks cooperatively. Your machine is a graph of blocks, walked in the same order every tick. A driver that has to wait for a chip simply waits, on a stack of its own, while the rest of the graph carries on. Nothing preempts anything, and there are no locks, because each part owns what it talks to and nothing is left to contend for.
Each part of the graph runs at the rate you declare, so a 1 kHz loop doesn't make the 1 Hz parts pay for it. Each part declares a time budget too, and a profile that can't fit is refused before it runs, with every budget named, instead of missing deadlines on the bench.
There's no heap. Nothing allocates while a profile runs, so hour thirty looks like hour one.
Fast where it counts
The work Trellis does each tick is fixed when the profile loads, and the scheduler is small enough to read in a sitting. Measured on the Nucleo-G474RE, a demo profile's worst tick is 46.5 µs against a 10 ms period, with no missed ticks.
Heavy signal processing runs off the control tick, on Arm's optimized DSP routines. On the same board, a spectrum that takes 5 ms to compute leaves the control tick unmoved.
Measurements are declared like everything else. A lock-in amplifier is mix, decimate, average; a distortion analyzer is window, transform, harmonics. That's how the B4 and B5 cards are built, and the same declaration works whether the samples come from a fast converter over DMA or one at a time from a sensor.
Profiles are data
You describe what an instrument does in a profile: a YAML file of blocks and the wires between them. Trellis compiles it to a small, sealed binary and checks it, along with the chip's pin setup, before anything runs.
The chip configures itself from the profile. At load, Trellis sets up the pins, their functions and the clocks, reads the registers back to confirm, and only then starts. A profile that doesn't fit the board is refused whole, with an error naming the pin.
Loading a new profile is a serial write, not a reflash, so there's no cross-compiler or vendor IDE in your loop. A profile can also be built into the flashed image, so the board starts it at power-on with no computer attached.
No instruction a profile can run reaches the watchdog or the safety peripherals.
Tested before the hardware
The same C runtime runs a profile on the microcontroller and on your laptop, bit for bit. Tested in simulation means tested.
Where it runs
The runtime is portable C99, and the compiler and tools are Go. Everything that differs between chips lives below one hardware layer, so a profile doesn't change when the chip does.
- Today
- ST's Nucleo-G474RE development board, which carries the same STM32G474 microcontroller as the Base, and your laptop. Support for the Base comes with the first Bases.
- Planned
- Other STM32 parts, from the small G0 to the F4.
- Designed to reach
- Other vendors' microcontrollers, such as the ESP32 and the RP2040, and Linux boards as a supervisory controller.
The sweet spot is a mid-range microcontroller with a floating-point unit, the kind most control products already use. On a tiny 8-bit part, hand-written C is still the right tool.
Trellis will be open source; the schematics of the Base and the cards won't be. Here's what's open.