Why are there no Flowcharts,STDs,DFDs for FreeRTOS provided surely they must have been drawn during the Design Phase of The project. (e.g. xTaskIncrementTick, vPortIncrementTick, taskSWITCHDELAYEDLISTS, vPortYieldISR, use of Syscall interrupts etc. how they interact) It would be very much easier and faster for designer to understand the Operating System and better incorporate(,tweak) to suite his Application rather than reading thousands of Lines of Code …

The published book and online documentation is about how to use FreeRTOS (including a state diagram for task states as the user sees them), not the design of the code – although there is a third party book somewhere (with a title something like ‘the design of open source software’) that diagrams some internal workings.

E.g. Windows O.S. which implements “everything-concievably-Needed” completely. User MAY(although providing them would have stopped unlimited questions in stackoverflow-Forum)not need to Bother about its internal Working. But with still unfinished code (e.g. Method For Switching to LPRC from FRC with PLL to Conserve Power -PIC32MX) User is forced to look into the FreeRTOS code to tweak it – But then he needs proper understanding of Kernel for the Task. Which Forces to open this thread? (Just Curiosity-Sorry If I am Rude…Given the Free Nature of RTOS)

pA, I will respectfully disagree with you on your point, and will point out that the issue you refer to doesn’t even have a need for the sort of data you are asking for. Maybe if you had an idea of the level of the StreamBuffers added in version 10, you might be able to make an argument that having more details on the inner workings would be useful. As to your other issue, the interfaces you really need to be using are well defined in FreeRTOS, but perhaps the problem is that you have a tough problem and sort of want someone else to have it. Changing the frequency of the CPU clock has basically ZERO impact on FreeRTOS itself, and isn’t really something that it deals with. It is VERY much processor dependent, so the little impact it would have would be confined to the port layer (which is generally a single header, and one C file and sometimes an assembly file), no where near thousands of lines of code. The requirements for this section are well described in the porting guides. The hardest part of this task is likely deciding when (and maybe how much) to drop the clock frequency. FreeRTOS can’t know this, as this is an application level decision. Because it is a real time system, and clock frequency changes tend to take quite a while, it isn’t something to be done just because the idle task is currently using a large percentage of the time, as a short latency requirement event might be eminant. (a non-realtime system can use such a criteron as it doesn’t attempt to handle events with tight deadlines). Note that tickless idle availability CAN be well detected as FreeRTOS can detect that no scheduled actions are due in the near future, and if the slight extra overhead of coming out of tickless idle would be important, you can just disable the tickless idle mode. The main requirement once you have decided when and how much to change the clock (application specific) and then implemented the clock switch (processor specific) you also need to make sure that the tick interrupt occurs at a constant (enough) rate, which is again hardware specific with a dash of application specific. For many ports, the provided code makes the assumption that the clock rate is constant so a built in timer off the clock can be used to generate the tick interrupt. If changing the cpu clock rate would affect the interval of the timer interrupt, then you need to either do something to maintain the tick period, or accept that you have vastly inaccurate time intervals. (This might be possible by reprogramming the timer with the clock change). A side affect of changing the processor clock rate is that many of the peripheals in the system may need to be reconfigured with the new clock rate, I have built code that changes processor clock rates, and it required ZERO changes to the FreeRTOS core code.