Please look around yourself. You can see many products included embedded computing systems inside themselves: VCR’s, digital watches, elevators, automobiles and automobile engines, thermostats, industrial control equipment, scientific and medical instruments, aircrafts and many other. Millions and millions of them are around yourself, each minute making their computations. People use the term embedded system to mean any computer system hidden in any of these products.
Software for embedded systems must handle many problems beyond those found in application software for desktop or mainframe computers. Embedded systems often have several things to do at once. For example think that your are waiting for guests invited to your birthday and to your own flat (in cold and windy winter time) which has one door. What are you doing? Listening for the door bell. When the doorbell starts ringing, it is a signal for you to open the door for your guests. This is simple. Now think, that you live in a big house with many entrances and doors, suitable for your guests to come in. In this case if there is a doorbell ringing, you start your quick way to the relevant door. So far this is still simple. But lets assume, that two doorbells ring at the same time? Which way to run? The closest? May be. Another quests will wait. No problem so far. But if you have three doors? If your quests can wait, you must simply run more quickly. But if there must be your favorite quest among all of them (let say a queen of England) and she cant wait, what will you do?
One solution would be to give her an invitation to go through the main door and if the main doorbell is ringing, in spite of all, run to open the main door. In this case the queen will wait the minimum possible time. But if this time is definitely described (let say 10 seconds for the queen) and you are alone in your house. So just in the time, when the queen rings the doorbell, you are in the far part of your house? Still a problem?
Although this stuff seems to be not very serious as in the case of your house, but lets study the case of the aircraft like Boeing or Airbus. Thousands of doorbells and all of them are important. In such a case the maximum possible reaction time is very critical and to make a good peace of software for such kind of applications is not a trivial task. In computing we call the doorbell as -"interrupt" and the time you need to open the door is the "reaction time" of the operating system. In embedded computing we have similar problems to the described above. But we have a solution – real time operating systems or RTOS in the other way. Despite of similar name, most real time operating systems are rather different from desktop machine operating systems such as Windows or Unix. There are several main differences.
|
Desktop |
RTOS |
|
The operating system takes control of the machine as soon as it is turned on and then lets you to start your applications. You compile and link your applications separately from the operating system. |
You usually link your application and RTOS. At boot-up time your application usually gets control first, and then starts the RTOS. |
|
Usually strong memory control and no recovery in the emergency case |
RTOS usually do not control the memory but the whole system must recover anyway |
| Standard configuration |
Sharp configuration possibilities and also the possibility to choose the limited number of services because of the limit in the memory usage |
We will furthermore discuss the environment RTOS in details. We will discuss the concept of a task, the share data problem, semaphores and some more issues. Commercial RTOS are available from numerous well known vendors such as VxWorks, VRTX, pSOS, Nucleus, C Executive, LynxOS, QNX, MultiTask!, AMX, and so on. The main standard is called POSIX.
