I don't use an RTOS because... - Page 5

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

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


Quoted text here. Click to load it

You talk about that as if it were a bad thing.  :)



Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

Yikes Ian, I didn't realize that I was being so
underhanded.

OK, include open source RTOS, eCos, RTEMS and *many*
others. The "commercial" attribute has no bearing on
my argument. What I *am* saying, and I think most embedded
software engineers would agree, is that when one uses
the term "RTOS", it is commonly assumed that it is preemptive
if for no other reason than the fact that most common
RTOS are preemptive.

I certainly do not deny that there may be those who
do not make this assumption. Of course, applications
written to run under a preemptive RTOS are different
from those written under the non-preemptive variety.

E.g. an application written for an RTOS does not need
to volutarily give time to other threads, unless it
is busy waiting instead of blocking.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it

Despite my comment about Salvo possibly being considered a commercial RTOS
without pre-emption (I believe this is how it is sold to the public since their
catch phrase is "The RTOS that runs in tiny places."), I agree with you, here.

If I see the word "RTOS," I presume that it is has support for pre-emption.
This expectation was, in fact, the reason I remember Salvo so well (I have never
tried to use it.)  I had this expectation when I started reading the manual for
it and was startled when I couldn't find pre-emption support.

My first exposure to the phrase, "real time operating system," came about with
RT-11 on the PDP-11, back in... 1973 or so.  At that time, real-time operating
systems were differentiated from time-sharing systems (like RSTS/E and, later
on, Unix, for example) and from systems that had no pre-emption support, at all.
The "real-time" meant that the operating system was designed from the ground up
to provide the real-time I/O services.  A minimal system required access to a
50/60 Hz clock, for example.  In any case, implicitly if not explicitly, this
idea of "real-time" meant pre-emption.

Today, I think the term "real-time" has been so mixed up by marketplace messages
that it's hard to say that it has any useful meaning we all share in common.  If
I had my choice, I'd prefer that "real-time" have a meaning that usefully
divides away some kinds of things while including others.  But it seems to mean
just about anything you want it to, and in going that way, looses all value it
may have once had.

If so, it means nothing useful now.  It's just a catch phrase.

But if I were to define it, it would be something like this:

A real-time operating system is one which provides an unusual focus on services
for time-critical responses to external/hardware events and does NOT focus on
providing general support for a wide variety of tasks, such as is provided by
Unix.  (Unusual in the sense of not being usual!)  A real-time operating system
should connote "lean" and "timely" and should be differentiated from any which
can be described as "large" (because of the extensive support required for a
wide variety of general purpose services) or "sometimes timely and sometimes
not" (because of the scheduling methods.)

Come to think of it, perhaps the process scheduler is the way to determine
whether or not something is "real-time" or not.  If it supports priorities and
supports an immediate and rapid transition to a high priority task on the basis
of an event with very low latency (for the given processor's capabilities), then
it may be "real-time."  But this *does* mean, if it supports hardware events and
not just software ones, that pre-emption is in place.

Which brings us back to expect that RTOS be a term NOT applied to operating
systems which do NOT feature pre-emption.

Well, that's my meandering on the topic.

Jon

Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it
services
on
by
system
which
a
sometimes

So far so good.

Quoted text here. Click to load it
and
basis
capabilities), then
Quoted text here. Click to load it
events and

Not sure about this. Most time-critical hardware tasks can be broken down
into:
  - the bits that *really* need to run now (via hardware interrupt)
  - the bits that can be dealt with by the scheduler in a synchronous
fashion

I therefore have no trouble with the idea of a real-time co-operative
scheduler. Maybe I'm misunderstanding your point. Perhaps you include
hardware interrupts in your definition of pre-emption (I don't).

Steve
http://www.fivetrees.com



Re: So... What are the alternatives? Was: I don't use an RTOS because...
On Sun, 23 Jan 2005 04:35:32 -0000, "Steve at fivetrees"

Quoted text here. Click to load it

"Synchronous" doesn't mean "real-time" to me.  Maybe that's it.

Jon

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


Quoted text here. Click to load it

Definition:

Describes a computer program or system that must respond to
stimuli within a fixed response time with a predictable and
deterministic upper limit on response.

A fixed frequency synchronous loop with a cycle time that is
less than the required response time is a fine example of a
real-time system.

Perhaps you are confusing Real-Time with Real Fast?.





 


Re: So... What are the alternatives? Was: I don't use an RTOS because...
On Sun, 23 Jan 2005 05:50:54 +0000, Guy Macon

Quoted text here. Click to load it

Actually, no.  I've written real-time operating systems so I'm not quite that
confused, Guy.  I wrote one I've already recently described here, in fact.

I also just laid out my own version of my perceptions and what I consider a
useful meaning.  I've no right to force that on anyone, but you've got my view
of matters.

If you are trying to include a polling loop as an example of a real-time
operating system that should be included in the classification, then the
classification itself loses much meaning to me.  I understand that it CAN be
faster than having to deal with the latencies involved in interrupt handling and
I've used exactly what you are talking about myself for just those reasons.  But
you wouldn't find me calling it a real-time operating system.  You might find me
calling it real-fast, though.

Quoted text here. Click to load it

And here I was thinking that's exactly what you are doing, calling a for-loop a
real time O/S.

Oh, well.  You have my views from an elsewhere post today.  They are my own and
from my perspective.  You can like them or not, but there they are anyway.

Jon

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


Quoted text here. Click to load it

I believe that "real-time" is a *functional* description.  You
appear to see it as an architectual description, which is why
you reject tight loops that clearly perform a real-time function.
Nothing wrong with seeing things that way, of course. I suspect
that you would also reject my opinion that the standard light
switch that is on the wall in my lab is a real-time system.

Quoted text here. Click to load it

In my opinion, "fast" has nothing to do with "real-time", and
thinking that it does leads to conceptual errors.

I once worked on a real-time system that kept the wax in a tank
hot enough to be liquid but not hot enough to vaporize and catch
fire.  If the wax became too hot it would catch fire, and if it
became too cool it would solidify and it would take several days
to slowly melt it.

The real deadline (determined by the physics of heating wax until
it catches on fire) was well over ten hours.  I designed my control
system for a worst-case response time of one hour and a typical
response time of 20-30 minutes (you don't want to turn the burners
on and off several time a minute...) and I defined a system hard
deadline of four hours. This was a very, very hard deadline; the
system absolutely had to turn off that heater before the four hour
deadline.

For the heaters to go on and stay on for over four hours would
have required failures in the control system and six different
emergency cutoff systems that measured with six technologies
(Bimetallic contact, thermistor, thermocouple, excessive fuel
use, IR, meltable link) which shut off the heaters four ways
(cutting off the fuel (four valves in series, all from different
manufacturers), cutting power to the fuel pump, dumping the fuel
into a holding tank, and cutting off the air to the burners.)
In addition, the operator manually checked the temperature once
per hour, and the security security guard checked another
temperature gage during his rounds. And we had a couple of
really loud sirens.

Real-time? Yes, Fast? Not even close.

I consider the bimetallic contact shutoff alone to be a real-time
system - because I view real-time as a functional description.


I like the following namespace:

(Management version)

real-time, high-performance
real-time, medium-performance
real-time, low-performance
ordinary high performance
ordinary medium performance
ordinary low performance
batch, high performance
batch, medium performance
batch, low performance


(Engineer version)

real-time + real fast
real-time + half fast
real-time + not fast
some-time + real fast
some-time + half fast
some-time + not fast
long-time + real fast
long-time + half fast
long-time + not fast

(Yes, I am setting up a joke about a half fast design... <grin>)


Real-time, low performance would be controlling the temperature
in the tank full of wax.

Ordinary high performance is your usual desktop application;
faster is better than slower, but slower is better than never.

Batch high performance would be the IRS processing millions of
returns. Soft deadlines but high throughput.


High performance is an interesting thing to design for, but high
performance is not the same as real-time. Low performance/low cost
is another interesting thing to design for, but low performance
/low cost is not the same thing as not being real-time.

--
Guy Macon <http://www.guymacon.com/




Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

I don't believe that Jonathan is arguing with the fact
that a real-time system can be realized without a real-time
operating system.

The issue is the implication that real-time operating systems
(RTOS) are preemptive in general. We are *not* discussing
the definition of "real-time system."

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it

This is on-point.  Thanks.

Jon

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

Quoted text here. Click to load it

Agreed.

I would guess 99.999% of installed real-time systems don't
have an RTOS.  After all, Mattel toys are real-time, right?

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it

Hehe.  Yes.  So is a chicken hatchery, with temperature sample times in minutes
and PI control loops that can oscillate over periods of hours.

The question in my mind was exactly whether or not an operating system itself
should carry the tag.  Not whether an application on the whole is "real time."

Letting the application decide whether or not an operating system it uses is
real time or not is the logical equivalent for not making any judgment about the
operating system at all.

Jon

Re: So... What are the alternatives? Was: I don't use an RTOS because...
"Guy Macon" <http://www.guymacon.com/ wrote in message
Quoted text here. Click to load it
<snip>

Heh - I have a similar story, but involving a vat full of lipstick ;).

Years ago I designed PID temperature controllers. There were several hard
real-time requirements, including:
  - Sample rate was 4 (or 8) samples per second. All signal processing,
including ADC capture, linearisation, PID calculations, and output
maintenance, *had* to be complete within one sample window (a relatively
long time, but an absolute limit).
  - Part of the ADC system involved switching the ADC input from the
measured variable to a couple of references (ratiometric system).
Measurement accuracy depended directly on the accuracy of the *time* spent
measuring each input; it had to be exact to a very tight latency indeed.
(Achieved via hardware interrupt processing.)
  - Comms was RS485, hence bidirectional, hence the transmitter had to be
turned off within a short time of transmitting the last stop bit; failure to
achieve this would result in clobbered comms. (Again achieved via hardware
interrupts.)
  - Front-panel key activity had to be "snappy", i.e. the display would
react rapidly enough that the operator would not perceive any delay.
  - etc...

All of this was run on a fairly humble 6801 (later 8051) CPU, with a fairly
simple (but nonetheless fairly sophisticated) synhronous cooperative
scheduler.

I guess the question is whether or not one would classify this scheduler as
an RTOS ;). I can see it both ways: in one sense, yes, it's an RTOS in that
it provided a set of services that were dedicated to timely response. On the
other hand, it was application-specific and depended on correct partitioning
of the tasks into top-level synchronous tasks and low-level interrupt-driven
tasks. And of course it depended on each task relinquishing control in time
for all other tasks to run before the end of the timeslot.

One thing to add to all this: these were low-cost, high-volume embedded
products - they *HAD* to be reliable. If they ever crashed or failed to meet
their time deadlines, the units could be considered to be broken - and we,
the manufacturers, would probably face lawsuits. (I'd argue that the
definition of an RTOS should include this parameter - total reliability -
since a software glitch represents a hard realtime failure!)

Which brings me back to the lipstick. One application involved controlling
the temperature of a vat containing about a million bucks worth of lipstick,
which had a very tight temperature control window - any overtemperature by
just a few degrees would result in a vat full of worthless goo. It served to
remind me, in a fairly banal but graphic fashion, of my responsibilities as
a designer ;).

Steve
http://www.fivetrees.com



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

Quoted text here. Click to load it

An interesting aside is that, in system specs I usually get, they demand
that the response to the pressing of any button, operating any switch or
clicking any mimic icon, is no more than 500ms. I have found that for items
that take a long time to get to where they are going, a flashing
indication, which begins the instant a user initiates an action, lets the
operator know that something is in progress. The indication can become its
final steady state when the action is complete. A separate user interface
processor can help quite a bit here as well.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it

Ah, 500 mSec to change the cursor to an hour glass, and an hour to get
back to an arrow.  Where have I seen that ...

I have designed front panels that beeped, these seemed to keep the operator
happy: if it didn't beep he pounded the front panel until he got a response -
and a 5-lb sledge seemed to be the proper tool for pounding.

I found if something really obvious doesn't start to happen in 0.1 seconds
the operator gets annoyed.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it
 
Can the operators really discern the difference between 100 and 500 ms? I
think that would be fairly hard. However, I said the spec was "no more than
500ms", a target that I always managed to be ahead of.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it
seconds
than

Very definitely. We did some tests (long time ago) that suggested that 0.1s
was barely acceptable, and 50ms was a realistic maximum. In the end we went
with 20ms.

500ms is an age ;).

Steve
http://www.fivetrees.com



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

Quoted text here. Click to load it

Well!, that was an interesting selection of responses.

I guess that the time to response "feel" of a system may depend on the type
of initiation device one is using. When the initiator is a mimic icon that
you click on, or a single pushbutton you press, to initiate the action then
seeing the change of colour of the mimic icon or illumination of the push
button's light in less than 500ms might not seem so bad.

I would agree that having to type commands at a keyboard, that took that
long to determine which key of each you just pressed, would seem very
sluggish. However, even here, 500ms might seem inconsequential for a
response time after you hit the enter key.

Incidently, I didn't write those specs I mentioned. I just implemented them
using the most appropriate techniques I could use at the time.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it



Only indirectly.  Somewhat obviously, the "felt" response time only
starts to count after the moment the human operator believes to have
completed the input action, and stops after he observes the status
change.  I.e. a mechanically soft, high-force push button switch on a
machine's operator panel doesn't pose the same requirements on
feedback speed as a keyboard key, esp. if the latter is a "klick"
keyboard.

As a good reference of what kinds of speeds you may need, take a look
at the hands of a professional musician, or a *very* fast touch typist
at work.  I consider myself fast, while not spectacular, yet even I
can easily type in short bursts faster than around 5 letters a second.
That's 200 ms per keypress, and I still usually manage to get them in
the correct sequence, which means there's at least some tactile or
visual feedback involved.

I've heard that some experiments regarding tactile feedback done with
highly specialized personnel (fighter pilots) indicated that you may
have to get the lag down to something like 1 ms before the last of
them stop complaining about sluggish reponse.

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

Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

I read of a study that found that users will accept anything
up to about 4 sec. as a tolerable delay in getting completion
of some operation and anything beyond that is "forever" and
unacceptable.  The study also found that the delay was not
the critical item, but the variation of the delay.  That is,
3.5 seconds +/- 0.5 is OK, but 4 +/- 3.9 is not.

I believe it was in the same study that it was stated that
1/4 sec. is about the minimum reaction time of people.

Site Timeline