Whether a smartphone’s baseband radio communications, ultrasound image processing, or production line video inspection, all of these and many other such systems need to process inputs quickly and get some information or action back to the user whether human or another machine.
These systems run on low-power processors and often do all of their processing with relatively small amounts of memory—a combination of requirements that often leads developers to use a real-time operating system (RTOS). The RTOS manages application tasks or threads, handles interrupts, and provides a means of interthread communication and synchronization.
RTOSes come in all sizes and flavors, from the large, like Wind River’s VxWorks, to the super-compact, like Express Logic’s ThreadX. Robust RTOSes offer many features adapted from desktop systems that are typically not available in compact RTOSes because such features execute a larger amount of code that takes a larger memory footprint and causes a slower real-time response.
In contrast, the compact RTOS generally operates as a library of services, called by the application through direct function calls. Underlying these RTOS services is an infrastructure (Figure 1, below) of scheduling and communications facilities that support these functions.
Figure 1. The compact RTOS generally operates as a library of services, called by the application through direct function calls.
Most "small footprint" RTOSes employ an architecture in which the application code is directly linked with the RTOS services it uses, forming a single executable image (Figure 2 below).
The application explicitly references the services it needs, using function calls with an API defined by the RTOS. These service functions are linked with the application from the RTOS library. The result is a single executable image, usually in the .elf format.
For development, this image then is downloaded to target memory and run or, in production, it is flashed into ROM and run at device power-on.
This "monolithic" approach is efficient in both time and space, but it lacks flexibility. Any changes to the application or RTOS require re-linking and a new download/flash of the entire image. While this is routine during development, after production it can present some limitations.
Figure 2. Most "small footprint" RTOSes employ an architecture in which the application code is directly linked with the RTOS services it uses, forming a single executable image.
In contrast, desktop operating systems such as Windows and Linux, and larger RTOSes, such as VxWorks and QNX, have a two-piece "OS/Application" architecture.In this architecture, there is a resident kernel, containing all the OS services available to applications or that are needed by other services within the kernel, all linked into a distinct executable.
This kernel executable boots the system and runs continuously, providing a foundation for applications which dynamically load and run. Usually, virtual memory provides demand paging to and from mass storage on desktop systems or multi-user separation in embedded systems.
This approach is used in mobile devices such as Apple’s iPhone or iPad, where new "Apps" can be downloaded over the wireless network. The OS runs in the device and handles the user interface, which enables selection of any of the downloaded “Apps.”
The selected App then runs along with the OS on the CPU. Similarly, large RTOS-based systems segregate applications from the RTOS kernel, usually in distinct memory spaces, within a virtual memory environment.
A nice feature of the large RTOSes, shared by their desktop OS cousins, is the ability to dynamically download applications onto a running system. In such partitioned architectures, the kernel runs as an entity and the applications run independently, but makes use of OS services to access and use hardware resources.
Even within embedded systems, such downloading and the dynamic addition or change of applications is found where big RTOSes operate in telecommunications infrastructure and defense/aerospace applications. This capability enables a high degree of modularity and field update of running systems.
Information is shared by www.irvs.info
No comments:
Post a Comment