Tasks behaving incorrectly in round-robin schedule

Question

I have FreeRTOS running on a STM32F4DISCOVERY board, and I have this code:

xTaskCreate( vTask1, "Task 1", 200, NULL, 1, NULL );
xTaskCreate( vTask2, "Task 2", 200, NULL, 1, NULL );
vTaskStartScheduler();

where vTask1 is this function:

void vTask1( void *pvParameters )
{
volatile unsigned long ul;

    for( ;; )
    {
        LED_On(0);

        for( ul = 0; ul < mainDELAY_LOOP_COUNT; ul++ )
        {
        }
        LED_On(2);
        LED_Off(0);
    }
}

vTask2 has nearly the same code:

void vTask2( void *pvParameters )
{
const char *pcTaskName = "Task 2 is running\n";
volatile unsigned long ul;

    for( ;; )
    {
        LED_On(3);
        LED_Off(2);
        for( ul = 0; ul < mainDELAY_LOOP_COUNT; ul++ )
        {
        }

        LED_Off(3);
    }
}

When I run the program, I see that LED0 and LED3 are always on (their switching is too fast for my eye, which is fine), and that LED2, the "shared resource", is blinking very fast. The problem is this: when I reverse the order of the xTaskCreate calls, I get the same situation with a different blinking behavior of LED2, which is much slower. Why would this happen, since the tasks should have equal priority and therefore follow a round-robin schedule? Shouldn't they get the same amount of time? Why is their behavior changing after only having created them in different order?

Thanks in advance.

The logic is clearly correct in my opinion. How aoubt tring the **delay** methods provided by FreeRTOS rather than void loop? Maybe the complier have done some optimization background. — iama, Jan 18 '15 at 03:12
Initially I was wondering the same thing, but the compiler would not change that depending on the order in which task creation functions are called. — TSG, May 28 '15 at 20:29
Does it blinks really slower, or with a different "on" time only? Even the task have the same priority and are scheduled by round robin, it does **not** imply that the time from `LED_On(2)` to `LED_Off(2)` is the same as from `LED_Off(2)` to `LED_On(2)` — Matthias, Jul 08 '15 at 07:04
I don't think your LED diagnostics are sufficient for determining this. It would be illuminating to see the on-off waveform of the LEDs on a scope; or i create a buffer for each and log time stamps at each LED transition. It might be a good exercise in how to compress logs as well. — mevets, Mar 28 '19 at 13:45

score 1 · Answer 1 · answered Sep 21 '21 at 19:23

The rtos does not try to round robin through the tasks and you should not expect them to execute in any specific order. Neither of the tasks you have created have a delay in them as iama pointed out in their comment. instead of creating a delay by burning through no-ops in a for loop, use the delay function. this will allow the code in your while(1) loop to execute then yield back to the rtos so that the processor can run other tasks until the wait time has elapsed. If you need to synchronize work you may want to just keep it in a single task. If you have one task that is dependent on something done in another, you may want to use semaphores, queues, or other cross thread communication method.

Your code reminds me of when I was transitioning from using a while(1) loop in main to an rtos. If your new to using an rtos, this guide from ST looks like it would be a good introduction https://www.st.com/resource/en/user_manual/dm00105262-developing-applications-on-stm32cube-with-rtos-stmicroelectronics.pdf

Also, do not rely on the delay function for fine grain timing; use a timer driven interrupt instead. The link above should give you a better understanding of why then I could manage in this post.

ST should also have example projects somewhere, which would be good to reference or use as a start for your own project.

Thanks for attempting to answer, although this is a _really_ old question from 2013. Also, even at that time, I wasn't really asking for advice on how to use FreeRTOS features, but rather for an explanation of the very specific behavior I described, so pardon me but I find the answer a little off-topic, besides the first sentence. Regarding that: any references on what the FreeRTOS scheduler would do with the tasks then? As I have written, they have equal priority. — 0x5C91, Sep 22 '21 at 19:58
As comments have pointed out, the example probably needs more debugging, done in a smarter way than just observing the LEDs. I would accept an answer that explains the behavior, but in that case I would prefer if it was supported by either a link to documentation, or a pointer to source code. — 0x5C91, Sep 22 '21 at 20:06
Ah, I missed the date on this, for some reason it came up in my recommendations for unanswered questions. As to what rules the scheduler would follow, I'm not entirely sure. Ive just learned to not rely on the tasks executing in the order they are spawned or to run in the same order every cycle. Your right that I probably should have asked clarifying questions before answering (if it wasn't an 8 year old question ‍♂️) — Luke Sackash, Sep 23 '21 at 18:09

Tasks behaving incorrectly in round-robin schedule

1 Answers1