What’s planned
Where STM32 Platform stands today, what’s scheduled next, and what it isn’t going to do.
- Title
- Roadmap
- Dwg no.
- Q1-ROA
- Rev
- 2026.1
- Part of
- STM32 Platform
Where it stands
Today the platform builds firmware, flashes real hardware and talks its wire protocol over UART, CAN and USB, using a hand-written HAL with no vendor code running on the target.
A GUI config editor (pinouts, clock trees, CAN buses) and a CANopen stack are already working and being finished off. It’s being built section by section from a written specification. Each numbered section has to pass its own gate, including tests on real boards, before the next one starts, so the list below is in the order the work will happen.
Planned work
What’s being built
Grouped by theme, in the order we plan to do them. There are no dates, and nothing on this page is a delivery commitment. The order can change if a customer gives us a good reason.
-
Next
The kernel, in two sizes
A scheduling kernel in a LITE profile with the profiling core, then a FULL profile on top of that. Data acquisition, the bootloader and the display all sit on these, so they come first.
- Kernel LITE, with the profiling core
- Kernel FULL
- Multi-configuration selection at init, with a safe mode
- Determinism and exhaustion tests for the allocator
-
Next
Protocol, transports and acquisition
First the wire protocol core over UART, then CAN, then the data-acquisition runtime that streams over either one. Each transport is tested on a hardware bench instead of a simulator. The CAN soak test runs two different parts against a host adapter, including bus-off recovery.
- Protocol core and UART transport
- CAN transport, with a hardware bench soak and bus-off recovery
- Data-acquisition runtime: rate groups, slots and snapshot coherency
- Streaming, with a hardware jitter rig measuring it
- Logging and console, and the monitor, ident and param commands
-
Later
Getting firmware onto a board
A bootloader with a flash session state machine, driven from the host tool over UART first and the other transports after that.
- Boot services and the flash session state machine
- The host flash command, over the bootloader route
- A full update cycle run on all three boards
- USB device enumeration checks on hardware
-
In progress
Desktop tools
A configuration app with pinout and clock views, and a live display of what the firmware is streaming. The display works, but it looks dated, so it’s being rebuilt on a single token system with instrument-grade widgets.
- Desktop application shell
- Pinout, clock and peripheral views, with diff and save
- A rebuilt display: one token system, tabular readouts, instrument-grade widgets
- Write support with a danger confirmation, and record and replay
-
In progress
A full CAN protocol layer
More than raw CAN transport: a message database with code generation, a cyclic transmit engine, and a CANopen slave built on top.
- Message database and code generation
- Cyclic and event transmit, receive scatter, filter plan and timeout supervision
- CANopen: network management, heartbeat and emergency objects
- An SDO server with the full abort-code matrix tested
Out of scope
Not on the roadmap
If you need one of these, STM32 Platform isn’t the right product for you.
-
Vendor HAL compatibility
The build has no ST HAL, no ST LL and no CubeMX output. That’s the point of the platform. Code written against the vendor HAL won’t drop in.
-
Every STM32 part
L4 and H7 are supported, and G4 is in progress. The device database is generated from vendor register data, so adding a family is doable, but it takes work.
-
A real-time operating system
The kernel is a scheduler sized for this platform’s profiles. It isn’t trying to be a general-purpose RTOS.
How this is maintained
Every item above is tracked in our own issue tracker, and this page is rewritten from it. Open bugs and security work are left off. Those stay in the tracker until they’re closed.
Want more detail on something here, or to know where it stands? Write to dmoore@
Next
Build on STM32 Platform
Ask about licensing the platform, bringing up a board, or contract firmware work.