Sensor Driver - Synchronous calls to sensor_sample_fetch() and sensor_channel_get()

Lawrence King

Dear All:


I have finally gotten around to writing a driver for the lsm9ds1 sensor. Boy have I learned a lot about the core of the Zephyr kernel and sensor sub-system, and in general I really like it.


As I look through the sensor driver examples, both the drivers, and the sample user land code I see a pattern. Sensors can be used asynchronously (no interrupts) or synchronously (with interrupts indicating when data or other info is available). In this email I will only discuss Synchronous (with interrupts) challenges.


The lsm9ds1 chip has (up to) 4 interrupt pins, two are typically used as data ready interrupts, and two are usually used to signal other conditions (such as buffer overflow, or acceleration exceeding a pre-programmed threshold, i.e. a collision), but they could also be used to indicate data rady. Each one of these 4 pins need to be configured and each one can generate interrupts for multiple reasons. Some of the reasons can be signaled on either of the interrupt and data ready pins, or both. All of the possible configurations are mind boggling. Some configuration information can be described in the device tree (specifically which of the interrupt pins are connected to the processor, as well as which bus the device is attached to). The rest of the config information can be described in the Kconfig. Just to add to the challenge there is also a data enable output from the processor back to the sensor (total 5 gpios in addition to the SPI or I2C bus).



In general when an interrupt comes in from the device the call back in user land calls sensor_sample_fetch() and then may also call sensor_channel_get(). sensor_sample_fetch() transfers the raw data over the interconnect (i2c or spi) to storage in the driver, and then sensor_channel_get() converts the data stored in the driver storage from raw sensor values to engineering units and passes the sensor data back to the user program.


My question is about the need for the user to call sensor_sample_fetch() in the interrupt handler callback.


On one hand I can see that the bus traffic *could* be reduced if the user decides that he doesn’t really need the data at this time (although I didn’t find any sample code where sensor_sample_fetch() was not called in the user callback interrupt handler). On the other hand, in every case I looked at, sensor_sample_fetch() *MUST* be called to clear the interrupt.


It seems to me that if a driver has an interrupt handler, the driver should be responsible for calling sensor_sample_fetch() which then collects the data into driver storage, and more importantly, clears the interrupt. Having the user program responsible for calling sensor_sample_fetch() creates the possibility of the user hanging Zephyr completely (because the interrupt was not cleared), and is a unnecessary level of indirection. [I only know this because I managed to hang Zephyr while I was developing the driver]


Who should I discuss this kernel design decision with? I know how it is currently done, and I can work with this, but is this the right way to do it?



Lawrence King

Principal Developer

Connected Transport Market Unit



1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7


CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.




Join to automatically receive all group messages.