The duplication of APIs (the “regular” and the “FromISR” varieties) is the weakest aspect of FreeRTOS design and the biggest hindrance for its extensibility. The “performance” and “flexibility” arguments in the aforementioned FAQ are, of course, exaggerated. In fact, the need for the “pxHigherPriorityTaskWoken” parameter in the “FromISR” variety, which then needs to be dragged through layers of calls defeats much of the “performance”. Other RTOSes somehow manage to offer a single, unified API, so it obviously is doable.
A good case in point is the popular FreeRTOS-ESP32 adaptation provided by Espressif. They apparently nixed the “FromISR” variety. But by doing so they have created a different RTOS, incompatible really with FreeRTOS (even though they still call it so…)
The duplication of APIs creates hazards of using inappropriate APIs in a given context, and there is no help from the FreeRTOS to detect or assert that the wrong API is being used. For example, many callbacks run in the ISR context, yet people often use the “regular” APIs in those callbacks.
The duplication of APIs creates big problems for providing higher-level services on top of FreeRTOS. It is simply not possible to hide the duplication, but rather it must be exposed to the highest levels, all the way to the application. For example, I provide an event-driven, active object framework called QP that can run on top of traditional RTOSes. The QP port to FreeRTOS is many times bigger than all other ports to RTOSes like embOS, ThreadX, uC/OS-II, etc., because I have to provide “FromISR” variety for most services, such as: event posting, publishing, or even allocating an event from a pool. This is because all these services can be called from the ISRs.
So, I’d like to join all the other developers in a plea to please reconsider the current design and provide a single, clean, unified API. I really hope that this makes sense to everybody.