I’m trying to determine what priorities should be used for each task (or whether their priorities need to be even any different)
One task (
task1) would be responsible for feeding stuff to the display driver to show stuff on the display screen every 2 seconds, while the other (
task2) is reading some sensor data as fast as it can. Both the tasks start doing upon a push button being pressed.
- Both the tasks are blocked on a condition set true by the push button ISR
task2 is reading the sensor data constantly but
task1 every 2 seconds, we could set
task1 as a higher priority task since it needs to run exactly every 2 seconds whereas
task2 doesn’t have “set” requirement. So after the 2nd second,
task2 gets a chance to read as much sensor data before the 4th second and so on…
- would task priorities even be meaningful given the interrupts preempt the tasks and if we solely rely on interrupts (i2c for sensor, SPI for display) to preempt the respective tasks? In other words, there’s no chance of task starvation, or could there be?
Priorities are meaningful if there ever could be a case where both tasks are active, and you have a preference for which one finishes first.
Other comments, “Display” tasks tend to not have tight requirements (unless it is actually timing the video signals to the display, then they are very tight) and the eye isn’t that precise in measuring time. You say “exactly 2 seconds”, but you probably are fine it it was 2.1 seconds between two updates.
Task2, is described as “as fast as it can”, which sounds like “high priority” words. Sometimes we say that but don’t actually mean it, but it does imply urgency. While you comment on it not having a set requirement, my guess is that there actually IS some at least qualitative concept of what is needed. My guess is who ever wrote that spec would not be happy with a 3 second lag in reading the sensor data.
Some important questions, does the reading of the sensor have a measurable “gap” time where the sensor task can block for the data to be ready and allow the display task to work during that interval, or are we stuck with a polling loop. If the sensor task can block for much of the sensor read cycle, then it seems making it the higher priority would make sense. If reading the sensor is a CPU hog, then it can’t be a high priority task,
yeah, so sensor reads are interrupt based, and while the task gets blocked till the transaction is completed (when the ISR fires). So you’re saying in this case, it makes sense to make sensor task higher priority since while it’s blocked, the display task continues to run and gets preempted by the sensor task once the ISR fires?
And display task needs to be updating the display every 2 seconds – hard requirement.
Perhaps the “gap” time isn’t big enough given interrupts in the sensor task are firing quite often hence making it higher priority task may not make sense since it’s going to hog the CPU and strave the display task which is supposed to be running every 2 seconds?
Rather make display task of higher priority due to the hard requirement of updating the display every 2 seconds no?
The question is, are you tight on the time needed to get the update done every 2 seconds, the “Hard” requirement or not, and if the display update takes like 1 second to process, is it better to have tighter control of the display, but only 1 second of sensor data every 2 seconds, or do you want the full 2 seconds of sensor data?
Presumably, the sensor has some time limit in it that if you don’t process the data from it within some time limit, the data will get lost (because the buffer is full), so the sensor DOES have its own “Hard” time limit, but perhaps you can afford to lose some data. If this time is longer than the processing time for the display, then maybe you don’t even need an RTOS (or you can use one but don’t need to worry about the requirements as much). If you can’t wait that long, then you need to weight the lose of sensor data to what ever “Risk” it imposes on your one “Hard” Specification.