Hi, I am trying to understand how the FreeRTOS Scheduler works. The tasks.c file has comments in it, however, is there a good starting point that I can see to understand:
How the Scheduler works
What Scheduling policy it uses
How the tasks are put to a blocked state
How the real-time guarantees are given, etc?
Any leads or answers to the above questions would be very helpful. Thank you!
There are some “books” available that go into more details, a good place to start is use the web-site navigation a look at Kernel / Getting Started.
The simple answers:
The Scheduling policy is run the Highest Priority task that is ready. In case of tie, the one that has been waiting the longest.
When a task blocks, it is put on a list connected to the thing it blocked on so that when that thing gets “triggered” the system can unblock the task(s) that need to be. There is also a list of task sorted by the time they will get unblocked by time (for delays or timeouts on other blocks).
FreeRTOS itself, doesn’t do anything about actual real-time guarantees. You, the programmer need to design your system to meet the requirements using the tools provided. FreeRTOS CAN’T guarantee that a task will meet its requirement, as the task (or the system) might not have the time it needs to meet it. YOU need to make sure your tasks have appropriated bounded execution times, and then put them in a priority order that will let you tasks meet their requirements.
There’s a world of difference between real-time operating systems such as FreeRTOS and simple scheduling systems like that one. If your application isn’t real time then by all means use something simpler than FreeRTOS.
But FreeRTOS HAS a scheduler (and that is at its core) so you can’t really change that and say you are using FreeRTOS. You seem to have some sort of fundamental confusion. Perhaps you don’t understand what an RTOS is?
This C++ scheduler could be an option for the future. I’m not going to study Your source-code, there is so much missing. I’m going to use exceptions in multi-tasking and give You the possibility to safely catch them in the main-task.
Well, it isn’t “my” source code, as I am just another user here. FreeRTOS couldn’t use your scheduler as an option, because FreeRTOS is written in C, not C++, and doesn’t have “hooks” to allow that sort of change.
You are perfectly free to adopt pieces of FreeRTOS to use in your own RTOS based on your C++ scheduler, but then it would be up to you to provide the needed support to anyone that chooses to use it. I will warn you that it seems that a number of your ideas seem to have a shaky basis, but perhaps you can work out the details to solve them.
Note, there is nothing “missing” in the FreeRTOS repositories, it is a fully functioning software package, and all the source code is there.
My own wrappers, are just that, a wrapper, and fully provide the functions they provide when combined with FreeRTOS, so I don’t know what you think is “missing”.
If you mean functionality that you want, then sure, there can always be features desired. FreeRTOS has a design goal, and if your desires are aligned with that, you may see things missing.
I told You everything i am missing. My heap is written in C, all my modules are C++. I come from Windows programming and have experience there, i cannot use in FreeRTOS. Basically this is handles, so i don’t have to deal with memory in my driver. And exceptions for sure, for simplification.
So, it isn’t really much i am missing, but i’m missing it everywhere.
What it seems you are missing, is an understanding of what the field you are talking is about.
FreeRTOS is, at its essence, a scheduler for tasks that you can define. It includes a set of inter-task communication primitives, many of which (the original ones) are based on a simple queue structure.
If you want to replace that scheduler, you aren’t using FreeRTOS any more. As I said, go ahead a borrow what you want from the code, it is open sourece. If you don’t know how to do that, then maybe this isn’t the task you are meant to be doing. This seems to be a possiblity based on the “questions” you ask.
FreeRTOS has 5 heaps, but only one scheduler. For me it was easier to work with a new C++ API. I’m not going to push my scheduler, it is license-free software. Everybody may use it, FreeRTOS could provide it.
FreeRTOS provides 5 different heap implementations, but most applications will only use 1 of them (and you need to edit things to try to have two different heaps), and the 5 implementations are included for different levels of need, and in truth, many programs just won’t need a heap at all. (I know, something a big iron C++ programmer can’t imagine).
The heap is also an ancilary function for FreeRTOS, small and well defined API, fairly straight forward to implement, and easy to test independently. Because of the simple API, also easy to replace if you want something different.
The Scheduler is core functionality, and subject to a ot more interactions, and thus not easy to just “replace”. Your API is incompatible with the current system, making it really not usable for “substitution”.
I will point out that I built a C++ wrapper for the FreeRTOS API, that lets you use many of the more common C++ methods, but still runs the standard FreeRTOS scheduler (because the wrapper creates standard FreeRTOS tasks for it to run).
Writing a new kernel with a new scheduler isn’t really something to be done as “a hobby”, as it is a lot of work, unless you are just going to build a toy.