We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all,
I have a problem in switching my tasks.
As I thought, every task has 37ms to work before it gets interrupted by the task-scheduler, who then activates the task with the highest priority or, if prioritys are all equal, the task which waits the longest time. I am running 57 tasks. One of them should not have any breaks longer then 23ms. But how to do. If I work with an endless loop. The task gets interrupted and several other tasks are executed. So the break will be much longer then 29ms. Then I increased the priority of that task and only that task worked, no other. To get other tasks working, I had to build in a 63ms 'task_wait'. But then, in spite of the high priority of that task, the break was as long as it was with the endless loop and the same priority like the other tasks. I thought, I would leave the task with 'task_wait', an other task is executed and after 31ms(task_wait) the first task will be executed again because of its high prioriy. But that does not seem to be so.
Any solutions for my problem?
Thanks for all replies
Susi
You have 57 tasks. Don't you think that is quite a lot of tasks for an embedded system?
What kind of work requires a pause of max 23ms? Is it buffering of input data or making a decision based on data received from an interrupt?
Can you move part of your critical task to be done by the interrupt handler that now supplies it with it's decision data?
You really should not have a "worker" thread that both need high priority and have enough work to run constantly since that means that you can't give it a higher priority without loosing 100% CPU capacity to that thread. A high-priority thread should be written so that it only wakes up on a trigger event, and then quickly performs it's work and goes to sleep again. That allows the remaining time to be distributed to lower-priority tasks.
Hi Per,
Thank you for your reply.
I do need a pause of 23ms because I need to make a reliable pulse of 52Hz.
I will need more tasks later on, but they will be dynamically created and destroyed.
Don't use a task to generate a 52Hz signal - use the hardware in the processor. This is trivial to do in a timer interrupt. How else will you be able to keep down temporal jitter?
I think I understand.
But what do you mean by temporal jitter?
It sounds like something from a Star Trek episode?
Have I got to be careful not to break the temporal directive?
"I do need a pause of 23ms because I need to make a reliable pulse of 52Hz."
23ms would give a frequency of (about) 43Hz.
Surely you need a pause of (about) 19.23ms to give a frequency of (about) 52Hz.
Or am I being silly?
Temporal jitter is when the pulse flanks comes at random time.
Using a task to generate a square wave means that every delay will vary depending on what other tasks that are busy. This jitter may be very high. If the tread has max priority, the jitter is at least one task switch. But something must inform the OS to perform the task switch. If that is a delay, the OS will not guarantee that it performs the task switch immediately. If the OS is informed to task switch based on an interrupt, then it is quite stupid to require a task switch to toggle a signal, instead of letting the interrupt handler do it.
Controlling the pulse from an interrupt will greatly decrease the jitter, since the interrupt response is only affected by other interrupts or by interrupts being disabled in critical sections.
Controlling the pulse from a comparator function directly controlled by a timer means that there will be no jitter at all. The CPU will be able to toggle the signal without checking what state the software is in.