What is planned
Where STM32 Platform stands today, the work that is scheduled next, and the things it is deliberately not going to do.
Where it stands
The platform builds firmware, flashes real hardware and speaks its wire protocol across three transports today, with a hand-written HAL and no vendor code operating on the target.
It is being built section by section against a written specification, and each numbered section has to pass its own gate — including tests on real boards — before the next one starts. That ordering is why the list below is a sequence rather than a wish list.
Planned work
What is being built
Grouped by theme and ordered by intent. These are horizons, not dates — nothing on this page is a delivery commitment, and the order can change when a customer gives us a reason to change it.
-
Next
The kernel, in two sizes
A scheduling kernel in a LITE profile with the profiling core, and then a FULL profile above it. Everything downstream — data acquisition, the bootloader, the display — sits on top of these, which is why they are 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
The wire protocol’s core over UART first, then CAN, then the data-acquisition runtime that streams over either. Each transport is proven on a hardware bench rather than a simulator — a CAN leg soak-tests 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 then the other transports.
- 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
-
Later
Tools a person actually looks at
The desktop side: a configuration surface with pinout and clock views, and a live display for what the firmware is streaming. The display exists and works; the current ticket on it is blunt about the fact that it looks dated, and it is being rebuilt on one token system with instrument-grade widgets rather than restyled.
- 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
-
Later
CAN as a first-class protocol layer
Beyond raw CAN transport: a message database with code generation, a cyclic transmit engine, and a CANopen slave on top of it.
- 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
Said plainly, because the alternative is a sales conversation that ends in disappointment. If one of these is the thing you need, STM32 Platform is not the product for it.
-
Vendor HAL compatibility
There is no ST HAL, no ST LL and no CubeMX output in the build, and that is the product. Code written against the vendor HAL will not drop in.
-
Every STM32 part
L4 and H7 are supported, with G4 in progress. The device database is generated from vendor register data, so adding a family is tractable — but it is work, not a configuration flag.
-
A real-time operating system
The kernel is a scheduler sized for this platform’s profiles. It is not a general-purpose RTOS and does not aim to be.
How this is maintained
Every item above corresponds to work tracked in our own issue tracker, and this page is rewritten from that tracker rather than kept by hand. What is not shown: unfixed defects and security work, which belong in the tracker until they are closed, not on a product page.
Want the detail behind a line on this page, or a view of where something sits? Write to dmoore@dwmmholdings.com and ask.
Next
Build on STM32 Platform
Ask about licensing the platform, a board bring-up, or contract firmware work.