drivers: sensor: st: lis2du12: add SENSOR_TRIG_DELTA support

[kabeljan]

This PR extends the LIS2DU12 accelerometer driver with support for SENSOR_TRIG_DELTA.
The trigger detects changes based on the slope between successive channel readings.

This patch also adds support for configuring:

• SENSOR_ATTR_SLOPE_TH (threshold, in SI units m/s²)

• SENSOR_ATTR_SLOPE_DUR (duration, in samples relative to the ODR)

The new trigger can be routed either to the same GPIO used for the data-ready interrupt or to a dedicated interrupt line.

The changes were tested using a nucleo_l433rc_p connected to the LIS2DU12 via I²C and confirmed to work reliably.

[kabeljan]

Fixed SonarQube's "discards 'const' qualifiers" warnings.

[avisconti]

It seems not bad. Please look at my notes. The only doubt I have is that we will need sooner or later to migrate to new read and decode APIs, which means also a different way to handle triggers.

[avisconti]

Why it defaults to 2? Because you want to keep drdy on int1 and interrupts on int2?

[kabeljan]

@avisconti That is influenced by the LIS2DH sensor. Per default, INT1 is used there for data-ready and INT2 for motion interrupts, so I chose these defaults here as well, even if one could use only one line for both interrupts here.
Maybe choosing a default of 1 would be a little bit more robust here, because this will work with one or two interrupt lines connected (if we assume a user would connect INT1 at first)?
If you want, I could change It to 1 as default, but personally I see no real advantage for this one or another.

[avisconti]

No no, your choice is fine. I was thinking to add more of such details in the description itself

[kabeljan]

@avisconti :D ok, now I get you. I will add the additional information that one could use both interrupts together on one line.

[kabeljan]

@avisconti I have added the additional explanations.

[avisconti]

Maybe we want to add wakeup threshold and duration also here, to configure it at compile time. What do you think?

[kabeljan]

@avisconti I have thought about that as well, but my conclusion was that the sensor API has attributes for these values and assumes that they are set through the API because the documentation of sensor_trigger_type states:

SENSOR_TRIG_DELTA:
Trigger fires when the selected channel varies significantly.
This includes any-motion detection when the channel is acceleration or gyro. If detection is based on slope between successive channel readings, the slope threshold is configured via the SENSOR_ATTR_SLOPE_TH and SENSOR_ATTR_SLOPE_DUR attributes.

And with that in mind, my conclusion was that I don't wanted to introduce settings with "no effect" to the device-tree, only that a user could get those from there manually to pass it to the sensor_attr_set() function.

[avisconti]

oooook (with still some thinking :) )

[kabeljan]

@avisconti Thank you for your quick response, I really appreciate it!

Don't know if I get you wrong, but you wrote:

The only doubt I have is that we will need sooner or later to migrate to new read and decode APIs, which means also a different way to handle triggers.

But wouldn't this have an effect on the most of the sensor drivers and is more of a general problem of deprecation of API (here the fetch and get API)? I think this extension could help someone (at least me/us) as long as the fetch and get API is valid. Everything else has to be tackled by future PRs, after the fetch and get API is deprecated.

[avisconti]

@avisconti Thank you for your quick response, I really appreciate it!

Don't know if I get you wrong, but you wrote:

The only doubt I have is that we will need sooner or later to migrate to new read and decode APIs, which means also a different way to handle triggers.

But wouldn't this have an effect on the most of the sensor drivers and is more of a general problem of deprecation of API (here the fetch and get API)? I think this extension could help someone (at least me/us) as long as the fetch and get API is valid. Everything else has to be tackled by future PRs, after the fetch and get API is deprecated.

Yes, that is also correct. I think that I was confused by the fact that it is not possible to submit NEW drivers using fetch_and_get APIs, but I guess it would be OK to maintain drivers even based on old solution. I'm not sure if I have been clear enough, but I would ask @teburd to comment on it.

[kabeljan]

@avisconti and maybe @teburd

... it is not possible to submit NEW drivers using fetch_and_get APIs ...

I have read https://docs.zephyrproject.org/latest/hardware/peripherals/sensor/index.html#implementing-sensor-drivers before and there was no hint that it is not possible to add new drivers with fetch and get API. Maybe there should be a note or at least a hint if the information is documented somewhere else.

I cross the fingers that maintenance of existing drivers is still allowed 🤞😅

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[avisconti]

@avisconti and maybe @teburd

... it is not possible to submit NEW drivers using fetch_and_get APIs ...

I have read https://docs.zephyrproject.org/latest/hardware/peripherals/sensor/index.html#implementing-sensor-drivers before and there was no hint that it is not possible to add new drivers with fetch and get API. Maybe there should be a note or at least a hint if the information is documented somewhere else.

I cross the fingers that maintenance of existing drivers is still allowed 🤞😅

Tomorrow I'll take a look again to your new push.