I am wondering when a FreeRTOS standard function will be named in the API to standardize the choice of a CPU to be used for xTaskCreate*(), for those platforms that support it.
I think the key thing is that at its heart, FreeRTOS is designed as a single processor OS, and the standard code base really depends on that assumption. The Multiprocessor variants by necessity need to be fairly invasive. One key factor is that with a single processor system, short critical sections are very light weight and simple, disable the interrupt, do your stuff, reenable the interrupt, and you’re done, not much overhead. One there is a second processor in the mix acting in possible contention for the resources, you need a MUCH more complicated critical section that. may even force you do hold off execution until the other processor finishes a critical section it is in, and then the needed memory barriers. This not only makes the critical section code more complicated, but really should impact system design, as it is a much heavier weight operation. (I haven’t looked at any of those ports in detail, so I don’t know if they have done that sort of optimization.
I suspect that there also is an issue that how/why you want to pin a task to a core might change depending on the processor, and that could impact the API design (things like the x86 hyper-threading say that if just for cache reasons you want to be pinning, then you want to pin to just a core-pair, but if for competition prevention you might need different rules. This says that the would likely be some effort to designing a ‘good’ API, and that effort would detract from the development of the core single processor system that is FreeRTOS.
My guess (and somewhat my preference) is that at some point the FreeRTOS developers may decide that it is worth building support for a multi-processor version of FreeRTOS, and that version is likely an independent branch of the existing code since, as I mentioned, tradeoffs ARE different in how you want to do things and many of the core structures need to be changed. It isn’t just a ‘port layer’ change to the code. There may still be some common code between the two versions, or at least a simple path to integrate from one to the other, but it will be two distinct code bases.
All very good comments. What might be a useful starting point however is having defined macros that indicate multi-cpu availability and an optional set of CPU API calls for starting a task. Espressif (ESP32) provides macros for use with the xTaskPinnedToCore() to choose one or the other CPU, or for “any” CPU (i.e. not pinned).
What I fear is that everyone who adapts FreeRTOS software to support the multi-cpu environment is going to come up with their own API for doing so. Since Espressif (as far as I know) is the first to do this, that might serve as inspiration for a “standard”. The API needed for starting a task just needs some definition. The implementation, as you say, would not be a simple matter.
As for CPU usage, ESP32 puts support for WiFi etc. in one CPU and runs application stuff in the other (but the developer can still choose to run a task in either). There is an idle task for each CPU. The biggest challenge seems to be supporting fair round-robin scheduling for tasks at the same priority. This page lists some of the challenges they faced.
With increasingly more multi-core CPUs being offered, this would seem to be an area for new FreeRTOS development.