Thanks for the answer. The issue with jitter is one of signal integrity - for example, if I want to sample audio (using an external 16 or 24 bit ADC) and perform some signal processing, then it's critical that the sampling interval is as deterministic and jitter free as possible. Therefore, I need to *start* the conversion on precise intervals.

So to clarify with an example: let's say I want to compute the signal spectrum of some incoming audio. I choose to perform double buffering of the samples - populate front buffer with samples; perform FFT on the back buffer; then swap the buffers every time the buffer is full.

This is what I am proposing:

- I use a Ticker to simply signal a waiting thread A on precise intervals (it is the only interrupt I am currently using).

- Thread A has the highest priority and spends most of its time blocked in the WAITING state (waiting for a signal); once unblocked, it obtains the next sample via I2C and adds it into the front buffer;

- Thread B is lower priority and will perform a background FFT on the back buffer (utilising CPU cycles while thread A is blocked in the WAITING state).

- Conceivably, I might run other lower-priority threads that perform background tasks (save to SSD, Serial comms etc..)

I suppose the question comes down to this:

- Are you saying that when the ISR signals thread A, thread A will pre-empt all other threads *immediately*? - If thread B is in the RUNNING state, won't it be given it's full epoch? (and hence the jitter)

I had assumed the context switch would occur only once a full epoch has elapsed (unless a thread explicitly yields).

Many thanks.

Most ADC/DAC devices have a sample period which can be set but assuming the one you have doesn't, there could be small jitter but even this approach should be quite accurate on timing. Here is a snippet of the behavior of the scheduler. http://www.keil.com/pack/doc/cmsis_dev/rtos2/html/theory_of_operation.html#Scheduler

Alternatively you could build a library that samples the ADC and override the lock and unlock functions and take ownership of synchronization or use the asynchronous API for I2C or SPI which aren't synchronized.

Many thanks for taking the time to answer this - it really is appreciated. I'll certainly take a closer look at the docs on the scheduler.

Delegating hard real-time requirements to hardware is probably the way I am going to go in the near-short term (we also have an FPGA to mop-up such tasks and abstract such problems from the MCU) but it's good to know what can be achieved in software.

A nice exercise for my students would be to write an (initially) unprotected I2C driver and, as you say, take ownership of synchronization.

I wonder if there is a case for some additional components without thread locks, for example, I2C_UNSAFE and SPI_UNSAFE ?