A Dive into Zephyr Device Driver Model
summary
Explains Zephyr's device driver model: a tiny struct device that holds an init function, a driver name string, API pointer and optional config, placed into ordered linker sections to implement four init levels and priorities 0–99 at build time. Shows a watchdog example with a four-function API and current workflow: driver + binding (.yaml) + board DTS. Lists pain points: failed-init hides APIs (breaks ROM placement), per-instance DEVICE_AND_API_INIT macros, runtime string lookups. Proposes auto-generating instances from DTS to remove names, save RAM and speed boot.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 0:35Back in 2015
- 1:32No drivers
- 2:26Dedicated driver model
- 3:46Structure
- 4:34Device Section
- 5:11Array
- 5:28Device Sections
- 6:13Macros
- 7:01Boottime subsystems
- 11:57kernel economics
- 12:43use case
- 13:27create instances
- 14:11device tree
- 16:15device instances
- 17:54other improvements
- 18:32name thingy
- 20:43Any questions
related talks
23mA Dive into Zephyr Device Driver Model
41mFuture of Zephyr Device Model
53mHow to Contribute a Zephyr Sensor Driver
15mIs the Zephyr Device Tree Too Complicated?
46mDevice Tree in Zephyr Project
41mZephyr & Linux Devicetree, Similarities and Differences – Practical Guide To Boards, Shields and Con
43mBeyond Static Devicetrees: Implementing Runtime Hardware Dynamism in Ze...
44mConfigure Zephyr: Kconfigs and Devicetree in Simple Words