A Block Stream API for Zephyr
summary
Zephyr gains a DMA-friendly block-stream interface that claims to let drivers submit lists of buffer operations and get completions via an io_uring–like RTIO context so ISR code can start transfers without forking Zephyr. Proof-of-concept executors target Nordic nRF52 hardware, handle single-producer single-consumer ring semantics, support chained operations across SPI I2C ADC and DMA, and reduce threads. A real device example captures a critical 30 milliseconds capture window from four sensors. Minimal implementations fit in ~400 byte executor and ~1400 byte concurrent executor ROM and run without a Zephyr fork.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:03Zephyr I/O problems in real-time
- 5:18Zephyr forking and the need
- 6:44Block Stream API concept
- 8:10API submissions and completions
- 10:17Ordering and failure handling
- 12:25Chaining operations sequentially
- 14:09Concurrent operations on devices
- 15:32Q&A
- 18:23Solving original problem
- 20:09API mapping to DMA hardware
- 21:12Challenges with Zephyr async APIs
- 22:14Busy peripherals and async mutexes
- 22:56High-level device adoption
- 23:19Feedback and future directions
- 24:31Q&A on completion queue
- 26:23Q&A on ISR submission
- 28:34Code size and examples
- 30:42Async API consistency
- 32:49Closing
related talks
35mMulti-core Application Development with Zephyr RTOS- 35mMulti-core Application Development with Zephyr RTOS
40mReal-Time I/O (RTIO) for Developing Real-Time Zephyr Applications
41mZephyr for Open Source Health Devices
49mThe Zephyr™ Project – An Updated Overview
37mZephyr: A Game Changer for the Automotive Industry
40mGetting Strange New Displays and Sensors Running on Zephyr for Open Health Devi...
05mZephyr