Choosing the optimal real-time operating system (RTOS) for an MCU project can pay off massively to invest some time up-front matching project requirements with the features offered by RTOSes.
A few years ago I wrote a primer on the various levels of ‘real-time’ and whether you may even just want to forego an RTOS at all and use a simple Big Loop & interrupt-based design.
Assuming only open-source RTOSes are being considered, it can be narrowed down to the following list which includes Contiki-NG, OpenERIKA, FreeRTOS, MicroC/OS, Nano-RK, NuttX, RIOT, Rodos, RT-Thread, TI-RTOS, TizenRT, Zephyr, ChibiOS/RT, and Apache Mynewt.
Baseline developer requirements should approximately match those provided by FreeRTOS as it runs on a wide range of (MCU) platforms, supports various compilers and supported programming languages, provides direct hardware access to peripherals, and stays out of the developer's way beyond scheduling and multi-tasking matters.
Developers should look at issues pertaining to the build system requirements, compiler demands, supported programming languages, direct hardware access to peripherals, accessibility of source code, and support availability when choosing an RTOS.
The strengths of FreeRTOS lie in its flexibility, as it can be customized and optimized for the target platform by adding custom schedulers and heap allocation algorithms.
The author's approach to MCU-based RTOSes gravitates toward simplicity and reducing potential pain points by finding the optimal ways to do as little work as possible. The optimal RTOS for a project will depend on individual priorities.
There are numerous approaches to developing a project, and the best solution is the one that ends up getting the job done on time, within budget, with no keyboards thrown through the room.