荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: georgehill (人生不定式), 信区: Linux
标  题: Comp.realtime FAQ 5
发信站: BBS 荔园晨风站 (Sat Sep 16 11:40:32 2000), 站内信件

【 以下文字转载自 georgehill 的信箱 】
【 原文由 georgehill.bbs@smth.org 所发表 】
发信人: hhuu (什么是水,就是water啊), 信区: FreeBSD
标  题: Comp.realtime FAQ 5
发信站: BBS 水木清华站 (Sat Sep 16 00:25:17 2000)


======================================================
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.
This FAQ is not the place to start a new war, but you can send any additions
to mailto:l.uhres@rtusi.com.
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.


--
  行列中        作不朽文章
  谈笑间        论古今英雄
  痴狂里        诉红尘情爱
  来去时        不枉一生风流
                        ---------  bbs.ntu.edu.tw


※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.161.33]
--
※ 转载:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 192.168.1.115]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店