There are two primary reasons to consider using the POSIX API for FreeRTOS:
- Portability to general-purpose operating systems: By definition, the goal of POSIX is portability. There are many general-purpose operating systems meant to be run on CPUs with MMUs that are POSIX-compliant. Increasingly, there are also several lightweight operating systems aimed at MCUs that are also POSIX-compliant. If your goal is to run your code base on these types of systems, the POSIX API is the interface to use. It is the only API for FreeRTOS that will allow code to be portable to a fully fledged operating system (rather than a real-time kernel).
- Third-party POSIX libraries: Many open source libraries are written to interface via POSIX. Having the ability to bring in some POSIX-compatible third-party code (as long as it only accesses the portions that have been ported by FreeRTOS) has the potential to quickly boost a project's functionality.
Of course, there are some drawbacks to using the POSIX API as well:
- Still in beta: At the time of writing (early 2020), the POSIX API is still in FreeRTOS Labs. Here's an explanation from freertos.org:
The POSIX library and documentation are in the FreeRTOS Labs. The libraries in the FreeRTOS Labs download directory are fully functional, but undergoing optimizations or refactoring to improve memory usage, modularity, documentation, demo usability, or test coverage. They are available as part of the FreeRTOS-Labs download: https://www.freertos.org/a00104.html.
- Being limited to the POSIX API may reduce efficiency: Having code that is portable between many different operating systems running on both MCUs and CPUs will come with a cost. Any code that you'd like to make portable to any platform that supports POSIX will need to contain only POSIX functionality (that is implemented by FreeRTOS). Since only a small subset of the FreeRTOS API is exposed through POSIX, you'll be giving up some of the more efficient implementations. Some of the most time- and CPU-efficient functionality (such as stream buffers and direct task notifications) won't be available if you're aiming to have ultra-portable code that uses only the POSIX API.
Having the POSIX API available to ease the addition of third-party code is an exciting development for embedded developers. It has the potential to bring a large amount of functionality into the embedded space very quickly. But keep this in mind: although today's MCUs are extremely powerful, they're not general-purpose processors. You'll need to be mindful of all of the code's interaction and resource requirements, especially with systems that have real-time requirements.
So, we have three primary options regarding which API to utilize when interacting with FreeRTOS. What kinds of considerations should be made when choosing between them?