I have three tasks to flash Red, Green and Blue LEDs on the board. The objective is to get the colours to blink periodically (all flashing at the same period) but out of phase so that no two colours are on at the same time.
I am trying to do this using a task for each LED colour, with task priorities 3 for red, 2 for green and 1 for blue. The tasks use vTaskDelayUntil() to synchronize their operations, i.e., while one LED is on, the other LEDs are off and delaying (presumably in blocked states).
However, I am having the problem that the highest priority task (Red LED Task) does not seem to enter the blocked state. Only the Red LED flashes. Using the debugger (and setting breakpoints within each task’s while (1) loop), I notice that the the lower priority tasks have the opportunity to run only once! After that, the highest priority task never yields (the scheduler stays in the Red task’s loop, even while executing the vTaskDelayUntil() API function).
And I attach the code and my FreeRTOSConfig.h file.
Not looked at code in detail yet, but have you checked the value of
delayTicks inside the functions?
Start with one task only, and a long delay time to make it obvious when
the LED is toggling. With just a single task, if the LED does not seem
to be toggle at the frequency you think, set a break point in that task
and check the values are as you expect. Once you have that one task
working as expected you can add in the others.
The problem may be that you are creating the structures you pass on the main stack. The main stack is reused in some ports for the interrupt stack, so its contents might not be preserved. Make those structures globals instead of function locals in main to see if that makes things work.
Thanks for this point. I think it is spot on! I could not understand why the parameters were not being passed into the task functions. I wrote the code in this way to illustrate to my students that it is possible to pass in fairly complex data structures using type casting of void pointers within the task function.
A mutex is a very heavy object to use here, a simple and fast
critical section is all that is needed.
You are holding the mutex across the vTaskDelay() call - that should
not be necessary especially if toggling will interleave with other tasks
in which case you will serialise access by holding the mutex that long.
Richard, thank you for taking the time to look over the code and provide feedback! I cannot argue with your assessment because no one knows this kernel better than you.
However, I was hesitant to use taskENTER_CRITICAL()/taskEXIT_CRITICAL() because I thought all context switches are suspended during that section of code, whereas the mutex localizes the impact on context switching to a single resource (in this case, we are trying to have only one LED colour displaying at any time).
This example is admittedly contrived, but we are intentionally serializing access to prevent colour mixing, which is why I was using the mutex across the vTaskDelay()…
You are right in that you cannot call vTaskDelay() inside a critical
section created with taskENTER/EXIT_CRITICAL(), so my suggestion was not
clear, in that I only meant to protect accessing the LED with the
critical section. However from your last reply it sounds like you want
to protect access across the delay too.
