Lessons Learned for reusable firmware
summary
Products require 10 years maintenance so hardware swaps and OS drift force design for reuse; copying 20k LOC and fixing "two dozen" pin sites becomes unmaintainable. Implement a strict hardware abstraction layer (mockable, template + header injection) and a middleware abstraction that injects thread/allocator configs; prefer a template-based base GPIO with tech-type traits, generate board glue from a device tree, use message-board/room patterns and type-erased write ports, and run simulation + unit tests across layers.
AI-written summary · about
chapters (13)
- 0:00Introduction and context
- 1:54Complexity in firmware collaboration
- 5:50Mutation problem and hotfix
- 8:02Benefits and drawbacks of reusable firmware
- 10:49Hardware abstraction layer basics
- 16:58Writing a hardware abstraction layer
- 17:41Middleware abstraction layer
- 21:56Middleware abstraction summary
- 22:39Business logic structure
- 25:26Room pattern for communication
- 30:04Key takeaways for reusable firmware
- 31:28Recommended resources
- 32:32Q&A
related talks
44mReflections around SW obsolescence
25mLeveling up hardware production with Rust
01h 00mDealing with Embedded Limitations
39mLessons we’ve learned after starting to work exclusively on IoT projects
55mThe Process of Shipping Hardware Products: Hardware Tales for Software Engineers
31mEmbracing FOSS in Embedded Development: From Proprietary to Modular and Collaborative
57mKeynote: The Demarcation of the Edge of Innovation
38mWriting Code That Lasts Forever