Re: So... What are the alternatives? Was: I don't use an RTOS because...

From: CBFalconer (cbfalconer_at_yahoo.com)
Date: 01/21/05 

Date: Fri, 21 Jan 2005 22:48:08 GMT

larwe@larwe.com wrote:
>
>>> A simple event-loop programmed from scratch along with the rest
>>> of the application doesn't fit these criteria by any stretch of
>>> the imagination.
>
>> I assert that it can because I with others developed just such a
>> simple event loop topology which was reused in a range of products
>> of varying complexity over a ten year period.
>
> So? Semantic point. You call this an RTOS or at least an OS. I, and
> also apparently Hans-Bernhard, call it a programming technique for
> OS-less embedded systems. Pursuing this to its logical conclusion
> you would be calling any switch statement an OS, no?

I see you are using google, and managing to make it quote. Does it
fail to attribute or are you stripping those off?

To the subject. To me, an OS is something that manages resources,
some of which are sharable (like a file system, maybe memory) and
others are not, such as displays, ports, disk drives. The OS has
to be able to apparently run at least one program, when sharability
becomes moot, or multiple, when sharing and exclusion becomes very
important. Now a critical thing becomes "how does the OS schedule
things". This may be by pre-emption (fairly safe, but complex) or
by mutual agreement between programs (requiring cooperation). Even
further, the OS may be able to guarantee some sort of response time
to an external stimulus, regardless of the various programs
action. This last makes it a RTOS.

Notice that with sufficient rules the cooperative system can be a
RTOS. In all cases the complete gestalt of OS and programs (or
processes) can be viewed as one big single thread of execution.
(Except some real multi-processing systems). A model for a
cooperative system can be as simple as:

    while (running) {
       process(n);
       n = selectnext(n);
    }

accompanied by specifications of how process operates. If these
rules include specification of the longest execution path, together
with a limitation on the range of n, it can be used to build an
RTOS. 

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson