I am unsure about the proper design of a high frequency task that needs to run at a certain frequency. I could just set that task at highest priority however this would just create time jitter from all context switching I believe? Is there any way to have a task run with time slicing other tasks regardless of priority (essentially is always the same priority as the current executing task). I dont know much about coroutines for example but they sound like something that may be a used in this application?

Don’t recommend doing this with co-routines as that would more likely add jitter (plus they are deprecated). It is not clear to me what you are wanting to do as time slicing with tasks of equal priority would seem to increase jitter rather than decrease it as the other tasks may run first (may get a time slice before the task you want to run without jitter). It also depends on the frequency you want to achieve. If it is very high frequency then you can trigger that task from a peripheral timer interrupt. If the frequency is a multiple of the tick frequency then you could add code into the tick interrupt using a tick hook function – but that would mean the code could not do anything that cannot be done from an interrupt.

As has been said, if what it does could be done in an ISR, then that might be the best option. Note, that if the task is the highest priority task in the system (and the only task of that priority), and is activated by a timer interrupt (eather the system tick or some other timer), there is very little jitter in activating it, as the sequence of instructions to context switch is very consistant. There is some lag from the interrupt, so if the rate is very high, it might make sense to be in an ISR if possible to reduce that overhead, but generally the overhead should be fairly constant.

Thanks, for the responses.

It is not clear to me what you are wanting to do as time slicing with tasks of equal priority would seem to increase jitter rather than decrease it as the other tasks may run first (may get a time slice before the task you want to run without jitter).

Sorry, I should have included this in the beginning. so three things ADCISRComplete: ISR callback for ADC complete SignalProcessingTask: High priority. Task to read and process data from ADC ControlTask: High priority. yields until SignalProcessingTask is done to read processed value and execute control loop. I am worried that putting this all in the ISR will have it run too long and as I know, I shouldnt have a long running ISR. So my solution was to do what you see below. However my other worry was doing this would cause too much jitter of the lower priority tasks. However if time slicing it would cause more jitter, would not the frequent context switching from mid level priorities to these two high priority tasks at the very least cause a performance hit from the context switching overheads? ~~~ ADCISRComplete { //trigger SignalProcessingTask //trigger ControlTask } SignalProcessingTask{ //read ADC value //do some potentially long running signal processing on the value //trigger } ControlTask{ //do some preparation //yield until signal processing task is done //read processed signal value //process control loop. } ~~~

First, if you are worrying about jitter in your lower priority tasks, you may have your priorities messes up. Typically if I have a jitter spec, that output is high priority. There may be a low priority task behind it if I have a lot of time to compute, but just need tight jitter. There then is a high prioriry (or ISR) task that gets trigger when I am scheduled to send the response with low jitter, and it does it. If it is always ISR => SP Task => Control Task, then one question is could not they be the same task. It is a bit of an Anti-Pattern to have one task do half the work and pass it on to a second task, especially if both are Compute limited. If the signal processing task needs to do some I/O that will need additional blocking, then perhaps this might make sense (like an I2C ADC that has signalled data available) If you are worried about jitter in the control loop, then as I stated above, the process control loop should be blocking on a timing signal just before outputing the results, that will remove the jitter (to reduce jitter you need to increase average response time)