Add new channel: `SENSOR_CHAN_POS_DXYZ`, so that it is
consistent with other 3-axis channels.
Updated pytest, `sensor_shell` & `fake_sensor` accordingly.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
As new channels are added to the `enum sensor_channel`, some
of the newer channel aren't updated in the whitelist of rtio
decoder.
Instead of specifying every channel in the list, do:
1. Verify that the `channel` is valid
2. cherry-pick the channels that require special handling, i.e.
1. `three_axis_data`
2. `byte_data`
3. `uint64_data`
3. handle the remaining `channel` in the default case as
`q31_data`
to make sure that all channels are handled.
Updated the pytest to get channel 32, previously nothing would
happen for this channel as there isn't a decoder for it, now
it would return:
```
channel type=32((null))
```
the channel name is NULL because it wasn't added to the channel
name look up table in the sensor_shell.c, that is being fixed
in #72815.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Use a structured channel specifier rather than a single enum when
specifying channels to read in the new read/decoder API.
Replaces usages of a seperate channel and channel_index parameter
where previously used with a struct sensor_chan_spec.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
To be consistent with the computed offset on sensor_submit_fallback()
implementation. This prevents falling in misalignment issues when the
number of sensor channels changes.
Signed-off-by: Luis Ubieda <luisf@croxel.com>
Since this loops over all listed sensor channels, this makes more
difficult catching other debug log messages that might be of interest
(e.g: Decoding results).
Signed-off-by: Luis Ubieda <luisf@croxel.com>
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>
