sensing: implement the phy_3d_sensor

[lixuzha]

sensing: implement the phy_3d_sensor
This patch is to implement the phy_3d_sensor in sensing subsystem. It's a
wrapper layer of AGM sensor driver for sensing subsystem. It supports
the accelerometer and gyrometer now.
This has been tested with lsm6dso and lis2dw12 on hardware and bmi160 on
native_posix simulator. It can work fine while sensor is either in polling
mode or in data ready trigger mode. And set_sensitivity function is just
implemented following api definition and not tested yet.

Tested with:
$ west build -p -b native_posix samples/subsys/sensing/simple/ -t run

drivers: sensor: add helper functions to convert milli/micro to sensor_value

Depends on: #59469

[yperess]

This can/will likely cause a lot of false errors. Since the phy_3d_sensor is instantiated for each type and not once for the actual physical sensor. Imagine you have a standard IMU which provides accel/gyro/die_temp. This means you'll have 2 instances for the phy_3d_sensor and I'm assuming a phy_1d_sensor. If you try to read all 3 separately (in succession), the fetch call will fail on the 2nd and 3rd calls since new data isn't available yet. This is why my original design (referencing #58925) calls for only 1 device node and 3 info nodes to be bound in the example above. The problem is still complicated, but at least all the read requests will funnel into the same device instance so it would be easier (since they share the data/config structs).

[lixuzha]

Thanks for your comments. I use sensor_sample_fetch_chan instead of sensor_sample_fetch now. It can handle this case well.

[lixuzha]

In this case, It'll have 2 instances for the phy_3d_sensor and a phy_1d_sensor. For accel, it will use SENSOR_CHAN_ACCEL_XYZ, and it use SENSOR_CHAN_GYRO_XYZ for gyro and SENSOR_CHAN_DIE_TEMP for die_temp.

[yperess]

Still won't work because the fetch checks the status register, if you don't have a new sample between fetch calls, this will fail.

[lixuzha]

Dose between fetch calls mean between two fetch accel calls or between fetch accel call and fetch gyro call?

• Case 1: between two fetch accel calls
  In this case, the sensing subsystem(polling mode) and data ready trigger function(data ready trigger mode) will make sure that there is a new sample between two fetch accel calls.

• Polling mode:
  The freq of fetch called by Sensing subsystem is always less than sensor working ODR.
• Data ready trigger mode:
  The fetch is triggerd by the data ready trigger function which set by sensor_trigger_set.
  And data ready trigger function only be called by sensor driver while there is a new sample to fetch.

• Case 2: between fetch accel call and fetch gyro call
  In this case, the sensor driver should ensure the fetch accel call should only check and clear drdy_acc bit, and fetch gyro call should also only check and clear drdy_gyro bit. With this guarantee, it can work normally like the case 1.

[yperess]

Dose between fetch calls mean between two fetch accel calls or between fetch accel call and fetch gyro call?

• Case 1: between two fetch accel calls
  In this case, the sensing subsystem(polling mode) and data ready trigger function(data ready trigger mode) will make sure that there is a new sample between two fetch accel calls.

• Polling mode:
  The freq of fetch called by Sensing subsystem is always less than sensor working ODR.
• Data ready trigger mode:
  The fetch is triggerd by the data ready trigger function which set by sensor_trigger_set.
  And data ready trigger function only be called by sensor driver while there is a new sample to fetch.

• Case 2: between fetch accel call and fetch gyro call
  In this case, the sensor driver should ensure the fetch accel call should only check and clear drdy_acc bit, and fetch gyro call should also only check and clear drdy_gyro bit. With this guarantee, it can work normally like the case 1.

I'm talking about case 2, where you need to read accel and gyro. Most devices don't have separate data ready bits let alone registers. These status registers clear when read so when you fetch for the accel request you'll clear the status register and won't have data for the gyro. If you wait for new data for the gyro you'll either:

1. Get data from another frame (which may make the fusion of the 2 not very useful)
2. Have to wait a long time if the sensor requires warming up (some sensors take a long time to collect a sample for one-shot readings).

I didn't want to dive into it, but you can expand this further to the FIFO. Say you have an accel/gyro/die_temp driver that leverages a hardware FIFO. A single reading will contain samples from all 3 sensor types. If you have separate drivers like the current subsystem I'm not sure how you plan on fanning out the data. The accel phy_3d_sensor will get the full FIFO and will need to know about the other drivers. My model uses a single driver and 3 info nodes that are bound. This way the driver is aware of all the capabilities that are enabled and is able to service all 3 sensor types from one reading or the FIFO.

[lixuzha]

For case 2, a lot of sensors (like BMI160, LSM6DSO) support separated data_rdy bits, so their existing sensor device driver can be used directly; for sensors which do not support separated data_rdy bits, the solution is simply add soft data_rdy bit in its sensor device driver implementation.
On FIFO, given today there is no existing Zephyr sensor device driver that supports FIFO, we did not plan to cover FIFO based combo sensor case in this PR. We can provide an example PR based on #60063 to show how phy_3d_sensor wrapper works with FIFO enabled sensor, formal PR will not cover FIFO until #60063 got merged.

[yperess]

Please create and RFC for the proposal to support soft data ready bits per channel. I'm having a hard time seeing how this will scale and will be testable.

While I understand that you did not plan to cover the FIFO based sensor here, could you please explain how this will work. Currently there's a struct device created per sensor type. How will they be linked together?

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[lixuzha]

Basing on design changed, submit #64478 to instead of this one. Closed this one.