embedded Vs Realtime - Page 3

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

Translate This Thread From English to

Threaded View
Re: embedded Vs Realtime
On Sun, 23 May 2004 08:29:11 -0400, mwilson@the-wire.com (Mel Wilson)

Quoted text here. Click to load it

   I think it depends on who the "people" are. The MIDI file player in
MS Windows could be called "soft real time" because even though it
requires real-time proccessing to make the notes play and stop at the
appropriate times, it might delay notes (though I haven't noticed this
on MIDI playback, I've sure noticed problems with .wav and MP3
playback) while other programs are running, so a user will either not
do other things while playing MIDI files or accept the
less-than-perfect results.
   If the "concert organ" is intended for use by professional
musicians, problems such as "occasional missed timing" would NOT be
acceptable, so that would make it a "hard real time" system. Perhaps
the "concert organ" you worked on was a consumer product (which would
have lower standards). How "real-time" a system is can depend on the
target audience.

Quoted text here. Click to load it

   That's NOT real-time - the overall upload isn't required to be done
within a fixed amount of time. It needs handshaking to tell the
uploading system when the EEPROM has been written and another block
can be uploaded. This is just "as soon as it can be done" time.

Quoted text here. Click to load it

-----
http://mindspring.com/~benbradley

Re: embedded Vs Realtime
On Fri, 21 May 2004 22:46:32 -0400, Richard Saunders
Quoted text here. Click to load it
I have a customer with a 3-axis servo system controlled by an
industrial pentium PC with Windows NT (real time extension) with
vision software, ethernet etc. They also call this embedded because it
is embedded in their machine. This is the future by the way: many MB's
of code in machines, also in simple machines.

Quoted text here. Click to load it

A system with predictable timing is called "deterministic".

Real time means that is reacts fast enough to control your process.

Pieter

http://www.hoeben.com

Re: embedded Vs Realtime

Quoted text here. Click to load it

Yes.  The two concepts are orthogonal.

Quoted text here. Click to load it

Sometimes they are, but doing so is a mistake.

--
Grant Edwards                   grante             Yow!  I own seven-eighths
                                  at               of all the artists in
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime
Quoted text here. Click to load it

There are embedded systems, and there are real time systems, and there
are realtime embedded systems. It would not be a stretch to say that
the two concepts are found most often together.

Suggest you study what is embedded, and then what is realtime, then
it will become obvious.

Re: embedded Vs Realtime

Quoted text here. Click to load it


You have had some interesting responses and I have seen that you are
expected to give a presentation on this topic.

Firstly, one ought to question whether or not time is "Real". Einstein
has proved that it is definitely kinky or curved. What that means to
us as observers I am not too sure about but it can seem pretty real
and etherial at the same instant. Time remaining can certainly dissapear
at extraordinarily high rates or appear to stretch into a very far flung
future depending on whether one is enjoying ones self or not. For myself
I have determined that time is definitely not real.

That said, and within the definitions we all usually assume on this topic,
embedded systems are not always realtime systems but usually are. Similarly
realtime systems may or may not be embedded.

What determines whether or not the system is realtime and/or embedded
is purley down to what the application requirements are. If the application
demands that the functions are performed within hard and fast time limits
then the system is realtime. If the timescales are a not important then
the system is not realtime.

Embedded systems are fully dedicated to the function of the equipment it
is connected to. They do not allow games, or other office applications,
to be run while controlling that machine equipment. Many embedded systems
are also "Safety Critical" or "MIssion Critical". Some of these may also
be realtime systems.

Do any of these systems require an operating system? Not necessarily. In
my 30+ years I have designed and built many systems. Most of them have
used no OS at all. These are certainly my most successful ones. Those
that used an OS always had some problem with the uinderlying OS that
needed quite in depth exploration and examination to resolve fundamental
design flaws in the OS (not QNX, Linux or WinCE as these were not in the
consideration mix at that time). Latterly I start from Forth as my OS and
Application Specific Language development base.

Good luck in your presentation.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: embedded Vs Realtime

Quoted text here. Click to load it

Thanks to everybody. I am getting my concepts clear about realtime and
embedded operating systems.

It would be great if somebody points me to ACM or IEEE papers on embedded
operating systems.




Re: embedded Vs Realtime
Quoted text here. Click to load it

Yes.  Others have given this a try so let me.

Embedded systems are dedicated rather than general purpose.

Realtime systems have to deal with events that happen in real time.
A program that reads a file in one format and creates a new file
in a different format might be run whenever.  The original file
isn't going to go away.  (Well let's assume it is archived and
backed up.)  So the program can run whenever someone wants to
run it.

On the other hand, a program that receives a serial message
over a wire has to deal with events that happen in real time.
If the machine is turned off when the message gets sent then
the message is lost.  Oh sure there may be some buffers somewhere
in the system that ease the timing demands of the real time program,
but the events happen in real time.

If a program is suppose to read keystrokes and respond within
the time that a user will accept then it has to deal with
events in real time.  Sure there might be some buffering in
a processor, or there might not.  If the computer is running
another program and there is no buffer it will miss keystrokes
and fail to do its job.

The timing demands may be relatively easy to meet or very
tight.  Most computers can deal with keystrokes at a human
typist speed. (Of course some time in the past people were
warned that if they wanted to use MS Word on a Mac that
they needed to get a 68030 machine because using that software
a 68020 was too slow to keep up with a fast typist. ;-)

If a program is receiving and decoding radio signals the events
may come and go away in real time on the order of a few hundred
picoseconds or less.  If the computer is away doing something
else they are lost.

Realtime means things will be lost if not processed when events
actually happen.  Embedded means dedicated and although most
people associate them with the billions of tiny embedded processors
very large computers have also been used as dedicated/embedded
processors.  The term embedded comes from being 'inside of' and
we tend to think of the tiny computers inside of so many things
today that serve a specialized rather than general purpose function.

Best wishes

Re: embedded Vs Realtime
snipped-for-privacy@ultratechnology.com (Jeff Fox) writes:

Quoted text here. Click to load it

Then what's the difference between a turnkey system and an embedded
system? :-)

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

Re: embedded Vs Realtime

Quoted text here. Click to load it

Again, that's another orthogonal concept.  Turnkey means you
unpack it from the box, supply power, flip the "on" switch and
it does whatever it's supposed to do -- regardless of whether
that's provide general-purpose computer or some sort of
specialized "embedded" function.

IOW, you don't have to install any more software or integrate
any more hardware.

A turnkey system like a kiosk or cell phone or whatever may
contain one or more "embedded" computers (or it may not).

I'd call something like a Macintosh a "turnkey" general-purpose
computer.

--
Grant Edwards                   grante             Yow!  Do you have exactly
                                  at               what I want in a plaid
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline