The Real-Time Driver Model and First Applications

J. Kiszka
University of Hannover
Appelstrasse 9A, 30167 Hannover, Germany
[email protected]

Abstract
The Real-Time Driver Model (RTDM) is an approach to unify the interfaces for developing device
drivers and associated applications under real-time Linux. The device models supported by RTDM will
be introduced in this paper. An overview of the low and high level APIs will be given and the concept
of device profiles for defining generic device interfaces will be presented. Moreover, the integration of
RTDM in Xenomai will be explained and a survey of already available applications of this concept will
be provided.

1 Introduction trast, POSIX-I/O-based devices that handle discrete

messages either have to misuse the stream-oriented
Since the introduction of so-called dual-kernel hard read/write interface or define specific IOCTLs for
real-time Linux extensions like RTLinux [1] and message transmission and reception.
RTAI [2], a large number of drivers have been de-
veloped as well. Just to name a few, there are both Moreover, drivers are still being developed sep-
vendor-independent projects like Comedi [3], rtcan arately for the currently predominant free real-time
[4], or rt com [5] as well as vendor-provided driver Linux variants. Partly, this seems to happen due to
packages [7, 6]. personal favours of the driver maintainers. But there
Although many of those drivers address similar are also obvious technical reasons. As no common
hardware, only few effort has been spent so far on API exists, every driver would have to come with its
unified application programming interfaces. Most own abstraction layer for all target variants. The re-
drivers define their own library-like API which hin- quired effort makes it understandable that portable
ders easy replacements of hardware, as the applica- drivers are very few these days.
tion software has to be adapted to the driver of the
new hardware. In order to overcome this deficits technically
Comedi provides a useful abstraction for data ac- and organisationally, the Real-Time Driver Model
quisition devices but is limited to a subset of control (RTDM) has been specified and first implemented on
applications, excluding scenarios where direct access top of Xenomai [10], the successor of RTAI/fusion.
to low-level devices like fieldbuses is required. Also, Also several reference drivers have been ported or
Comedi does not include intermediate interface spec- newly developed to demonstrate the concept and
ifications for more complex device stacks, e.g. when proof its feasibility. Another aim of this effort is to
USB-attached acquisition devices shall be used over create a platform for research on secure hard real-
a reusable real-time USB stack. time operating systems and driver [11, 12], but the
Some RTLinux/GPL drivers [8, 9] map their latter aspect goes beyond the scope of this paper.
services on the POSIX I/O interface this variant
provides. This mapping aims in principle into the In the following section, the RTDM core concept
right direction, but the basic POSIX I/O interface is is introduced. Section 3 presents the implementation
too restrictive for message-oriented devices. Under for Xenomai, and Section 4 gives an overview of al-
common OSes, this type of devices is typically ad- ready realised or upcoming applications. The paper
dressed via protocol stacks which are mapped on the concludes with a summary and an outlook on future
well-established socket programming model. In con- goals.

1
2 RTDM 2.1 Device Models
The Real-Time Driver Model is first of all intended to Two different types of devices are supported by
act as a mediator between the application requesting RTDM. They have been selected based on the char-
a service from a certain device and the device driver acteristics of currently available drivers for real-time
offering it. Figure 1 shows its relation to other sub- Linux.
system layers.
• Protocol Devices
All message-oriented devices fall in this group.
Protocol devices are registered using two iden-
tifiers, the protocol family and the socket
type. They are addressed according to
the POSIX socket model, i.e. by in-
voking socket() for creation and close()
for destruction. At the least, they have
to provide support for sending and receiv-
ing messages: sendmsg() and recvmsg()
on which send()/sendto() and accordingly
recv()/recvfrom() are mapped internally.
FIGURE 1: RTDM and Related Layers Moreover, drivers of protocol devices may han-
The depicted libraries on its top and the hard- dle requests issued via ioctl(). This inter-
ware abstraction layers on the bottom are not within face is also used to pass the remaining socket
the scope of RTDM. Rather, they are optional indi- calls bind(), connect(), listen(), accept(),
rection layers which may be added where further ab- shutdown(), getsockopt(), setsockopt(),
straction is desired. Libraries may be introduced to getsockname(), and getpeername() to the
simplify the usage of the upper RTDM API for a spe- driver. This mapping has been chosen to avoid
cific device class. HALs are recommended to reuse creating a significant amout of entry points
code passages common to several drivers, e.g. a pro- in the RTDM layer for only infrequently used
tocol stack attached on top of different low-level com- functions.
munication adapter drivers. Consequently, RTDM
supports and encourages driver stacking, see Figure • Named Devices
2, but the driver developer remains free to define dif- These devices are registered with the real-time
ferent inter-driver layers where appropriate. An ex- subsystem under a unique clear-text name and
ample is the NIC adapter interface of RTnet which can then be instantiated using the open() func-
is derived from standard Linux in order to simplify tion. RTDM does not maintain a specific nam-
the porting of non-real-time drivers to RTnet [13]. ing hierarchy or file system. Basically, drivers
are free in choosing device names, but regu-
lar schemes are specified for common classes in
device profiles. Named devices can be subdi-
vided into those which support stream-oriented
I/O (read()/write()) and those that solely
offer functionality via the ioctl() interface.
A typical example for the former group are
UART devices. The latter group catches all
devices which do not match both the message
and stream oriented model.

RTDM does not include a specific model for real-

time block devices or even file systems. Such class
of devices is currently considered minor important
FIGURE 2: Stacking RTDM Devices
because most hard real-time applications can be re-
While RTDM’s high-level API follows the alised with non-real-time file systems in combination
POSIX socket and I/O model [14], its low-level inter- with appropriately sized intermediate buffers. How-
face is designed to provide a small RTOS abstraction ever, future extensions are possible in case demand-
layer for building portable drivers upon. ing scenarios emerge.

2
2.2 Device Registration and Invoca- source allocation strategies have to be used in real-
tion time contexts in contrast to non-real-time environ-
ments, a clear differentiation of service invocation
A RTDM device is registered by passing a device de- contexts is essential. In order to let the driver decide
scription to rtdm dev register(). Table 1 gives an how to handle different contexts, separate handlers
overview of central parameters that have to be spec- can be installed for each entry type. If, e.g., the
ified for this purpose (informational fields were left open procedure of a device shall only be executed in
out). non-real-time context, the driver simply registers no
real-time handler for open, and vice versa. In case a
handler is context-agnostic, it is also possible to reg-
Field Name Description
ister the same handler for both entry points. More-
over, the RTDM implementation can provide intel-
ligent context switching upon service invocations in
device flags Defines the device type
case the underlying RTOS supports such a feature.
(named/protocol) and if the
When an application or another driver creates a
device can be instantiated only
device instance, RTDM sets up a new context struc-
once at the same time (exclusive
ture for this usage and redirects the call to the related
device) or multiple times.
driver. The context structure keeps general informa-
tion about the instance like the file descriptor or a
device name Name to be registered (named
usage counter. It also allows to overwrite the opera-
devices only).
tion handlers to be used with this particular instance.
Attached to the general part is a private storage for
protocol family Protocol family (PF xxx) and
the driver. The size of the storage can be specified
socket type socket type (SOCK xxx) to be reg-
during device registration.
istered (protocol devices only).
Closing a device instance is sensitive to the cor-
rect context. If the instance has been created in non-
context size Size of the driver defined ap-
real-time context, it cannot be closed within a real-
pendix to the structure describ-
time task. This is due to the fact that resource allo-
ing a device instance (device con-
cations (foremost memory) of both the RTDM layer
text).
and the drivers will prefer non-real-time pools when
accessible to save typically more limited resources of
open rt Handler for named device in-
real-time pools. The RTDM layer has to take care
open nrt stance creation (real-time and
of this rule and catch potential violations.
non-real-time invocation).
Drivers are allowed to create device instances as
well. An equivalence of the user API is available to
socket rt Handler for Protocol socket cre-
them. Alternatively, drivers can also call operation
socket nrt ation (real-time and non-real-
handlers of other drivers directly. For this purpose,
time invocation).
the related device context first has to be resolved via
rtdm context get() after instantiating the device
ops Contains the operation handlers
as normal. Then this context can be used to ob-
for newly opened device in-
tain the desired handler reference and to invoke the
stances. The operations are
operation without any indirections of RTDM. The
close, ioctl, read, write, recvmsg,
context is locked against closure and has to be ex-
and sendmsg. Depending on the
plicitly released via rtdm context unlock() before
device type, not every handler
closing the device.
has to be provided. Again, differ-
ent handlers can be specified for
real-time and non-real-time invo- 2.3 RTOS Abstraction Layer
cations. To increase the portability of drivers, RTDM pro-
vides a generic API of elementary RTOS services
device class Categorisation of the device, see that is independent of the underlying system. The
device sub class Section 2.4. API is designed to offer only a minimum set of ser-
vices typical real-time drivers require. This helps to
keep the RTDM layer small and also improves its
TABLE 1: Device Structure (digest)
own portability over other real-time Linux variants.
As different synchronisation mechanisms and re- The following groups of services are available:

3
 • Clock Services below illustrates such a service handler and the usage
RTDM offers a single clock source which can of timeout sequences.
be queried by rtdm clock read(). Time is ex-
pressed by 64 bit values in nanoseconds. int device_service_routine(...)
{
• Task Services rtdm_toseq_t timeout_seq;
This group of functions allows drivers to create ...
their own real-time tasks, suspend the execu-
tion of user and driver tasks, or manipulate rtdm_toseq_init(&timeout_seq, timeout);
their characteristics (priority and periodicity). ...
while (received < requested) {
• Synchronisation Services ret = rtdm_event_timedwait(
Various elementary synchronisation services &data_available,
are provided by RTDM. First of all, spinlocks timeout,
can be used for protecting small critical paths, &timeout_seq);
also when they are located in interrupt han- if (ret < 0) // including -ETIMEDOUT
break;
dlers or run in non-real-time contexts. Clas-
sic mutexes and semaphores for synchronising
// receive some data
real-time tasks are available as well. As an ...
alternative to semaphores, events can be ap- }
plied. They do not count beyond 1 and can also ...
be instructed to only wake up currently wait- }
ing tasks without storing the event. Mutexes,
semaphores, and events support so-called time- By convention, timeouts should be passed in
out sequences which will be introduced later. nanoseconds as signed 64-bit values when request-
• Interrupt Management Services ing device services. The timeout value 0 is auto-
An essential service for most hardware drivers matically interpreted by synchronisation services as
infinite delay, any negative value as no delay at all
are interrupts. Handlers for real-time interrupt
lines can be registered with RTDM, and the (non-blocking request).
lines can be enabled and disabled explicitly. Time-triggered events outside service requests
can be executed within driver tasks. This allows to
• Non-Real-Time Signalling Services assign specific priorities to time-triggered actions in-
To propagate events from the real-time to the stead of just executing them at the level of all timers,
non-real-time domain, a special signalling ser- i.e. typically above any user task or even in interrupt
vice can be requested from the RTDM layer. context.
Triggering such a signal is safe from any con- Detailed information on all RTDM services is
text. The registered handler will then be ex- available through the Xenomai API documentation
ecuted in non-real-time context as soon as no which can be found on the project homepage [10].
more time-critical tasks are pending.

• Utility Services 2.4 Device Profiles

This group of services includes real-time mem-
ory allocation, safe access to user space mem- Beyond simplifying the implementation of device
ory areas, real-time-safe kernel console output, drivers for real-time Linux and improving their
and, as an alternative to separate service en- portability, another aim of RTDM is to establish
try points, a check if the current context is a device abstractions for common hardware classes.
real-time task. Generic device interfaces allows to develop applica-
tions that are less dependent on specific hardware
Timers are not explicitly provided. Instead, and their interfaces than it is now the case with real-
drivers are given the powerful mechanism of time- time Linux. Moreover, the learning curve for writing
out sequences for handling service requests. Time- real-time applications becomes steeper with a com-
out sequences can be used to apply a single, continu- pacter set of device interfaces.
ous timeout value while calling blocking synchronisa- RTDM organises device abstractions in so-called
tion functions multiple times. Stream devices, e.g., device profiles. Every profile defines for a specific de-
require to wait iteratively on incoming data while vice class how conforming drivers have to be realised.
maintaining an overall timeout. The code fragment More in details, the following aspects are covered:

4
 • Device Characteristics and is thus able to provide RTDM services indepen-
This category defines the device class and its dently. The RTDM user API is addressable both
representation in the device structure (see Ta- from kernel and user space. The function names of
ble 1), the device type (i.e. the device flags RTDM’s POSIX interface carry a rt dev prefix in
field), and the naming scheme for named de- order to distinguish them from non-real-time vari-
vices, respectively the protocol family and ants. A library, librtdm, is used to redirect API calls
socket type for protocol devices. from user space to the kernel services. The RTDM
skin makes use of Xenomai’s ability to switch user
• Supported Operations space real-time threads automatically between hard
All major operations that have to be imple- real-time (primary) and Linux (secondary) operation
mented by conforming drivers are listed here mode. In case no handler for a device service request
together with the required and optional invo- is available in the current mode, RTDM switches over
cation contexts (real-time/non-real-time) and to the supported one. If handlers for both contexts
the meaning of specific return values. More- are present, RTDM always preserves the operation
over, the IOCTLs and socket options devices mode so that the user is able to control in which
have to provide are described in details, i.e. context a device service shall be executed.
their arguments, return codes, and invocation The integration of RTDM into the POSIX skin
contexts. is realised differently. Here, the user space in-
• Types and Constants terface is directly included in the wrapper library
Structures and other data types typically intro- libpthread rt. RTDM devices can be opened un-
duced with device class specific IOCTLs and der the POSIX skin by using the normal function
socket options have to be described in details, names without any prefixes. As the name spaces of
as well as any constants to be used in this con- RTDM and standard Linux now overlap, the follow-
text. ing scheme is applied when handling instantiation
requests: first, the RTDM subsystem is consulted to
Non-common extensions to device classes are in- open the device or create the socket. If this fails
tended to be organised in subclasses. Thereby, fea- due to an unknown device name or protocol, the re-
tures that are only available with certain hardware quest is forwarded to the non-real-time subsystem as
e.g. can be specified as optional to the superior class. usual. To differentiate between file descriptors cre-
A significant number of device profile specifica- ated by standard Linux on the one side and RTDM
tions is currently under development or is pending to on the other, the maximum value of a non-real-time
be derived from existing drivers, Section 4 will give descriptor is limited to FD SETSIZE−1, reduced by
an overview. the typically small maximum number of real-time
descriptors. Every descriptor value above this limit
is handled by RTDM, everything below or equal is
3 RTDM in Xenomai forwarded to Linux. Keeping real-time descriptors
within the range of file descriptor sets allows future
While the history of RTDM lasts back to the releases extensions of RTDM with poll/select functionalities.
0.6 (RTOS abstraction layer) and 0.7 (device models)
of the real-time networking stack RTnet, Xenomai
was the first real-time Linux extension to support 4 Applications
the new RTDM revision as presented in this paper.
Xenomai allows to attach various user APIs, The RTDM revision described here was first tested
called skins, to its scheduler nucleus. These APIs are extensively with RTnet and a UART device driver
available to kernel space and user space real-time ap- under Xenomai. Both scenarios and the related de-
plications. Most skins may even be loaded in parallel, vice profiles are shortly introduced below. Mean-
thus offering interfaces for different types of real-time while, further applications emerged that are cur-
applications at the same time. Most popular skins rently being developed or planned for RTDM. On
are the native skin, an improved version of the clas- overview is given in the following as well.
sic RTAI API, and a POSIX-conforming skin. There
are also interfaces for commercial RTOSes available,
4.1 RTDM Devices of RTnet
e.g. VxWorks or pSOS+.
Early ideas to include RTDM in Xenomai’s na- The real-time networking stack RTnet comes with
tive skin were quickly dropped in favour of the final three different device profiles for RTDM. First of all,
concept to create a separate skin. This skin can now there are two protocol devices, real-time UDP and
be loaded together with the preferred main interface the packet socket interface. Both profiles basically

5
conform to the interfaces available with Linux and terfaces and mapped into one or more process im-
other POSIX implementations. Additionally, several ages. All communication to collect and update the
IOCTLs are defined to control RTnet-specific trans- I/O points are hidden behind this abstraction. The
mission parameters (priority and channel/slot), set a process image is updated either automatically or ex-
reception timeout according to the RTDM format, or plicitly triggered by the control application.
manipulate the number of packet buffers per socket. As a first approach to map this model in a generic
Moreover, the TDMA discipline for RTmac way on RTDM, the process image device profile has
maintains a special device for each real-time NIC it been developed. It consists of a named RTDM device
is attached to. This device provides an IOCTL to which solely supports two elementary IOCTLs. One
retrieve the offset of the local clock relative to the is used to update the process image. The image is
global TDMA clock. Another IOCTL is available to split into an input and an output memory block that
synchronise the calling real-time task on the TDMA can further be limited to a continuous block within
cycle of the related NIC. the full process image, see following code excerpt:
Support for recent RTDM can be found in RTnet
since release 0.9.0. #define RTPI_RTIOC_UPDATE \
_IOWR(RTIOC_TYPE_PROCIMG, 0x01, \
struct rtprocimg)
4.2 Serial Device
As an example for named stream devices, a serial struct rtprocimg {
off_t procdata_out_offs;
device profile has been worked out. This profile pro-
size_t procdata_out_size;
vides access to a serial device via read/write. It
void *procdata_out_buf;
also defines IOCTLs to manipulate the output sta-
tus lines, retrieve the input lines, wait on device off_t procdata_in_offs;
events, and configure the line characteristics, time- size_t procdata_in_size;
outs, and events of a serial device. As a specifically void *procdata_in_buf;
real-time-oriented feature, a timestamp history for };
every character in the input queue can optionally
be maintained. Such precise timestamping is typ- The update may happen synchronously or asyn-
ically required when synchronising multiple sensors chronously, depending on the device configuration
and actuators attached to different I/O interfaces. and hardware abilities. Moreover, several instances
The code excerpt below shows the related IOCTL referring to the same physical or logical process im-
and data structure to obtain timestamps: age device can be created. In this case, one instance
has to be elected to become the update master which
#define RTSER_RTIOC_WAIT_EVENT \ ultimately decides about the update time. The slaves
_IOR(RTIOC_TYPE_SERIAL, 0x05, \
have to provide their output changes before the mas-
struct rtser_event)
ter starts a new cycle. This scheme allows to dis-
typedef struct rtser_event { tribute the processing across several threads or pro-
/* signalled events */ grams while still keeping the image consistent.
int events; The second IOCTL provides an interface to con-
/* number of pending input characters */ figure the device, but it only defines mechanisms to
int rx_pending; pass and retrieve unspecified configuration data and
/* last interrupt timestamp */ to set the update timeout. The precise configuration
__u64 last_timestamp; data format depends on the subclass and is highly
/* reception timestamp of oldest character hardware-dependent.
in input queue */ To prove the profile’s applicability, a driver for a
__u64 rxpend_timestamp;
Hilscher InterBus master adapter has already been
} rtser_event_t;
implemented [15] and required configuration data
Xenomai comes with a reference driver for UART has been specified for this subclass.
16550A chips conforming to the serial profile. The
latest profile specification is available with the Xeno- 4.4 CAN Protocol Stack
mai API documentation.
With the aim to develop a compact socket-based pro-
gramming model for the CAN fieldbus, a driver for
4.3 Process Image Device
a SJA1000 CAN extension card is currently being
In automation scenarios, distributed I/O points are implemented at our institute. This effort is tightly
typically collected via various fieldbuses or other in- coordinated with parallel work on a CAN framework

6
for standard Linux. The goal is to have a common 4.6 Planned Profiles
user interface for both approaches, while the imple-
mentation details will differ: the Linux variant will Beyond the work listed above, at least two further
re-use the networking subsystem, the RTDM version projects plan to make use of RTDM soon. The RT-
has to implement a hard real-time capable infrastruc- FireWire project [19], a hard real-time implementa-
ture. The second revision of the device profile was tion of an IEEE 1394 stack, already ported its core
under development at the time of writing in order over the RTOS abstraction layer of RTDM. Future
to reflect practical experiences gained through the plans include to export a raw FireWire interface as
ongoing implementation efforts and to include bene- a RTDM device.
ficial ideas of a similar approach [16]. Also the USB4RT project [20] which realises a
With a first concept for mapping CANopen on hard real-time USB stack aims at a full RTDM sup-
the socket model [17] being available now, the de- port for its next releases. Again, the goal is to pro-
velopment of a RTDM CANopen profile is in reach vide the lower USB interface, on which high level
as well. Drivers implementing it may then either at- drivers for I/O devices, cameras, joysticks, etc. can
tach to CAN devices or even to other communication be built, via an RTDM device.
interfaces like RTnet. In best case, the application Beyond these plans, mapping Comedi on RTDM
will not notice significant differences between such is considered feasible as well. Comedi already uses a
stacks. POSIX I/O interface between its core and the user
API, which would be mappable directly on named
RTDM devices. Porting Comedi’s real-time core over
the RTDM RTOS layer would furthermore simplify
4.5 Tiny Messaging Service (TiMS) the maintenance effort for this project regarding sup-
ported real-time platforms.
As a revision and update of the real-time commu-
nication framework [18] used for mobile robotics at
our institute, the Tiny Messaging Service has been
defined and implemented for RTDM. While a de- 5 Summary and Future Devel-
tailed description would exceed the scope of this pa- opment
per, a short overview of improvements compared to
the original concept is given in the following. This paper presented the Real-Time Driver Model.
The basic idea of TiMS remains to exchange mes- It aims at unifying the interfaces against which real-
sages between real-time components both locally and time device drivers and the applications using them
remotely in a transparent but efficient and determin- can be developed. RTDM supports the two mod-
istic way. Addressing is based on 32 bit message IDs els of named devices for stream and miscellaneous
that are unique across the whole system. Unlike the use cases on the one side and protocol devices for
old concept which came with a set of special library message-oriented use cases on the other. An abstrac-
functions, TiMS provides its services as a RTDM pro- tion layer for RTOS services, specifically addressing
tocol device, thus based on the socket model. A mes- driver development, allows portable device drivers
sage receiver opens a PF TIMS raw socket and binds for any Linux platform that implements RTDM. De-
it to a specific ID. The sender opens a socket as well vice profiles are being defined in order to create
and passes the raw message header followed by the generic interfaces for common classes of devices, thus
payload to TiMS e.g. via send(). In case a destina- making applications less dependent on specific hard-
tion ID is not locally available, routing is currently ware and simplifying its replacement.
still based on static information for real-time links RTDM is fully implemented under Xenomai and
and dynamic lists for non-real-time traffic. By mak- serves as the reference model for driver development
ing use of RTnet for hard real-time communication in this environment. At the time of writing, an ef-
between distributed users, TiMS is also an example fort to port it over the RTAI development branch
for stacked RTDM drivers. (upcoming release 3.3) has been started as well. Im-
TiMS is part of the new Robotics Application plementing RTDM on other real-time Linux variants
Construction Kit (RACK) that has been developed is considered to be feasible, too. As soon as the
over Xenomai and is currently in an intensive test currently emerging effort around the PREEMT RT
phase. The RACK core is going to be released un- patch [21] to add native real-time support directly
der Open Source licenses afterwards. The goal is to the kernel matured and became common, a com-
to provide a mature framework for distributed real- patibility layer for RTDM is also imaginable and
time computing in user space both for academic and would increase the usability of existing hard real-
industrial use cases. time drivers even more.

7
 Future work on RTDM itself will deal with inter- [11] J. Kiszka, B. Wagner, 2003, Domain and Type
faces and mechanisms to provide poll/select seman- Enforcement for Real-Time Operating Systems,
tics also under hard real-time constraints. The de- 9th IEEE International Conference on
sign of such services is challenging because dynamic Emerging Technologies and Factory Au-
allocation of data structures for managing file de- tomation, Lisbon (Portugal).
scriptor groups that are monitored by poll/select has
to be avoided. Moreover, a common signalling mech- [12] J. Kiszka, B. Wagner, 2004, Securing Software-
anism has to be defined so that all combinations of Based Hard Real-Time Ethernet, 2nd IEEE In-
RTDM device types will be usable. Poll/select sup- ternational Conference on Industrial
port will likely introduce a certain overhead with re- Informatics, Berlin (Germany).
spect to code complexity and data structure sizes.
Therefore, it is planned to specify it as a configu- [13] J. Kiszka, B. Wagner, Y. Zhang, J. Broenink,
ration option both for the RTDM core as well as 2005, RTnet A Flexible Hard Real-Time Net-
conforming drivers. As many real-time applications working Framework, 10th IEEE Interna-
work fine without these semantics, they should not tional Conference on Emerging Tech-
suffer from overhead in the future without gaining nologies and Factory Automation, Cata-
advantages. nia (Italy).

[14] IEEE, 2004, IEEE Std 1003.1, 2004 Edition.

References [15] rt cifibm, 2005, CIF InterBus Master
[1] M. Barabanov, 1997, A Linux-based Real-Time Driver, www.rts.uni-hannover.de/mitarbeiter/
Operating System, Master’s thesis, New Mexico kiszka/rtaddon
Institute of Mining and Technology.
[16] I. Bertolotti, G. Cena, A. Valenzano, 2005, A
[2] P. Mantegazza, E. Bianchi, et al., 2000, RTAI: Socket-based Interface to CAN, 10th interna-
Real-Time Application Interface, Linux Journal tional CAN Conference, Rome (Italy).
#72, www.linuxjournal.com/article/3838
[17] G. Cena, I. Bertolotti, A. Valenzano, 2005, Mod-
[3] Comedi, Control and Measurement Interface, elling CANopen Communications According to
www.comedi.org the Socket Paradigm, 10th IEEE Interna-
tional Conference on Emerging Tech-
[4] rtcan, Realtime CAN for Linux/RTAI,
nologies and Factory Automation, Cata-
www.esfnet.co.uk/index.php?page=rtcan
nia (Italy).
[5] rt com, Real-Time Linux driver for the serial
port, rt-com.sourceforge.net [18] O. Wulf, J. Kiszka, B. Wagner, 2003, A Compact
Software Framework for Distributed Real-Time
[6] Hilscher GmbH, 2004, RTL CIF Device Driver Computing, 5th Real-Time Linux Work-
V2.000, System Software CD. shop, Valencia, Spain.
[7] ADDI-DATA GmbH, Company Homepage, [19] Y. Zhang, B. Orlic, P. Visser, J. Broenink, 2005,
driver download section, www.addidata.com Hard Real-Time Networking on FireWire using
[8] S. Pez, J. Vila, I. Ripoll, 2003, Building Ether- Linux/RTAI, 7th Real-Time Linux Work-
net Drivers on RTLinux-GPL, 5th Real-Time shop, Lille (France).
Linux Workshop, Valencia (Spain).
[20] USB4RT, USB for Real-Time, devel-
[9] OCERA, Linux CAN Driver (LinCAN), oper.berlios.de/projects/usb4rt
www.ocera.org/download/components/WP7
[21] PREEMPT RT, Realtime Preemption Patch,
[10] Xenomai, Project Homepage, www.xenomai.org redhat.com/∼mingo/realtime-preempt