What is Real Time Operating System?

Elder Costa <elder.costa@terra.com.br> writes:

> $50? Did you use it in a commercial product?

True, we paid more.  It was only $2,500 per product though (a one
time fee), which is small changed compared to a lot of things.  But
for some reason, it took some time for the legal and financial people
to cough up a check, which caused my boss to become annoyed since it
was such a small amount relative to other purchases.

-- 
Darin Johnson
    Gravity is a harsh mistress -- The Tick

sfbong@tm.net.my (Allen) writes:

> > In other words it can't continuously put it off because something
> > more important came up.
> 
> Does it mean that an interrupt can not be interrupted by another
> interrupt?  Or in another word, there is no interrupt priority (except
> put into queue) in RTOS?

It depends.  Most of them will allow preemptible interrupts.
Others don't, but then it's up to the programmers to ensure that
the interrupt handlers do the minimum necessary work (ie, our
standard was that the handlers would do nothing more than signal
a semaphore or enqueue a message).

The phrase "something more important" is probably wrong up above.
It should probably read "can't continuously put it off because it's
still dealing with something less important".  The programmer gets
to decide what's important, not the OS.

Compare to a typical UNIX implementation, where system calls are not
preemptible.  An interrupt usually just gets told "situation noted,
we'll get back to you" and then the OS goes back to what it was doing.
Only at the end of the system call does the OS call the interrupt
"back end" handlers, at which point it may notice that a higher
priority task is ready to run.

-- 
Darin Johnson
    Luxury!  In MY day, we had to make do with 5 bytes of swap...

Allen <sfbong@tm.net.my> says...
>
>CBFalconer <cbfalconer@yahoo.com> wrote...
>> 
>> A system where you can make a guarantee of the maximum interval
>> between requesting an action and performing that action.
>
>I can understand this one.
>
>> In other words it can't continuously put it off because something
>> more important came up.
>
>Does it mean that an interrupt can not be interrupted by another
>interrupt?  Or in another word, there is no interrupt priority (except
>put into queue) in RTOS?

There is interrupt priority.  It is up to the engineer who designs 
the real-time system to design it in such a way that it meets all
deadlines no matter what.  He could do this by not allowing an
interrupt to be interrupted by another interrupt, but that's not the
usual method.  The usual method is to make sure that the deadline 
is reached even though the interrupt can be interrupted by another
interrupt.  This involves keeping the interrupt routines short,
prioritizing them, insuring that there are sufficient resources to
meet the worst case needs, avoiding priority inversion, etc.

Using a RTOS doesn't make the system real-time.  That takes an 
engineer.  Using a non-RT Operating system makes the engineer's 
job much harder, but he can still do it by, for example, locking
up the OS and having a machine language program take over the 
system.  This is more common than you might expect; I often use 
FreeDOS or MS-DOS to boot a system and put my program into memory,
then I transfer control to my program and it runs with no operating
system until the system loses power.
 


-- 
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
have an "impossible" engineering project that only someone like 
Doc Brown can solve?  My resume is at http://www.guymacon.com/ 

Allen wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote:
>> Allen wrote:
>>>
>>> I saw the word "RTOS" appeared many times in this group but have
>>> no idea what it is.  So could the experts here give me a brief
>>> idea what is it in non-technical terms?
>>
>> A system where you can make a guarantee of the maximum interval
>> between requesting an action and performing that action.
> 
> I can understand this one.
> 
>> In other words it can't continuously put it off because something
>> more important came up.
> 
> Does it mean that an interrupt can not be interrupted by another
> interrupt?  Or in another word, there is no interrupt priority
> (except put into queue) in RTOS?

That's an implementation detail :-)  You asked what it is.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!
P

> > I disagree.  In either of those systems it is possible (although
> > unlikely in the case of Linux) that they may take over 60 minutes
> > to respond to an input while operating normally.  Just last week
> > I had Windows NT sit there for six hours thinking about how to
> > print a pdf file with Japanese fonts in it, and during that time
> > all further print requests waited.
> >
> >
>
> I agree with Guy, recently I decided to check out a screensaver in KDE on
my
> other laptop and the darn thing locked up the whole desktop! Can you
> imagine? Luckily that Linux box wasn't running the nuclear reactor. tee
hee
>

Neither Guy's application problem, nor yours would have been fixed by using
an RTOS.  These are problems due to the interaction of applications with
each other and with the operating system.  You can get the same sort of
problems under an RTOS, and inevitably will if you burden it with as many
tasks and as much of someone else's unknown code (whether or not you have
the gigabytes of source that made it) as is present in the average Windows
or Linux system.

Anybody who did decide to check out a screensaver on a Linux box that they
had running a nuclear reactor deserves the outcome they would get.
Unfortunately, the others around them wouldn't.

Cheers,
Alf


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.601 / Virus Database: 382 - Release Date: 29/02/2004

"Unbeliever" <alfkatz@remove.the.bleedin.obvious.ieee.org> wrote in message
news:4066344d$0$31775$afc38c87@news.optusnet.com.au...
> Neither Guy's application problem, nor yours would have been fixed by
using
> an RTOS.  These are problems due to the interaction of applications with
> each other and with the operating system.  You can get the same sort of
> problems under an RTOS, and inevitably will if you burden it with as many
> tasks and as much of someone else's unknown code (whether or not you have
> the gigabytes of source that made it) as is present in the average Windows
> or Linux system.
>

Agreed, that was the point of my post.

> Anybody who did decide to check out a screensaver on a Linux box that they
> had running a nuclear reactor deserves the outcome they would get.
> Unfortunately, the others around them wouldn't.
>

Agreed, it was some satirical humor in that at least you can run a
screensaver on Windows without the desktop locking up. None of us here would
run a Nuclear Reactor on a consumer OS. At least, I don't think so. :-)

Allen <sfbong@tm.net.my> wrote:

> So the OS for the computers that runs a 747 or an electronic organ is
> also considered as RTOS?  

*If* that computer is running any OS to speak of: absolutely.  Such
systems definitely have to be real-time, so if they employed a non-RT
OS, they would be criminally dangerous or plain unusable,
respectively.

For the 747, there's a good chance at least one of the independently
designed, triple-redundant computer systems will have been made based
on some commercial RTOS.

For an electronic organ, it's far less likely -- the instriuments
typically addressed by that term usually don't have any computer
inside, let alone one complicated enough to require an RTOS to build
the custom code on top of.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Allen <sfbong@tm.net.my> wrote:

> Does it mean that an interrupt can not be interrupted by another
> interrupt?  

It may mean that.  Or you can have severall interrupt priority classes,
and the deterministic time from an interrupt firing to its handler being
called will then have to be calculated by taking into account the execution
of all handlers of interrupts of higher priorities.

An RTOS may have to forcibly kill an interrupt handling routine if it
takes longer than the timing constraint can allow, in order to
guarantee the real-time condition for other interrupt sources at the
same priority level.

The only real guarantee a RTOS can make independant of the application
is that of the maximum delay between a maximum-priority even and the
*start* of its handler.  Once that handler is running, the
responsibility for correct behaviour of the system at large is in the
hands of the application programmer, not the RTOS.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

> I saw the word "RTOS" appeared many times in this group but have no
> idea what it is.

http://www.FreeRTOS.org/implementation
http://www.eeglossary.com/rtos.htm
http://www.faqs.org/faqs/realtime-computing/faq/
http://www.qnx.com/download/deliver.php?programid=8090

etc.

In article <cu1zna1rfb1.fsf@nokia.com>, Darin Johnson wrote:

> Later, a project went with OSE, which was a bumpy ride.  In hindsight,
> there was no advantage over the $50 uC/OS II, unless we had been
> rewritten our application from scratch.

$50??

The license must have changed a lot since then -- now it's a couple grand.

-- 
Grant Edwards                   grante             Yow!  I'm having fun
                                  at               HITCHHIKING to CINCINNATI
                               visi.com            or FAR ROCKAWAY!!