Sensor result representation.


Marcus Shawcroft <marcus.shawcroft@...>
 

On 29 November 2016 at 21:54, Davidoaia, Bogdan M
<bogdan.m.davidoaia(a)intel.com> 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.

Cheers
/Marcus


Marcus Shawcroft <marcus.shawcroft@...>
 

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

On 4 January 2017 at 18:05, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> wrote:
On 29 November 2016 at 21:54, Davidoaia, Bogdan M
<bogdan.m.davidoaia(a)intel.com> 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.

Cheers
/Marcus


Bogdan Davidoaia <bogdan.davidoaia@...>
 

Hi Marcus,

After the first set of patches were merged I didn't start on the single
value representation, partly because I was waiting to see if there would be
any more feedback on the mailing list, and partly because of work related
changes and winter holiday.

Since there was no feedback against the change, I will start working on it
and hope to have the patch ready by next week.

Sorry if the delay on my part caused any inconveniences,
Bogdan

On Wed, Jan 4, 2017 at 8:09 PM, Marcus Shawcroft <marcus.shawcroft(a)gmail.com
wrote:
Re-send with updated email address for Bogdan...

On 4 January 2017 at 18:05, Marcus Shawcroft <marcus.shawcroft(a)gmail.com>
wrote:
On 29 November 2016 at 21:54, Davidoaia, Bogdan M
<bogdan.m.davidoaia(a)intel.com> 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.

Cheers
/Marcus


Marcus Shawcroft <marcus.shawcroft@...>
 

Hi Bodan,

On 5 January 2017 at 09:13, Bogdan Davidoaia <bogdan.davidoaia(a)gmail.com> wrote:
Hi Marcus,

After the first set of patches were merged I didn't start on the single
value representation, partly because I was waiting to see if there would be
any more feedback on the mailing list, and partly because of work related
changes and winter holiday.

Since there was no feedback against the change, I will start working on it
and hope to have the patch ready by next week.

Sorry if the delay on my part caused any inconveniences,
I was just checking that the plan had not changed.

Thanks for the update.

Cheers
/Marcus