6.0Evidence matrixrev 2026.08

Every capability on this page carries the product it shipped in.

No self-assessed ratings and no logo wall of technologies I have read about. Each row names where the work went into a product and what it had to survive. Where something is specified but not yet shipped, the row says so.

Legend
shipped to production
built, not yet in the field
Products referenced
smart bed · smart chair · cooking robot · cooktop · chai maker · mobile robots
Languages
C (primary) · C++ · Python · Bash
Tools
oscilloscope · logic analyser · CAN analyser · SWD/JTAG · Git
6.1Capability register — condensedone row per block

Depth reported as data, not as a rating. Each row carries the products it shipped in — filled squares count products, out of the six I have worked on. The detail behind every row — what it had to survive, and where it is still specified rather than shipped — is in 6.2 to 6.6 below.

Block
Part / stack
Products
Silicon
STM32H757 dual-core (M7 + M4, AMP)
2
STM32H723 · STM32L476 · ATtiny402
3
ESP32-WROOM-32D · ESP-IDF
2
RTOS
FreeRTOS · CMSIS-RTOS v2
5
Boot
Bare-metal bootloader · A/B slots
1
Transport
CAN-FD · UART · SPI · I²C · USB CDC-ACM
5
Host
Embedded Linux · Raspberry Pi · ZeroMQ
3
Update
Secure OTA · AES-256-GCM · ECDSA
3
Production
Test tooling · provisioning · release automation
3
Table 6.1 — capability register. Filled squares count products out of six; the detail is in 6.2 to 6.6.
6.2Silicon & boards
Capability
St
Shipped in
What it had to survive
STM32H757 dual-core, AMP
Smart bed (5 boards) · smart chair, iteration 1
Two kernels on one die, separate clocks and power domains, one shared memory window, and a launch date
STM32L476 · STM32H723
Cooking robot · chai maker · smart chair, iteration 2
Six hardware variants across two product lines running one binary; real-time control alongside on-device inference
ESP32-WROOM-32D · ESP-IDF
Induction cooktop, 500+ units · smart chair connectivity
Consumer kitchens, customer Wi-Fi, field OTA and a touchscreen UI on the same chip as the control loop
Custom sensor board, ATtiny402
Chai maker — capacitive liquid priming detection
Designed from scratch as internal IP: sensing principle, firmware and calibration, on a part with almost no memory
Board bring-up from schematic
Every product listed
First power-on, clock and pin verification, drivers written from the datasheet where no library existed, and hardware bugs found with a scope rather than argued about
6.3Firmware architecture
Capability
St
Shipped in
What it had to survive
FreeRTOS / CMSIS-RTOS v2
5 products
Manager-per-subsystem task design, priorities set against measured deadlines, and independent kernels per core on the dual-core parts
Cross-core state discipline
Smart bed — became the platform-wide rule
Hardware semaphores, explicit cache maintenance and memory barriers; eliminated a class of intermittent corruption a debugger could not see
DMA-driven acquisition pipelines
Smart bed — 10,756 sensors per frame
3.4 s → 250 ms on fixed hardware: concurrent buses, cycle-counter timing, and skipping rows that carry no data
Closed-loop motor control
Smart bed (46 actuators) · smart chair · mobile robots
Position control with time-of-flight and encoder feedback, stall detection, per-class safety cutoffs, PID tuning that had to hold with a person on top
Self-configuring board identity
Smart bed (4 boards) · cooking robot and chai maker (6 variants)
One image to build, sign, test and flash — a factory line that cannot pick the wrong firmware because only one exists
On-device inference (TinyML)
Smart chair — in development
Posture classification on the control MCU, sharing a die with the real-time loop instead of waiting on a network
6.4Transport & host layer
Capability
St
Shipped in
What it had to survive
CAN-FD · UART · SPI · I²C · USB CDC
5 products
Custom framed protocols with integrity checking; detection of transmits that silently never left the peripheral
Embedded Linux daemons in C
Smart bed · cooking robot · chai maker
Multi-threaded services that re-sync a corrupted stream instead of dying, and hold state for hardware that can fail mid-operation
ZeroMQ bus & step orchestration
Smart bed · cooking robot · chai maker
Request/response over an async bus so a command is confirmed before the next step runs; one universal engine driving thousands of recipes, with parallel steps, abort at any point, and hot surfaces that must be made safe on failure
Secure app & cloud gateways
Smart bed · cooktop (500+ units)
TLS WebSocket bridging to the internal bus, multiple clients at once, and a fleet on customer networks
6.5Boot, update & security
Capability
St
Shipped in
What it had to survive
Bare-metal bootloader
Smart bed — one bootloader, five boards
Slot arbitration that must never leave a board unbootable, plus dual-core boot control and a quiesce handshake before any erase
A/B slots with rollback
Smart bed — 5 boards, staged rollout
Power loss mid-write in a customer’s bedroom; verification in memory and again after writing; no board asked to overwrite the slot it runs from
Signed, encrypted images
Smart bed · cooktop fleet OTA
Authenticated encryption and signature verification on an MCU, before anything is written to flash
Boot forensics & telemetry
Smart bed
Reset-cause capture on every boot, shared-memory logging across both cores, and resource reporting — so field failures arrive with evidence attached
6.6Production & team
Capability
St
Shipped in
What it had to survive
End-of-line test tooling
Cooktop — standard tool for a full manufacturing run
Operated by assembly staff who are not engineers: plain-language steps, pass or fail decided from live device data, serial and calibration written in the same pass
Release engineering
Smart bed
Every image built by script and stamped from git; a gate that refuses to release a dirty tree, an untagged commit or a debug build
Technical leadership
30+ engineer programme · 6-person team
Interface contracts across mechanical, electronics and app teams; three juniors mentored on a live product; a review gate so nothing reached production unreviewed
6.9The pattern underneath

Three unrelated codebases — a cooking robot, a bed and a chair, on three different silicon families — now share the same framed wire protocol with integrity checking, the same motor-driver integration discipline, the same rules for what may cross a core boundary, and the same manager-per-subsystem structure. That is deliberate. It is the part of my work a client actually buys: not knowledge of a part number, but a structure that has already survived production three times.

Book a call →See it applied — P-01