I developed a little more than 10 electronic devices and completely dispensed with their low-level operation without an operating system. The situation changed when the functionality of the next device expanded dramatically. In addition, there is a need for a task that is called at specified time intervals, and the accuracy of the call affects the result. It also became clear that it would not be possible to write all the software in the allotted time, and it would be created later. After some thought, I realized that the project needed to include a real-time operating system (RTOS or RTOS).
Unlike a PC, where the OS is more of a layer for working with system resources, for an RTOS microcontroller it is primarily a task scheduler, in fact it plays the main role in "real time". At the moment, it is important for me to provide the so-called "pseudo-parallel" task execution. That is, there are several tasks with the same priority and it is important to call them in the specified order at specified intervals.
The following example is clear: in the Eurobot 2011 project, there were 18 peripheral devices in the system. 2 electronic boards could be combined into one in terms of functionality. Their cost would decrease, reliability would increase (the number of components in the system would be reduced), and the amount of free space in the case would increase. The circumstance is complicated by the fact that the number of tasks grows proportionally and here you cannot do without the OS. RTOS also helps to avoid possible downtime of the processor, for example, during ADC conversion, you can block this task and perform others, thereby correctly distributing the work of the device. It is also important that now the device will not fall due to a failure in the task; instead, it is possible to maintain partial operability (although this may lead to unpredictable results). How do we ensure the growth of these indicators? In fact, we squeeze everything possible from MK, effectively using its computing capabilities.
After a short search, the choice fell on freeRTOS. This RTOS is distributed in C source and ported to 27 architectures. The last circumstance is decisive for me. It will reduce labor costs when working with MCUs from other manufacturers. Now I'm more interested in the port for the AVR.
The presence of RTOS freeRTOS in the project eats up about 9.8 KB of program memory and 1.8 KB of RAM. For example, for ATmega32 and the WinAVR compiler, these are 60% and 85%, respectively. Already for this model, it is difficult to create a device with great functionality - there will not be enough memory. But this problem disappears with the new AVR models. This is completely unimportant for the Mega2560 with its 256KB of program memory and 8KB of RAM. The trend of future MCs only accompanies the success of the RTOS.
Having skimmed through the Runet, I was surprised to find that there is no OS documentation in Russian. What is it! The original documentation is distributed at an additional cost. The situation was simplified by the article by Andrey Kurnits ( [email protected]) from the magazine "Components and Technologies". With the consent of the author, I will use the materials of the article in a revised version. His article may well serve as documentation in Russian. But the original is not available in printed form, the site of the magazine is lying, so the material will have to be slightly reworked. In general, the author has made an excellent article and there is no point in going over the theory again, it will be published in full here. The original article will be attached at the end of the publication. I also noticed that users were having difficulty compiling the RTOS. This is due to the fact that an external makefile is used, which contains the paths to the folders. Therefore, I will attach a finished project as a template for AVR Studio and AVR Eclipse. Unfortunately, the native makefile does not output debug information such as RAM and program memory usage, this had to be fixed by adding the appropriate standard call.
So, briefly about the need, it is advisable to use an RTOS in your project, if necessary:
Organize multitasking and alternate tasks
Ensure the launch of the task at strictly defined intervals
Transfer information from one task to another
Add new tasks as needed
RTOS advantages over M TO:
- Multitasking. RTOS provides the programmer with a ready-made, debugged multitasking mechanism. In a simple case, each task can be programmed separately, all work can be divided among several team members. You don't need to worry about switching between tasks, the scheduler will do it.
- Time base. Time intervals must be measured. The RTOS must have this tool. It will allow you to perform actions at strictly allocated intervals.
- Data exchange between tasks. For this, the RTOS uses a queue.
- Synchronization. If different tasks use the same resource, such as a serial port, then mutexes and critical sections can be used. If you need to execute tasks in a strict sequence or when a specific event occurs, you can use semaphores or signals to synchronize tasks.
Disadvantages of RTOS:
1. A sharp increase in the required program memory for the implementation of the kernel
2. Increasing the required RAM for storing the stack of each task, semaphores, queues, mutexes and other objects of the system kernel.
3. Delays when switching between tasks to save the context.
DescriptionfreeRTOS:
FreeRTOS is a free open source hard real-time OS. Mostly written in C, but assembler inserts are present. It was developed by Real Time Engineers ltd specifically for embedded systems. Recently, the SafeRTOS project has begun to develop - a modified, documented, tested and certified version of FreeRTOS for compliance with the IEC 61508 safety standard. This project was carried out by a German company and now safeRTOS is used in the aerospace industry and medical technology. There is also the openRTOS project - a commercial version with a manufacturer's warranty.
Main features of freeRTOS:
1. Scheduler supports 3 types of multitasking:
Displacing
A cooperative
Hybrid
2. The kernel size is 9.8 KB compiled for AVR. (WINAVR)
3. The base of the kernel - 4 files in C.
4. Supports tasks and coroutines. Coroutines are specially designed for MCUs with a small amount of RAM.
5. Rich tracing capabilities.
6. It is possible to track stack overflow.
7. There are no software restrictions on the number of simultaneously executed tasks.
8. There is no limit on the number of task priorities.
9. Several tasks can be assigned the same priority
10. Advanced means of synchronization "task-task" and "task-interrupt":
Queues
Binary semaphores
Counting semaphores
Recursive semaphores
Mutexes
11. Mutexes with priority inheritance.
12. Support for memory protection module for Cortex-M3
13. Supplied in debugged form with demo projects for various platforms and compilers.
14. Free. Can be used in projects without disclosing source code under the extended GPL license.
15. Documentation is paid, but available online here.
16. The context switching time for an AVR with a 16MHz quartz crystal is only 20.8 µs. This is exactly how much it takes to save data to the task stack and call the next one. (An interesting note, if you compare this with the PIC18xxx, then the AVR controller makes it 4 times faster !!!, most likely this is due to the quality of the compiler)
Preemptive multitasking means that a running task with a low priority is overlapped by a finished task with a higher priority. Switching between tasks occurs at equal time slices. Therefore, before the high-priority task can begin execution, the current slice of time when the low-priority is executed must end.
Thus, the reaction time of FreeRTOS to external events in preemptive multitasking mode is no more than one time slice of the scheduler, which can be set in the settings. By default, it is 1ms.
If several tasks with the same priority are ready for execution, then the scheduler allocates to each of them one time slice, after which control is received by the next task with the same priority, and so on in a circle.
Cooperative multitasking differs from preemptive multitasking in that the scheduler itself cannot interrupt the execution of the current task, even a task with a high priority that is ready for execution. Each task must independently transfer control to the scheduler. Thus, the high-priority task will wait for the low-priority task to complete its work and return control to the scheduler. The response time of the system to an external event becomes undefined and depends on how long the current task will be executed before control is transferred. Cooperative multitasking was used in the Windows 3.x family of operating systems.
Preemptive and cooperative multitasking concepts come together in hybrid multitasking, where the scheduler is called every time slice, but unlike preemptive multitasking, the programmer has the ability to do this forcibly in the body of the task. This mode is especially useful when it is necessary to shorten the response time of the system to an interrupt. Suppose a low-priority task is currently being executed, and a high-priority task is waiting for some interruption to occur. Then an interrupt occurs, but after the end of the interrupt handler, execution returns to the current low-priority task, and the high-priority one waits until the current time slice ends. However, if after the execution of the interrupt handler, control is transferred to the scheduler, then it will transfer control to a high-priority task, which reduces the system response time associated with an external event.
Whyonchatb?
You can start developing a microcontroller device running FreeRTOS by downloading its latest version.
The FreeRTOS distribution is available as a regular or self-extracting ZIP archive. Distribution Contains the kernel code itself (in the form of several header and source files) and demo projects (one project for each development environment for each port). Next, you should unpack the archive to any suitable location on the development station.
Despite the large number of files in the archive, the directory structure is actually simple. If you plan to design devices on 2-3 architectures in 1-2 development environments, then most of the files related to demo projects and various development environments will not be needed.
The detailed directory structure is shown in the diagram.
All kernel source is located in the / Source directory.
Content:
1.tasks.c- implementation of the task mechanism, scheduler
2. queue.c- implementation of queues
3. list.c- internal needs of the scheduler, but the functions can be used in application programs as well.
4. croutine.c- implementation of coroutines (may be absent if coroutines are not used).
Header files that are in the directory source / include
1.tasks.h, queue.h, tist.h, croutine.h- header files, respectively, for the files of the same name with the code.
2. FreeRTOS.h-contains preprocessor directives for configuring compilation.
3.mpu_wrappers.h- contains overrides of the FreeRTOS programming interface (API) functions to support the memory protection module (MPU).
4.portable.h-platform-dependent settings.
5.projdefs.h-some system definitions
6.semphr.h- defines API functions for working with semaphores, which are implemented on the basis of queues.
7. StackMacros.h- contains macros to control stack overflow. Each hardware platform requires a small piece of kernel code that implements FreeRTOS's interoperability with that platform. All platform-specific code is in the subdirectory / Source / Portable, where it is categorized by development environments (IAR, GCC, etc.) and hardware platforms (for example, AtmelSAM7S64, MSP430F449). For example, the subdirectory / Source / Portable / GCC / ATMega323 contains the files port.c and portmacro.h, which implement saving / restoring the task context, initializing the timer to create a time base, initializing the stack of each task and other hardware-dependent functions for microcontrollers of the mega AVR family and the WinAVR compiler (GCC).
Separately, you should highlight the subdirectory / Source / Portable / MemMang which contains the files heap_l.c, heap_2.c, heap_3.c that implement 3 different mechanisms for allocating memory for the needs of FreeRTOS, which will be described in detail later.
The / Demo directory contains ready-to-compile and build demo projects. The common part of the code for all demo projects is highlighted in a subdirectory / Demo / Commo n.
To use FreeRTOS in your project, you need to include the kernel source files and related header files. There is no need to modify them or understand their implementation.
For example, if you plan to use the port for MSP430 microcontrollers and the GCC compiler, then to create a project from scratch "you will need subdirectories / Source / Portable / GCC / MSP430_GCC and / Source / Portable / MemMang... All other subdirectories from the / Source / Portable directory are unnecessary and can be removed.
If you plan to modify the existing demo project (which, in fact, is recommended to do at the beginning of the FreeRTOS study), then you will also need subdirectories / Demo / msp430_GCC and / Demo / Common... The rest of the / Demo subdirectories are unnecessary and can be removed.
When creating an application, it is recommended to use makefile(or development environment project file) from the corresponding demo project as a starting point. It is advisable to exclude from the build (build) files from the / Demo directory, replacing them with your own, and files from the / Source directory - intact. The header file should also be mentioned FreeRTOSConfig.h which is in every demo project. FreeRTOSConfig.h contains definitions (#define) that allow configuring the FreeRTOS kernel:
1. A set of system functions.
2. Using coroutines.
3. The number of priorities of tasks and coroutines
4. Sizes of memory (stack and heap).
5. Clock frequency of MK.
6. The period of the time scheduler allocated to each execution task, which is usually 1 ms. Disable some system functions and reduce the number of priorities (reduces memory consumption).
The FreeRTOS distribution also includes tools for converting trace information received from the scheduler into text form (directory / TgaseCon) and license text (directory / License).
conclusions
With the help of the first article in the series, the reader got acquainted with the operating system for FreeRTOS microcontrollers. The features of the work are shown. Describe the contents of the FreeRTOS distribution. The basic steps to start developing a device running FreeRTOS are given.
In future publications, attention will be paid to the multitasking mechanism, namely tasks and coroutines. An example of the scheduler will be shown using the example of Atmel AVR microcontrollers and the WinAVR compiler (GCC).
RTOS MAX is a free Russian real-time operating system for multi-agent coherent systems.
MAKS embodies the classic functionality of operating systems of this type and has a number of advantages that significantly speed up the development of embedded software when creating new devices based on microcontrollers. The advantages of the new OS are especially evident in the issues of organizing the interaction of many devices.
RTOS MAX includes:
- Fully functional RTOS core.
- Complete set of source codes.
- Documentation.
- Demo applications.
Or download the stable version as part of the Eclipse-based MACS Master development environment
Development tools support
 |
Eclipse + GCC. |
RTOS MAX is:
Scheduler:
- dynamic creation and deletion of tasks,
- support for preemptive and cooperative multitasking modes,
- selection of the task execution mode - privileged or unprivileged.
- binary and counting semaphores,
- recursive and non-recursive mutexes with support for priority inheritance,
- developments,
- message queues.
- to protect the process stack from overflow,
- to protect memory at address zero,
- to protect peripheral ports from unprivileged access.
- activation of custom handler tasks from a predefined universal interrupt handler that does not require additional configuration,
- the ability to assign several handler tasks for one interrupt,
- control of the processing sequence through the priorities of the processing tasks.
- measuring the execution time of code sections from point to point or in the scope of an automatic variable,
- the possibility of automatic adjustment (increasing the measurement accuracy by calculating the delays of its own work),
- formation of statistics of measurements with grouping of sections by sections (total execution time of all sections with and without nesting, minimum / average / maximum section execution time, standard deviation).
- synchronization of the context of tasks between devices,
- exchange of messages within a group of devices.
Microcontroller-controlled devices are used to solve a wide range of tasks. RTOS MAKS is a universal platform for the development of embedded applications, and its scope is related to the expediency of using microcontrollers in a particular task.
Robotics, UAV
- Control system
The control electronics is installed directly on the robot itself and implements algorithms that allow it to solve the task.
- Telemetry system
Provides communication between the robot and the remote terminal, enables the operator to receive information about the status of the robot and send commands.
- Positioning system
Additional external devices allow robots to navigate indoors and outdoors, find their way to their destination and base stations.
- Power and lighting control
Ensuring uninterrupted power supply to the building, controlling energy consumption, automatically turning on / off lighting depending on the presence of people in the room and controlling the level of illumination (adjusting the brightness of the light at different times of the day).
- Climate control
Maintaining a comfortable indoor climate (temperature and humidity control, ventilation and air purification) is carried out depending on the user's preferences, the presence of people in the room, as well as external factors (weather, time of day).
- Monitoring and security systems
Video surveillance and control of access to premises, tracking events that threaten the safety of a home (burglary, fire, water leakage) and automatic notification of owners and relevant services about them (security, fire service).
With the development of technology, household appliances are becoming more functional and easier to use. For example, nowadays the consumer already has access to equipment controlled centrally from a smartphone or tablet instead of separate remote controls. “Smart” technology requires less and less attention from the human side, which makes it possible for the user to significantly save time and money (robotic vacuum cleaners do the cleaning themselves, the delayed start and auto-off functions control the operating time of the device and thereby optimize energy consumption). The rapidly developing technologies of the Internet of Things (IoT) imply complete autonomy of devices, which generates high requirements for their software stuffing, and from the developers of these devices there is growing interest in OS that already "out of the box" provide services and interaction protocols. allowing to ensure this autonomy.
IoT technologies imply complete autonomy of devices. This gives rise to high requirements for their software stuffing. On the part of the developers of these devices, there is a growing interest in the OS, which already provide out-of-the-box services and interaction protocols to ensure this autonomy.
Mesh support
- Network reliability and resiliency
The nodes of the network are connected to each other, forming a large number of links. Several traffic routes can be formed between nodes. If there are redundant routes, the failure of one of the intermediate nodes will not disrupt the functioning of the entire network. The information will be dynamically redirected to a different route.
- Self-organization
The network structure is formed automatically as nodes are connected / disconnected. If necessary, each node can independently obtain information about the availability of the destination node and build an optimal route for data exchange.
- Increased communication range
Each of the devices can have a short communication range. However, the territorial distribution of many devices connected to each other allows for much greater coverage.
- Optimal configuration of a distributed system
The hardware resources of each device in the system are selected based on its functional purpose. There is no need for powerful computers to solve simple tasks such as identifying objects or measuring parameters of the external environment. These functions can be performed in small, stand-alone modules, which reduces the cost of a distributed system.
- Autonomous functioning of the system
By interacting with each other, the devices are able to make decisions and perform tasks without human intervention, which reduces the cost of maintaining the system.
- Scalability
Input and output of devices from the network is painless and automatic. The network "will figure it out by itself" which device has appeared in it and how to use it.
- Sensors, sensors, transducers
- Smart home, smart city systems
- Internet of things (IoT)
- Industrial automation, control
- Robotics
- Medical equipment
- Railway transport
- Consumer electronics
- Communication systems
Hello, Habr!
Today I will talk about such an interesting thing as the real-time operating system (RTOS). I'm not sure if this will be interesting for seasoned programmers, but I think beginners will like it.
What is an RTOS?
If we look at Wikipedia, we see as many as 4 definitions.In short, an RTOS is an operating system that reacts to external events within a certain period of time. Hence, we can understand the main purpose of RTOS - devices in which a quick reaction to events is required (however, in no case do not confuse RTOS operation with interrupts).
Why do we need it?
There are quite a few reasons for this.First, the RTOS supports multitasking, process priorities, semaphores, and more.
Secondly, it is very lightweight and requires almost no resources.
Thirdly, we can get all of the above on almost any hardware (for example, FreeRTOS runs even on 8-bit AtMega).
And fourthly: just play and have fun.
Review of 3 well-known RTOS.
Attention: what follows is my personal opinion.FreeRTOS
One of the most popular RTOS today. Ported to a huge amount of iron. Official site.pros
1) Free2) Ported to a large amount of iron
3) Powerful functionality
4) There are various libraries: graphics, internet and more.
5) Good documentation.
Minuses
1) Quite a complicated process of porting to new hardware.Conclusion: This is a truly professional RTOS with good documentation. It will be good for a beginner if there is already a port on his hardware.
KeilRTX
Until recently, this RTOS was commercial, but recently became open. Works on arm architecture only. Official site.pros
1) Free2) Easily ported to new hardware (within the arm architecture).
3) There are various libraries: graphics, internet and more.
Minuses
1) Working for Keil with her is almost impossible2) Slightly stripped down functionality
3) Only arm is supported.
4) (from personal experience) Loses to many RTOS in speed.
Conclusion: ideal for beginners and small projects.
uc / os
Powerful commercial RTOS. Site .pros
1) A huge number of functions and libraries.2) Supports a lot of iron
Minuses
1) Commercial.2) Difficult to use.
Conclusion: it is a stretch to call it an RTOS for a beginner.
Other interesting RTOS
RTLinux An RTOS based on regular Linux.QNX RTOS based on Unix.
Features of development using RTOS
Well, first of all, you need to understand the following: RTOS is not Windows. It cannot be installed. This system is simply compiled with your program.When writing programs with RTOS, functions in their usual sense are not used. Instead of functions, processes (or tasks) are used. The difference is that processes, unlike functions, are infinite loops and never end (unless someone or he himself kills him - that is, unloads him from memory).
If several processes are enabled, the RTOS switches them, displaying machine time and resources in turn. This is where the concept of process priority arises - if two processes simultaneously need machine time, then the RTOS will give it to the one with the higher priority.
In RTOS there are special delay functions - so that time is not wasted during the delay of one process, the second is executed.
Now let's talk about such a thing as a semaphore - this is such a thing that controls a process's access to application resources. For each resource there is a marker - when a process needs a resource, it takes it and uses this resource. If there is no marker, then the process will have to wait for it to be returned. I will give an example: different processes send information on one UART. If there was no semaphore, then they would send bytes one by one and it would be a mess. And so the first process took the marker on the UART, sent a message and gave it to the second (and so on - ad infinitum).
Additional RTOS libraries.
RTOS often offer various libraries to work with, for example, with graphics, the Internet, etc. They are really comfortable and you shouldn't hesitate to use them. However, remember that without the RTOS for which they are written, they will not work.Here are some examples:
For RTX
Embedded system, embedded system An embedded system is a specialized computer system in which the computer itself is usually embedded in the device it controls.
Characteristics:
- Very low power consumption, on the order of 0.5 to ~ 20 watts
- Small size
- Lack of large heat removal (cooling) systems. Often the CPU is not cooled at all or a small heatsink is used.
- CPU and system logic, as well as some other ICs, are often combined on a single crystal (System On Crystal = SOC)
The basis for the construction of embedded systems can be single-board or single-chip microcontrollers, specialized or general purpose CPUs, FPGAs. An interesting feature of some types of embedded systems is the use of rather outdated processors of the x86 family (for example, i386, i486, Pentium) and their clones due to low power consumption and low cost (about $ 1-5). Also, many kinds of embedded systems use ARM architecture CPUs.
At the moment, a fairly large number of companies (including in Russia) produce single-board computers based on microcontrollers and CPUs with RISC architecture. Among them Advantech, AAEON, Advanced Micro Peripherals (AMP), Ampro Computers, Diamond Systems, iBASE, InnoDisk, Fastwel (Russia), Lippert, Octagon Systems, RTD Embedded Technologies, Tri-M Systems - Engineering, SanDisk, STEC. Examples of embedded systems include ATMs, avionics, PDAs, telecommunications equipment, and the like.
Some embedded systems are used in bulk (eg RFID devices). Embedded systems are an attractive target for malicious code creators due to their ubiquity and relative defenselessness. Malicious code for embedded systems is gradually emerging (Cabir, RFID virus); Fortunately, this process is still hampered by the heterogeneity of embedded devices, the lack of dominant software, and limited functionality of some types of devices. On the other hand, the task of antivirus companies and computer security researchers is also complicated by these circumstances, as well as by the low power of embedded systems, which often does not allow the use of common antivirus software.
The main manufacturers of CPUs for embedded systems are VIA technologies, Transmeta Corporation, Infineon Technologies.
Operating systems for embedded systems
Embedded systems use about real-time operating systems (RT OS).
A real-time operating system OS is an OS that reacts at a predictable time to unpredictable external events. Sometimes RTOS is called interactive systems of constant readiness. They are classified in the RTOS category based on marketing considerations, and if an interactive program is called "working in real time", it only means that requests from the user are processed with a delay imperceptible to humans. Sometimes the concept of a real-time system is equated with a "fast system", but this is not always correct, since it is not the delay time of the RTOS response that is important, but that this time is sufficient for the application in question and it is guaranteed.
Sometimes systems are distinguished "Hard" and "soft" real time... The "hard" real-time OS guarantees the execution of some actions in a certain time interval, the "soft" real-time OS, as a rule, manages to perform actions in a given period of time, but does not completely guarantee this. Most software is soft real-time oriented.
Such systems are characterized by:
- guaranteed response time to external events (interruptions from equipment);
- a rigid subsystem for scheduling processes (high-priority tasks should not be supplanted by low-priority ones, with some exceptions);
- increased requirements for the response time to external events or reactivity (the delay in calling the interrupt handler is no more than tens of microseconds, the delay in switching tasks is no more than hundreds of microseconds)
A classic example of a task requiring an RTOS is controlling a robot taking a part off a conveyor belt. The part is moving and the robot has only a small amount of time to pick it up. If he is late, then the part will no longer be in the correct section of the conveyor, and therefore, the work will not be done, despite the fact that the robot is in the correct place. If it is positioned earlier, then the part will not have time to drive up yet, and it will block its path.
Windows CE (aka WinCE) is a variant of the Microsoft Windows operating system for handheld computers, mobile phones, and embedded systems. Windows CE is not a "stripped-down" version of Windows for the desktop and is based on a completely different kernel. The main disadvantages of the system include the complete absence of the necessary software applications. Supports x86, MIPS, ARM architectures and Hitachi SuperH processors.
The main competitors of WinCE are VxWorks, eCos, OSE, QNX, LynxOS, Symbian OS, OS-9 as well as various Linux derivatives (e.g. uClinux ) and, most famous, PalmOS ... Some device manufacturers also make their own system.
Windows CE is optimized for devices with minimal memory: the Windows CE kernel can run on 32KB of memory. With a graphical interface (GWES), Windows CE will need at least 5 MB to run. Devices often do not have disk memory and can be designed as "closed" devices, with no user expandability (for example, the OS can be "hardcoded" into ROM). Windows CE meets the definition of a real-time operating system.
Many platforms are based on Windows CE, including Handheld PC, Pocket PC, Pocket PC 2002, Pocket PC 2003, Pocket PC 2003 SE, Smartphone 2002, Smartphone 2003, Windows Mobile, as well as many industrial devices and embedded systems. The Sega Dreamcast had Windows CE support. Windows CE itself was not included in the initial delivery, but it could run on a set-top box from a CD. Some games have used this feature.
The names Windows CE, Windows Mobile, Pocket PC are often used interchangeably. This is not entirely correct. Windows CE 3.0 is a modular operating system that serves as the basis for multiple device classes. Any developer can buy a Platform Builder that contains all these components and programs to build their own platform. However, applications such as Word Mobile / Pocket Word are not part of this toolkit.
Windows Mobile is best thought of as a set of platforms based on Windows CE. Currently, this set includes platforms: Pocket PC, SmartPhone and Portable Media Center. Each platform uses a different set of Windows CE components, plus a different set of related features and applications.
Windows CE .net is the codename for Windows CE version 4.2.
Windows Embedded CE 6.0(codenamed "Yamazaki") is the sixth version of the Windows Embedded operating system targeted at industrial controllers and consumer electronics companies. Windows Embedded CE 6.0 has a completely redesigned kernel that supports over 32,000 processes, up from 32 in previous versions. The virtual address space allocated for processes has increased from 32 MB to 2 GB.
Windows Embedded CE 6.0 was released on November 1, 2006.
Windows CE 6.0 R2 was released on November 15, 2007.
Windows Embedded CE 6.0 is also the basis for Windows Mobile 7 (codenamed “Photon”).
QNX is a commercial POSIX-compliant real-time operating system designed primarily for embedded systems. It is considered one of the best implementations of the concept of microkernel operating systems.
How microkernel operating system QNX is based on the idea that most of its components work as small tasks called services. This distinguishes it from traditional monolithic kernels, in which the operating system kernel is one large program, consisting of many "parts", each with its own characteristics. Using a microkernel in QNX allows users (developers) to disable any functionality they don't need without changing the kernel. Instead, you can simply not start a specific process.
The system is small enough to fit on a single floppy in the minimum configuration, but at the same time it is considered very fast and properly “complete” (practically free of errors).
QNX Neutrino released in 2001 has been ported to many platforms and is now capable of running on virtually any modern processor used in the embedded market. Among these platforms, there are families x86, MIPS, PowerPC, as well as specialized processor families such as SH-4, ARM, StrongARM, and xScale.
A non-commercial version is available for download on the developer's website.
LynxOS- Unix-like real-time operating system designed for embedded systems, compliant with POSIX standards and, more recently, GNU / Linux operating system. LynxOS is used primarily in aviation, industrial process control systems and telecommunications.
ChorusOS is a microkernel real-time operating system designed for embedded systems. In 1997, Sun Microsystems bought Chorus systems, the company behind ChorusOS. In August 2002, the Founders of Chorus Systems formed a new company, VirtualLogix, and began developing embedded systems using Linux and ChorusOS.
Nucleus is a real-time operating system created by Accelerated Systems, the embedded systems division of Mentor Graphics, for a variety of processor platforms. Widespread in TV decoders, mobile phones, and other portable and handheld devices. Nucleus is used by Garmin International in a GPS module for civil aviation.
OS-9 is a multitasking, multi-user real-time operating system developed by Microware Systems Corporation.
Used for interactive and embedded systems. Today OS-9 is owned by RadiSys Corporation based in Oregon (USA).
VxWorks- real-time operating system (RTOS) developed by Wind River Systems (USA).
Like most other RTOSs, VxWorks includes a preemptive scheduling kernel with fast interrupt response, interprocess communication and synchronization, and a file system and networking (TCP / IP protocol stack). The package includes tools for cross-compilation, performance monitoring (WindView), remote symbolic debugging, and emulation of various processors. Additionally, a significant number of different protocol stacks, graphics subsystems, and others are supplied, both from Wind River Systems itself and from third parties. The many embedded platforms supported by VxWorks are among the most extensive in an RTOS.
The latest version of the Wind River Workbench IDE (which ships with VxWorks 6.x, as well as 5.x) builds on the Eclipse framework. The previous proprietary development environment was called Tornado.
Usage:
- Mars Reconnaissance Orbiter in Mars orbit (using VxWorks system)
- The Spirit and Opportunity probes and the Mars Reconnaissance Orbiter use VxWorks on the POWER platform. The system is also used in other space missions, such as Deep Impact.
- Planned for use in the latest airliners Boeing 787.
- Communication equipment of many companies (for example, Nortel, 3COM, Alcatel, etc.).
- Linksys WRT54G (ver.5,6, ...), NetGear WGR614 (ver. 5,6,7)
- Some PostScript printers.
- Medical equipment from Siemens AG (in particular, magnetic resonance imaging machines).
- Latest BMW iDrive interface systems
OS2000- Real-time operating system (RT OS) developed by NIISI RAS by order of the Ministry of Defense of the Russian Federation for MIPS and Intel microprocessors.
This RT OS is designed to develop software for systems (software and hardware complexes) operating in hard real time.
Device support:
- Ethernet network devices (NFS, FTP, Telnet protocols), for the Intel version, support is limited to ISA and PCI cards from Realtek, NE2000 compatible cards.
- storage devices - floppy and hard drives (vfat and tar file systems)
There is support for the X Window System, a graphical client-server subsystem used on Unix systems.
An RTOS provides the developer with a framework on which system elements are built and organized. In fact, the benefits extend far beyond the real-time aspect - even for systems that do not need it, because the program can be much better organized if it is based on an RTOS.
RTOS integration allows you to solve many of the problems that can arise with an application program, as it allows multitasking and allows you to break the application into smaller parts (tasks). Each task gets its own priority based on its importance, and preferential scheduling ensures that the microcontroller will execute the task that has the highest priority among the tasks ready to run. In most cases, adding a lower priority task does not affect the system's responsiveness to higher priority tasks.
Currently, ARM- and Cortex-based microcontrollers are available for about the same price as 8- or 16-bit microcontrollers. The additional operability they offer means that the specialized system will perfectly cope with the operation of the RTOS. In addition, the increased complexity of modern applications will benefit from RTOS projects. However, the microcontroller must have at least 16 to 32 KB of flash or program memory in order to use the RTOS successfully.
SELECT RTOS
An RTOS is just one component of a complete development ecosystem. This complexity, associated with the wide range of products available, raises new questions. The designer must decide which RTOS is ideal for the application and which RTOS is ideal for the microcontroller. Hopefully, it’s the same in both cases. In addition, the developer must select programming and debugging tools that work well under the selected RTOS. Fortunately, there are objective sources of information available today for developers to help them answer the aforementioned questions.
HIGH PRIORITY / LOW PRIORITY
The main problem in real-time systems is the time it takes to respond to an interrupt and run custom code (tasks) to process the interrupt. Non-RTOS systems are known as foreground / background and operate as shown in Figure 1. The application calls modules to perform the desired operations: low-priority modules are executed sequentially in the main program loop, and interrupts handle high-priority asynchronous events. Typical applications will do a lot of polling and the program will get messy as the application grows. Without an RTOS, you also have to implement useful services yourself, such as time delays and timers, which are required to run a program with many state machines.
picture 1
MULTI-TASKING
Multitasking is the process of scheduling and switching a processor between multiple tasks that share the processor. One of the most important aspects of multitasking is that it allows the application programmer to control the complexity inherent in modern applications. An RTOS can make application programs easier to design and maintain by managing tasks and transferring information between them.
When the system needs to start another task due to a more important event, the current contents of the processor registers are saved as part of the current task. The context of the new (more important) task is restored to its previous state before executing its code. This procedure is performed by a so-called context switch or task switcher. The current top of the stack for each task, along with other information, is stored in a data structure called a Task Control Block, which is managed by the RTOS.
PLANNING
The order in which tasks are executed is determined by the scheduler or dispatcher. There are two types of schedulers: cooperative (non pre-emptive) and preemptive (pre-emptive).
In a cooperative scheduler, tasks interact (cooperate) with each other to gain control of the processor: when a task frees up the processor, the kernel executes the code for the next most important task, ready to run. Asynchronous events are still served by interrupt handlers, which can make a high-priority task ready for execution, but the interrupt handler always returns to the interrupted task. A new higher priority task will only have access to the processor when the current task voluntarily releases the processor, as shown in Figure 2.
picture 2
When, in the preemptive scheduler shown in Figure 3, an event or interrupt handler makes a task with a higher priority ready for execution, the current task is immediately suspended and the task with a higher priority gains access to the processor. Most real-time systems use preemptive schedulers because they respond faster than cooperative kernels.
picture 3
RESOURCES
The obvious benefit of using an RTOS is that it reduces time to market by simplifying development without consuming a lot of processor resources. Micrium's uC / OS-II, for example, uses only 6 to 24 KB of program memory and 1 to 8 KB of data memory on ARM devices. On small 8- or 16-bit platforms, the costs are even lower - only 4 to 16 KB of program memory.
An RTOS, as a rule, has a deterministic characteristic, that is, a given set of critical tasks can be fully completed by a given deadline. Polling is avoided by performing tasks only when events occur. Tasks waiting for events do not consume processor cycles.
COMMERCIAL ADVANTAGES OF OSRV
Some companies use their own RTOS, but their systems may suffer from lack of documentation and extensive testing. Native RTOS usually cannot be ported to other processors and their code is often imperfect. Worse, if the designer who created them leaves the company, the system may be impossible to maintain.
A commercial RTOS is used in hundreds, if not thousands of projects, and is based on proven code to make sure it works. Micrium's uC / OS-II is FAA / FDA / IEC certified, making it suitable for use in aviation electronics, medicine and other types of safety-critical applications. Even if a device doesn't need the reliability of a RTOS certified for Aviation Electronics, it's still nice to know that the RTOS has gone through extensive testing. uC / OS-II is also highly mobile and can run on over 45 different processors. Application code can be easily ported (ported) from 8-bit to 32-bit architecture and even to DSP. The user is provided with full-scale support and documentation.
Most of the services that an application might need are already integrated into the RTOS. Among them:
Time management - time delays and timers
- Task management - create, delete, suspend, resume
- Mutual exclusions
- Messaging
- Signal transmission
The benefits of using an RTOS are underscored by the availability of a complete portfolio of firmware components (software) as well as middleware including TCP / IP stack, USB stack, CANbus stack, UART, file systems, and graphical user interface. Of course, some components may require more performance than low-end processors.
Two pillars in the commercial RTOS industry make getting started even easier. Many RTOSs, including uC / OS-II, are now sold on a royalty-free basis, which is much more profitable than using RTOSs, which require continuous royalty payments. Often, RTOS is included, in the case of a license purchase, in many starter kits (MCU starter kits).
