Continuous Background I2C process

RE: Continuous Background I2C process

haakonsh — Wed, 01 Mar 2023 17:19:15 GMT

I believe you can't trigger I2C transfers via PPI with zephyr's I2C API, but you can if you use the nrfx driver directly if you set up transfers by calling twim_xfer() with the NRFX_TWIM_FLAG_REPEATED_XFER flag set.

RE: Continuous Background I2C process

mneber — Mon, 27 Feb 2023 15:02:19 GMT

Thank you Haakonsh,

That gives us a good place to start from. Are there any benefit to using PPI to connect the timer to trigger the i2c read? I was thinking no in this case.

RE: Continuous Background I2C process

haakonsh — Tue, 21 Feb 2023 15:02:20 GMT

[quote user="mneber"]The metairq sample uses a resetting z_add_timeout() for the timer. Is this ok to use system timer or do we need to look at a different timer module that can be setup to run in background?[/quote]

I think you might want to use a TIMER peripheral for this application, as the 32.768kHz system timer will have at best 0.0 - 30.51us resolution. Though you can always try it with the system timer, i think you will be able to spot issues if you are aware of they can manifest.

See modules\hal\nordic\nrfx\samples\src\nrfx_timer\timer\README.md

RE: Continuous Background I2C process

haakonsh — Mon, 20 Feb 2023 23:50:59 GMT

[quote user="mneber"]A basic master repeat start sequence is good for us, in our application we write 1 byte to read 6 bytes. Is i2c_read() from i2c.h in the zephyr library sufficient for us? [/quote]

Yes I believe so.

[quote user="mneber"]How do we know when the transfer has completed?[/quote]

i2c_read() is synchronous, it will return 0 if the transfer has completed successfully.

I'll get back to you regarding this question asap.

RE: Continuous Background I2C process

mneber — Mon, 20 Feb 2023 12:54:24 GMT

Hi Haakonsh,

Thank you for your insightful reply. From researching your comments I think the direction we want to go is using a TIMER to trigger transfers. Reading i2c data at a consistent cadence is important.

I like the idea of batch processing samples. Processing the read data is less important. I think we want to run timed i2C reads from the main thread and queue the read data in their own thread for processing? This makes good sense to me.

Thank you for pointing out the metairq sample, we will adapt to use as a tool to measure latency within our processing.

A couple more questions on I2C and timer in Zephyr:

A basic master repeat start sequence is good for us, in our application we write 1 byte to read 6 bytes. Is i2c_read() from i2c.h in the zephyr library sufficient for us?

For processing we want to call k_msgq_put() with the read data shortly after i2c_read(). How do we know when the transfer has completed? When we did this with the nrfx library using nrfx_twim_rx() there is an event handler that flags when the transfer completes. We use this handler to move the data into processing. I don't think I see an event handler in the zephyr i2c.h library. Do we need to register a handler to capture that event somehow?

The metairq sample uses a resetting z_add_timeout() for the timer. Is this ok to use system timer or do we need to look at a different timer module that can be setup to run in background?

Thanks!

RE: Continuous Background I2C process

haakonsh — Wed, 15 Feb 2023 20:11:35 GMT

You might also be interrested in the zephyr\samples\kernel\metairq_dispatch sample, as it can give you valueable insight into the latencies of your sample processing under various system loads.

RE: Continuous Background I2C process

haakonsh — Wed, 15 Feb 2023 19:54:51 GMT

[quote user=""]My question is should we submit work to the system workqueue at a rate of 100/second or is there a better way to do this? Would it be less intrusive to the other parts of the application to create a dedicated workqueue (and thus its own thread) for this process alone? Or would a simple timer trigger be best to avoid the hardware effort of supporting another queue?[/quote]

I depends a bit on your latency requirements for the I2C sensor data, and whether you need to process the sensor samples at the same thread priority as the system workqueue or if you need a higher/lower priority.

Can you process samples in batches or do you need every sample to be processed before the next sample is ready?
If so how long can you wait?

Do you need a driver for the I2C communication or can a basic Master repeated start sequence get the sensor info?
If so, using a TIMER to trigger a TWIM transfer instead of an RTOS timer will probably reduce the scheduling overhead a fair bit, as well as remove lots of time-scale jitter from your data.