ftp.pasteur.org/FAQ//ftp-pasteur-org-FAQ.zip/FAQ/realtime-computing/faq

Internet Message Format | 2004-05-09 | 43.8 KB

Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
Message-ID: <realtime-computing/[e-mail]>
Supersedes: <realtime-computing/[e-mail]>
Expires: 19 Jun 2004 10:07:04 GMT
X-Last-Updated: 2002/05/16
From: <[e-mail]>
Organization: none
Newsgroups: comp.realtime,news.answers,comp.answers
Subject: Comp.realtime: Frequently Asked Questions (FAQs) (version 3.6)
Followup-To: poster
Reply-To: [e-mail]
Summary: Answers to real-time frequently asked questions (periodic posting)
X-Posting-Frequency: every 4 weeks
Organisation: RTUSI (http://www.rtusi.com)
Approved: [e-mail]
Originator: [e-mail]
Date: 08 May 2004 10:08:19 GMT
Lines: 953
NNTP-Posting-Host: penguin-lust.mit.edu
X-Trace: 1084010899 senator-bedfellow.mit.edu 574 18.181.0.29
Xref: senator-bedfellow.mit.edu comp.realtime:46118 news.answers:271025 comp.answers:57104

Archive-name: realtime-computing/faq
Version: 3.5 (July 1998)

This posting provides an overview of newsgroup comp.realtime by summarizing
the history, common past topics, and frequently asked questions.
A companion posting to this one, "Comp.realtime: Welcome to comp.realtime"
<[e-mail]>, complements this one by providing a concise
introduction to the group.  Another posting, "Comp.realtime: A list of
real-time operating systems and tools", <[e-mail]>, provides
references to available operating systems and software tools.

These articles are repeated periodically for the benefit of new readers.



Comp.realtime FAQ
-----------------

This posting provides an overview of newsgroup comp.realtime by summarizing
the history, common past topics, and frequently asked questions.
HTML versions (much easier to read) are available at:
http://www.realtime-info.be/encyc/techno/publi/faq/rtfaq.htm
http://www.groupipc.com/rtfaq.htm
http://www.faqs.org/faqs/realtime-computing/faq/
http://www.cis.ohio-state.edu/hypertext/faq/usenet/realtime-computing/top.ht
ml

What's new in the FAQ?
----------------------
     This What's new section!
     Updated the HTML version locations (note that the two first one are
real html whereas the others are text converted to html).
     Updated the real-time definition.
     Updated the Windows NT as a RTOS section.
     Added the problem of year 2000 in real-time or embedded systems.
     Added RTOS Market Polling results (Mainly Japan Market Study)
     Added RMA Definition
     Book section updated

Table of contents

I- INTRODUCTION
     What is the purpose of this FAQ?
     What is the charter of comp.realtime?
     Where should I ask questions about real-time systems?
     What is considered good net.etiquette on comp.realtime?

II- DEFINITIONS
     What exactly is meant by real-time?
     What is POSIX 1003.1b (formerly 1003.4)? Where is it available?
     What makes an OS a RTOS?
     What is a good RTOS?
     What is RMA?

III- PUBLICATIONS COVERING REAL-TIME TOPICS
     Books
     Magazines
     Other newsgroup and mailing lists dealing with real-time topics.
     Web Site covering real-time topics.

IV- POLEMIC TOPICS
     Is Windows NT (or windows 95) a Real-Time Operating System?
     Which methodology should I use to design a Real-Time System?
     Which programming language should I use to develop a Real-Time System?
     What kind of processor should I use for my Real-Time System?
     What kind of bus should I use for my Real-Time System?
     What Mezzanine technology should I use?
     Dedicated Systems and year 2000: what are the risks?

V- MARKET
     Where can I find informations related to real-time products?
     Where can I find informations about real-time Conferences, Workshops
and Tradeshows?
     International organisation for standards?
     International User and Manufacturer Groups?
     RTOS Market Study (Mainly Japan Market)

VI- RESEARCH AND FREE PRODUCTS
     Which Research Institute and Universities are involved in the Real-Time
field?
     Free Real-Time Product lists

VII- CONTRIBUTIONS AND FAQ LOCATION
     Where can I get the current copy of the FAQs?
     Contributions to comp.realtime FAQs.

======================================================
I- INTRODUCTION
------------------------------
   What is the purpose of this FAQ ?

The purpose of this FAQ is to give sufficient knowledge to a new user in the
Real-Time field and to serve as a reference to the engineer working in this
field. This FAQ gives an overview about each topic and refers to other
ressources (Internet, Publications, Company) for a more complete
information.
A companion posting to this one, "Comp.realtime: Welcome to comp.realtime"
<[e-mail]>, complements this one by providing a concise
introduction to the group. Another posting, "Comp.realtime: A list of
real-time operating systems", <[e-mail]>, provides
references to available operating systems.

------------------------------
   What is the charter of comp.realtime?

The charter of comp.realtime is to provide a forum for discussion of both
the theory and practice of real-time computer systems. The group is
unmoderated; participation is open to all.
[If there was a formal charter for the newsgroup at the time of its
creation, we don't have access to it at the moment. Readers?]

Note that the listing in the canonical "newsgroups" file is:
comp.realtime Issues related to real-time computing.

------------------------------
   Where should I ask questions about real-time systems?

Comp.realtime is certainly the place. However, if you are asking about a
particular real-time system, see below for a (possibly) better place to
start.

For topics that are only somewhat related to real-time systems, also
consider comp.arch and/or comp.os.misc. For instance, topics about bus-based
computer systems are best asked in comp.arch, or, if they're about the
VMEbus, comp.arch.bus.vmebus.

------------------------------
   What is considered good net.etiquette on comp.realtime?

Here are some etiquette reminders that will help us all to make the group an
ever-friendlier place:

-- Please, before posting, ensure that you've read the basic Usenet
etiquette guide in news.announce.newusers.

-- Please set the Followup-To: line in your post. This is especially true if
you are cross-posting. If you are requesting information, consider setting:
Followup-To: poster, and then summarizing the replies to the net.

-- When following up, please change the Subject: line if the subject has
really changed.

-- Some sites that receive comp.realtime are on branches of the net that
frown on overtly commercial announcements. These postings are welcomed on
comp.newprod and anywhere in the biz.* hierarchy. However, short offers by
vendors to provide further information by email are usually seen as
acceptable.

======================================================
II- DEFINITIONS
------------------------------
   What exactly is meant by real-time?

There are _several_ definitions of real-time, most of them contradictory.
Unfortunately the topic is controversial, and there doesn't seem to be 100%
agreement over the terminology.

1. The canonical definition of a real-time system (from Donald Gillies
mailto:[e-mail] ), is the following:

"A real-time system is one in which the correctness of the computations not
only depends upon the logical correctness of the computation but also upon
the time at which the result is produced. If the timing constraints of the
system are not met, system failure is said to have occurred."

Others have added:

"Hence, it is essential that the timing constraints of the system are
guaranteed to be met. Guaranteeing timing behavior requires that the system
be predictable. It is also desirable that the system attain a high degree of
utilization while satisfying the timing constraints of the system."

A good example is a robot that has to pick up something from a conveyor
belt. The piece is moving, and the robot has a small window to pick up the
object. If the robot is late, the piece won't be there anymore, and thus the
job will have been done incorrectly, even though the robot went to the right
place. If the robot is _early_, the piece won't be there yet, and the robot
may block it.

Another example is the servo loops in an airplane when on auto-pilot.
The sensors of the plane must continuously supply the control computer with
proper measurements. If a measurement is missed, the performance of the
airplane can degrade, sometimes to unacceptable levels.

David Sonnier  ( mailto:[e-mail] ) adds the distinction:

In the robot example, it would be hard real time if the robot arriving late
causes completely incorrect operation. It would be soft real time if the
robot arriving late meant a loss of throughput. Much of what is done in real
time programming is actually soft real time system. Good system design often
implies a level of safe/correct behavior even if the computer system never
completes the computation. So if the computer is only a little late, the
system effects may be somewhat mitigated.

2. POSIX Standard 1003.1 defines "real-time" for operating systems as:
"Realtime in operating systems: the ability of the operating system to
provide a required level of service in a bounded response time"

3. One will occasionally see references to "real-time" systems when what is
meant is "on-line", or "an interactive system with better response time than
we used to have". Often, this is just marketing hype. For instance, although
some have queried whether running "rn" is real-time, it is not, as it is
interacting with a human who can tolerate hundreds of milliseconds of delays
without a problem. Similarly, on-line stock quotation systems interact with
humans.

4. One will also see references to "real-time" systems when what is meant is
just "fast". It might be worth pointing out that "real-time" is not
necessarily synonymous with "fast"; that is, it is not the latency of the
response per se that is at issue (it could be of the order of seconds), but
the fact that a bounded latency sufficient to solve the problem at hand is
guaranteed by the system. In particular, frequently, algorithms that
guarantee bounded latency responses are less efficient overall than
algorithms that don't.

5. One will also occasionally see discussions of "soft" vs. "hard" real-time
systems. In many of these discussions, "hard" real-time means the type of
real-time system discussed above, and "soft" real-time means systems which
have reduced constraints on "lateness" but still must operate very quickly
and repeatably. However, the definition is controversial, as some mean by
"hard" and "soft" the degree of time constraints. For instance, a real-time
process attempting to recognize images may have only a few hundred
microseconds in which to resolve each image, but a process that attempts to
position a servo-motor may have tens of milli-seconds in which to process
its data.

6. Robert Bristow-Johnson adds the following distinction (in the case of
DSP):
In a real-time DSP process, the analyzed (input) and/or generated (output)
samples (whether they are grouped together in large segments or processed
individually) can be processed (or generated) continuously in the time it
takes to input and/or output the same set of samples independent of the
processing delay.

Consider an audio DSP example: if a process requires 2.01 seconds to analyze
or process 2.00 seconds of sound, it is not real-time. If it takes 1.99
seconds, it is (or can be made into) a real-time DSP process.

A common life example I like to make is standing in a line (or queue)
waiting for the checkout in a grocery store. If the line asymtotically grows
longer and longer without bound, the checkout process is not real-time. If
the length of the line is bounded, customers are being "processed" and
outputted as rapidly, on average, as they are being inputted and that
process _is_ real-time. The grocer might go out of business or must at least
lose business if he/she cannot make his/her checkout process real-time (so
it's fundamentally important that this process be real-time).
The last definition (5) is the one used for real-time audio and video, for
phone call over Internet, and so on. It means that the processing time is
less than the time to get a sample. Note that in the case of Internet it is
easy to get starvation because the sample arrivals depend on the bandwidth.

------------------------------
   What is POSIX 1003.1b (formerly 1003.4)? Where is it available?

POSIX 1003.4 was the working name for what is now the 1003.1b standard..

The ratified POSIX standards that generally pertain to real-time OS's
consist of: 1003.1 (OS, process, filesystem and device API), 1003.2
(utilities), 1003.1b (real-time), and 1003.1c (threads). POSIX 1003.1d
(which defines some additional real-time extensions like standardized
interrupt handler support) is not yet ratified, although some OS's already
support portions of it.

The best way to get the most current status is to refer to some of these
texts and contacts:
The POSIX 1003.1 standard is ISBN 1-55937-061-0. A good O'Reilly text is
"POSIX Programmer's Guide: Writing Portable UNIX Programs". Donald Lewine.
ISBN: 0-937175-73-0

For other standards, the IEEE's address is:
Secretary, IEEE Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
USA
http://cs-www.bu.edu/pub/ieee-rts/Home.html
Many of the POSIX draft standards can also be obtained by calling the IEEE
Draft Standards Office. Credit card in-hand, phone [phone] to place
an order.

Another contact is the IEEE-USA Customer Service Center at 800 678 4333
([phone] for outside of 800 zone); fax: [phone].

------------------------------
   What makes an OS a RTOS?

1. A RTOS (Real-Time Operating System) has to be multi-threaded and
preemptible.
2. The notion of thread priority has to exist as there is for the moment no
deadline driven OS.
3. The OS has to support predictable thread synchronisation mechanisms
4. A system of priority inheritance has to exist
5. OS Behaviour should be known
So the following figures should be clearly given by the RTOS manufacturer:
1. the interrupt latency (i.e. time from interrupt to task run) : this has
to be compatible with application requirements and has to be predictable.
This value depends on the number of simultaneous pending interrupts.
2. for every system call, the maximum time it takes. It should be
predictable and independent from the number of objects in the system;
3. the maximum time the OS and drivers mask the interrupts.
The following points should also be known by the developer:
1. System Interrupt Levels.
2. Device driver IRQ Levels, maximum time they take, etc.

------------------------------
   What is a good RTOS?

A good RTOS is not only a good Kernel ! A good RTOS should have a good
documentation, should be delivered with good tools to develop and tune your
application. So even if some figures like the Interrupt latency, Context
switch time are important, there are a lot of other parameters that will
make a good RTOS. For example a RTOS supporting many devices will have more
advantages than a simple very good nano-kernel.

------------------------------
What is RMA?
   "Rate-Monotonic Analysis" is a term coined by researchers at CMU. It
refers to the real-time performance analysis of a system design that uses
static-priority driven scheduling, in particular, the "rate-monotonic"
static priority assignment, where tasks with shorter periods get the higher
priorities, in a typical static-priority driven real-time operating system
like pSOS VxWorks VRTX etc.
Research (mostly) from CMU and U-York and Illinois gives you the
mathematical tools to answer "what if I designed it this way???" analysis on
your system workload. You need to break your software into "tasks" with
"periods" and "deadlines" (relative to the period) and you must be able to
guess or prototype a rough "execution time" for each task. Also, for more
precise analysis, it helps to know all the critical sections and their
runtimes and who shares them, or at the least, the length of the longest
critical section in all of your software.
You can plug all this data into a "schedulability analyzer" tool (PERTS,
MIMOSA, Scheduler 1-2-3 (CMU), Software Engineer(?s) Notebook (CMU, newer)),
or even the back of an envelope "Utilization Test" or "Formula Test" and
find out if your workload will meet all its different deadlines.
If you workload does not meet deadlines, the better tools can help you to
explore changes to your workload, in order to meet all the deadlines.

======================================================
III- PUBLICATIONS COVERING REAL-TIME TOPICS
-------------------------
   Here are some references to the theory and practice

Several people recommended as a starting place the article "Tutorial on Hard
Real-Time Systems", edited by John A. Stankovic and Krithi Ramamritham, IEEE
Computer Society reprint series, Computer Society order number 819.
Kopetz, H.: Real-Time Systems, Design Principles for Distributed Embedded
Applications. Kluwer Academic Publishers, Massachusetts, 1997.
A good book indeed. It covers:
Real-Time Environment, Distributed Solutions, Global Time, Modeling
Real-Time Systems, Real-Time Entities and Images, Fault Tolerance, Real-Time
Communication, The Time-Triggered Approach, Input/Output, Real-Time
Operating Systems, Real-Time Scheduling, Validation, System Design, Time
Triggered Architecture

PRACTITIONER'S HANDBOOK FOR REAL-TIME ANALYSIS:    Guide to Rate Monotonic
Analysis for Real-Time Systems. Klein,Mark; et al, Year 1993, Definitive
developer's guide. Ten chapters in 4 parts: Introduction;Concepts &
Techniques; Analyzing Real-Time Systems; & Using the Handbook on Realistic
Systems. KLUWER ACADEMIC, Pages 712, ISBN: 0-7923-9361-9
STRATEGIES FOR REAL-TIME SYSTEM SPECIFICATION, Hatley,D.J. & Pirbhai, I.A,
Year 1988, Casebook & practical reference for modeling requirements &
architecture. Topeics include: Process; Control; Finite State Machines,
Timing; Dictionary; & Examples, DORSET HOUSE, Pages 408, ISBN: 0-932633-11-0

STRUCTURED DEVELOPMENT FOR REAL-TIME SYSTEMS, Combined Version, Vols 1,2 &
3., Ward, P.T. & Mellor, S. J., Year 1987, PRENTICE HALL, Pages 468, ISBN:
0-13-854654-1

Caxton Foster's "Real-Time Programming: Neglected Topics," despite the
title, is a very good introduction to the basic topics of real-time control,
starting with simple things like interrupts and debouncing switches, all the
way through digital filters. It's a thin paperback (Addison Wesley
MicroBooks), and a (somewhat) experienced programmer can get through it in a
couple of days.

iRUG. Proceedings of the Intel Real-Time User's Group. Annual, back copies
available from iRUG, P.O. Box 91130, Portland, OR 97291, [phone].
Annual conference proceedings dealing primarily with Intel's family of
real-time OSs, iRMX.

Books references in The Online Real-Time Encyclopaedia(there is always a
comment there) http://www.realtime-info.be/encyc/techno/publi/books.htm
J.E. Cooling, Software Design for Real-time Systems, SBN 0-412-34180-8,
published by Chapman and Hall.
Yann Hang Lee and C.M. Krishna, Readings in real-time systems, ISBN
0-8186-2997-5, 1993, published by IEEE Computer Society Press.
Mathai Joseph, Real-Time Systems, University of Warwick, ISBN 0-13-455297-0,
1996, published by Prentice Hall Professional Technical Reference.
Krishna M. Kavi , Real-time systems, abstractions, languages and design
methodologies, ISBN 0-8186-3152-X, 1992, published by IEEE Computer Society
Press.
Phillip Laplante, Real-time systems design and analysis, an engineer's
handbook, ISBN 0-8186-3107, 1993, published by IEEE Computer Society Press
David L. Ripps, An implementation guide to real-time programming, ISBN
0-13-451873-X, 1989, published by Yourdon Press, Prentice-Hall Building, now
out of print!
Ken Shumate and Marilyn Keller, Software specification and design, a
disciplined approach for real-time systems, ISBN 0-417-53296-7, 1992,
published by John Wiley and Sons, Inc.
Another list of books with comments http://www.realtime-os.com/rtresour.html
A publisher: http://www.powells.com

---------------------------------
Peter Desnoyers <mailto:[e-mail]> sends along:
The classic reference in the area of timers is:

George Varhese and Tony Lauck, "Hashed and Hierarchical Timing Wheels: Data
Structures for the Efficient Implementation of a Timer Facility", Operating
Systems Review 21, no. 5 (Proceedings of 11th ACM Symposium on Operating
Systems), 1987.
Their results show O(1) times for insert and delete of 13 and 7 instructions
for one of the schemes, and decent performance with large numbers of
outstanding timers.

---------------------------------
Christian Ebner mailto:[e-mail] sends along a classic
reference in priority inheritance algorithm:
Sha, L., Rajkumar, R. and Sathaye, S.: Priority Inheritance Protocols: An
Approach to Real-Time Synchronization. IEEE Transactions on Computers, Vol.
39(9). pp.1175-1185.
Analysis shows that the priority inheritance protocol can lead to chained
blocking and deadlocks. To solve this problem, the priority ceiling protocol
was developed by L. Sha, R. Rajkumar and S. Sathaye.

---------------------------------
Here are some other suggestions from various net.sources, in publishing date
order:
Mellichamp, D. A. Real-Time Computing. New York: Van Nostrand Reinhold,
1983. 552 pp.
Twenty chapters by 11 authors on topics ranging from signal processing to
managing real-time computing facilities.

A. K. Mok, The Design of Real-time Programming Systems Based on Process
Models, in Proc. 1984 Real-Time Systems Symposium, Dec.1984, pp5-17.

E. Kligerman and A. Stoyenko, Real-Time Euclid: A Language for Reliable
Real-Time Systems, in TOSE, Sep. 1986, pp 941-949, vol SE-12.

D. W. Leinbaugh and M.-R. Yamini, Guaranteed Response Times in a Distributed
Hard-Real-Time Environment, in TOSE, Dec.1986, vol SE-12.

A. Stoyenko, A Real-Time Language With A Schedulability Analyzer, Computer
Systems Research Institute, University of Toronto, Dissertation, Dec. 1987.

Lawrence, P. D. and Mauch, K. Real-Time Microcomputer System Design. New
York, McGraw-Hill, 1987. 568 pp.
The emphasis is on the design of I/O circuits and assembly language
interfaces for small microprocessors used for embedded systems.

H. Kopetz and A. Damm and Ch. Koza and M. Mulazzani and W. Schwabl and Ch.
Senft and R. Zainlinger, Distributed Fault-Tolerant Real-Time Systems: The
MARS Approach, in IEEE Micro, vol.9, Feb.1989, pp25-40.

Burns, A. and Wellings, A. Real-Time Systems and Their Programming
Languages. Wokingham: Addison-Wesley, 1990. 575 pp.
Ada, Modula-2, and occam 2 are used throughout the book, which covers topics
ranging from basic programming techniques, fault tolerance, exception
handling, concurrency, resource management, and distributed designs.

Vickery, C. Real-Time and Systems Programming for PCs. New York:
McGraw-Hill, 1993. 604 pp. The thesis is that the development environment
for real-time systems is ideal for studying systems programming, too. After
some introductory material, the book deals exclusively with Intel's iRMX
operating systems, with particular emphasis on iRMX for Windows.

-------------------------
   Real-Time and Embedded Systems related magazines

List from The Real-Time Encyclopaedia
http://www.realtime-info.be/encyc/techno/publi/magazine.htm
* Embedded Systems Engineering: Embedded Systems Engineering is a UK based
magazine dedicated to embedded systems and development tools. Although
highly focused on embedded systems this publication also covers real-time
products. For more info email to Jeremy Kenyon.
(mailto:[e-mail])
* Details: 10 issues/year, 60 pages, English.
* Embedded Systems Programming: Embedded Systems Programming is the leading
magazine on embedded systems design in the US. Although covering mostly
embedded systems, a lot of the editorial is dedicated to real-time systems.
* Details: 12 issues/year, 106 pages, English.
* Mezzanines: Mezzanines is the official publication from GRoupIPC, the
international user & manufacturer group promoting IP & PMC mezzanine
solutions. This fancy publication contains technical articles, application
notes and offers a new products section besides a currently updated product
directory.
* Real-Time Magazine: Real-Time Magazine is THE European reference magazine
for the real-time systems developer. Each magazine is dedicated to a special
theme, such as Buses (VME, PMC, CompactPCI,...), RTOS, Tools (debugging,
monitoring, simulation, design, bus hardware analyzers), Real-Time Networks,
etc. A must for real-time engineers who don't have the time (and money) to
spend on courses and workshops. The magazine also contains Real-Time
Gazette, the supplement which contains new products information.
* Details: 4 issues/year, 124 pages (+16 page supplement), English.
* Real-Time Systems: Real-Time Systems is a journal on time-critical
computing systems. Although very real-time focused, this publication is very
theoretical and more targeted toward researchers.
* Details: 6 issues/year, 320 pages A5, English.
* RTC Magazine: The RTC Magazine (before "The Real-Times"), not to confuse
with Real-Time Magazine, is a more commercial publication which supports the
RTC shows in the US and Europe. The magazine helps the exhibiting companies
to better promote their products.
* Details: 6 issues/year, 92 pages, English.
* VITA Journal: The VITA Journal is a VMEbus related publication and the
official publication from VITA, the VMEbus International Trade Association.
As VME is an important standard in real-time, we shouldn't omit this
publication in our list.
* Details: 4 issues/year, 46 pages, English.

------------------------------
   What other net.resources are available on real-time systems?

There are at least two other newsgroups devoted exclusively to a particular
vendor's real-time operating system:

news:comp.os.lynx The LynxOX real-time operating system.
news:comp.os.os9 Discussions about the os9 operating system.
news:comp.os.qnx The QNX real-time operating system.
news:comp.os.vxworks The VxWorks real-time operating system.
news:comp.sys.harris The Harris NightHawk & CX/UX & CX/RT operating systems.

Here are some other related newsgroups:
news:alt.industrial.computing
news:comp.arch Computer architecture.
news:comp.arch.bus.vmebus Hardware and software for VMEbus Systems.
news:comp.os.misc General OS-oriented discussion not carried elsewhere.
news:comp.robotics All aspects of robots and their applications.
news:comp.sys.m68k Discussion about 68k's.
news:sci.engr.control The engineering of control systems.
news:sci.engr.manufacturing

There are too many other newsgroups devoted to computer operating systems
that support some form of real-time scheduling to list here. The interested
reader is advised to check the "newsgroups" file on her or his local
machine.

There is a realtime-related mailing list for embedded computer systems
developers. It is not strictly real-time, but there is some overlap. To
subscribe, send your email address to mailto:[e-mail].

A mailing list for discussions concerning the use of Futurebus+ now exists.
Appropriate topics include the design, implementation, integration and
operation of the hardware and software that are related to Futurebus+. To
subscribe, send the one-line email message (in the body of the message, not
the header; the Subject line is ignored) as shown below to
mailto:[e-mail].

subscribe fbus_users <your_email_address>

To get more information about the mailing list, send the one-line command
shown next to mailto:[e-mail]:

info fbus_users

The info page is automatically sent when you subscribe.

A mailing list intended for the discussion of topics relating to the
pSOSystem and other products of Integrated Systems Inc., Software Components
Group, has been started. Send articles to mailto:[e-mail] and
administrative (subscription) requests to mailto:[e-mail]. The
list administrator is Radek Aster who can be reached at
mailto:[e-mail].

Russ Hersch <mailto:[e-mail]> is now maintaining two _extensive_
FAQs about specific microcontroller families, and one about microcontrollers
in general. Here's the pointers:

Subject: 68hc11 microcontroller FAQ
Summary: This article is a collection of information sources on the Motorola
68hc11 line of microcontrollers.
Archive-name: 68hc11-microcontroller-faq
Posting-Frequency: monthly

Subject: 8051 microcontroller FAQ
Summary: This article is a collection of information sources on the Intel
8051 line of microcontrollers (and variants).
[He's working on the archiving of this one.]
Posting-Frequency: monthly

Subject: Microcontroller Primer FAQ
Summary: This article is a primer and general FAQ about microcontrollers.
[He's working on the archiving of this one.]
[Posting-Frequency: monthly, I think]

He also states that Tom Kellett is working on a FAQ on the PIC
micro-controller line, and adds that "hopefully, this will lead towards a
much needed collection of microcontroller FAQs."

------------------------------
   Which Web Sites give information about real-time?

The Real-Time Encyclopaedia about everything you want to know about
Real-Time (http://www.realtime-info.be)
E. Douglas Jensen Web Site (http://www.realtime-os.com/rtresour.html)
Frank Miller Resource list http://www.cs.umd.edu/~fwmiller/etc/realtime.html
EEToolbox Resource link list http://www.cera2.com/realtime.htm
The RTC Group (http://www.rtcgroup.com)
Embedded Systems (http://www.embedded.com/net.htm)
VITA (http://www.vita.com)
GRoupIPC (http://www.groupipc.com)
A good collection of links
(http://www.ifi.unizh.ch/groups/ailab/embedded.html)

======================================================
IV- POLEMIC TOPICS
------------------------------
    Is Windows NT (or windows 95, or even Windows CE now) a Real-Time
Operating System?

This question appears repeatedly in this news group. Here are the key
points:
- Despite a real-time class process, the Win32 API is not suitable to be
used for a Real-Time System:
1. Too few priorities for processes and threads
2. No priority inheritance mechanism
3. Some calls are synchronous with process from the Dynamic Class
- Despite a good interface to hardware for CLASSICAL applications, this
interface is not suitable to develop a Real-Time System:
1. Most of the job in a device driver is done at the DPC level. And most
COTS DD take too much time in the DPC.
2. The DPC problem could have been avoided by increasing the number of DPC
levels, but this is not the case.
3. Pentium Power Management interrupt can preempt your system for an
unpredictible amount of time (depending of the BIOS)
- Real-Time clock
There is a lack of programmable timer.

For a more complete view, look at article:
http://www.realtime-info.be/encyc/magazine/97q2/winntasrtos.htm
Some companies are now providing Real-Time Extensions to fill up the hole
let opened by Microsoft. (cf the RTOS list)
To do so three main approaches exists: include NT as the lowest level
process in an existing RTOS, put a WIN32 API on top of an existing RTOS,
make NT coexists with a RTOS by modifying the HAL. For complete view, look
at article:
http://www.realtime-info.be/encyc/magazine/97q2/winntext.htm
One might also be interested in the vendors proposing such products
http://www.qnx.com/whitepaper/qnxwin32.html
http://www.vci.com
http://www.radisys.com
http://www.imagination.com/
http://www.lp-elektronik.com

------------------------------
    Which methodology should I use to design a Real-Time System?

At least you should use one. It is high time people are convinced of the
interest of building a house with the plan. It is very strange that people
still think that Software development is equal to writing or even hacking
code. There are at least three big classes of methodologies :
- The one related to Ada (Booch)
- The one based on data flows
- The OO Methodology (OMT)
One could add the formal approach too (SDL, MSC).
The choice will be based on the inhouse knowledge, level of education and
the client knowledge of software development. For each methodology you have
tools that are more or less good.

------------------------------
    Which programming language should I use to develop a Real-Time System?

Of course you can choose to use assembler. You can always use tools from the
Ancient Age. Nevertheless it would be much better to use a higher level
programming language. Most of them will fit. The Ada Community will always
try to convince you their language is the best to use in any cases. Here is
not the news group to argue about this (news:comp.lang.ada is THE place).
Others will try to convince you to use an OO language. Then you have to be
carefull with the memory management unpredicitbility (Is there a garbage
collection ? Is it under the developpers control?). The best solution is to
avoid the use of dynamic object creation. Just create them at startup. You
have to know that the most used languages are (in alphabetical order) :
Ada, C, C++ for realtime system development.
Most of the time small parts of the system are still written in assembler
(small parts of Device Driver).

------------------------------
    What kind of processor should I use for my Real-Time System ?

CISC vs RISC: there has been a lot of discussion in the past about this
issue. Because of the high number of registers in a RISC processor, people
said the context switch was not compatible with real-time systems
requirements. This is not true as compilers can optimise the use of
registers to reduce the size of the context switch. A lot of points could be
added here, but as a conclusion we can say that both can be used for
Real-Time System.
PowerPC 60x versus 40x
The PowerPC 60x family is well suited for calculation, but to deal with the
external world (through Hardware Interrupt) the family 40x should be
prefered as the interrupt management is much more oriented to hardware
whereas in the 60x family it is more oriented to software.

------------------------------
    What kind of bus should I use for my Real-Time System ?

VMEbus vs Compact PCI
Just remember these few things :
1. you can have 21 boards on the same VME bus.
2. you have 7 priority levels for Interrupting on the bus
3. you have 4 level to take the bus
4. last but not least: the installed VME bus based applications is huge.
The Compact PCI offers a bigger bandwidth, is based on a widely spread
standard and the boards should be less expensive to produce (the interface
chips are cheaper).
Other busses:
The choice is big : FutureBus+, Multibus, VXIbus, PCI, ISA, ...
The choice will depend on the type of application, the type of hardware to
use (price/performance) and the target maket.

------------------------------
    What Mezzanine technology should I use ?

Industry Pack, PMC, M-Module, S-Bus ...
For IP and PMC, a good place to look at is http://www.groupipc.com/
For M-Modules, CXC Modules, a good place to look at is
http://www.vita.com/mezzprod/mezzdirindex.html
It should finally be noticed that the choice will depend on the type of I/O
you deal with. If the key point is price, then IP or M-Modules is the
answer, if performance is the key PMC or S-Bus Module should be choosen.
Another point is the availability of the products: here PMC and IP is THE
choice. They are much more widespread than any other. They are also
supported by a usergroup organisation : GRoupIPC

------------------------------
    What real-time network should I use for my real-time system?

Here the choice is huge and the standardization efforts still poor (but this
is changing quickly):
PROFIBUS, BITBUS, WorldFIP, FIELDBUS, CAN, MIL-STD-1553, ATM, Reflective
Memory, ...
The choice will depend on the price (MIL-STD-1553 is quite expensive, ATM
also), on the availability of controllers, drivers, PLC, ...

------------------------------
    Dedicated Systems and year 2000: what are the risks?

Martin Timmerman from Real-Time Consult explained:
There can be two causes of year 2000 problems: hardware and software
Software:
---------
The problem is there if you use somewhere only a two-digit system in the
software. Therefore you should check all time data structures the software
uses.
Most real-time systems do not use the absolute time for decision making,
they work with relative time. However if a time delay is computed starting
from 2 absolute times then you have a problem.
If the time is used only for time stamping then there is no problem. The
year 2000 will be 00.
The message here is: for each individual system one should look if absolute
time is used. If yes, wherefore it is used - are computations based on it?
Hardware:
---------
- Most Time Of Day (TOD) ICs have only two digit year codes.
In this case the software, should use something like:
if TODyear < 60 add 2000
else add 1900
Problem could be with leap years (1900 is not a leap year, but 2000 is. you
need to check IC spec)
- GPS can have problems (not at 2000, but on another date: this was error in
GPS specifications)
- Other HW: See TOD (remark that some Time interfaces do not have any year
information at all: IRIG-B for instance)
Special note for black boxes:
- Check the Interfaces with your system (if time is used) (use the ISD:
Interface Specification Document) or check with the Black box manufacturer
(if he is still alive.....)
Rule: everywhere time is used by the system, there is a potential year 2000
problem.
Remark: this may generate a lot of work. Subsystem by subsystem should be
examined. You need good documentation for the subsystems, which might not be
available. Having the design documentation is almost imperative and this may
also be a fundamental problem for older systems.

======================================================
V- MARKET
------------------------------
    Where can I find information related to real-time products?

Product directories :
VME Products Directory http://www.vita.com/vmeprod/prodir.html
Industry Pack and PMC Products Directory
http://www.groupipc.com/products/products.htm
Chips Products Directory http://www.xs4all.nl/~ganswijk/chipdir/
ULC Buyer's Guide http://www.cera2.com/ulc.htm
RTOS :
http://www.cs.arizona.edu/people/bridges/oses.html
http://www.realtime-info.be/encyc/market/rtos/rtos.htm

New Products :
http://www.vita.com/npgallery/npgallery.html
http://www.embedded.com/prod.htm
http://www.realtime-info.be/encyc/market/chronic/chronic.htm

------------------------------
    Where can I find information about real-time Conferences, Workshops and
Tradeshows?

http://www.realtime-os.com/rtresour.html#olconf
http://www.realtime-info.be/encyc/market/calendar/calendar.htm

------------------------------
    International organization for standards?

List from Real-Time Encyclopaedia
http://www.realtime-info.be/encyc/techno/asso/standard/standard.htm

ANSI: American National Standards Institute
IEC: International Electrotechnical Commission
IEEE: Institute of Electrical and Electronics Engineers
ISO: International Organization for Standardization
OMG: Object Management Group
OSF: Open Software Foundation
X/Open

------------------------------
    International User and Manufacturer Groups?

List from Real-Time Encyclopaedia:
http://www.realtime-info.be/encyc/techno/asso/user/user.htm
VITA VMEbus International Trade Association (http://www.vita.com)
GRoupIPC Association promoting Mezzanines Solutions
(http://www.groupipc.com)
PICMG Association promoting the Compact PCI bus (http://www.picmg.com)
Profibus (http://www.profibus.com)

------------------------------
    RTOS Market Study (Mainly Japan Market)

Because we could received only a few responses from outside Japan in regret,
only the responses from Japan have been tabulated and analyzed. You can
access the result from the following URL:
http://tron.um.u-tokyo.ac.jp/TRON/ITRON/survey97/result-e.html
Other Market studies are available (not for free) from some companies. One
of them is http://www.realtime-consult.com

======================================================
VI- RESEARCH AND FREE PRODUCTS
------------------------------
    Which Research Institute and Universities are involved in the Real-Time
field?

Here is a link to a page describing activities of Universities and Research
Institutes:
http://www.realtime-info.be/encyc/techno/research/research.htm

This list includes the following Universities and Research Institutes:
* Carnegie Mellon University, Pittsburgh, USA
* Computer Science Department at Boston University
* Cornell University, USA
* DIRECT-Distributed Real-Time Control of the Research Division of
Responsive System, GMD,
* National Research Center for Computer Science in Germany.
* DIstributed and Real-Time systems group at University of North Carolina,
Chapel Hill, USA
* Florida State University, Florida, USA
* Information Systems Engineering at University of Western Australia
* Kansas State University, USA
* Real-Time and Distributed Systems Group at Carleton University in Ottawa,
Canada
* Real-Time Systems Group at University of Pennsylvania, USA
* Real-Time Systems Laboratory (RTSL) at University of Illinois, Urbana
Champaign, USA
* Real-Time Systems Research Group at University of York, England
* Tenet Group at University of California, Berkeley, USA
* The Centre for Autonomous, Real-Time Systems (CARTS) at University of
Massachusetts, Amherst
* The Experimental Real Time Group at Uppsala University, Sweden
* The Real-Time Systems research group at University of Texas, Austin, USA
* University of Maryland, USA
* University of Michigan, Ann Arbor, USA
* University of Pittsburgh, USA
* University of Virginia, USA
* VTT Electronics
* your research group could also be added to this list.
List of links to research centers
http://www.cs.umd.edu/~fwmiller/etc/realtime/research.html

------------------------------
    Free Real-Time Product lists

Here is a collection of links towards free products
http://www.eg3.com/realxrto.htm

======================================================
VII- CONTRIBUTIONS AND FAQ LOCATION
------------------------------
    Where can I get the current copy of the FAQs?

The FAQs are posted every 4 weeks to comp.realtime, comp.answers, and
news.answers.
It is available in html format at :
http://www.realtime-info.be/encyc/techno/publi/faq/rtfaq.htm
http://www.groupipc.com/rtfaq.htm
http://www.faqs.org/faqs/realtime-computing/faq/
http://www.cis.ohio-state.edu/hypertext/faq/usenet/realtime-computing/top.ht
ml
They are also available for anonymous FTP on rtfm.mit.edu in
pub/usenet/comp.realtime:
ftp://rtfm.mit.edu/pub/usenet/comp.realtime/
Comp.realtime:_A_list_of_real-time_operating_systems_and_tools_(LONG)
Comp.realtime:_Frequently_Asked_Questions_(FAQs)
Comp.realtime:_Welcome_to_comp.realtime

For those without direct FTP access, there is also a mail-server. Address a
message to [e-mail]; leave the subject blank and include in
the body: send help. It will return the instructions for proper use.
------------------------------
Contributions to comp.realtime FAQs.
The following net.folks, among others, have contributed to this posting:

Martin Timmerman <mailto:[e-mail]>
Luc Perneel <mailto:[e-mail]>
Sebastien Deleersnijder <mailto:[e-mail]>
Christian Ebner <mailto:[e-mail]>
Thomas M. Breuel <mailto:[e-mail] >
Tim Chambers <mailto:[e-mail]>
Chuck Cox <mailto:[e-mail]>
Peter Desnoyers <mailto:[e-mail]>
Kevin Driscoll <mailto:[e-mail]>
Kurt Fuchs <mailto:[e-mail]>
Milt Fulghum <mailto:[e-mail]>
Donald Gillies <mailto:[e-mail]>
Jean-Christophe Monfret <mailto:[e-mail]>
Marcelo C Mourier <mailto:[e-mail]>
David L. Oseas <mailto:[e-mail]>
Alan F. Perry <mailto:[e-mail]>
David B. Stewart <mailto:[e-mail]>
John Theus <mailto:[e-mail]>
Alexander Vrchoticky <mailto:[e-mail]>
Christopher Vickery
Lee Brown
A. Lester Buck
David Hansen
Russ Hersch
Rob Lesieur
Dave Lunger
mailto:[e-mail]

I welcome reactions, additions, and corrections to these postings via
mailto:[e-mail]

Dedicated Systems Experts NV
Gerechtsstraat 21
1070 Brussels
BELGIUM
Tel: [phone]
Fax: [phone]
mailto:[e-mail]
http://www.dedicated-systems.com