Re: Sensor result representation.

Marcus Shawcroft <marcus.shawcroft@...>

Re-send with updated email address for Bogdan...

On 4 January 2017 at 18:05, Marcus Shawcroft <marcus.shawcroft(a)> wrote:
On 29 November 2016 at 21:54, Davidoaia, Bogdan M
<bogdan.m.davidoaia(a)> wrote:

Hi Bodan,

If we want to define specific value types for each channel type, then we might as well have the same type for all the channels. As you also pointed out, using double is not really necessary for most drivers and the ones that need it can just return the values converted to _INT_PLUS_MICRO.

As such, we could eliminate the type field altogether and have the implicit type _INT_PLUS_MICRO (although this should be done as a separate step, as it will affect the apps that use the type field).

If you think this is ok and nobody has an objection to this change, then I can start working on it next Wednesday as I am currently away with only access to email from time to time.
Following up on this old thread. Looking in the current tree we have
no drivers using SENSOR_VALUE_TYPE_DOUBLE, the sensor.h API does still
define SENSOR_VALUE_TYPE_DOUBLE and the type field used to distinguish
the last two remaining value types.

Is the intention that we continue along the path of moving to a single
value representation?

If so, are you intending to present further patches, if not, then I am
happy to post patches to continue this work.


Join to automatically receive all group messages.