Sensor Drivers - Asynchronous 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. 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 Asynchronous challenges.


In general if a sensor is being used without interrupt(s) the user calls sensor_sample_fetch(dev) [or sensor_sample_fetch_chan(dev,chan)] followed by sensor_channel_get(dev, sensor, values). The first call (sensor_sample_fetch) reads the raw sensor data through the physical bus from the device to local storage in the device driver. The second call (sensor_channel_get) takes the stored values in device driver, converts them to engineering units and passed them back to the caller.


This is great for simple sensors, but of course has problems. If the user decides to call the fetch and get in a tight loop it can swamp the bus, or if the user calls the fetch and get faster than the sensor actually updates the values in the registers the user gets the same data over and over. If the user calls fetch and get slower than the sensor is collecting new data, then data will be lost. In reality loosing data usually isn’t a problem, however some sensors may do weird things (like buffer overflow) if the data is not taken away regularly.


None of these problems are earth shattering and are a side effect of the nature of asynchronous data collection from a sensor. It would be nice  (but not critical) if Zephyr had a call to the sensor subsystem where the user can ask the driver if the sensor has new data available (i.e . read the status register). Consider this a low priority feature request.


I suppose I should learn how to formally put this feature request into the Zephyr work queue 😉




Lawrence King

Principal Developer

Connected Transport Market Unit code.



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.