richard_damon wrote on Thursday, July 12, 2018:
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.