Sensor result representation.


Marcus Shawcroft <marcus.shawcroft@...>
 

Hi!

The sensor.h public API provides a mechanism for a sensor drivers to
publish results in one of four different formats:

SENSOR_VALUE_TYPE_INT
SENSOR_VALUE_TYPE_INT_PLUS_MICRO
SENSOR_VALUE_TYPE_Q16_16
SENSOR_VALUE_TYPE_DOUBLE

There is no guidance (that I could find) on which data format a
driver should return for any given sensor channel. This flexibility
in the API has been exploited to a degree, looking at just temperature
sensors in the current tree we have:

dht, bmg160,tmp007,tmp112, hp206chts221dsc1009, bma280, mpu6050,
mcp9808, lis3mdl, sht3xd, bmi160, bme280 all returning temperature
values formatted as INT_PLUS_MICRO.

and

lsm6ds0, lps25hb, th02, lsm9ds0 all returning temperature values
formatted as DOUBLE.

Having different drivers return data for the same channel type in
different formats implies that every application written to consume
such data needs some kind of demuxing code or, more likely, it will
be built to work against a specific flavour of driver... either way
this situation is not ideal.

Is there a reason we have designed in this degree of flexibility?

If not then perhaps for each channel type in sensor.h we should
define the data format returned by all drivers supporting that channel
type?

I raise this issue now while there are relatively few drivers, because
tighting API behaviour now is going to be significantly easier in the
short term than it will be in the medium / long term when we have more
drivers and more divergence in behaviour.

Cheers
/Marcus

Join devel@lists.zephyrproject.org to automatically receive all group messages.