RFC: bus transaction timestamps for sensors

[teburd]

Problem description

When polling sensors we often want to know when the read actually occurs. This isn't possible today with the blocking i2c_transfer/spi_transcieve calls, nor with rtio (though easy to add).

The problem comes when, especially with i2c, you might have sensor code that does the equivalent of:

ts = timestamp()
i2c_transfer(...)

Which looks fine on the surface of course, but does not take into consideration that the i2c bus might be busy doing a very long slow read to some other device. The delay between the timestamp() call and the actual i2c transfer beginning could be very long.

The stashed timestamp of when the sensor thought the read occurred is then potentially skewed in the past by some, potentially large, amount of time.

Proposed change

Provide timestamp information of when transfers actually occur!

For rtio supported devices this could be as simple a timestamp operation being part of the spi/i2c transaction, e.g.

rtio_prep_timestamp(sqe, &timestamp) /// store the timestamp into timestamp

for i2c_transfer/spi_transceive blocking calls the timestamp could perhaps be provided in new API call

i2c_transfer_ts/spi_transceive_ts which take the current array of spi/i2c messages and a reference to a timestamp parameter to store the time at which the transaction actually occurs.

Dependencies

Highlight how the change may affect the rest of the project (new components, modifications in other areas), or other teams/projects.

Concerns and Unresolved Questions

It would be difficult and time consuming to add this to the existing drivers implementing the existing blocking APIs. Adding it to RTIO supported devices would be trivial given the i2c_rtio_context and a potential spi_rtio_context.