Zephyr Footprint – Where Are We and Where Are We Going
summary
Claim: replacing indirection-heavy APIs reduces ROM size if the build actually sees single-driver instances. Tools used: west build size reports, a Python script that generates direct calls from enabled driver metadata, and compiler/linker work including LTO and link-time GC. Measured results: tiny wins on some apps (850 bytes ≈ 0.1%, 1,400 bytes ≈ 1.5%), regressions on ZMK, and mixed outcomes where static dispatching plus LTO sometimes reaches double-digit savings on specific builds but often yields only marginal gains.
AI-written summary · about
chapters (11)
- 0:00Zephyr footprint challenges
- 1:10Software footprint importance
- 3:23Measuring footprint tools
- 5:11Techniques to reduce footprint
- 8:48Future footprint reduction
- 11:43Function pointer elimination
- 19:13Real-world footprint testing
- 23:06Link-Time Optimization impact
- 24:56Static dispatch and LTO results
- 27:05Key takeaways and future
- 28:33Q&A
related talks
41mZephyr RTOS: Under 1KB of RAM- 41mZephyr RTOS: Under 1KB of RAM
51mDemystifying Memory: A Practical Tutorial on Managing & Optimizing Memory in Zephyr- 51mDemystifying Memory: A Practical Tutorial on Managing & Optimizing Memory in Zephyr
43mBeyond Static Devicetrees: Implementing Runtime Hardware Dynamism in Ze...
10mLightning Talk: Debugging Edge AI on Zephyr and Lessons Learned
58mOptimization Tips - Mo' Hustle Mo' Problems
55mCode Size Compiler Optimizations and Techniques for Embedded Systems