Introduce a streaming API that uses the same data path as the async API.
This includes features to the decoder:
* Checking if triggers are present
Adding streaming features built ontop of existing triggers:
* Adding 3 operations to be done on a trigger
* include - include the data with the trigger information
* nop - do nothing
* drop - drop the data (flush)
* Add a new sensor_stream() API to mirror sensor_read() but add an
optional handler to be able to cancel the stream.
Signed-off-by: Yuval Peress <peress@google.com>
topic#sensor_stream
Fix a build warning on 64 bit architectures:
zephyr/drivers/sensor/default_rtio_sensor.c:238:17: error: format '%zu'
expects argument of type 'size_t', but argument 2 has type 'uint32_t'
{aka 'unsigned int'}
num_channels type changed to uint32_t in 96175fcc47.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Add padding to the header and remove unnecessary memset in order to fix
alignment faults in cores such as M0 or ones that support
CONFIG_TRAP_UNALIGNED_ACCESS
Signed-off-by: Yuval Peress <peress@google.com>
Update the decoder APIs to vertically decode the raw sensor data. This
means that instead of getting each channel on a frame by frame basis,
the API takes a channel specifier and returns as many frames of that
given channel as there's room.
The goal of this is to make the end decoded result the most useful and
usable for the Zephyr application. See #60944 for details.
Signed-off-by: Yuval Peress <peress@google.com>
The default decoder would take the micro-unit value of the old sensor
value and multiply it by INT32_MAX. This would, at times, cause an
overflow for the int64_t which is the cause of some bugs like when
-7952 was used (-7952000000 * INT32_MAX < INT64_MIN). Instead the new
math converts:
- `value_u * INT32_MAX / ((1 << header->shift) * 1000000)`
to a bitmap:
- `sample.val1` consumes the upper `N` bits
- `sample.val2 * BIT(32 - N) / 1000000` consumes the lower `32-N`
bits
This both improves the accuracy, and avoids the overflow since
`shift` is guaranteed to be between 0 and 31.
Signed-off-by: Yuval Peress <peress@google.com>
Update the sensor shell logic to use the new sensor_read() APIs and
make triggers an option of the sensor_shell sample (this avoids the
trigger stealing the interrupt status from one-shot reads).
Signed-off-by: Yuval Peress <peress@google.com>
Add a new async API based on the RTIO subsystem. This new API allows:
1. Users to create sampling configs (telling the sensor which channels
they want to sample together).
2. Sample data in an asynchronous manner which provides greater control
over the data processing priority.
3. Fully backwards compatible API with no driver changes needed for
functionality (they are needed to improve performance).
4. Helper functions for processing loop.
Signed-off-by: Yuval Peress <peress@google.com>
