Where the SRAM Goes: Reviewing the FreeRTOS-C and Embassy-Rust Memory Comparison
AI Analysis Abstract A 13-page preprint compares FreeRTOS-C/lwIP with Embassy-Rust/smoltcp across eight firmware milestones on a 64 KiB RISC-V microcontroller. Its reported totals suggest substantial SRAM savings, but our PDF review found that the Embassy attribution categories…
AI Analysis
Abstract
A 13-page preprint compares FreeRTOS-C/lwIP with Embassy-Rust/smoltcp across eight firmware milestones on a 64 KiB RISC-V microcontroller. Its reported totals suggest substantial SRAM savings, but our PDF review found that the Embassy attribution categories in Table 7 fail to reconcile with every printed milestone total. Treat the headline results as author-reported measurements pending clarification, not independently reproduced benchmarks.
Key Highlights
- Table 6 reports 63,776 bytes of static RAM for FreeRTOS-C and 14,568 for Embassy-Rust at the MQTT milestone. The resulting 49,208-byte difference is arithmetic on reported totals; we did not rebuild the firmware.
- On page 8, Table 7 lists 9,316 bytes of networking storage, 4,585 of async task state and 3,750 of other static data at M07. These add to 17,651, exceeding the printed 14,568 total by 3,083 bytes.
- The discrepancy is not confined to M07: at M00, the listed categories sum to 717 bytes against a printed total of 556. Our arithmetic check found mismatches in all eight Embassy columns.
Technical Details
- The proposed attribution method restricts ELF symbols to SRAM section address ranges and accounts separately for linker reservations. The intended invariant is that category sums equal section totals; the published Embassy table does not demonstrate that invariant.
- We checked the table visually against the PDF to exclude a text-extraction alignment error. Without the underlying ELF files, scripts and measurement outputs, this review cannot determine whether the categories, totals or table transcription are wrong.
- The build-time comparison uses different rebuild and parallelism arrangements: C uses serial make, while Cargo uses its dependency cache and default parallel jobs. Its warm-build advantage should not be presented as an intrinsic Rust compiler advantage.
Implications
- Editorial assessment: compare complete configured firmware stacks, not C and Rust in isolation. Network-buffer sizing, allocation policy, task architecture and compiler settings all matter.
- Before using these figures for a design decision, obtain the build artifacts and reconcile every category. Runtime stack use, network throughput, latency and actual TLS integration also need measurement.
Limitations
- This is a critical reading and arithmetic audit of arXiv:2610.21064v1, not a replication. The PDF reports one hardware specimen and omits runtime stack high-water marks and execution-performance measurements.
- The PDF describes firmware and tooling as available from the corresponding author on reasonable request. We did not obtain those artifacts. TLS feasibility remains an estimate rather than a demonstrated integration.
- The original PDF remains on arXiv. This article publishes original analysis and source links; it does not reproduce the full paper.
Source: https://arxiv.org/abs/2610.21064