When A Embedded System Need An OS

Hi Experts,

I am doing my masters in embedded systems..... when does an embedded system needs an opereting system....under what circumstances it is needed.

pls clear my doubt

Reply to
Harry
Loading thread data ...

Op Mon, 18 Sep 2006 09:31:32 +0200 schreef Harry :

Your question is similar to: "When does one need to wear snow shoes....under what circumstances it is needed."

The answer to this question is that it is never needed. You can always struggle forth, or roll, crawl, use skis etc. I think the question should be: when does one _want_ to wear snow shoes?

If you know you want to wear snow shoes, but don't have them, then the obvious next question is: "When does one want to buy snow shoes, as opposed to making them?"

No can do.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

When the available software saves more work than doing it on your own.

Rene

Reply to
Rene Tschaggelar

When having an OS and the resources to implement one costs less than not having one.

Cheers, Alf

Reply to
Alf Katz

Hi Harry,

actually, an operating system is never needed. It may just sometimes be useful. It is just like asm or a higher language like c. You can code everything in asm, but life can be much easier with c.

So you better ask '..under what circumstances is an OS useful'.

I am neither an expert here since I have only read about RTOSes like VxWorks, QNX, OSEC, and the like. All of my own embedded projects where without an RTOS.

That is, you have an endless

for(;;)- loop in main(). Within this loop, you have to poll certain timer flags. One such timer flag in my project, e.g., ticks every second. After a timer tick, I perform all my 1sec-'tasks', one by one. I think this is called round-robin scheduling. If something 'asynchronous' happens, such as a new value of the A/D converter or an incoming message from the CANbus, then I have to handle this in Interrupt Service Routines.

An RTOS provides better and more flexible ways to schedule your tasks (or processes). You can give your tasks different priorities. It also provides mechanisms for inter process communications like semaphores, mailboxes, or queues. All of this frees you among others from writing complicated Interrupt Service Routines that can be a nightmare to get right. Another advantage is that some RTOSes support several processor achitectures that makes porting to these processors easier.

Disadvantages of RTOSes can be price, royalties, support, and a certain overhead (memory and time). Also, in most cases you need to write device drivers for special Hardware which is probably no easy task if you don't know the RTOS yet.

I recommend you to read the following books about Embedded Systems:

Jack G. Ganssle, The Art of Designing Embedded Systems.

David E. Simon, An Embedded Software Primer

I found them great books to read. As I remember, they also have a chapter about using an RTOS.

Best regards

Johannes

Reply to
Johannes Eble

As has been stated an embedded system never _needs_ an OS (at least not an explicit one separate from the application code), but it is often best to have one -- just as it is often best not to have one.

Having an OS gives you a higher hurdle to overcome before you get basic functionality -- you may spend 10% of your time before 'first light' getting the OS up and running. Having an OS also means, however, that each incremental increase in functionality is much smaller. Consider these two effort vs. results curve (view in fixed-width font, and pardon the lousy graphs):

. .... effort . .... . .... . . . | . | --'------------------------> --'----------------------->

results results Without OS With OS

The reason for this is that an OS comes with a certain amount of built-in complexity, which you must account for when you get the thing up and running, and at least some of which you'll have to understand before you can use it effectively. Furthermore, it'll have a complex interface to all of this built-in functionality which you'll have to learn. Once you do that, however, you'll find that the OS provides you with a bunch of services to do common things, so doing something like adding a task to control a whole new section of hardware becomes an incremental addition to you code, instead of a major hack-and-replace job on a big tasking loop.

The basic result is that if you have something small to do you should go without an OS, while if you have something big to do you should go with an OS. If you have something in the middle be prepared to argue endlessly with coworkers and USENET contributers about what's appropriate, what constitutes 'big' and what constitutes 'small' (I'll stay out of that argument, other than to point out that there's a good chance that what you're most comfortable with is probably the best thing in the short term).

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

all embedded systems have an operating system, some are stand alone from the application and some are integrated directly into the application. usually the size of the system determines if you need a stand alone commercial OS, but sometimes even in large systems other factors (like life critical applications) may prohibit you from using an off-the-shelf proprietary OS.

Reply to
steve

1) You have two or more asynchronous processes. 2) You want to use OS services: file system, TCP/IP stack, etc. 3) ...
--
WBR, Yuriy.
"Resistance is futile"
Reply to
Yuriy K.

A better question is: Why is a Masters candidate asking a bunch of strangers to explain his thesis for him?

--Gene

Reply to
Gene S. Berkowitz

with the addition, "I need to know because I'm writing a guide on how to cross the Antactic by foot" ;)

-Lasse

Reply to
langwadt

Now all you have to do is define "costs". :)

--
Grant Edwards                   grante             Yow!  HUGH BEAUMONT died
                                  at               in 1982!!
 Click to see the full signature
Reply to
Grant Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.