RFC: sensor decoder associated data

[teburd]

Introduction

The new sensor API seperates the tasks of reading raw data from the device and interpreting (decoding) that data into a common numerical format, with common units, and such. The decoder today is stateless by design, but this leads to some issues when state is useful to avoid large amounts of data passing from the device driver to the decoder.

Problem description

The BME280 driver has a significant number of calibration values that are read once at startup and then used to compensate values. In the current PR looking to make use of read + decode APIs with this device the compensation values are being passed along with the read values to the decoder.

https://github.com/zephyrproject-rtos/zephyr/pull/72395

This requires a relatively large amount of memory (~64 bytes) compared to the actual sensor reading (8 bytes). In the ideal scenario the decoder would have access to the compensation values for that sensor so that it can compensate the readings without having to pass along the compensation parameters.

Proposed change

Provide a pattern for passing along shared static data from the device driver to the decoder instance, in a way that works with user space.

Concerns and Unresolved Questions

What is the best manner of doing this? Or is it even needed if we try a different route.

[teburd]

Sensor WG 05/20/2024

Two ideas came up

• Could pass a pointer in the buffer so the decoder could read it
• Could generate a per device instance API wrapper that knows how to find the static data

Both effectively require a way of exposing shared state potentially with a thread in user space.

[teburd]

A potentially different option might be (and I realized this after the meeting) share only the compensated values. The compensated values are larger, but in this case are still much smaller than the compensation parameters themselves.

E.g. the sensor provides the compensated temperature, pressure, humidity. The decoder takes those and provides fixed point values with appropriate units/scale.

The compensation parameters then remain private to the sensor driver, at the cost of an extra word or two of memory being saved in the "raw" sensor readings, and the raw sensor readings are just not quite as raw as the straight register values from the device in this instance.

[ubieda]

A potentially different option might be (and I realized this after the meeting) share only the compensated values. The compensated values are larger, but in this case are still much smaller than the compensation parameters themselves.

My 2-cents on this: I like better keeping the data-conversion in the decoder as much as practical.

[teburd]

Replaying our discussions we’ve had the decoder would be nice to be stateless so that it can be moved to other computing nodes (phone, etc) for mostly optimal information transfer. If a driver needs compensation parameters as bme280 needed, in my opinion those need to be applied to the values being provided as output.

[ubieda]

If a driver needs compensation parameters as bme280 needed, in my opinion those need to be applied to the values being provided as output.

By this, do you mean having the 'raw' output of sensor_read() compensated with calibration/coefficients? e.g:

A potentially different option might be (and I realized this after the meeting) share only the compensated values. The compensated values are larger, but in this case are still much smaller than the compensation parameters themselves.

My 2-cents on this: I like better keeping the data-conversion in the decoder as much as practical.