Bill Greiman
Well-known member
I was planning to drop support for my FreeRTOS library. I didn't realize how many people were using my old port. I should have known by looking at GitHub traffic.
Since there are so many users, I will upgrade to FreeRTOS V9, not just fix issues. Supporting an RTOS on Arduino is a challenge since it involves use of internal features that were not intended for use by libraries.
I have been looking at 2017 surveys of embedded developers and FreeRTOS is by far the most popular RTOS for new projects. It is even more popular than embedded Linux or "In House Solutions" for new projects.
FreeRTOS is three times more popular than the next RTOS, Micrium uC/OS-III. Micrium is not free. There is just no free popular alternative.
I am beginning to understand why FreeRTOS so popular. It's not technical superiority, I wouldn't have minded if Paul said that EventResponder prevents use of FreeRTOS. I haven't really supported the FreeRTOS port very well since, in my opinion, it is technically just OK.
I received an interesting email today from a user developing a medical device. This user is trying to get FDA approval for a medical device using my SdFat library. He needs to reduce risk as much as as possible because:
Here is a quote from the FreeRTOS website:
FreeRTOS has a great business message, it's about risk, they don't claim their product is fastest or has the best features.
I won't be able to support features that would improve I/O performance since that would require changes to the Arduino core. I can't see trying to get Paul to modify the Teensy core since my port will run on AVR, SAMD, SAM3X, STM32, and more, not just Teensy.
I can't make use of callbacks in SPI, Wire, or other core libraries. I look at FreeRTOS as a scheduler, not a true RTOS with a HAL.
I can provide the CMSIS-RTOS API since it is supported by FreeRTOS.
Since there are so many users, I will upgrade to FreeRTOS V9, not just fix issues. Supporting an RTOS on Arduino is a challenge since it involves use of internal features that were not intended for use by libraries.
I have been looking at 2017 surveys of embedded developers and FreeRTOS is by far the most popular RTOS for new projects. It is even more popular than embedded Linux or "In House Solutions" for new projects.
FreeRTOS is three times more popular than the next RTOS, Micrium uC/OS-III. Micrium is not free. There is just no free popular alternative.
I am beginning to understand why FreeRTOS so popular. It's not technical superiority, I wouldn't have minded if Paul said that EventResponder prevents use of FreeRTOS. I haven't really supported the FreeRTOS port very well since, in my opinion, it is technically just OK.
I received an interesting email today from a user developing a medical device. This user is trying to get FDA approval for a medical device using my SdFat library. He needs to reduce risk as much as as possible because:
FDA approval requires that the device forever operate exactly as released, and any code change is a big issue.
Here is a quote from the FreeRTOS website:
Developed in partnership with the world's leading chip companies over a 12 year period, FreeRTOS is the market leading real time operating system (or RTOS), and the de-facto standard solution for microcontrollers and small microprocessors.
With millions of deployments in all market sectors, blue chip companies trust FreeRTOS because it is professionally developed, strictly quality controlled, robust, supported, free to use in commercial products without a requirement to expose proprietary source code, and has no IP infringement risk.
FreeRTOS has a great business message, it's about risk, they don't claim their product is fastest or has the best features.
FreeRTOS is downloaded every 260 seconds (on average).
FreeRTOS came top in class in the 2011, 2012, 2013, 2014 and 2015 EETimes embedded systems market surveys in two categories: The RTOS kernel currently being used, and the RTOS kernel being considered for the next project!
FreeRTOS offers lower project risks and a lower total cost of ownership than commercial alternatives because:
It is fully supported and documented.
Most people take products to market without ever contacting us, but with the complete peace of mind that they could opt to switch to a fully indemnified commercial license (with dedicated support) at any time.
I won't be able to support features that would improve I/O performance since that would require changes to the Arduino core. I can't see trying to get Paul to modify the Teensy core since my port will run on AVR, SAMD, SAM3X, STM32, and more, not just Teensy.
I can't make use of callbacks in SPI, Wire, or other core libraries. I look at FreeRTOS as a scheduler, not a true RTOS with a HAL.
I can provide the CMSIS-RTOS API since it is supported by FreeRTOS.
Last edited: