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
"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.