On Thu, 3 Mar 2016, Vlad Dogaru wrote:
I have uploaded a new iteration of the sensor API patches to Gerrit, you
can find them at . 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.
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  is an example of how to add support for
cases (2) and (3) if the initial driver only supports triggerless
There are more drivers available in the sensors topic on Gerrit , 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.