Hai every body,
how an embedded os differs from normal os's ?
what special things i have to do for it appart from normal os's ?
i have already developed a realmode kernel (in dos).
WIN THE WORLD !!
embedded os
-
Schol-R-LEA
RE:embedded os
An embedded OS is one used for running a special-purpose microcontroller, like those in routers, microwave ovens, elevator controllers, traffic light sequencers, etc. Until quite recently, the idea of a 'embedded operating system' was a contradiction in terms; even now, most microcontroller applications are written to run on bare hardware, with a single body of code running from power-on to shutdown. However, as the cost hardware dropped and the demand for software rose, some of the more complex embedded systems - telephone switching equipment and fire control systems were the classic examples - needed a full OS that could switch quickly and efficiently between many seperate tasks, and run certain calcluations between events. By the early 1990s, it had become feasible for even far simpler applications to be built around off-the-shelf RTOSes like eCOS rather then spend all the development money on coding and testing a complete system.
The key requirements of an embedded OS are:
- It has to drive the hardware in question. This may seem obvious, but you have to keep in mind that there are no standard drivers or libraries for, say, a robotic arm for painting car body parts on an assembly line. Every new embedded project involves a lot of new coding; the OS has to be able to support that code, whatever it is.
- It must be an RTOS (real time OS). If it cannot guarantee the repsonse times for time critical operations, it is of no use. It doesn't *have* to be very fast, necessarily, but it *must* be consistent, and the maximum response time has to be within the required tolerances.
- It has to be ROMmable. That is, it must be possible to run it from ROM, usually without loading the code itself into RAM. This is slowly changing as flash memory and cheap minature hard drives begin to appear, but for cost and reliablity most embedded systems are still in ROM and will be for the foreseeable future.
- It has to be small. Even now, most embedded systems don't load more than 64K each of ROM and RAM; codebases as small as 4K are still common.
- It has to be reliable; if you're programmable clock controller crashes, how the hell do you reboot it? Add to this the fact that many embedded systems are mission critical, with human lives dependent on their correct operation (aircraft, nuclear power stations, water works) and it is clear that *no* amount of error is acceptable (even though it is unavoidable of time). There have already been some notorious cases where software failures have resulted in deaths; regular reading of the RISKS mailing list is advisable to anyone coding for RT systems.
- It often has to run on the cheapest hardware available. This factor cannot be understated. A typical embedded application (toster overns, for example) may ship *millions* of units, a ten of a cent extra cost per unit could make a huge difference in the bottom line. Many embedded systems even today are based on such old workhorses as the 8051, 8080A, z80, and z8; those that need an OS are usually on newer CPUs, but not all *that* new - 80486s, perhaps. This is also why the memory requirements are so tight; even with memory prices falling through the floor, the less that is used the better in this case.
HTH.
The key requirements of an embedded OS are:
- It has to drive the hardware in question. This may seem obvious, but you have to keep in mind that there are no standard drivers or libraries for, say, a robotic arm for painting car body parts on an assembly line. Every new embedded project involves a lot of new coding; the OS has to be able to support that code, whatever it is.
- It must be an RTOS (real time OS). If it cannot guarantee the repsonse times for time critical operations, it is of no use. It doesn't *have* to be very fast, necessarily, but it *must* be consistent, and the maximum response time has to be within the required tolerances.
- It has to be ROMmable. That is, it must be possible to run it from ROM, usually without loading the code itself into RAM. This is slowly changing as flash memory and cheap minature hard drives begin to appear, but for cost and reliablity most embedded systems are still in ROM and will be for the foreseeable future.
- It has to be small. Even now, most embedded systems don't load more than 64K each of ROM and RAM; codebases as small as 4K are still common.
- It has to be reliable; if you're programmable clock controller crashes, how the hell do you reboot it? Add to this the fact that many embedded systems are mission critical, with human lives dependent on their correct operation (aircraft, nuclear power stations, water works) and it is clear that *no* amount of error is acceptable (even though it is unavoidable of time). There have already been some notorious cases where software failures have resulted in deaths; regular reading of the RISKS mailing list is advisable to anyone coding for RT systems.
- It often has to run on the cheapest hardware available. This factor cannot be understated. A typical embedded application (toster overns, for example) may ship *millions* of units, a ten of a cent extra cost per unit could make a huge difference in the bottom line. Many embedded systems even today are based on such old workhorses as the 8051, 8080A, z80, and z8; those that need an OS are usually on newer CPUs, but not all *that* new - 80486s, perhaps. This is also why the memory requirements are so tight; even with memory prices falling through the floor, the less that is used the better in this case.
HTH.