Hi everyone,

I have uploaded a new iteration of the sensor API patches to Gerrit, you
can find them at [1]. We hope to address some of the concerns regarding
memory consumption of sensor drivers.

For the moment, I have only converted one driver to the new
infrastructure, as I would like to get early feedback on the direction
the API is evolving.

The major change since the previous version is the handling of sensor
triggers. Previously, we operated under the assumption that each driver
that supported interrupts would create its own fiber to which it would
defer bus traffic (since it can't touch I2C or SPI in an ISR).

In this new iteration, the user is given a choice via Kconfig of the
following three approaches:

(1) Driver does not support triggering. No fiber is created.

(2) Driver supports triggering, but uses a system-wide fiber to defer
bus traffic. Multiple drivers can choose this approach, meaning they
only pay the cost of the one fiber.

(3) Driver supports triggering and creates its own fiber for bus
traffic. This ensures the best response time, but uses more memory if
multiple drivers choose to go with this option.

The last patch of the series [2] is an example of how to add support for
cases (2) and (3) if the initial driver only supports triggerless
operation.

There are more drivers available in the sensors topic on Gerrit [3], but
they have not been converted to this newest iteration of the API. If
the response to this RFC is positive, we will convert them to the three
option approach detailed above.

Finally, please be aware that this is still an RFC; at the very least,
the final API will need documentation for standard units for each type
of channel and magnetometer channel types.

[1] https://gerrit.zephyrproject.org/r/487
https://gerrit.zephyrproject.org/r/488
https://gerrit.zephyrproject.org/r/489
https://gerrit.zephyrproject.org/r/490
[2] https://gerrit.zephyrproject.org/r/541

[3] https://gerrit.zephyrproject.org/r/#/q/topic:sensors

Regards,
Vlad

On Thu, 3 Mar 2016, Vlad Dogaru wrote:

Hi everyone,

I have uploaded a new iteration of the sensor API patches to Gerrit, you
can find them at [1]. We hope to address some of the concerns regarding
memory consumption of sensor drivers.

For the moment, I have only converted one driver to the new
infrastructure, as I would like to get early feedback on the direction
the API is evolving.

The major change since the previous version is the handling of sensor
triggers. Previously, we operated under the assumption that each driver
that supported interrupts would create its own fiber to which it would
defer bus traffic (since it can't touch I2C or SPI in an ISR).

As for me, it's a very good aproach for drivers in general. At the very
least, it reduces interrupt latency. Keeping in mind the fact that some
drivers support callback functions, it may be reasonable to off-load
callback functionality to triggered fibers.
Regards,
Dmitriy

In this new iteration, the user is given a choice via Kconfig of the
following three approaches:

(1) Driver does not support triggering. No fiber is created.

(2) Driver supports triggering, but uses a system-wide fiber to defer
bus traffic. Multiple drivers can choose this approach, meaning they
only pay the cost of the one fiber.

(3) Driver supports triggering and creates its own fiber for bus
traffic. This ensures the best response time, but uses more memory if
multiple drivers choose to go with this option.

The last patch of the series [2] is an example of how to add support for
cases (2) and (3) if the initial driver only supports triggerless
operation.

There are more drivers available in the sensors topic on Gerrit [3], but
they have not been converted to this newest iteration of the API. If
the response to this RFC is positive, we will convert them to the three
option approach detailed above.

Finally, please be aware that this is still an RFC; at the very least,
the final API will need documentation for standard units for each type
of channel and magnetometer channel types.

[1] https://gerrit.zephyrproject.org/r/487
https://gerrit.zephyrproject.org/r/488
https://gerrit.zephyrproject.org/r/489
https://gerrit.zephyrproject.org/r/490
[2] https://gerrit.zephyrproject.org/r/541

[3] https://gerrit.zephyrproject.org/r/#/q/topic:sensors

Regards,
Vlad

Hello,

I have uploaded another iteration of the sensor API patches on Gerrit [1].
This addresses some minor issues that have been raised this week and
also ports another driver, the SX9500 SAR proximity.

There is also an API change: previously, there were two functions for
reading a channel. One operated on a sensor_value, in the interest of
avoiding floating point operations, while the other used floating point.
I folded these two functions into a single one and there is now a
SENSOR_TYPE_DOUBLE to indicate that the structure actually contains a
valid floating point value. The sensor_value structure now includes a
union to accomodate this case.

Documentation has also been updated, the most significant change being
that each channel now has a comment specifying the unit of measurement.

At the moment I feel that the API, infrastructure and two drivers are
ready to be merged, unless there are more comments, of course.

If everything is on track, we will start porting the other drivers [2]
to this iteration of the API.

[1]
https://gerrit.zephyrproject.org/r/487 Introduce new sensor API
https://gerrit.zephyrproject.org/r/488 Add infrastructure for sensor drivers
https://gerrit.zephyrproject.org/r/489 sensor: Add driver for MCP9808 temperature sensor
https://gerrit.zephyrproject.org/r/490 samples: Add sample app for MCP9808 sensor
https://gerrit.zephyrproject.org/r/541 sensor: Add threshold trigger support for MCP9808
https://gerrit.zephyrproject.org/r/491 sensor: Add sx9500 SAR proximity driver
https://gerrit.zephyrproject.org/r/492 samples: Add sample app for sx9500 sensor driver

[2] https://gerrit.zephyrproject.org/r/#/q/topic:sensors


Thanks,
Vlad