Using SoC Vendor HALs in the Zephyr Project
summary
Zephyr reuses SoC vendor HALs to avoid rewriting peripheral register maps and bare‑metal drivers, leveraging MCUxpresso SDK artifacts (database‑generated CMSIS‑compatible headers, docs and examples) and vendor QA-tested drivers across NXP, ST, Nordic and Intel. Three reuse patterns are used: transactional/stateless/register-only drivers, with transactional drivers giving the most reuse. Imported code lives in the xed folder and follows a formal TSC→Governing Board import process (two‑week review); tradeoffs include API mismatches, occasional license decisions and upstream bug‑fix coordination.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 0:43Zephyr Project Overview
- 1:36Zephyr Ecosystem
- 3:16Why Vendor HALs
- 6:19Tradeoffs
- 8:12Vendor HALs
- 8:55Types of HAL abstraction
- 10:51Simpson FRS
- 16:25Xed Folder
- 17:59Importing Code
- 19:07Documentation
- 19:38FAQ
- 22:39Summary
- 23:15Questions
related talks
42mEnabling Zephyr on Your Hardware Platform
42mEnabling Zephyr on Your Hardware Platform
47mSponsored Session: Does Zephyr Scare the Bare Metal Embedded Developer World?
33mZephyr Support for Heterogeneous SoCs
40mHow to extract a bare metal flavor of code out of Zephyr to use in RTOS?
43mZephyr for Open Source Health Devices
08mKeynote: Zephyr as the Foundation for a Microcontroller SDK
30mSoC Development: From ROM to Application