I am working on a system in which several tasks need to complete a full cycle of operation within a few milliseconds. Do I understand correctly that the value of configTICKRATEHZ determines the basic rate at which FreeRTOS will operate in the sense that no OS work will be done in between these ticks? For the sake of example, if I configure the value to 1Hz, will FreeRTOS then perform all its management and then let a scheduled task to run for 1 entire second? If so, then I have a problem, because I will need to set the value fairly high – 10000Hz at the very least – and then both power consumption and CPU usage will be high.

configTICKRATEHZ defines the rate the tick interrupt occurs. The tick count is only incremented in the tick interrupt, and tasks will only unblock because of a timeout when the tick count changes, but that is not the only time the scheduler does anything. Interrupts can unblock tasks at any time in between tick interrupts, so a task that starts running when the tick count increments might only execute for a fraction of a time slice before it gets preempted because of an interrupt (UART for example). What is it you are actually wanting to do? Runs your tasks without them getting preempted? In so just raise their priority. A 10KHz tick will just mean they get less running time as more interrupts are handled.

What I want is to have the firmware (all its tasks, of which there are approximately 10) complete a full cycle of operation within 2 (or 3) milliseconds. For this, I at the very least need to give every task some time to run at least once within that 2ms period. I don’t mind servicing an interrupt. I also assume that the tasks themselves are sufficiently quick. The way I understand your reply, I am right in thinking that tasks will only unblock once the tick count has been incremented. This means that if I have 10 tasks to complete within 2 ms, then I need to set configTICKRATEHZ to 5KHz at the very least, and probably higher. Am I correct?

A task will stop running if: 1) It is preempted by a higher priority task. 2) It blocks to wait for something. 3) It calls taskYIELD() and there is another task that has the same priority that is ready to run. If you task needs to run every 2ms then use xTaskDelayUntil() with a period of 2ms. ~~~~ void mytask() { while(1) { xTaskDelayUntil(); domy_work(); } } ~~~~ Each time it has finished doing its work it will Block allowing other tasks to run until it is time to to its work again. Increasing the tick rate will leave less time for domywork() as it buzzes around with other rapidly executing tasks, each with a tiny time slice at a time. If the tasks need to be synchronized or one can’t start its next cycle until all the other tasks have finished theirs then use xEventGroupSync(). Of course, that assumes it is actually possible for all your tasks to do so much processing within that time. If it is tight then you would be better adding all the work into one task: ~~~~ void mytask() { while(1) { xTaskDelayUntil(); task1work(); task2_work(); etc. } } ~~~~

Running most embedded processor with a tick rate over 5khz leaves little time for most task to run. 1) you have the overhead of the RTOS, 2) interrupt processing time ect. How fast is your processor? How much time is required for each task to run? Will they all run and finish in 100us? 200us. Even with a 200 MHz processor, not a lot of code can run in 100us. So you need to do some real testing ! Most likely if you need speed like this you should consider running from an hardware timer ~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ Sent from my Phone

On Jun 18, 2014, at 11:13 AM, “Dennis B” pptz@users.sf.net wrote: What I want is to have the firmware (all its tasks, of which there are approximately 10) complete a full cycle of operation within 2 (or 3) milliseconds. For this, I at the very least need to give every task some time to run at least once within that 2ms period. I don’t mind servicing an interrupt. I also assume that the tasks themselves are sufficiently quick. The way I understand your reply, I am right in thinking that tasks will only unblock once the tick count has been incremented. This means that if I have 10 tasks to complete within 2 ms, then I need to set configTICKRATEHZ to 5KHz at the very least, and probably higher. Am I correct? configTICKRATEHZ values Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

Thanks, Dave, that’s very helpful.

The way I think about it is that most tasks will be waiting for some sort of event (queue, semaphore, mutex) which will be normally triggered by some other task, or an interrupt. Neither of these will need a tick to occur. If something needs to happen periodically, and there isn’t an interrupt occurring to start it, then that operation will need to be triggered by a tick interrupt, so the tick rate needs to be about a multiple of that rate. If a task wants to wait for an event, but continue on if that event doesn’t happen is some time period, then that continuing needs to be triggered by the tick interrupt, so the tick rate needs to be fast enough to handle the precision of that timeout (which normally isn’t that high). If there are multiple long running tasks that don’t naturally block periodically, then one option is to make them all of the same priority (normally 0), and let the tick interrupt switch between them. (They also could just call yield now and then). I rarely find that this pushes me to a very fast tick interrupt. Often 50-100Hz is more than enough.