Sponsored Session: Does Zephyr Scare the Bare Metal Embedded Developer World?
summary
Zephyr claims to structure complexity rather than hide it and maps bare‑metal idioms to equivalents so familiar patterns still work. Hands‑on evidence: simple LED blink shows GPIO blink parity with little code change, ADC drivers require turning on configs and adding a device tree node so ADC via Kconfig/device tree replaces hand‑rolled register sequences, interrupts normally defer work to threads but support zero‑latency ISR for time‑critical paths, toolchain uses west, Kconfig, device trees and GDB/JTAG/OpenOCD, and practical minimal RAM is around 4 KB practical RAM for simple use cases.
AI-written summary · about
chapters (10)
- 0:00Introduction to Zephyr
- 1:52Bare-metal vs. RTOS evolution
- 13:52The necessity of frameworks
- 16:06Practical code comparisons
- 23:46Interrupt handling concepts
- 29:03Migration and adoption path
- 32:01The role of AI in coding
- 34:54TI and Zephyr summary
- 37:34Developer survey
- 38:12Q&A and closing
related talks
40mHow to extract a bare metal flavor of code out of Zephyr to use in RTOS?
55mZephyr: An Ideal Platform for Introducing Processes of Safety-Critical Embedded Systems
49mThe Zephyr™ Project – An Updated Overview
31mA Zephyr User Story
41mZephyr & Linux Devicetree, Similarities and Differences – Practical Guide To Boards, Shields and Con
10mLightning Talk: Using Zephyr to Power the Sustainable Cloud
30mZephyr ❤️ Internet: How Zephyr Speeds Implementation for New IoT Devices
25mChallenging Hardware Contests With Zephyr and Lessons Learned