Asynchronous sensor API

[nordic-krch]

Is your feature request related to a problem? Please describe.
Currently sensor API is synchronous and thus limited to be called only from thread context. Sensor API has many other limitations. It has been identified (#13718) but it seems that it slowed down and asynchronous API was not mentioned there as the limitation. My use case is more similar to one mentioned here: #13718 (comment)

I have following use case:
Internal, low frequency clock calibration on nRF platform. Calibration is performed or skipped based on temperature measurement. nRF has internal temperature sensor implemented using sensor API. Handling TEMP peripheral is super simple (trigger measurement, get interrupt when done). I need to periodically sample temperature and based on the result trigger calibration. For periodic callbacks i use k_timer (or hw timer peripheral) which callback is called from interrupt context (at least on nRF). I cannot use sensor API there. Need to have dedicated thread or use work queue. Using work queue is simpler and requires less resources but leads to blocking work queue for certain time thus thread seems like safer option. Anyway, it's crazy to use such complex instrumentation for such simple task.

Additionally, enabling internal temperature sensor adds 4.3kB of ROM and 1.3kB of RAM!!! It is a bit biased because test application is simple thus sem, work queue got added but still it does not look good given that simplest driver would probably fit in 100 bytes of code.

It may be that issue is caused by wrongly implementing internal temperature sensor using sensor API but I can think of very similar case with external temperature sensor on i2c where i would hit the same issue.
External sensor temperature measurement would consist of few simple steps that could easily be triggered from any context: write to i2c to trigger asynchronous transfer, in data ready gpio interrupt trigger i2c read, from i2c interrupt report value that was read to the callback. It cannot be done that way because sensor, i2c and spi APIs are synchronous.

Describe the solution you'd like
I would like to have asynchronous sensor API (e.g. something similar to https://github.com/pabigot/zephyr/commits/wip/sensor2 from @pabigot ). For i2c/spi sensors that would also mean extending i2c/spi with asynchronous api (with callback).

[pabigot]

Thanks. That particular branch has an outdated version; the most recent work is on https://github.com/pabigot/zephyr/commits/next/sensple

If there's serious interest in this approach I can clean it up and submit a PR sometime in January.

[nordic-krch]

will take a look. It makes sense to distinguish between simple and complex sensors as it seems that #13718 is targeting something that is more complex.

[mbolivar]

Hi -- @BFrog has a proposal for "RTIO sensor" which we would like to include in Zephyr 2.2

Edit: #17434

Can we treat this issue as something to fold into that existing discussion?

[kartben]

see #57962.