Hi Guys,

    Let's not get too agitated on this issue.

    It's nice to know that there is a solution
    such as Olin's solution and commercial
    solution like Salvo.

    I'm sure Salvo provider is entitled to
    profit from engineers who is too lazy to
    write their own task manager ;-)

    Another simple solution would be to write
    the modules in the "superloop" as state
    machines.

    State machines acts more or less like a
    cooperative OS by slicing codes into
    fragments that gets a tiny slice of CPU
    time in a particular state. It gives
    up CPU time before proceeding to the
    next state, this way, letting other state
    machines (modules) gets a share of CPU
    time in the "superloop".

    Of course, it's still non-deterministic,
    but by careful slicing of code in the
    state machine, system responsiveness
    can be very much improved compared to
    conventional function call.

    Critical events can still be handled
    in foreground by interrupt subroutines.

    A good side effect is that it helps you
    identify which state that your app is
    stucked in during debug.

    I've used state machines in complicated
    control application such as Compact Disc
    servo control and it works pretty well
    without an RTOS.

Rgds,
Peter Tiang

----- Original Message -----
From: "Olin Lathrop" <olin_piclist@EMBEDINC.COM>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Thursday, August 16, 2001 8:48 PM
Subject: Re: [EE]:Embedded system ,RTOS


> > That's all very interesting -- I used to write code like that. But to
> > do it in Salvo takes just one line:
> >
> >         for (;;) OSSched();
> >
> > Time is money ...
>
> I hope you're not seriously suggesting one should run out and buy an RTOS
to
> save writing a few tens of lines of code!  Evaluating RTOSs, ordering one,
> installing it, and reading its documentation would take many times longer
> than just writing the code.  Like you said, time is money.  And then you
> have something that you know exactly how it works, and can modify for
future
> projects to suit.  All make versus buy decisions don't automatically come
up
> "buy" because you want people to buy your product.
>
> I'm not against RTOSs in general, but they just don't make sense on really
> small processors like the 16xxx PICs.  I've also noticed that most
embedded
> control problems don't need most of the features of most RTOSs.  There are
> very few problems that can't be solved very nicely with a simple
cooperative
> task model where tasks can optionally sleep until some number of clock
ticks
> have elapsed.
>
> I know you say you now program everything using your RTOS.  That only
proves
> an RTOS can be used if you really want to.  If you didn't have an RTOS and
> didn't have the bias of trying to profit from one, you would find most
> problems can be solved very well without one.
>
>
> ********************************************************************
> Olin Lathrop, embedded systems consultant in Littleton Massachusetts
> (978) 742-9014, olin@embedinc.com, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics
>
>
>

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics