Possibly the most popular among the open source operating systems for embedded devices, FreeRTOS is a well-established project with more than 15 years of development history, and it is extremely portable across many embedded platforms, with more than 30 hardware-specific ports.

Designed with small-code footprint, simple interfaces in mind, this system does not offer a complete driver's platform or advanced CPU-specific features, but rather focuses on two things: real-time scheduling of the threads and heap memory management. The simplicity of its design facilitates the port to a large number of platforms, and keeps the development focus on a restricted amount of well-tested and reliable operations.

Nevertheless, third-party libraries and example code provided by hardware manufacturers often integrate FreeRTOS, which facilitates building more complex systems based on its scheduler. Third-party code that is not integrated in FreeRTOS promotes competition among different solutions, as, for example, it is possible to integrate it with many TCP/IP stack implementations to provide networking support, even though none of them is part of the core system or tightly integrated with the kernel. Device drivers are not included in the kernel, but there are several demos of complete systems based on the integration of FreeRTOS with board-support packages distributed by the manufacturers.

The scheduler is preemptive, with fixed priority levels and priority inheritance through shared mutexes. One of the most interesting features offered by FreeRTOS, though, is the heap memory management, available in five flavors optimized for different designs:

• Heap 1: Allows only one-time, static allocation in the heap, with no possibility of freeing up the memory. This is useful if the applications are able to allocate all the space needed at the beginning, as the memory will never become available to the system again.
• Heap 2: Allows freeing memory, but does not reassemble the freed blocks. This mechanism is suitable for implementations with a limited number of heap allocations, especially if they keep the same size of previously freed objects. If used improperly, this model may result in a heavily fragmented stack, with the risk of running out of heap in the long run even if the total size of the allocated object does not increase, due to the lack of memory reorganization.
• Heap 3: This method is a wrapper for a malloc/free implementation provided by a third-party library that ensures that the wrapped memory operations become thread-safe when used within the FreeRTOS multithreading context. This model allows us to define a custom memory management method, by defining the malloc/free function in a separate model, or by using the library implementation and attaching the sbrk() system call, as seen in Chapter 5, Memory Management.
• Heap 4: A more advanced memory manager, with support for memory coalescence. Contiguous free blocks are merged and some housekeeping is done to optimize the use of the heap across heterogeneous allocations from different threads. This method limits the fragmentation of the heap and improves memory usage in the long run.
• Heap 5: Using the same mechanism as heap 4, but allowing us to define multiple non-contiguous memory regions to be part of the same stack space. This method is a ready-to-use solution to physical fragmentation, provided that the regions are defined during the initialization and provided to the system through the available API.

Support for MPU and thread mode is available, and threads can be run in restricted mode, where the only memory accessible is the one assigned to the specific thread. When running threads in restricted mode, the system API is still available, as the system functions are mapped in a specific area in memory. The main safety strategy consists of voluntarily placing tasks in the restricted mode and defining memory access boundaries, by allowing the task to access only its own stack and up to three configurable regions in the mapped memory.

Low-power management is limited to sleep mode, and no deep-sleep mechanism is implemented by default. The system, however, allows us to redefine the scheduler callback functions to enter custom low-power modes, which may be used as starting points to implement tailored power saving strategies.

Recent versions of FreeRTOS include specific distributions with third-party code as a starting point for building secure connected platform for IoT systems. The same authors have created a TCP/IP stack that is designed for FreeRTOS, and it is distributed in a FreeRTOS Plus bundle package alongside the kernel and wolfSSL library to support secure socket communication.

Despite being designed for simplicity of use, the application API is not standard, but rather unique and tailored to the specific implementation of the system, making applications written for FreeRTOS very hard to port to other platforms.

The project has recently abandoned its historical GNU-modified free software license to adopt a more permissive, open source license, so, despite the name, the project is no longer free software.