March 13, 2018

In the past I had a chance to work on both Chrome EC firmware and FreeRTOS projects. Both project have strong and week sides to consider. I’ll go into details for their scheduling policies.
Let’s try to explain Chrome EC firmware scheduler first. This firmware has platform depended scheduler layer for every port of different CPU architectures.
Incidentally Chrome EC firmware uses SVC (software exception) to manipulate scheduling policy. This is handled with PendSV in FreeRTOS. As it can be seen the code segment below SVC handler is responsible to peak next task.

When we observe lines between 8 and 26, PendSV handler save the context. On the line 27 scheduler algorithm (bl vTaskSwitchContext) gets called.As we came to line between 28 to 42 PendSV handler restores the next task. At this point FreeRTOS differs from the task scheduler of Google EC firmware. FreeRTOS always apply the policy save, schedule and restore as contrast to Google EC firmware schedule and switch if needed.

As can be seen in the figure Google EC firmware first check if we need to call context switch function __switchto.

At this point a question can be popped-up in our mind. Why FreeRTOS apply this scheme. I think this is related the historical background of FreeRTOS. I am aware of FreeRTOS at least 10 years and its architecture has been designed to comply with single stack 8-bit micro-controllers. Incremental enhancements, through the history, accumulate this inefficiency for new architectures. On the other hand, Google EC firmware is relative new project and intended to be used for ARM cortex processors.

I hope this article would give some insights of scheduling paradigm differences for different firmware projects.