#Microcontrollers

PoE32 Lite v3 is a small RISC-V board that takes its data and its power from one Ethernet cable, now with the whole PoE power path on the board. It failed out of the box: why, how it runs with jumper wires, and where v4 goes.

Selecting a firmware stack for a memory-constrained microcontroller is usually guided by aggregate binary sizes, which report how much SRAM a build consumes but not where it goes or why. We address that gap with a per-symbol attribution method that decomposes static RAM into architectural categories — scheduler heap, network buffers and pools, task stacks, and linker-reserved regions — by bounding sized ELF symbols to the .data, .bss and .stack section ranges. The method is validated by reconciling every category sum exactly against the size-based totals for all sixteen builds. We apply it to eight cumulative firmware milestones, from a bare task scaffold to a full MQTT-over-Ethernet client, implemented twice — in FreeRTOS-C and in Embassy-Rust — on the CH32V203RBT6, a RISC-V microcontroller with 64 KB SRAM and an on-chip Ethernet MAC and PHY, with functional parity verified on hardware at every milestone. The decomposition shows that both stacks spend a nearly identical share of their RAM on networking (63.8% versus 63.9%), yet the absolute cost differs by 4.4 times: 40,719 bytes for lwIP against 9,316 bytes for smoltcp. FreeRTOS task stacks grow linearly at roughly 1 KB per task while Embassy async state grows with state-machine complexity. We also report that lwIP could not be integrated under an all-static discipline on this platform, requiring a 20 KB arena that smoltcp does not. The measurement harness, the attribution tool, and the sixteen firmware implementations are released as artefacts.

Editing, building, and flashing had all moved to the terminal; reading serial output was the one job still holding a vendor IDE open. Replacing it took a program already on the machine, plus six decisions the IDE had been making silently.