-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.24.1.13
217 lines (156 loc) · 9.16 KB
/
README.24.1.13
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
RTAI 24.1.13
============
This is the Realtime Application Interface (RTAI) for Linux 2.4. It
currently supports the following architectures:
- i386
- PowerPC
- ARM
- MIPS
- m68k-nommu
- CRIS (yet to be natively integrated into RTAI, in case of a hurry:
download http://www.efd.lth.se/~d98mad/rtai-24.1.9-cris.tar.gz,
learn how with http://www.efd.lth.se/~d98mad/rtai.html)
RTAI can now work with gcc-3.xx. Such compilers are not yet the official
ones to be used for making Linux. In fact the Linux kernel produces a
flood of scaring warnings when compiled with gcc-3.xx. Thus the choice is
up to you but it is likely that you should avoid mixing using gcc 2.95.xx
and 3.2 at least.
In the ./patches directory you'll find patches using the RTHAL and ADEOS
technologies for the Linux kernels up to 2.4.23. ADEOS is the more recent
real time support layer and at the moment is available just for i386. To
know more about it have a look at the help that comes with menuconfig and
references thereof, a useful entry might be: http://www.nongnu.org/adeos/.
ADEOS/RTHAL does not affect RTAI usage. The only thing to chose is the patch
to apply. Then you'll work the same way on either of them.
RTAI is a very lively project that is being continuously enhanced. So if
you don't find a patch for a kernel you want to use just feel free to ask
on the mailing list (see http://www.rtai.org for details).
Some of the many functionalities found in RTAI:
- Configuration based on the mechanism which is also used for the Linux
kernel (CML1, kbuild). See README.INSTALL for details.
- Efficient multi list (timed/ready/active tasks) schedulers.
- The possibilty of chosing between FIFO and RR scheduling policies on a
per task basis.
- Support for Rate Monotonic (RMS) and Early Deadline First (EDF)
scheduling.
- Extended POSIX APIs and message queues, in kernel and user space, adapted
to the new schedulers for improved performances.
- Improved an robustified dynamic memory management used by default
throughout many RTAI modules, to allow dynamic creation and deletion of
objects in real time.
- Portable fifos with extended APIs.
- Semaphores can be typed as: counting, binary and resource. Resource
semaphores can be recursively nested and support full priority
inheritance, both among semaphore resources and intertask messages, for a
singly owned resource. Priority inheritance becomes an adaptive priority
ceiling when a task owns multiple resources, including messages sent to
him. In such a case in fact its priority is returned to its base one only
when all such resources are released. This is a compromise design choice
aimed at avoiding extensive searches for the new priority to be inheredited
across multiply owned resources and blocked tasks sending messages to him.
Such a solution will be implemented only if it will prove necessary.
- Binary-counting semaphores and mailboxes can now queue tasks either in
FIFO or priority order, the related choice can be made dynamically at run
time.
- Mailboxes can now use also resource queues, RES_Q, beside FIFO_Q and PRIO_Q,
so that priority inheritance is available also to tasks waiting on a mailbox.
Resource semaphores always use priority queueing.
- A mailbox implementation, tbx, based on typed mailboxes, has been added.
It allows urgent sends and broadcasts to all queued mailboxes,
(G.M. Bertani, gmbertani@yahoo.it, http://www.geocities.com/gmbertani).
- A module, watchdog, is available for various watchdog protection
services aimed at shielding RTAI, and the host Linux OS, against
programming errors in RTAI applications (Ian Soanes, ians@lineo.com).
- Added functions rt_sched_lock/unlock, rt_get_prio, rt_get_inher_prio,
rt_change_prio, rt_task_wakeup_sleeping, rt_mbx_evdrp.
- A function to choose which CPU APIC timer must be used by the SMP scheduler.
- A module to implement tasklet functions, either as simple or prioritized
periodic/oneshot timed functions, both in kernel and user space. It can be
very useful in many instances. For an explanation of this new feature see
the file README in directory tasklets.
- Tasklets/timer are also integrated with (NEW)LXRT.
- No need to calibrate, required frequencies assigned dynamically at run time.
Fine calibration procedures available for those that want it better.
- (NEW)LXRT, for soft hard real time in user space, is a fully informed unified
environment with the possibility of both inlining and library linking.
A lot of work has been poured in it.
It would take too long to explain it all, look at the code.
- (NEW)LXRT can be made to not break if Linux is called in hard real time mode;
it switches to soft real time returning later to hard operations.
- Hooks for remote gdbegugging in place natively under conditional compilation.
- AIO support module offering open/read/write/close from hard real time kernel
tasks, in both sync and async manner
- Availability of the nice LinuxTraceToolkit, natively integrated into RTAI
modules.
- Octave files directly usable in user space for real time.
- Matlab/Simulink/Real_Time_Workshop automatic generation of control programs
supported in user space hard real time. A direct porting of what Mathworks
distributes for Tornado/vxWorks. (Developed no more, see RTAI-Lab below)
- An helper module exists to support kernel space omly applications that need
intermodule registration of objects and full QNX messaging. They can now
avoid using the full LXRT just for that.
- In kernel space it is now possible to use intertask messaging with
arbitrarely sized messages, including asynchronous send, along the lines
of the corresponding RTAI APIs, with equivalent QNX functionalities but
without full correspondence.
- net_rpc is available to allow use of almost all of the RTAI services in a
distributed way. The net support distributed with RTAI is not yet real time
but the APIs implementation is so already. For real time networking
download RTNet from: http://www.rts.uni-hannover.de/rtnet/.
- multi events synchronization to allow synchronizing on a the matching of
multiple conditions through bits masks (events).
- RTAI can work on 5 architectures now: ix86 (and compatibles), PPC and ARM,
m68k-nommu, CRIS.
- Support for vintage 386/486.
- Support of non 0/1 APIC mapping.
- Support for use of real time serial ports (rt_com/rt_com_lxrt) directly from
user space (Giuseppe Renoldi, giuseppe@renoldi.org).
- A new support for using serial ports in real time, user/kernel space (SPDRV),
with blocking/timedout read/write also.
- NEWLXRT, i.e. LXRT without using RTAI proper tasks. It schedules anything
schedulable under RTAI-LINUX, i.e: Linux tasks/kernel threads and RTAI proper
kernel tasks. Under NEWLXRT kernel space threads works in hard mode always.
In user space Linux tasks can be soft/hard as in LXRT. Anything that ran the
standard way can run under NEWLXRT (kernel/user space).
- Support for writing interrupt handlers in user space (UserSpaceInterrups,
USI).
- Support for LABVIEW under (NEW)LXRT, in soft hard real time. It should now
be possible to program your hard real time application, including interrupt
handlers, using the visual 'G' language.
- Support for making it easy to prepare a bootable floppy that run RTAI
(uRTAI, read it microRTAI).
- Support for COMEDI kernel space APIs (kcomedilib) in user space under
LXRT/NEWLXRT, in soft/hard real time.
- RTAI-Lab to run control/simulation application automatically generated by
Matlab/RTW and Scilab/Scicos the way you like, i.e. alone, mixed, locally
remotely, monitoring signal on scopes, back logging data and changing system
parameter on the fly when and wherever you want. Comedi support available.
The naming convention used for RTAI is the following:
X.Y.Z
The major version number, X, refers to the Linux kernel series, e.g. "24"
is for the Linux 2.4 kernel series. The minor version number, Y, is odd for
development series and even for stable releases; micro (Z) is the current
release.
It is likely that field 2 will never become even. In practice full usage of
the naming convection is postponed indefinitely.
What above does not tell it all. In fact it is important to remark that now
RTAI is far from being a single hand, or departmental (DIAPM), work.
See README.COORDINATORS for a whole picture of who's who in RTAI
development. So even if I (Paolo) still pretend that RTAI must be traced
back to my Department (DIAPM), which remains its homeland, I like to stress
wholeheartedly that it is now a true open source project, where many
important new contributions have been, and are being, added by many people,
who often contributed also substantial improvement to the core
functionalities available since its birth.
The installation procedure, from Linux 2.4.4., is based on standard
patching.
We'll be glad if you take your chances, test it, and maybe help in any
further fix, bugs are always there.
Any help, suggestion and bug reports will be warmly welcomed by all RTAI
developers.
A common RTAI users/developpers forum is the project mailing list:
rtai@rtai.org
For more details see the homepage:
http://www.aero.polimi.it/~rtai,
or its main mirror:
http://www.rtai.org