High Bandwidth Sensors

### Overview At the Zephyr Developer Summit, Yuval Perez discusses modernizing the sensor subsystem within the Zephyr RTOS to support high-bandwidth sensors. The talk details the transition from legacy blocking, driver-owned buffer architectures toward an asynchronous, non-blocking model powered by the rtio subsystem and memory pools (mempool), followed by the introduction of new streaming sensor APIs.

### Key Topics - **Limitations of Legacy Blocking Sensor APIs**: In older APIs, the application initiates a blocking fetch call where bus I/O writes directly to a driver-cached buffer. This blocks the calling thread and risks data inconsistency across multi-channel reads if context switches occur during processing. - **Asynchronous Architecture via rtio and Mempools**: Shifting buffer ownership to the application enables non-blocking bus operations. Utilizing an rtio context with a mempool allows flexible buffer allocation, delayed processing, and eliminates driver cache dependency. - **Stateless Decoders**: Sensor decoders are decoupled from physical device instances and linked to device tree compatible strings. This allows raw byte buffers to be decoded on separate threads, separate cores, or different boards running the same Zephyr version. - **Streaming and Trigger Management**: Expanding beyond one-shot asynchronous reads to streaming APIs (targeted for Zephyr 3.5), handling both hardware events (e.g., tap, motion) and buffered sensor samples (e.g., FIFO watermarks).

### Technical Details - **Configuration & Setup**: Readers are defined statically via devicetree macros using `rtio_i_o_dev` specifying channels. A mempool is configured with submission and completion queues, block count, block size, and alignment for DMA access. - **API Calls & Lifecycle**: Asynchronous reads are queued via `sensor_read()`. A helper function `sensor_processing_with_callback()` blocks on the rtio completion queue event (CQE), copies required data, frees the CQE, calls a user callback, and releases the buffer back to the mempool. - **Data Decoding & Types**: Sensor data is decoded using frame and channel iterators initialized to zero. Decoded values are represented as `q31` fixed-point fractional numbers (spanning -1 to 1) processed using Zephyr's digital signal processing library (`zdsp`). The decoder provides a shift value via `decoder_get_shift()`, guaranteed to be uniform across matching axes within a buffer. - **Streaming Mechanism**: Configured via `sensor_stream_prep` and started using `sensor_stream()`. Triggers (which reside in the buffer header) can be configured to include data in the mempool buffer, drop data, or perform a no-op.

### Takeaways The new asynchronous and streaming sensor frameworks unify the data path across one-shot reads and streaming events. By moving interrupt processing and memory management away from drivers into rtio and application-owned mempools, Zephyr saves RAM, avoids timing unpredictability associated with the system workqueue, and enables efficient DSP processing for high-bandwidth embedded sensors.