I don't use an RTOS because...

>Subject: Re: I don't use an RTOS because...
>From: "Ignacio G. T." igtorque@yahoo.es 
>Date: 13/01/2005 16:33 GMT Standard Time
>Message-id: <34nm81F4dq5ssU1@individual.net>

>
>> 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.

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.

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.

On Thu, 13 Jan 2005 22:01:21 -0200, Elder Costa
<elder.costa@terra.com.br> wrote:

>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.

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.)

"Elder Costa" <elder.costa@terra.com.br> wrote in message
news:34ogclF4ak2g2U1@individual.net...
> 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.

Hierarchies of state machines, basically.

Steve
http://www.fivetrees.com

> > I use an RTOS every day, but I was wondering why
> > a lot of people still don't use one?
>
> 2k flash, 128 bytes RAM, a lot to do. Nuff said?
>
>
> I use an RTOS if I need one and have the space- I even wrote one (very
> simple one) once.
>
> Paul Burke

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.

>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?

So, you do write you C libraries yourself too ?

-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@epost.de instead !

Robert Scott wrote:
> It is quite possible to write big messy buggy code even if you are
> using an RTOS.  
Agreed.

> What do you think using an RTOS buys you in the way of
> insurance against such things?  
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.

Steve at fivetrees wrote:
> 
> Hierarchies of state machines, basically.

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.

Elder Costa wrote:

>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.

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 <http://www.guymacon.com/>