Real-Time Operating Systems (RTOS) and their applications
interrupt handling is a technique of deferring interrupt computation into an RTOS task, the ISR will only generate an event through the RTOS object, then the RTOS task will be unblocked by the event and do the computation.
Low Energy (BLE) beacon, the MCU can be put into deep sleep between the advertising interval. As shown in Figure 1, the beacon is put into deep sleep mode for most of the time, consuming power in tens of µA. Conclusion An RTOS provides features like scheduler, tasks, and inter-task communication RTOS objects, as well as communication stacks and drivers. It allows developers to focus on the application layer of the embedded software, and design multitasking software with ease and speed. However, just like any other tools, it has to be used properly in order to bring out more value. To create safe, secure, and efficient embedded software, developers should know when to use RTOS features and also how to configure RTOS.
(e.g., from mutex to counting semaphore) if there is more than one SPI module available. OSAL and other abstraction layers help in software testing as well by simplifying mock function insertion during unit testing. Tick interval selection Ideally, a lower tick rate is better because of less overhead. To select a suitable tick rate, the developer can list down timing constraints of modules in an application (repeating interval, timeout duration, etc.). If there are some outlier modules needing a small interval, having a dedicated timer interrupt can be considered for the outlier modules rather than increasing RTOS tick rate. If the high frequency function is very short (e.g., write to register to turn an LED on/off), it can be done inside an Interrupt Service Routine (ISR), otherwise deferred interrupt handling can be used. Deferred
on a different RTOS. Similar design patterns allow us to develop applications on different microcontrollers and even a different RTOS. Modularity Divide and conquer. By separating features in different tasks, new features can be added easily without breaking other features, provided that the new feature does not overload shared resources like the CPU and peripherals. Development without RTOS will normally be in a big infinite loop where all features are part of the loop. A change to any feature within the loop will have an impact on other features, making the software hard to modify and maintain. Communication stacks and drivers Many extra drivers or stacks like TCP/IP, USB, BLE stacks, and graphics libraries are developed/ ported for/to existing RTOSs. An application developer can focus on an application layer of the software and reduce time to market significantly.
that a RTOS object can be created successfully, saving the hassle of handling a possible failed allocation and making the application more deterministic. In terms of deciding stack size needed for a task, the task can be run with a bigger (more than enough) stack size and then the stack usage can be checked in runtime to determine the high- water mark. There is a static stack analysis tool available as well. Operating system abstraction layer (OSAL) and meaningful abstraction Just like Hardware Abstraction Layer (HAL), use of the RTOS abstraction layer allows application software to migrate easily to other RTOSs. Features of RTOSs are quite similar, so creating OSAL should not be too complicated. For example: Using the freeRTOS API directly: if( xSemaphoreTake( spiMutex, ( TickType_t ) 10 ) == pdTRUE ) { // dosomething } Wrapping the RTOS API into OSAL: if( osalSemTake( spiMutex, 10 ) == true) { //dosomething } Using the abstraction layer on inter- task communication to make code more readable and minimize the scope of an RTOS object: if( isSpiReadyWithinMs( 10 ) ) { // doSomething } Additionally, the abstraction also allows a programmer to change the RTOS object used underneath
combination condition to be fulfilled ■ Available in Zephyr as a Polling API, in FreeRTOS as QueueSets
System tick
Tick suppression for low power application
RTOS need a time base to measure time, normally in the form of a system tick counter variable incremented in a periodic hardware timer interrupt. With system tick, an application can maintain more than time-based services (task executing interval, wait timeout, time slicing) using just a single hardware timer. However, a higher tick rate will only increase the RTOS time base resolution, it will not make the software run faster.
Tickless idle disables tick interrupt when the system is going idle for a longer time. One significant way for embedded firmware to reduce power consumption is to put the system in low power mode for as long as possible. Tickless idle is implemented by disabling the periodic tick interrupt and then setting up a countdown timer to interrupt when a blocked task is due to execute. If there is no task waiting for a timeout, the tick interrupt can be disabled indefinitely until another interrupt occurs (e.g., button pressed). For example, in the case of a Bluetooth
Why use RTOS?
Organization Applications can always be
written in a bare metal way, but as the code complexity increases, having some kind of structure will help in managing different parts of the application, keeping them separated. Moreover, with a structured way of development and familiar design language, a new team member can understand the code and start contributing faster. RFCOM Technologies has developed applications using different microcontrollers like Texas Instruments’ Hercules, Renesas’ RL78 and RX, and STMicroelectronics’ STM32
Figure 1: Current consumption of a BLE beacon Credit: RFCOM
Tips Static allocation
Use of static allocation of memory for RTOS objects means reserving memory stack in RAM for each
RTOS object during compile time. An example of a static
allocation function in freeRTOS is xTaskCreateStatic(). This ensures
we get technical
6
7
Powered by FlippingBook