3 weeks, 1 day ago.
As the I2C component is not ISR safe, what is best practise for precise sampling?
I've now understood that the I2C and SPI component are not interrupt safe (although they are thread safe)
This raises the question: how would I perform very precise (low jitter) sampling of an I2C sensor?
One option might be to create a minimalist driver using an API below mbed to grab the sample in real time, then dispatch this off to a thread context using mailbox. However I would prefer to use the mbed APIs "if" possible.
Another suggestion was to signal a waiting thread from a Ticker ISR, using either signal-wait or an event queue, and perform the read in the thread context. Furthermore the waiting thread should have higher priority than all the others. However this surely this will result in some sampling jitter as presumably mbed os won't pre-empt a lower priority thread immediately? ( I assume the scheduler at least allows the lower priority thread a full epoc if it is already in the running state)?
Does anybody have any suggestions ?
3 weeks ago.
Another suggestion was to signal a waiting thread from a Ticker ISR, using either signal-wait or an event queue, and perform the read in the thread context. Furthermore the waiting thread should have higher priority than all the others. However this surely this will result in some sampling jitter as presumably mbed os won't pre-empt a lower priority thread immediately
This seems the most natural approach. The thread that dispatches the event queue could be real-time and would preempt any running thread on the return from interrupt context (see conversation here about global queues https://github.com/ARMmbed/mbed-os/pull/4406). Also, regarding the jitter, most sensors I've seen (SPI, I2C, etc.) tolerate jitter as they have to acquire the next sample and shift across / notify the host of data to collect assuming you're not just polling for data managing sample time from the main MCU in which case you might have jitter.
2 weeks, 6 days ago.
Correct me if I am wrong, but isn't it perfectly save to use those functions from an interrupt, as long as only that interrupt is using that specific peripheral?
So lets say, if you have on the (same) I2C peripheral two sensors, one you poll from your main function, the other one from an interrupt, then it is probably a matter of time until it goes wrong. However if you just have one sensor you poll from the interrupt, or two sensors you poll from equal priority interrupts, can it really go wrong?
Edit: In older question/answer I now see that apparently the lock from thread safety blocks usage in an interrupt. However this is only the case then for mbed OS 5. Mbed OS 2 (without RTOS) it should work fine in IRQ context.
To post an answer, please log in.