Boosting Product Development With the Zephyr RTOS – a Critical Reflection
summary
Concrete outcomes and pain points are front and center: a prototype optical instrument reaches working firmware after four months despite missing hardware by using emulation and modular board definitions, with tooling like West meta tool and native SIM on Linux to build and test, and reliance on over 2,000 device bindings to avoid driver work. Expect a steep learning curve (device tree, Kconfig, CMake presets), occasional driver surprises and memory tuning, but a running prototype and upstream contributions prove the approach viable.
AI-written summary · about
chapters (14)
- 0:00Zephyr RTOS project intro
- 7:30Hardware resilience with Zephyr
- 13:29Developing via simulation
- 16:20Driver development and API
- 17:46Zephyr tools and workflow
- 20:54Success metrics and readiness
- 23:02Reusability and future projects
- 24:19Adoption challenges in companies
- 27:25Version management and dependencies
- 28:02Community contributions
- 29:05Learning curve and expertise
- 30:41Testing with Twister
- 32:11Bluetooth certification support
- 33:01Cost comparison with custom
related talks
31mA Zephyr User Story
40mHow I Fell in Love with Zephyr – a System Architect’s Tale
40mArduino to RTOS - A Pilgrim's Progress
08mKeynote: Zephyr as the Foundation for a Microcontroller SDK
34mPractical Tips to Boost Your Productivity When Using Zephyr
27mInsights on the Re-Architecting to a Single Codebase, Running on Different Hardware...
25mChallenging Hardware Contests With Zephyr and Lessons Learned
43mGoing West: How We Develop and Maintain a Zephyr-based Microcontroller SDK