drivers/lis2dux12: add read_and_decode APIs support

[avisconti]

Add RTIO async and RTIO stream functionalities that enables, among all the other things, the sensor data streaming from FIFO.

RTIO stream supports following triggers:

• SENSOR_TRIG_FIFO_WATERMARK
• SENSOR_TRIG_FIFO_FULL
• SENSOR_TRIG_DATA_READY

Following FIFO parameters has to be defined in device tree to correctly stream sensor data:

• fifo-watermark
• accel-fifo-batch-rate

Currently the driver can decode FIFO content with Accelerometer 16-bit samples.

[ct-lt]

We could store fifo_status[0] (also in rx_data->int_status instead of fifo_status[1]) in .int_status and then use that in the decoder like

static bool lis2dux12_decoder_has_trigger(const uint8_t *buffer, enum sensor_trigger_type trigger)
{
	const struct lis2dux12_fifo_data *data = (struct lis2dux12_fifo_data *)buffer;
	const struct lis2dux12_decoder_header *header = &data->header;

	if (header->is_fifo) {
		switch (trigger) {
		case SENSOR_TRIG_FIFO_WATERMARK:
			return data->int_status & 0x80;
		case SENSOR_TRIG_FIFO_FULL:
			return data->int_status & 0x40;
		default:
			return false;
		}
	}

	return false;
}

[avisconti]

Actually it seems to me a good idea. There are so many things still left to be implemented. I appreciate your help!

[ct-lt]

I'm happy to help as I really appreciate the driver!
The FIFO triggers are easy as we configure and read the correct registers anyway.
The others like (in)activity and tap recognition require some more configuration and registers to be read, so maybe it would also make sense to put the whole trigger topic to a different PR. Then we could replace int_status with a bitfield for the detected triggers or something like that.

[avisconti]

I just pushed a new version. Nevertheless I saw a furter review from your side just now. So, I think there will be another one later on

[ct-lt]

Yeah sorry for the single comments, should've batched them in a review from the beginning. But I'm done for now

[ct-lt]

#define DT_DRV_COMPAT st_lis2dux12 is missing before

[avisconti]

I had forgotten it. Changed, tested and re-pushed

[ct-lt]

Thanks for that driver!
I tested the following on a custom board with an nRF5340 and the LIS2DUX12:

• Streaming and decoding with various sample rates and ranges using samples/sensor/stream_fifo
• Fetch + Get of temperature
• One-shot reads of temperature and three-axis data
• Accelerometer batching (we currently need to enable temperature batching for that due to the underlying ST driver)

[ct-lt]

I'd remove the else branch as it is the same as the return below, but that may just be my personal preference

[avisconti]

Yes, it makes sense. The code would be more compacted

[ct-lt]

I guess these are leftovers from the other driver?

[avisconti]

Ooops, yes. The lsm6dsv16x drivers also support sensor fusion stuff, while this one doesn't.
Thanks again for the rview.

[avisconti]

Thanks for that driver!
I tested the following on a custom board with an nRF5340 and the LIS2DUX12:

Streaming and decoding with various sample rates and ranges using samples/sensor/stream_fifo
Fetch + Get of temperature
One-shot reads of temperature and three-axis data
Accelerometer batching (we currently need to enable temperature batching for that due to the underlying ST driver)

Very good! I appreciate your help. It really motivates me.
I am working at a new commit for this driver which will support 3 types of FIFO content:

 - 0x0 # 1x Accelerometer @12bit and 1x temperature @12bit samples
 - 0x1 # 1x Accelerometer @16bit sample
 - 0x2 # 2x Accelerometer @8bit samples (previous and current)

This will be selectable from a new DT prop: fifo-mode-sel.
Please note that fifo-mode-sel = <1> is matching the FIFO content of this current PR.