Embedded Technology Making RTOS more energy efficient By Dirk Akemann, partnership marketing manager, SEGGER T
he need for rapid responsiveness and deterministic operation have made real-time operating system (RTOS) usage essential in many modern applications. Through this, it is possible for data from a wide array of different sources to be acted upon and numerous functions controlled while keeping within necessary time constraints. As the complexity of system implementations continue to increase and the criteria that must be focused on alter, new RTOS advances are now being expected.
An example of an implementation where an RTOS is not incorporated is the super-loop architecture (which is often referred to as bare-metal programming). The structure here is fairly simple (as described in Figure 1). In the main function, the programming engineer will set up all variables, drivers, libraries, etc. After this has been done, one or more periodic tasks will be executed within the loop. This is all quite resource heavy though and not particularly practical.
External events must be programmed at the interrupt level of the processor, which communicates with functions from the main loop via global variables. There are always dependencies between data, time, functions and priorities. There is the prospect of major issues emerging if program parts from the main loop are extended, as this will mean that the time behaviour of the whole application changes. It is also difficult to process a program in a priority-oriented way via this approach. Disturbances in one function are certain to have an effect on another, and this will make the system very error-prone. Among the other drawbacks that should be considered are the loss of computing time by polling and missing multitasking, since an intervention into the program sequence is possible only by interrupts. Of course, there are further challenges to be aware of - such as the manual management of resources (e.g. timers, interfaces, memory and computing time) which all have to be shared. In contrast, an RTOS will be able conduct all these tasks directly. The application will be divided up by the person responsible for programming into a series of different threads.
24 March 2023
Figure 1: Example of a super- loop architecture
This result is a modular arrangement which brings with it the opportunity for coding reuse, thereby saving time and effort. Tasks that are to run with different priorities are implemented as separate threads (see Figure 2). Each of the separate threads will have a specific state at any point in time. As shown in Figure 2, there are three basic states. These are namely: ● Running: Here the thread is executing. Of course, on a single-core microcontroller unit (MCU) only one thread can be in this state at any given time. ● Ready: Where the tasks are prepared to run and are awaiting processing resources to be allocated to them. ● Waiting: Here the tasks are not ready to run at the moment. Only once certain events have occurred (e.g. data is available or a predefined point in time has been reached), will the threads move into the Ready state.
Scheduling and execution The central switching point of the RTOS is the scheduler. This determines which thread gets allocated the available processing resource. All threads must be executed before their deadline is reached to prevent problems occurring. The deadline is the maximum acceptable time which may pass from the arrival of an event
Components in Electronics
Figure 2: In an RTOS the application is divided into separate threads
to the completion of the associated function. Threads can be executed almost concurrently, even if the embedded system on which they run has only a single processor core. Execution can be carried out in two different ways. These are: ● Time-slicing: Where all threads that are deemed ready are executed for a specified time in a ‘round-robin’ arrangement. A time slice is generally a period of 1ms or multiples of this. The disadvantage of time-slicing is that executing a given task can take several time slices. This will not be critical for things like user interfaces (UIs), but for a network stack that can operate in a separate thread this can be critical, meaning it is no longer possible to complete the task. ● Priority-driven scheduling: Here the limitations of time-slicing are overcome, by more time-critical tasks having a higher priority than less time-critical ones.
In the majority of cases, the RTOS will allow both types of scheduling to be combined
Hardware abstraction Another advantage of using an RTOS is hardware abstraction. This is becoming of even greater value in the current landscape, due to the chip shortages being experienced - as it enables portability of applications from
one hardware platform to another. Whereas in-house developments will lock OEMs in with a specific MCU, if the right RTOS is selected then there will be scope for this to be utilised with a wide range of different devices. As well as offering extensive versatility in terms of MCUs (with support for almost 1,000 different models), SEGGER’s embOS RTOS portfolio has proven very popular within the embedded engineering community. The arrival of the latest version, embOS-Ultra, is acknowledged as game changing - because of its far finer time granularity.
All about timing
A scheduler works with a system tick, which is the basic time unit. So, every time specification is given in multiples of ticks, where the distance between these ticks can be configured (usually for a 1ms period). This then means that a hardware timer is programmed to generate an interrupt 1000 times/second, indicating the expiration of 1ms each time. 1ms may already sound like a fairly high resolution, but nevertheless today’s embedded systems are now asking for more. The proprietary clock cycle-based scheduling featured in SEGGER’s embOS- Ultra changes the fundamental time unit of the system, dramatically increasing
www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62
