fd204f31d4
Adds a new sample application that demonstrates using the RTIO subsystem to read periodic sensor data directly into buffers allocated by the application, asynchronously process batches of data with an algorithm, and recycle buffers back for reading additional sensor data. The sensor iodev in this application is an timer-driven device that executes one read request per timer period. It doesn't actually send any transactions to a real I2C/SPI bus or read any real data into the application-provided buffers. This timer-driven behavior mimics how a real sensor periodically triggers a GPIO interrupt when new data is ready. The sensor iodev currently uses an internal message queue to store pending requests from the time they are submitted until the next timer expiration. At least one pending request needs to be stored by the iodev to ensure that it has a buffer available to read data into. However, any more than that should probably be handled by the application, since it's the application that determines how often it can submit new requests and therefore how deep the queue needs to be. The sensor iodev is implemented to support multiple instances with devicetree, but additional work remains to enable and use more than one in the application. Tested on native_posix and frdm_k64f. Signed-off-by: Maureen Helm <maureen.helm@intel.com>
33 lines
525 B
Plaintext
33 lines
525 B
Plaintext
/*
|
|
* Copyright (c) 2022 Intel Corporation
|
|
*
|
|
* SPDX-License-Identifier: Apache-2.0
|
|
*/
|
|
|
|
/ {
|
|
app {
|
|
#address-cells = <1>;
|
|
#size-cells = <0>;
|
|
|
|
vsensor0: sensor@0 {
|
|
compatible = "vnd,sensor";
|
|
reg = <0>;
|
|
label = "SENSOR_0";
|
|
sample-period = <100>;
|
|
sample-size = <16>;
|
|
max-msgs = <8>;
|
|
status = "okay";
|
|
};
|
|
|
|
vsensor1: sensor@1 {
|
|
compatible = "vnd,sensor";
|
|
reg = <1>;
|
|
label = "SENSOR_1";
|
|
sample-period = <120>;
|
|
sample-size = <16>;
|
|
max-msgs = <4>;
|
|
status = "disabled";
|
|
};
|
|
};
|
|
};
|