A Dive into Zephyr Device Driver Model
Talkat Open Source Summit Europe + Embedded Linux Conference Europe 2019 · on Tuesday, 2019-10-29· at 15:15· Forum 6·
summary
Zephyr exposes peripherals via a tiny device-driver model wired into the device tree (DTS) so each device provides an init function, a driver API pointer, optional config data and a priority; the build puts objects into device sections ordered at link time across four init levels, avoiding runtime dependency resolution. Drawbacks include failing boots when a device init fails (current hack hides the API), ROM-placement and per-instance hardcoded macros, and string-based lookups costing RAM — work is underway to generate instances from DTS to fix these.
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
15mIs the Zephyr Device Tree Too Complicated?
46mDevice Tree in Zephyr Project
43mBeyond Static Devicetrees: Implementing Runtime Hardware Dynamism in Ze...
41mZephyr & Linux Devicetree, Similarities and Differences – Practical Guide To Boards, Shields and Con
53mHow to Contribute a Zephyr Sensor Driver
40mHow to extract a bare metal flavor of code out of Zephyr to use in RTOS?