I have sees several roundrobin scheduler implementations on other rtos, they are same on behavior when the priority preempted, but have some difference when the priority are identical,
in these scheduler implementations, the time slice can be set and coordinate to fit a best performance. but on contrast, FreeRTOS RoundRobin scheduler only supports 1 tick time slice on identical priority tasks, which means the scheduler would very busy on the identical task priority groups.
so , why design like this? did the frequency of scheduler invoke would affect the performance?
and did the FreeRTOS implementions ways is the cause of is more “real time” than others?
My guess is it is implemented like this because it is the cheapest way to implement it, having very small overhead in space and time. On of FreeRTOS’s design goal is to be light weight, so usable at the bottom end of the machine spectrum.
Note that this doesn’t really affect how often the scheduler would be invoked, as it is likely that you would still run the scheduler each tick to see if it is time to switch to a new task or not, and for the class of machines FreeRTOS is designed for, the timing is the same to go back to the task that was interrupted or a new task.
Agree with Richard D, but would be interested to hear your (tugouxp’s) thoughts on what you would like to see in this regard, as well as the benefit you would expect to get from it. It would be simple enough to change the round robin behaviour if the benefits were large enough. Don’t forget you can turn time slicing off all together if you want.