I use an RTOS every day, but I was wondering why a lot of people still don't use one? I find it a very useful tool, but I still run into a lot embedded engineers that don't use one, why?
Too hard?
To expensive?
I don't need one?
Never bothered to learn?
My boss said no way?
I almost always use RTOS's these days, but:
If the application is way small, or if it requires very high reliability, then an RTOS doesn't make sense. Otherwise its useful.
If you've never ever used an RTOS before you would pull the threshold much higher -- learning to effectively use an RTOS is a pretty steep curve for any one project, but it sure makes sense in the long run.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On Wed, 12 Jan 2005 19:57:30 -0800, snipped-for-privacy@Rasdoc.com wrote in comp.arch.embedded:
Use them in some places, either commercial or custom built in house, don't use them in others.
An RTOS is expensive in terms of code space, RAM space, and execution time even it has no direct monetary cost for source or run-time licenses. How expensive it is in those terms relative to the rest of the application depends on a lot of factors.
I don't use one when I don't need one. There are two major reasons that I can see for using an OS (RT or not) in an embedded system:
On the other hand, something like an 8-bit micro built into a hand control device that has to debounce user button presses and send messages over a serial or CAN bus when they happen doesn't need one.
Know how to use 'em, know how to make 'em for special purposes.
My boss knows enough to leave such decisions to me, unless the financial cost is significant.
-- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
I drive a Truck every day, but I was wondering why a lot of people still don't use one? I find it a very useful tool, but I still run into a lot embedded engineers that don't use one, why?
Too hard?
To expensive?
I don't need one?
Never bothered to learn?
My boss said no way?
Simple CPUs and simple project do not need them. Bigger project MUST use them. Then of course there is the projects in the middle that could go either way.
The engineer needs to decided what the project needs. Cost , learning curve, memory, and familiarity are all part of the equation.
dont know
sometimes, everything is expensive compared do FreeBSD and Linux
yes, but i'm lucky
yes
I'm not that schizofrenic :))
Pozdrawiam.
-- RusH // http://randki.o2.pl/profil.php?id_r=352019 Like ninjas, true hackers are shrouded in secrecy and mystery. You may never know -- UNTIL IT'S TOO LATE.
2k flash, 128 bytes RAM, a lot to do. Nuff said?
Or requirements are simple. I don't want to use a PowerPC and 256G RAM and a compact flash boot disk just to flash a couple of LEDs. Though it looks better on the CV.
I use an RTOS if I need one and have the space- I even wrote one (very simple one) once.
Paul Burke
They are only really usefull for big projects, especialy team efforts.
Not really. They are very useful when you need to do unrelated tasks on a single system, or have a time sensitive control task and a number of other tasks (human interface, setup, management) that you would like to operate transparently while the main task goes on. Very useful in their place, can be very expensive (in resources if not fees) out of place.
Paul Burke
As others have said, RTOSs have their uses. But they're not a panacea.
Most of my applications are cost-sensitive and high-reliability. If I had to choose one reason for *not* using an RTOS, it would be reliability. I'm a big fan of the KISS principle, and I'm adept at writing complex but reliable schedulers. Why should I spend money on something that contributes bloat and reduces reliability?
Steve
In fact, one of the biggest embedded project I've worked to date (+100,000 LOCS) is the only one in which I have not used an RTOS! That's because it was safety-critical, and it was much cheaper to design it as a one-task program and show its safety level this way than to use an RTOS and show its safety level with the several tasks approach.
Reasons -
1/. Cost 2/. Size 3/. Complex of project - Do you thing toggling a lamp need a RTOS ?
Hmm, I cant imagine ever using a rtos to run unrelated tasks, the inter thread messaging system is it's only real benefit over more traditional methods. It's true that I tend to make smaller real time systems that probable aren't suitable for a rtos anyway, nevertheless I have no trouble running a dozen tasks at once.
I have followed the thread with a great dose of interest. Though a small system can be implemented with an infinite loop running the main tasks and some interrupts to handle asynchronous events, I wonder how one could handle more complex systems with no RTOS (or at least a multithread cooperative scheduler) without getting into a big messy buggy code. I guess it is not an mission impossible but I cannot see clearly how to achieve it without a great effort and cost.
Thus I would appreciate hearing from you folks about the alternatives to an RTOS, with some links to code or concepts if possible.
TIA & Regards.
Elder.
It is quite possible to write big messy buggy code even if you are using an RTOS. What do you think using an RTOS buys you in the way of insurance against such things? A simple cooperative multithreading scheduler is something that can be written in less than a page of code. It is not something you need to buy from someone else. But if you find yourself re-inventing the more complex features of a full RTOS, then you should just use one that has been developed and checked out rather than roll your own. Deciding when to do what depends on what services you need the RTOS to perform for you.
-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)
Hierarchies of state machines, basically.
Steve
4 k Flash, 512 byte SRAM and using message passing proprietary single stack O/S... Application: press a button , send/receive commands on serial port, light LEDs depending on commands and button.
It is fairly easy to do this with a scheduler calling tasks implemented as statemachines.
-- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.
So, you do write you C libraries yourself too ?
-- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use @epost.de instead !
Agreed.
I don't. RTOS or whatever does not preclude the design phase. It's just seem to me for more complex designs with strict latencies it makes the design task easier, depite its caveats.
Regards.
Elder.
Would you have any pointer to an example of such a system?
I've used this scheme in the past and turned out with messy code. :-) Not the scheme's fault though. :-) It was a pretty simple message passing system that worked fairly well for task isolation but the tasks themselves were awfully implemented, making the outcome complex.
Elder.
I worked on an application where we were making eight systems total that cost several million dollars each. Most of what we did was done with one microcontroller per task, each running a classic loop-style real-time program and communicating with each other through a redundant serial buss.
One portion of the design wasn't well-suited for that approach, so I specified a system running the QNX RTOS, but to the rest of the system it just looked like one more device on the buss.
Doing it all in one program would have been much, much more complex. Separate processors communicating with each other are the purest form of object-oriented programming.
-- Guy Macon
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.