are embedded systems usually real-time systems?

real-time does not mean super fast but merely meet the requirements.

Most embedded systems are in the category "as fast as possible" systems.

Asking this you compare to different things.

HTH,

Adib.

John schrieb:

"You are asking the wrong questions. The right questions are:

1. What should be done.
2. How much time and money do we have."

(c) YK

VLV

Yes to both questions.

It is rare to find an embedded system that doesn't have some hard real-time deadlines, such as processing an interrupt before the next one occurs. Most also have soft real-time deadlines.

It is also rare to find a real-time system that isn't embedded. If the system has hard real-time deadlines and is important, than you put it on its own circuit board and not on a desktop PC with Windows.

There are exceptions, but since you phrased it as "usually" ... I'd say "yes" to both questions.

And even if you use Windows for some non-critical soft real time applications, make sure that the computer system does not have any visible floppy/CD-ROM drives or USB connectors, since bored users seem to be eager to load all kinds of computer games into the system, when they realise it is a Windows system :-).

While other systems work properly even when loaded by other low priority programs, there is always the risk that the unspecified program might hog all memory resources etc., unless the OS has a strict quota system (such as VMS) limiting the amount of resources a single process can grab.

Thus, any critical real-time system would be embedded in the sense that only predefined programs are allowed.

Paul

Hello John,

John schrieb:

The answer is

1) No and yes, it depends. e.g. many micro controller have a simple runtime environment but no RTOS because they only have 4 KB RAM/ROM!

2) No and yes, it depends. e.g. cash management in bank firms have to be realtime, since time is money and those systems are huge, not embedded!

Hope it helps to formulate the question better suiting for news groups!!!

--
BaSystem Martin Raabe
E: Martin.RaabeB-a-S-y-s-t-e-mde

Hmmm, first post with the group and semester finals coming up. Better ask your professor.

If these are examples of realtime systems, most of these are extremely soft realtime systems :-).

In computer games, it is very hard to define when the game becomes useless due to lack of computing power.

For multimedia, dropping a video frame now and then is not so bad, however failing to deliver audio samples in time is a bad thing.

In communication, most systems rely on flow control (e.g. RTS/CTS for RS-232 or TCP in network communication), so only a few systems are truly realtime systems.

Paul

It is probably much more "objective" to consider the "degree of determinism" required by the "actual application" and what happens if deadlines are missed.

soft realtimehard realtime

multimedia telco switching vehicle tracking ctrl/mgmt precision machine milling scada

ruined movie ignored calls machine parts ruined, car wrecks

nb.these are all both embedded and realtime.

David Moore Systems consultant

=====================================

John wrote:

Play Battlefield 2 or Battlefield 2142, the definition becomes clear rapidly on a busy night and server.

Define which is the largest delay in milliseconds that is still acceptable and the first value that is not acceptable, use at least two significant digits. Is 97 ms acceptable but 98 ms not, is 470 ms OK but 480 ms not, is 1600 ms OK but 1700 ms no longer acceptable ?

Paul

Op Sat, 11 Nov 2006 09:54:47 +0100 schreef Martin Raabe :

You can have a real-time system without an RTOS.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

I agree here. A lot of people confuse real time with "fast response". A real time system does not necessarily have to be fast, and a fast system is very often not real time. Subjective measurements don't fit in very well with real time systems.

There is a range though, from "hard real time" to a softer notion. Ie, there may be a requirement that a buffer be completely processed within a period of time, otherwise it gets overwritten. A hard real time system would say that any failure there means the system has failed (data is corrupted). A soft real time system would say that occasional breakage can be tolerated (ie, dropping a frame of video, causing a network packet to be resent, etc).

-- Darin Johnson

Also,

Most embedded systems will respond to something in realtime whether this is generated by a temporal deadline or responding to an external asynchronous response. However *some* embedded systems may have a non-realtime subsystem - for example in autonomous mechatronics there may be a scene-analysis and/or reasoning engine which may not be operating in realtime however the *overall design* of the embedded system can be such that if required the negative impact of any nondeterministic subsystems can be factored for.

David Moore

Systems consultant

=========

John wrote:

A system can be both hard and soft realtime.

Take for instance the classical airline ticket reservation system.

There is a hard realtime situation, when there are people in the queue waiting for the ticket at departure time and the plane leaves nearly empty due to this slow ticket processing.

However, there is also a soft realtime constraint, when there are two competing airlines on the same route. If you can not handle your customers fast enough, people will sooner or later move from your queue to the competitor's queue, which means a loss in revenues. This is much harder to define.

Paul

4 KiB of code+data is _plenty_ of memory for a simple pre-emptive kernel and a few simple tasks. 20-50 bytes for each stack, kernel perhaps 500-1000 bytes and still you could have 5 tasks with 500 bytes of code each (several pages of assembler/task).

Just do all your actual work in the interrupt context, while the "main program" consists of an infinite loop consisting of a single "wait for interrupt" instruction.

Paul