Hello, I’m running FreeRTOS on FRDM-K22F and it’s not behaving as expected.Putting some code to explain what’s going on: ~~~ static const char text1[] = “Periodic taskrn”; static const char text2[] = “Continous Taskrn”; static const char text3[] = “Continous Task 2rn”; void periodicTask(void pvParameter) { TickType_t prevCount; char *printText = (char)pvParameter;

prevCount= xTaskGetTickCount();

for(;;)
{
    printf(printText);
    vTaskDelayUntil(&prevCount,pdMS_TO_TICKS(5));
}

} void continousTask(void pvParameter) { char *printText = (char)pvParameter;

for(;;)
{
    printf(printText);
}

} int main(void) {

xTaskCreate(periodicTask,"periodic task",200,(void*)text1,3,NULL);
xTaskCreate(continousTask,"continous task",200,(void*)text2,0,NULL);
//xTaskCreate(continousTask,"continous task 2",200,(void*)text3,0,NULL);

vTaskStartScheduler();

while(1)
{

}
return 0 ;

} ~~~ So if i create periodic and continous task, basicaly only continous runs all the time, sometimes periodic fires but no at desired rate(every 3ms) that shouldn’t happend because periodic got higher priority. Now lets go to time slicing, if i create 2 continous tasks with same priority only one runs even if i got defined configUSETIMESLICING as 1. Shouldn’t they get same amount of time? I’m pretty new in FreeRTOS but i’m pretty sure something is not correct

One big question, how does your ‘printf’ function work. If it is based on ‘Semihosting’, then often it will interfere with how FreeRTOS wants to work. The second question, do you have Preemtion enabled? If not then unless printf was is using an output designed for an RTOS, and has a block in it, once you get into one of the continous task, you have no ‘yield’ point, and thus never allow the system to swtich tasks. Last, you many need to make sure your printf is reentrant and usable in an RTOS enviornment, sometimes library functions aren’t.

Yeah printf is based on semihosting and seems like it’s blocking the execution or somehow is not reentrant. UART printf it’s working as intended.

Semihosting often doesn’t block but will spin in a tight idle loop, perhaps with interrupts being blocks. If the UART driver has the proper blocking, that would allow the switching. I would still double check that you have preemption enabled, as that still might be part of the issue, which has now been hidden by the fact that the tasks continully are blocking, providing context change points. If you change the continous tasks to do some other long running operation that doesn’t need blocking, you may find that you get the starving again without preemption. Turning off preemption makes things ‘tactically’ simpler, as you don’t need to worry about as many inter-task sharing concerns due to the limited context switch points. It does make things significantly more complicated in a ‘stratigic’ sense, as now every task, even low prioirty ones, need to make allowance for the highest priority response time by frequently providing context switch points.