Why should you consider an RTOS? For most, it comes down to knowing ‘what you do best’: if you have always programmed with bare-metal, then it becomes routine to always program that way. If you have never used an RTOS, you may not be aware of the benefits an RTOS can bring to an embedded project. Whilst they are more powerful and complex, using an RTOS is not necessarily a more time-consuming development route.
Scheduling tasks using a super loop architecture on bare-metal can be a perfectly adequate solution when using small systems with limited functionality, but when there is higher demand on scheduling, and execution timing becomes more complex, it could be time to consider an RTOS.
A key problem with super loop architectures is timing and response times, as these are fixed by the structure of the code and will change if modifications or additions are made. In contrast, typically an RTOS enables greater scheduling flexibility. A priority based, pre-emptive RTOS permits the prioritisation of tasks according to their real time requirements. Tasks that have strict timing constraints are able to take precedence over those that have greater scheduling flexibility, improving the application’s responsiveness to time critical events. Although a form of pre-emptive scheduling can be achieved on bare-metal, it will be limited in scope.
Even if you do not require a real time response, using an RTOS can simplify integration. If your application needs to, or may need to, interact with components such as file systems, TCP/IP and GIU in the future, these can be simply added to the system as individual tasks. While bare-metal applications interact directly with the processor registers, an RTOS and/or a Hardware Abstraction Layer (HAL) sits between the bare-metal and the application. Instead of interacting with the bare-metal, the programmer interacts with the RTOS and HAL. The modular design of the RTOS therefore makes it easy to communicate with the tasks and drivers using the RTOS resources provided, cutting down development time.
Less Coding, More Code Re-Use
The resources that the RTOS provide also enable easy task creation, destruction, synchronicity, and communication between tasks and processor resources. All that is needed is an understanding of the RTOS API. This is a consistent interface that, once mastered, enables code reuse and portability between applications and processors. An RTOS also allows an application to be broken down into smaller, autonomous tasks, each executing in their own context, which can reduce complexity and aid in debug and verification.
Learn in Three Days
An RTOS is more complex than bare-metal scheduling but mastering one does not necessarily mean hours of self-taught learning. A short course can be a fast and focused way to learn and, on completion, provide the practical experience necessary to implement an RTOS within an embedded system. WITTENSTEIN high integrity systems (WHIS) provides a three-day FreeRTOS training course for individuals or organisations that would benefit from learning from an expert that don’t have any time to waste. More information on this course is available here https://www.highintegritysystems.com/amazon-freertos/freertos-training/.
Why Learn FreeRTOS?
An RTOS should be easy to use, compile and be supported by multiple architectures. The FreeRTOS kernel is the world’s most popular embedded RTOS and has a huge user base. WHIS has always supported FreeRTOS with licensing, support, and an upgrade path to SAFERTOS for safety critical applications. FreeRTOS is processor and compiler agnostic and therefore provides cross platform support, currently supporting more than 35 different architectures. As the name suggests, the FreeRTOS kernel is free to download and use from the FreeRTOS website, distributed under an M.I.T. license.
For more information about training, or FreeRTOS. visit our website https://www.highintegritysystems.com/amazon-freertos/freertos-training/.
Andrew Longhurst, WITTENSTEIN
A skilled project leader with an extensive background in electrical, electronic and software engineering, Andrew is able to deliver an in-depth understanding of the challenges facing embedded engineers within the safety critical sector. Andrew has worked in Medical, Aerospace and Automotive since 1993 and has worked for WITTENSTEIN since 2000. Andrew holds a BEng in Electrical & Electronic Engineering and an MSc in Robotics & Automation.