In the case of “configUSETIMESLICING==1″, then Ready state tasks of equal priority will share the available processing time using a time sliced round robin scheduling scheme, acroding to RTOS-task-priority. I thougt that in the case of “configUSETIMESLICING==0″, fixed scheduling is used. But, the current implementation does not seem to work as expected. Could you refer to the attached patch?

What behaviour do you expect and what behaviour do you observe. That has been discussion on this recently.

Hi Richard, I’m sorry for my late response. I think that expected behaviour in the case of “configUSETIMESLICING=0″ is not Round-Robin but FIFO schedulineg, even if plural ready state tasks of equal priority exist. That is, unless the task explicitly blocks(e.g. vTaskDelay()), it does not switch to another task with the same priority as the task. But, when taskSELECTHIGHESTPRIORITYTASK() is called by some interrupt, taskSELECTHIGHESTPRIORITYTASK() returns the next ready state task with the same priority. So, although the task does not block explicityly, it is preempted. Could you tell me the recent discussion about this?

Hi Richard, I’m sorry. I found the bug in the porting layer. I used linux porting shown below. https://github.com/megakilo/FreeRTOS-Sim I should fix Source/portable/GCC/POSIX/port.c instead of Source/task.c. Could you please refer to the attached patch? And, I tried FreeRTOS with STM32. In this environment, the behavior was exactly what I wanted.

Thanks for reporting back. The project you linked to is not one of ours so suggest you submit the patch there too.

I tried to provide a patch there, but that repository was already read-only, so I couldn’t. In the following URL, linux simulator for FreeRTOS exists. But, this is not updated. Megakilo’s github is based on this. Posix/Linux Simulator for FreeRTOS