University of Twente
Faculty EE-Math-CS
Department of Electrical Engineering
Adequacy of the Universal Serial
Bus for real-time systems
Niels Korver
Individual Design Assignment
Supervisors
dr.ir. J.F. Broenink
MSc. B. Orlic
May 2003
Report 009CE2003
Control Engineering
Department of Electrical Engineering
University of Twente
P.O.Box 217
7500 AE Enschede
The Netherlands
ii
Adequacy of the Universal Serial Bus for real-time systems
Table of contents
1
2
3
4
5
6
Introduction _____________________________________________________1
1.1
Real-time systems __________________________________________________ 1
1.2
Universal Serial Bus ________________________________________________ 2
Real-time characterization _________________________________________3
2.1
Real-time systems __________________________________________________ 3
2.2
Latency time demands ______________________________________________ 3
2.3
Jitter demands ____________________________________________________ 4
2.4
Reliability and errors _______________________________________________ 4
2.5
Flexibility and scalability ____________________________________________ 5
2.6
Physical structure __________________________________________________ 5
2.7
Flow control ______________________________________________________ 5
2.8
Composability _____________________________________________________ 6
2.9
Sporadic and periodic data __________________________________________ 6
2.10
Hard versus soft real-time ___________________________________________ 6
USB specifications ________________________________________________7
3.1
Features __________________________________________________________ 7
3.2
Connection structure _______________________________________________ 7
3.3
Endpoint of device _________________________________________________ 8
3.4
Transfers ________________________________________________________ 10
3.5
Latency time _____________________________________________________ 13
Experimental Setup ______________________________________________14
4.1
Introduction to USB device _________________________________________ 14
4.2
Introduction to USB port on PC _____________________________________ 15
4.3
Approach ________________________________________________________ 16
Results_________________________________________________________20
5.1
Meaning of results ________________________________________________ 20
5.2
Statistical analysis_________________________________________________ 20
Conclusions and recommendations _________________________________25
Appendix A Measurement results ______________________________________27
Appendix B User-guide for performing the measurement tests______________31
References _________________________________________________________32
iii
List of abbreviations
CAN
CRC
FX2
HC
HUB
IN
IRP
LAN
MCU
OUT
PC
PCI
SOF
USB
USBD
WCET
iv
Control Area Network
Cyclic Redundancy Check
A certain programmable USB device
Host Controller
A device that provides additional connections
Data flow in the direction to the computer from the USB device
Interrupt Request Packet
Local Area Network
Microprocessor Control Unit
Data flow in the direction from the computer to the USB device
Personal Computer
Peripheral Component Interconnect
Start Of Frame
Universal Serial Bus
Universal Serial Bus Driver
Worst-Case Execution Time
Adequacy of the Universal Serial Bus for real-time systems
1 Introduction
Nowadays there are a lot of things done by machines. Often these machines make use of
communication channels to receive controlling information from human persons or other
machines. Also between subparts of a machine there is often a communication channel. There
are several kinds of communication channels varying from a simple electrical wire to
complicated networks.
Since the computer is increasingly used to receive information and to control machines
(devices) it is important to think about what is the best kind of communication channel to use
between them. In former days the serial port was most used, now there are a lot of
technologies for the communication between computer and device such as IEEE1394
(FireWire), IrDa (Infrared), Bluetooth, CAN, I2C and USB. Of course each technology has its
own advantages and disadvantages regarding to specific properties. If we want to use a
communication channel between computer and device important to find out what are the
necessary properties for the desired application. As an example of different kind of properties
there are: data transfer/second; robustness; prize; distance between device(s) and computer;
topology; delay time; amount of data/transfer; constancy of data/time.
Goal of this project is to investigate some of the specifications of the delay time of data
transfers in systems with the USB protocol. Unfortunately it is not possible to investigate all
the parameters; therefore we only look at the most interesting of them. When the average and
worst-case delay time are known possible to determine if the protocol is feasible for certain
real-time applications. This explains the title of this report: "Adequacy of the Universal Serial
Bus for real-time systems". To clear up the term real-time and to explain why we want to test
USB the remaining part of this chapter is about these subjects.
1.1 Real-time systems
When one place a telephone call with somebody, it seems that there is no delay between the
instant that one say something and the other person hears it. In reality there is always some
time between both moments, it is about a millisecond and one have no troubles with it. There
are situations where a communication process is used in which a millisecond delay time is a
lot too much. When the specification of the delay time in a specific system is good enough
regarding to the demands of the system, we can say that the system has a "real-time"
behavior.
In the current systems it is common to use computers to perform digital signal processing.
Therefore, the use of digital communication channels is useful and thus there will be a certain
delay time. There are several reasons for a digital delay time like:
• Data always consist of one or more 'ones' and 'zeros', called bits. All bits must be a certain
time active, the time it takes to transfer data is dependent on how many bits are sent after
each other.
• If the data needs some processing (e.g. modulating, determining target) this takes some
time.
• When there are more than two things connected to the same channel the sender has
sometimes to wait until the channel is idle.
Since this project is about real-time systems in general and not about one specific system it is
not possible to formulate strict demands for the real-time communication channel. One can
1
analyze the channel and determine some parameters of it. Thereafter one can look at a specific
system and say if the communication channel is feasible. Several things concerning the realtime behavior can be analyzed using the available literature.
1.2 Universal Serial Bus
The problem of the old connection methods was that there were a lot of problems with
installing the peripherals to the PC and they were very slow. The solution for these problems
was to replace the Serial and Parallel ports with the USB port, and the solution regarding to
the ISA was the PCI interface.
USB and PCI are said to be "Plug & Play": plug them into the PC and after installing the
right software the peripheral will play trouble-free. The biggest advantages of the USB-port
compared to the Serial and Parallel port are: faster (480 Mbytes/second instead of 115
Kbytes/second), easier to install, more peripherals can be connected to one computer (up to
128), connect and release is possible without restarting the computer. The USB protocol has
full support of real-time data transport for voice, audio and video. Unfortunately real-time
control data differs a lot from real-time data for voice, audio and video. For a real-time voice,
audio and video data transfer important that the transfers happen with a constant bandwidth
and an average delay time according to certain specifications. With real-time applications the
exact delay time is most times less important than the fact that the worst-case delay time is
bounded. In order to understand the global manner the USB operates these key aspects are
mentioned in chapter 3 "USB specifications". Other aspects are determined in an
experimental setup and are discussed in chapter 4 and 5, "Experimental Setup" and "Results".
2
Adequacy of the Universal Serial Bus for real-time systems
2 Real-time characterization
Key demands for a real-time network concern the latency and jitter of the network. In this
chapter one can discover that it is not only about latency and jitter. In real-time systems there
is always something to be controlled (Kopetz, 1997). However possible to analyze the realtime behavior without utilizing a controlled system.
In this chapter the real-time behavior of the USB protocol is discussed. One can discover
that a lot of the real-time behavior can be analyzed using the literature about USB.
Nevertheless some parameters cannot be theoretically analyzed and some of them will be
mentioned in the following chapters.
2.1 Real-time systems
Since the USB communication channel is always used in cooperation with a computer, it is
useful to consider the definition of a real-time computer system: this is a computer system in
which the correctness of the system behavior depends not only on the logical results of the
computations, but also on the physical instant at which these results are produced. A real-time
computer system is always part of a larger system, called a real-time system, which changed
its state as a function of physical time (Kopetz, 1997). An overview of a real-time system is
given in Figure 1.
Man-Machine
Interface
Instumentation
Interface
Embedded
System
Operator
Controlled
Object
Figure 1 Real-time system layout
In a real-time system the Man-Machine interface consists of in- and output devices (e.g.
keyboard and monitor), while the Instrumentation interface consists of sensors and actuators.
2.2 Latency time demands
The most stringent latency time demands for real-time systems are enforced by the
requirements of control loops. If there is a man-machine interface the latency time demands
are not very stringent because of the human perception delay (about 50-100 ms) (Kopetz,
1997). Latency time influences directly the dead time. Dead time of an closed control loop is
the time interval between an observation of a real-time entity and the start of the reaction of
the controlled object due to a computer action based on this observation. Stability of a control
loop is also dependent on the dead time; therefore the dead time (and thus the latency time)
should be as small as possible (Kopetz1997).
Latency times can be specified with many parameters, one of the most important is the
worst-caste latency time also called Worst Case Execution Time (WCET). This parameter
represents the maximum latency for all possible scenarios, with all possible input data and
execution scenarios of the task. This worst-case latency time can be analyzed by looking at
the source code of the programs, analysis of the compiler and the micro architecture.
Unfortunately this type of investigation cannot be carried out on the USB protocol, since the
3
behavior is dependent on the operating system and other specific design principles. Moreover
several implementations of the USB protocol exist.
Finally one must conclude that in this project the worst-case latency time only can be
estimated by carrying out experimental tests.
2.3 Jitter demands
If the latency time is not constant over the time then jitter exists. A large jitter can cause the
unpredictable and very inconstant latency times. Many control algorithms are based on the
assumption that the delay time is constant implying the delay jitter is much smaller than the
delay time. In such a way the algorithm can be designed to compensate for the constant delay
(Kopetz, 1997).
Since jitter causes an additional uncertainty, this has an adverse effect on the performance
of the control. Jitter should be as small as possible. The jitter should be smaller than one
percent of the latency time. If the latency is about 1 ms, then the latency jitter should be
smaller than a few µs (SAE, 1995).
In the previous section one can see that determining the worst-case USB latency time
should be estimated by doing experimental tests. Since the jitter is in a certain extent
dependent on the worst-case latency time, the same story holds true for the determination of
the jitter. Besides the jitter is the variance of the latency and this cannot be analyzed by
analyzing several implementations. Also for the investigation of the jitter one should do
experimental tests.
2.4 Reliability and errors
In general one must always avoid the occurrence of errors. The amount of tolerated errors is
also dependent on the properties of the system. In some cases a certain amount gives no
difficulties such as:
• If the nature of the data has a certain error (e.g. measurement error) and the error of the
communication channel is much smaller.
• If there are a lot of samples and only one sample has an error the other samples give
enough information to indicate that there is an error in the sample and the data can be
interpolated.
Sometimes one error can cause a lot of damage, and therefore it is very important to have any
idea of the amount of errors on the channel. One must always consider what kind of errors are
allowed or prohibited. There are algorithms that are able check and correct data for possible
errors such as the CRC algorithm (Relisoft, 2003). The USB protocol uses always a CRC
code and can consequently always detects (and dependent on the transfer type repairs) the
data errors.
If a protocol relies on a single locus of control, it has a single point of failure. If the
transmission of a token (bits that serves as a symbol of authority, and is used to indicate the
station that is temporarily in control of the transmission medium) fails, the communication
will fail until the token loss is detected. This problem can also be found in a multi master
versus single master control. Since the USB protocol is built to work with a single master,
USB is less reliable compared to not so centralized networks, and if the master fails the whole
system fails.
4
Adequacy of the Universal Serial Bus for real-time systems
2.5 Flexibility and scalability
Many real-time communications must support different system configurations that change
over time. Restriction in bandwidth causes the system to have constraints of having increase
in data traffic. The USB protocol is designed to be hot pluggable and is thereby flexible,
further according to the USB specifications, the required communication bandwidth is
guaranteed. If there is no guarantee for enough bandwidth, the attached device cannot be
initiated.
Scalability of the USB protocol is related to the flexibility of it. The USB can provide
large scalability (Kopetz, 1997) since USB devices can be added till there is no longer enough
bandwidth available. If the USB channels are fully utilized, there is the ability of adding an
extra USB port to the host (PC), or sometimes adding only an extra HUB to the network. The
complexity of the system can further stay unaffected if the system is scaled.
2.6 Physical structure
A multicast communication network requires a bus or a ring network. A point-to-point
network, requires as many communication channels as there are nodes. Therefore the costs
are much higher.
The channel from host to HUB can be seen as a point-to-point with the same properties as
a bus or ring (namely data for several nodes are available on one communication channel).
The channel from host or HUB to node must be seen as a typical point-to-point network. The
USB protocol takes advantage from the benefits of both a bus or ring network and a point-topoint network.
In the USB topology every message is only send to one device. If the message must be
send to more than one device, the sending has to be executed separately for each device. If
there is more than one point at a network (for example a USB keyboard with integrated
mouse), the bus is split up with a HUB. Only the bus from the host to the HUB will transmit
data for more than one device. This is opposed to the standard communication topology used
in a regular real-time system, which is multicast, not point-to-point. Multicast implies that
messages are send across the network to all nodes and that there is no communication
between two individual nodes.
2.7 Flow control
Controlling the speed of information flow between sender and receiver is called flow control.
The existing types of flow control are explicit and implicit flow control. With the explicit
flow control the sender communicates with the receiver about the data speed and checks if the
data is faultlessly sent. Implicit flow control is the opposite, the data is sending with a
constant data speed, and the correctness of the transmitting is never checked.
The USB protocol uses both flow control mechanisms. Bulk and Control transfers (see
Section 3.4) use explicit flow control while with the Interrupt transfer the device does not
have the ability to influence the speed. With Isochronous transfers, in general, the sender is
also missing the ability to check for errors and use obvious implicit flow control. Implicit
flow control has the advantage that the transfer time is more constant and predictable.
5
2.8 Composability
Network architecture is composable with respect to a particular property if the behavior is not
affected by other attached devices (Kopetz, 1997). Regarding to the specifications of the USB
protocol the behavior of the system is never affected when another device is attached
(Garney, 2000). This means that also the temporal behavior of the USB protocol is fully
composable.
2.9 Sporadic and periodic data
In architecture with periodic data, the transmission must take place with a minimal latency
jitter. The moments of data transmission are known. If at these moments sporadic data is
transmitted, the system has to make a choice between the offered data.
The USB protocol can handle both sporadic and periodic data. All data, sporadic and
periodic, can be transmitted within a specified time if the transfer type is Isochronous or
Interrupt. Theoretically the latency jitter will be lesser if the data is periodic with the same
time interval as the USB frame interval.
2.10 Hard versus soft real-time
Depending on the specifications of a particular system, a system can be hard or soft real-time.
Hard real-time systems have a fully deterministic response to an event. The response cannot
be based on an average response time because than we talk about a soft real-time system
(Dione, 2000). Most important is how strictly the specifications are defined.
A hard real-time system must remain synchronous with the state of the environment,
where this does not matter with soft real-time systems. Concluding one can say that the safety
criticality of hard real-time systems is much larger than that of soft real-time systems.
The USB protocol seems to be hard real-time, because theoretically the temporal behavior
of it can be bounded and constant. But since the USB protocol is not designed for hard realtime applications and is built for working with normal MS Windows® operating systems one
can expect that in practice the behavior of USB will be soft real-time.
6
Adequacy of the Universal Serial Bus for real-time systems
3 USB specifications
USB is designed to be user-friendlier than the previous communication protocols (such as
serial RS 232). The reverse side of this improvement is that the designing of USB-devices and
USB software is more complicated. While the previous communication protocols were quite
simple, the USB protocol is extensive and more complicated. Since this project is also about
USB it is good to take a look into the details. This chapter is not a manual for building or
installing a USB device but only an explanation of the general aspects of the USB protocol
regarding to this project.
3.1 Features
The USB 2.0 protocol is the successor of the USB 1.0 protocol. USB 2.0 is fully backward
compatible for devices built to previous versions of the specification (Garney, 2000).
Therefore USB 2.0 supports also the transfer speeds of the previous protocol. The transfer
speeds of the previous protocol are still used for slower devices (e.g. mouse's, keyboards). In
this way we get three different transmission speeds: low-speed (1,5 Mb/s), full-speed (12
Mb/s) and high-speed (480 Mb/s).
The list of features of the USB protocol is large. Only the most important and relevant
features of the USB 2.0 protocol are listed (which is the same for USB 1.0): single model for
cabling and connectors, self-identifying peripherals, dynamically attachable peripherals, high
range of bandwidths, Isochronous as asynchronous transfers, concurrent operation of many
devices, up to 127, low protocol overhead, guaranteed bandwidth and low latencies, wide
range of packet sizes, identification of faulty devices, protocol is simple to implement and
integrate, plug and play uses commodity technology, and buffering-induced hardware delay is
bound to a few milliseconds (Garney, 2000).
3.2 Connection structure
In a USB system there can be only one host and up to 127 devices. The devices are connected
to the host by use of the USB interconnect. The physical structure is a tiered star topology
(see Figure 2). In the center of each star there is a hub. The number of tiers is limited to seven
(Garney, 2000). At the top-level tier there is the host with the host controller and root hub.
The host controller provides the connection with the host computer while the root hub
provides one or more attachment points.
The USB is a polled bus; in such a way that the host controller initiates all data transfers.
Data transfers are initiated at scheduled moments in order to diminish the arbitration overhead
and to support Isochronous data transfers.
7
Figure 2 Bus topology
The USB cable exists of 4 electrical wires. Two of these wires, the VBUS and GND, are
for power delivery to the devices (5 Volt and up to 500 mA). The other two wires are used for
the serial data and are named D+ and D-. The data transfer model between a source
destination on the host and an endpoint on a device is referred as a pipe. Data on a pipe can
have a USB-defined structure, then it is called a message otherwise it is called a stream. The
Default Control pipe exist from the moment the device is powered, other pipes exist from the
moment the device is configured. There are 4 different kinds of pipes, which are treated in the
next section.
With the USB 2.0 protocol one can use three signaling rates namely: Low-speed (1,5
Mb/s), Full-speed (12 Mb/s) and High-speed (480 Mb/s) (Garney, 2000). The Low- and Fullspeed rates are also available at the USB 1.0 protocol. For each rate there is a difference in the
used output impedances in order to make the several rates electrically possible. These
different output impedances are also used to determine which signaling rate is used. If the
signaling rate becomes higher also the demands of the transmission lines become higher.
Robustness of the USB is ensured by the use of (Garney, 2000):
• Flow control for streaming data to ensure Isochrony and hardware buffer management
• Control and data fields are CRC protected
• Differential drivers, receivers, and shielding enhance signal integrity
• Data and control pipes for an independency from adverse interactions between functions.
• Timeouts for lost or corrupted packets as a self-recovery in the protocol.
• Detecting of attachments, detachments and system-level configurations of resources.
3.3 Endpoint of device
As already mentioned in the previous section, there can be several communication pipes
between a host and a device. The place where the pipe ends at the device is called the
endpoint of the device. Each endpoint and its pipe has its own properties such as (Garney,
2000):
• Type of transfer (Control, Bulk, Isochronous, Interrupt)
• Bandwidth requirement
• Number of the endpoint
• Error handling behavior requirements
8
Adequacy of the Universal Serial Bus for real-time systems
•
•
•
•
Maximum packet size that the endpoint is capable of sending or receiving
The data transfer direction.
Bus access frequency
Latency requirements
The communication between the host and a physical device can be seen from different
levels. At first there is the real communication link (the USB cable) with its hardware
required to perform the USB interactions. The next level is the general USB software. This
software provides the link between the hardware and the application software. At the side of
the device, this performs the general USB actions (e.g.: the identification, protocol, transfers)
and at the PC-side this performs also the general USB actions and gives the possibility for the
Client software to interact with the device. This software consists of the Host Controller
Driver (HCD) and the USB Driver (USBD)(Garney, 2000). The last level consist of the
specific functions. At the side of the device this is the part that performs the operations
specific for the device (e.g.: delivery of the data) and at the PC-side this are the specific
software programs that is device specific. This software can differ for each device.
Figure 3 The relationship between pipes and the hard- and software
When a device is connected there is always an endpoint zero. While all pipes have
transfers in only one direction, the pipe to the endpoint zero is a bi-directional pipe. This pipe
is always a Control pipe and is used, as the name says, to control the device. The pipes to the
endpoints other then zero can only be used after the device configuration process.
The number of device endpoints is limited by the specific protocol definition, and by the
standard USB definition the number is limited to 30 per device. In Figure 3 a schematically
overview of these levels is reflected.
9
3.4 Transfers
Data is transferred over the USB bus in frames. Frames are mainly used for the timing and
synchronization of the several devices. If the bus is Low- or Full-speed then the duration of
the frames is 1 (± 0.005) ms, in a High-speed bus the frames duration is 125 (± 0.0625) µs
(see also Figure 4).
Figure 4 The frames and microframes
The frames of 125 microseconds are referred as microframes. It depends on the type of the
bus what kind of and how many transactions are allowed in a frame. The frames exist on the
USB cable, and say nothing about the rest of the configuration of the device.
The USB bandwidth is allocated in two different ways. For Isochronous and Interrupt
transfer (see next sections) the bandwidth is allocated when the device is configured and is
fixed from then on with a maximum of 80% (or 90% for Low- and Full-speed transfers) of the
total bandwidth (Garney, 2000). The bandwidth for Control and Bulk pipes are not fixed,
there is only bandwidth available for these transfers if the bandwidth is not used by another
pipe. Here, the fair policy is used.
Frames can consist of data packets, handshake packets, Start of Frame (SOF) packets,
token packets and split packets. The protocol overhead of the several transfers depends on a
lot of factors, the average protocol overhead is about 10 and up to 70 bytes (Garney, 2000).
There are four kinds of transfer types; the specifications of these transfers differ in some
way from each other. In the following subsections the most important features of the transfer
types are mentioned. Unfortunately the latency times are not specified, but this is related to
the service time, which is the time period between the transfers.
3.4.1 Control
The Control transfer gives the opportunity to exchange configuration, control and status
information between the host and device. Control pipes are typically message pipes while all
the other transfer types use stream pipes. The transfers must adhere to the USB data structure
definitions. Control transfers are usually only used with the endpoint zero, if the device
requires more Control pipes then this is possible. The exact amount of bandwidth for each
Control pipe is controlled by the host and varies with the time. The service times, max
payload and the maximum bandwidth are given in Table 1 (Garney, 2000).
10
Adequacy of the Universal Serial Bus for real-time systems
Speed Service times
Max payload (bytes)
Max bandwidth (bytes/s)
*1)
Low
8
24 000
*1)
Full
64
832 000
*1)
High
64
15 872 000
1)
There is no way to indicate desired bus service times.
Table 1 Control transfer specifications
3.4.2 Bulk
The Bulk transfers are used to transfer large amounts of data at highly variable times. Only if
there is available bandwidth on the bus data transfers can take place. There is always a
guaranty of errorless delivery but no guaranty of bandwidth or latency times. Bulk transfers
have a lower priority than Control transfers. If there are more than one Bulk transfers waiting
for available bandwidth then it is determined with fair-policy which device is allowed to start
the transfer. This fair-policy is host controller dependent. Low speed devices are not allowed
to do Bulk transfers. The service times, max payload and the maximum bandwidth are given
in Table 2 (Garney, 2000).
Speed Service times
Max payload (bytes)
Max bandwidth (bytes/s)
*2)
*2)
*2)
Low
*1)
Full
64
1 216 000
*1)
High
64
53 248 000
1)
There is no way to indicate desired bus service times.
2)
There are no Bulk transfers possible in low speed.
Table 2 Bulk transfer specifications
3.4.3 Interrupt
When a maximum service period is required to the transfers, Interrupt transfers give a good
possibility. With this transfer type the endpoint can specify its desired maximum bus access
period. This maximum period time is a multiple of the frametime (with low- and full-speed 1
ms and with high-speed 125 µs). If there is enough bandwidth the service time can be less
than the maximum otherwise the service time is the same as the maximum service time. In
case of a failure the protocol will retry to receive the data the next period. Only in that case
the service period will be larger than the maximum service period.
The USB device requires a buffer large enough to hold the transfer data, which is
typically only one USB transaction. The service times, max payload and the maximum
bandwidth are given in Table 3 (Garney, 2000).
Speed Service times
Max payload (bytes)
Max bandwidth (bytes/s)
Low
10 – 255 ms
8
48 000
Full
1 – 255 ms
64
1 216 000
High
32 256 000 *3)
125 µs - 4096 ms 1024
3)
For high speed the max bandwidth can go up to 49 152 000 bytes/s but this is no part of
default interface settings.
Table 3 Interrupt transfer specifications
11
3.4.4 Isochronous
The use of Isochronous transfers provides a high bandwidth and bounded latency times. In
order to obtain a constant data delivery there is no retry of the data delivery in case of a
delivery error. Since the USB bus is expected to have low error rates the bus is optimized
assuming transfers normally succeed. A CRC send with each transfer, thus error-detection and
therefore sometimes error-correction is possible. When a device is configured, the required
bandwidth is directly allocated to that device. If there is not enough bandwidth available the
device cannot be configured. In contrast to the Interrupt transfers, the Isochronous transfers
require always a minimum of two buffers in order to maintain the continuous streaming
transfer model. In this way one buffer can be filled while the other buffer is emptied for the
next transfer. The service times, max payload and the maximum bandwidth are given in Table
4 (Garney, 2000).
Speed Service times
Max payload (bytes)
Max bandwidth (bytes/s)
*4)
*4)
*4)
Low
Full
1 – 32768 ms
64
1 216 000
High
57 344 000 *5)
125 µs – 4096 ms 1024
4)
Low speed Isochronous transfers are not allowed on the USB bus.
For a high-bandwidth endpoint the data payload can go up to 3072 bytes per microframe
and a bandwidth of 49 152 000 bytes/s.
5)
Table 4 Isochronous transfer specifications
3.4.5 Conclusion
Obviously there are some important differences between the several transfer types. Some
transfer types are not feasible at all for our real-time demands. The Bulk transfer is not
appropriate because the maximum transfer latency time is never guaranteed. Further the
Control transfer is not accessible in some kind of USB application devices and is also left out
of consideration. The remaining transfer types are the Interrupt and Isochronous types. The
Isochronous type has the advantage that the protocol implementation is not fixed a lot and
therefore leaves the possibility to design a certain part by oneself. This is opposite to the
Interrupt type. Here all such choices are already fixed in the protocol. Apart from that, the
bandwidth of the Isochronous type is almost twice such high as the Interrupt type. However,
the total bandwidth of 480 Mb/s is only reached if there are a number of endpoints used. The
benefit and also disadvantage of the Interrupt type is the built in error correction method
which is not available with the Isochronous type. The error correction method uses the
repeating of sending data in the case of an error. Consequently the latency time is not constant
in case of errors, causing unwanted jitter. Furthermore the Interrupt type can be cheaper and
more reliable since less design options has to been filled in.
If high reliability is required one should opt for the Interrupt type, if high data payload
and constant latency is desired one can choose the Isochronous type. Since the bandwidth is
higher the Isochronous type offers more and better possibilities for future applications. The
key benefits of the Interrupt type can also be implemented in most Isochronous applications.
12
Adequacy of the Universal Serial Bus for real-time systems
3.5 Latency time
Regarding to the standard USB specification one can predict the expected delays caused by
the USB protocol. This is only based on theoretical assumptions and gives therefore only the
order of magnitude obtained by the practical experiences.
3.5.1 Buffering
Before the transfer of a data packet, the data has to be buffered at the sending side. With
Isochronous data at least two buffers are required while at the other transfers one buffer can
be enough. Buffering causes some latency and especially the double buffering at the
Isochronous transfers cause much (two frames) latency. If other transfer types than
Isochronous transfers are used in combination with transfers each (micro)frame, it seems
impossible to transfer data with only one buffer, because the transfer stream must be
maintained. In the protocol specification this is not mentioned.
3.5.2 Frame interval
Since the (micro)frames are periodic (with an interval of 1 ms or 125 µs), the periodic
sampling interval is the same as the frame interval. If there is an a-periodic sampling interval
and the device is polled each interval then the expected average latency time is half the frame
interval. Variances in the frame interval are very small and can be neglected.
3.5.3 Bus turnaround
The propagation delay of the cable is always very small. This delay is for the USB protocol
restricted to about a few ten ns. The restrictions for the Low- and Full-speed cables and hubs
are reflected in Figure 5 (Garney, 2000)
Figure 5 There are delay restrictions for the cables and Hubs
If the data has to go around the whole bus the times this takes delivers the round trip delay
time. We can calculate this time for the High-speed bus as:
12 cable delays
=
312 ns
10 hub delays
=
92 ns
1 device response
=
27 ns
round trip delay
=
431 ns
Which is almost 0,5 µs and is far away from 125 µs.
3.5.4 Conclusions
From the previous sections only the buffer latency times deliver a noticeable amount of
latency to the USB protocol. In the practice there are more reasons for a time delay, such as
the software operations the computer (host) has to do and the availability and speed of the
device.
The expected theoretical total latency time will be the sum of the times mentioned in this
section. This means twice the frame time, so 2 ms for Full- and Low-speed transfers and 250
µs for the High-speed transfers.
13
4 Experimental Setup
Since the theory gives only a coarse estimation of the temporal behavior of USB the most
important parameters concerning the real-time behavior have to be determined with some
experimental tests. In order to be able to do the experimental tests one need at least a PC
equipped with a USB port and a USB device. When one wants to do tests with the USB 2.0
protocol then both the device and PC must be equipped with USB 2.0.
In this chapter, an introduction to the USB port and device is given and thereafter the
approach for doing the experimental tests is mentioned.
4.1 Introduction to USB device
From a previous project on the Control Engineering Group, already two programmable USB
devices were available. These are programmable MCUs with a fully integrated single-chip
solution for High-Speed USB peripherals. These devices are manufactured by Cypress and
referred to as EZ-USB FX2™ or abbreviated as FX2.
The FX2 can operate at Full speed as well as High speed (12 Mbps or 480 Mbps) as
defined in the USB 2.0 specification. Low speed is not supported. Isochronous, Bulk and
Interrupt transfers are fully supported; Control transfers are only used by the device itself.
The FX2 can operate as a normal USB device and seen from the host, it acts as a normal
USB device. Data processing in the FX2 is done by a 8051 microprocessor which has access
to the USB buffers, registers to control USB, I2C bus, UARTS, Interrupt ports, and two 230
KBaud UART ports. There are four programmable Bulk, Isochronous, Interrupt endpoints
with buffering options: double, triple and quad.
Two FX2s were ordered because it was thought that this was required in order to be able
to do extensive tests. It was thought that these boards could act as a host. Unfortunately the
FX2 boards can only act as a client and the communication from one to the other board must
always be via a host. Autonomous tests between the two boards are not possible and thereby
the second board is useless for this project.
In addition to the FX2 boards, there is also some software supplied: Keil µVision, EZUSB Configuration Panel and an EZ-USB General Purpose Driver. The µVision program is
used to write software for the 8051 microprocessor. This program can compile C and machine
code to the required .HEX code. This HEX code can be uploaded to the 8051 microprocessor
of the FX2 in three ways:
• By USB, using the EZ-USB Configuration Panel: if the there is no program on the FX2
then the USB data send to the FX2 is used as program data. When the sending is
completed and enumerating process is started, in which the FX2 disconnects from the
USB bus and after a few moments reconnects. The FX2 has now another device
descriptor and the host will see another device on the bus.
• By serial port, the program can be uploaded by the serial port. After the download process
there is a possibility to monitor the 8051 in order to debug the program.
• By external ROM, one can connect external ROM the 8051, this provides the benefit that
the program stays on the FX2 also without power. The disadvantage is that programming
is more work.
The EZ-USB General Purpose Driver achieves part of the communication between FX2 and
PC; see next section.
14
Adequacy of the Universal Serial Bus for real-time systems
4.2 Introduction to USB port on PC
Nowadays in almost every computer there is an internal USB port available. Only in the
newest computers there is a USB 2.0 port available, in the other computers it is only up to 1.1.
There are PCI extension cards available that offer a possibility to upgrade to USB 2.0. An
example of such a card is reflected in Figure 6
Figure 6 The DYN480H of the company Dynalink, which is a USB 2.0 PCI extension card.
At the Control Engineering Group there are no computers available with a USB 2.0 port. In
order to be able to do USB 2.0 test the above-mentioned extension card is bought.
Unfortunately even after an updated driver version from the manufacturer version the highspeed Isochronous transfer does not work. After these disappointments the decision has been
made to continue the project with the USB 1.1 protocol. Fortunately the architecture of the
USB 1.1 protocol is roughly the same as that of the USB 2.0. The main difference between
both protocols is in the high-speed transfers, they are not supported in the USB 1.1 protocol.
A device driver performs the communication between PC and the USB device. A USB
device is identified with its device descriptor. The first time a device is connected to the PC
the matching driver is found by the use of an .INF file. From than on this information is stored
in the windows registry. For the FX2 the required driver is the EZ-USB General Purpose
Device Driver. A certain software program can communicate with the FX2 by opening a
handle to the USB device. If the FX2 device is connected to the PC, the FX2 has the symbolic
form of EZusb-i, with "i" the number 0. If the FX2 is the second attached FX2 device than the
"i" must be 1 and so on. The code given in Figure 7 gives a demonstration of a specific handle
to a FX2 device (Cypress, 1999).
HANDLE DeviceHandle;
DeviceHandle = CreateFile("\\\\.\\ezusb-0",
GENERIC_WRITE,
FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);
Figure 7 Creating a handle to a FX2 device
After a handle to the device is created, a DevieIOControl function call is specified. This
function call requires a number of arguments (see Figure 8) in order to be able to transfer data
over a certain USB pipe (Cypress 1999).
BOOL DeviceIoControl(
HANDLE
DWORD
LPVOID
DWORD
LPVOID
DWORD
LPDWORD
LPOVERLAPPED
hDevice,
dwIoControlCode,
lpInBuffer,
nInBufferSize,
lpOutBuffer,
nOutBufferSize,
lpBytesReturned,
lpOverlapped
//
//
//
//
//
//
//
//
//
//
handle to device of interest
control code of operation to perform
pointer to buffer to supply input data
size of input buffer
pointer to buffer to receive output data
size of output buffer
pointer to variable to receive output
byte count
pointer to overlapped structure for
asynchronous operation
);
Figure 8 Specification of argument required for a I/O control
15
Due to a quirk in the USB host controller driver an Isochronous pipe must be reset before
starting each new transfer (Cypress, 1999). This is done with the ResetPipe command.
4.3 Approach
As described in Section 3.4 the Bulk and Control transfer are never feasible enough for our
purpose. In this project, the choice has been made to opt for the Isochronous transfer type
instead of the Interrupt type. The Isochronous type seems to have more opportunities for
future projects while the disadvantages of the Isochronous type are surmountable.
Measurements are done using three software programs. The most important parts of these
programs are treated in the following section. Main objective of the analyzing of the USB
protocol is to determine several aspects of the latency time and thus also jitter. In subsection
4.3.2 these aspects will be considered. Thereafter some remaining aspects of real-time in
relation to USB will be shortly treated.
4.3.1 Software code for measurements
A special computer program (see Figure 9) is developed in order to be able to do the
measurements. The program is developed in Microsoft Visual C++ 6.0®. This program has the
possibility to give at a certain moment a trigger event from the parallel port (using conio.h
library), measure the time (using a High Performance Timer), and communicate with the FX2.
Figure 9 Screenshot of the developed program
The required arguments (DeviceDescriptor, PipeNumber, PacketCount, PacketSize,
BufferCount, Frames/Buffer) for the data transfers (see section 4.2: Introduction to USB port
on PC) can be changed in order to perform the several tests. There are buttons to do an IN
transfer and OUT transfer measurement. The program can store the retrieved results in a text
file, and has also the possibility to perform a series of measurements and put the
accompanying results in the text file (which can be imported in a mathematical software
program such as Matlab®).
Furthermore two programs are developed which can be executed on the FX2 board. These
programs are able to read and write to the USB buffers on the FX2 board. Apart from that the
program can react on receiving a falling edge on the Interrupt pin. For the OUT-transfers the
16
Adequacy of the Universal Serial Bus for real-time systems
program uses a 16 bit counter on the FX2. The measured time of this counter is put in the
USB buffer where the PC program will read this value and process it further.
4.3.2 Temporal aspects of the USB
There are several parameters to characterize the temporal behavior of real-time systems. In
this project only the most important temporal parameters of the USB protocol are analyzed.
These parameters (see also Figure 10) are:
• Worst case latency.
• Average latency.
• Latency variance
• Dependency of parameters on data payload.
• Dependency of parameters on data direction.
The values can be statistically obtained by measuring many times the transaction time with
different data payload and direction. Therefore there must be a possibility to measure the time
between sending and receiving of the data (Irey, 1998). This is only possible if there is a
single timer with the knowledge about the moment of initiating send and receiving the data.
Receive
worst case
average latency
Send
t
jitter
Figure 10 Schematically representation of the various parameters.
This timer can be implemented in PC, FX2 board or in another device. In this project, the
timing problem is solved for each direction in another way. In both configurations, a single
interrupt line from parallel PC port to an input port on the FX2 board is used.
OUT transfer
PC
USB Device
IN transfer
Figure 11 Definitions of IN and OUT transfers
Time measurements of the IN-transfers (see Figure 11) are performed with the pseudocode fragment scenario as shown in Figure 12. In this scenario (see Figure 13) the parallel
port on PC gives a trigger event, while a timer on PC is started. If the trigger arrives at an
interrupt pin on the FX2 the output buffer of the FX2 is filled with a predefined number. In
the meantime the PC is reading the USB port till the number arrives. The timer is stopped as
soon as the number is arrived.
PC
give interrupt;
start timer;
while (data != 3)
recv(pipenum, mesg_size);
stop timer;
USB
FX2-board
if (int_recvd)
bufferdata = 0x03;
bufferdata = 0x00;
Interrupt
Figure 12 Pseudo-code for analyzing In-transfers
17
It is obvious that the value of the timer represents the latency time for an IN-transfer
according to the equation (Irey, 1998):
IN transfer latency = stop_time – start_ time
Parallel
interrupt
from PC
Start
timer on
PC
Receive
interrupt
on FX2
Initiate INtransfer on
PC
Bufferdata = 3
Receive
data on PC
Stop timer
on PC
if (data=3)
Figure 13 State-Machine representing the sequence of actions for IN transfer measurements
Latency time of the OUT transfers is measured in a modified way. Here the interrupt from
PC is used to start the timer on the FX2 board. Immediate after the interrupt from the PC, the
PC is sending a predefined number over the USB port. If the FX2 receives the number, the
timer will be stopped (see Figure 14 and Figure 15).
PC
give interrupt;
data = 3;
write(pipenum, mesg_size);
USB
Interrupt
FX2-board
if (int_recvd)
start timer;
if (bufferdata=0x03)
stop timer;
Figure 14 Pseudo-code for analyzing OUT-transfers
Here it is clear that the OUT transfer latency time can be computed using the value of the
timer on FX2 using:
OUT transfer latency = stop_time – start_time
Receive
interrupt
on FX2
Parallel
interrupt
from PC
Send data=3
from PC
Start
timer on
FX2
Read
buffer on
FX2
Stop timer
on FX2
if (data=3)
Figure 15 State-Machine representing the sequence of actions for OUT transfer measurements
A complete transfer loop is created by sending some data from PC to FX2, followed by
the FX2 sending the data back to the PC. The latency time regarding such a loop can be
computed by:
Loop latency = IN transfer latency + OUT transfer latency
Observing the programs on PC and FX2 one can see that building such a loop must consist of
both transaction times. For the computation of this time, one has to execute the experiments
for the IN and OUT transfer, the loop latency is the sum of both times.
Both the programs for the IN transfer measurement and for the OUT transfer
measurement are able to perform a large amount of latency time measurements. This gives the
opportunity to analyze statistically the above-mentioned interesting parameters. Using a
statistical program one can analyze and compute the several parameters in the following way:
• The worst-case latency can be found by extrapolating the probability density plot, where
the lowest time with zero possibility of occurrence is the worst-case latency.
• Average latency time can be computed by (Irey, 1998):
18
Adequacy of the Universal Serial Bus for real-time systems
average _ latency =
•
1
∑ latencyi
amount _ measurements all
Latency time variance and standard deviation can be found using (Irey, 1998),(Meijer,
1999):
latency var iance =
1
∑ (latencyi − average _ latency) 2
amount _ measurements all
latency _ standard _ deviation = latency _ var iance
•
By varying the data payload and or the data direction, the above-mentioned parameters
can be calculated depending on the payload and direction.
The measurement results are statically analyzed with the Matlab® commando's: "plot", "hist",
"mean" and "cov". In this way a good representation of the results is obtained.
4.3.3 Other aspects of the USB
Real-time behavior of a protocol concerns more than only the temporal aspects of it. In this
project also the behavior of USB concerning transmission errors is investigated. The amount
of errors can be easily measured by examining how many errors occur during a certain
amount of transfers. This percentage can be calculated by (Irey, 1998):
percent _ errorless _ data =
errorless _ transfers
.100%
amount _ of _ transfers
19
5 Results
The adequacy of the USB protocol is dependent on a lot of aspects. Some of them can be
expressed with a number, but many of them not. This chapter will mainly focus on the results
of the quantitative aspect of the USB protocol. The numerical results are obtained by
experiments executed according to the method of approach mentioned in section 4.3.
5.1 Meaning of results
The obtained latency times consist mainly of the pure latency times. Accuracy is also affected
by unwanted action times and inaccuracies. For the IN transfers the inaccuracies consist of the
following elements:
• Time between receiving and executing the interrupt function on the FX2, which is
between 4 and 16 FX2 instruction cycles, or between 4/48 and 16/48 µs (Cypress 2001).
• Resolution of the 16-bit timer on FX2, which is 0,25 µs.
• Executing time of part of the PC software program, which is less than 100 µs.
The inaccuracies of the OUT transfer measurements are influenced by:
• Time between receiving and executing the interrupt function on the FX2, which is
between 4 and 16 FX2 instruction cycles, or between 4/48 and 16/48 µs (Cypress 2001).
• Resolution of the High Performance Timer (Platform SDK, 2003), which is processor
dependent and in general smaller than 0,1 µs.
• Executing time of part of the PC software program, which is less than 100 µs.
The measurements are carried out on a Pentium III, 450 MHz PC, using the onboard USB 1.1
port under Windows 98 SE®. The settings of the various parameters are:
PipeNumber 0
PacketCount 1
PacketSize
1 (only IN); 2; 4 and 16 bytes
BufferCount 1
Frames/Buffer 1
Direction
IN; OUT
Under these settings the latencies are measured 2000 times. Also the required time for a
ResetPipe command (See section 4.2) is measured 2000 times. This delivered times of 0,3 ±
0,1 ms, which is not a serious additional time, and is not further analyzed in this project.
5.2 Statistical analysis
The latency times of the measurements are depicted in Figure 16 and Figure 17; the
realizations are depicted in the same time order as the measurements were done. The latencies
are several times larger than the expected latencies of about 2 ms. The High Performance
Counter can measure the execution time of a specific function. In this way it is found that the
execution of the send/receive function (done by the DeviceIOControl, see section 4.2) is
responsible for about 95 percent of the total latency time. This function executes an action
defined in the EZ-USB General Purpose Driver. This means that the large latency times are
caused by the overhead of the driver.
Clearly perceptible are the extreme high latency times of the IN transfers with 2 byte
(noted as "o") data payload around the 700th measurements and 1 byte (noted as "+") data
20
Adequacy of the Universal Serial Bus for real-time systems
payload in begin and end. Possibly this large times are caused due to another program using
processor power of the PC. It is obvious that this is not payload dependable because the high
values are only visible in a certain period. To demonstrate that there is not any relation
between the number of measurement and the amount of latency time, also the covariance of
the measurements is calculated. Fortunately the results for the OUT transfers are much more
constant over time. From this it can be seen that the behavior of the IN transfers is much more
dependent on other operating system active tasks than the behavior of the OUT transfers.
The realisations
55
50
45
Time - milliseconds
40
35
for 1:+, 2:o, 4:> and 16:< bytes payload
30
25
20
15
10
0
200
400
600
800
1000
Realisation
1200
1400
1600
1800
2000
Figure 16 Latency times for IN transfers with varying data payload
21
The realisations
8
for 2:o, 4:> and 16:< bytes payload
7.5
Time - milliseconds
7
6.5
6
5.5
5
0
200
400
600
800
1000
Realisation
1200
1400
1600
1800
2000
Figure 17 Latency times for OUT transfers with varying data payload
Looking at the results of Figure 16 and Figure 17, one can see that the average times of
the IN transfers are about double as high as for the OUT transfers. Looking further into the
behavior of the PC program, it is noticed that the loop for receiving data has to be executed
twice in order to obtain the valid data (0x03). This is explained by the fact that FX2 has a
double buffer. So if the trigger on the FX2 is received, the data is placed in the first buffer and
is shifted after one reading cycle of PC. Only after the next reading cycle of the PC the right
(trigger)data is in the second output buffer and will be send to the PC. In the reverse (OUT)
direction the same story might be expected. However in reality this is different. Here, the data
are send from the PC and arrive in the second buffer of the FX2. Now there is not another
sending cycle of the PC required in order to let the FX2 process the newly received data
(0x03).
The results depicted in the previous plots are difficult to interpret. Therefore also
histograms of these results are made (see Figure 18 and Figure 19).
22
Adequacy of the Universal Serial Bus for real-time systems
Histogram
1800
1600
1400
Realisations
1200
1000
800
600
for 1, 2, 4 and 16 bytes payload
400
200
0
10
15
20
25
30
35
Time - milliseconds
40
45
50
55
Figure 18 Histogram of the latency times for IN transfers with varying data payload
Histogram
1000
900
800
700
Realisations
600
for 2, 4 and 16 bytes payload
500
400
300
200
100
0
5
5.5
6
6.5
Time - milliseconds
7
7.5
8
Figure 19 Histogram of the latency times for OUT transfers with varying data payload
23
In these histograms it can also be seen that there are large differences between the results of
the IN versus OUT transfers. OUT transfers have duration of half the duration of IN transfers.
The latency time of the OUT transfers is much more bounded than that of the IN transfers
which has a peak of about 55 ms. Noteworthy is the periodic behavior of the OUT transfer
times which has a peak at about 5.7 and 5.8 ms, so with a gap of 1 ms (in accordance with one
frame). One can think the reason for this is a retransmission if the previous transmission
failed. There are two reasons to reject this opinion: The USB protocol has obvious lesser
errors than 10% and there are no retransmissions with the Isochronous transfer type. Other
motivations for these periodic times have not been found.
The worst-case latency can be graphically determined using the histograms. The latency
time for the IN transfer is not very bounded mainly because of the peak at 55 ms which is
only one measure. The worst-case latency time for the IN transfers should be estimated on
about 25 ms. However there is one measurement of 55 ms, therefore the worst-case latency is
55 ms. In contrast to the IN transfers, the worst-case OUT transfer latency time is much more
bounded and is estimated to be 8 ms.
The mean (or average) value of the latencies is also computed and is found to be for the
IN transfers: 11.9569 ms; 11.9629 ms; 11.8071 ms; 11.8072 ms (for 1, 2, 4 and 16 byte data
payload) and de results for the OUT transfers are: 5.8959 ms; 5.8844 ms; 5.8806 ms (for 2, 4
and 16 byte payload).
Determining the variance of the results is combined with computing the covariance
matrix. The covariance shows if there is a relation between the payloads, the latency, and the
number of the measurement (Meijer, 1999). The covariance matrix (Matrixi,j = <(payloadiµi)(payloadj-µj)>) of the IN-transfer is:
1.5428 0.0058 -0.0034 0.0107
0.0058 1.4882 -0.0069 -0.0025
-0.0034 -0.0069 0.0928 -0.0014
0.0107 -0.0025 -0.0014 0.0989
This matrix shows that there is no significant relation between the above-mentioned
properties, which is an extra prove for the correctness of the results. From this the variances
are: 1.5428 ms; 1,4882 ms; 0.0928 ms; 0.0989 ms for (1,2,4,16 bytes data payload). From
these results the latency standard deviation can be calculated: 1.2420 ms; 1.2199 ms; 0.3046
ms; 0.3144 ms. Here the pikes in the results of the 1 and 2 bytes data payloads are
recognizable in the larger variances for these payloads. The covariance matrix (Matrixi,j =
<(payloadi-µi)(payloadj-µj)>) of the OUT-transfers is:
0.1374 -0.0012 0.0057
-0.0012 0.1248 0.0005
0.0057 0.0005 0.1236
Here the covariance is also small enough. And the corresponding variances are: 0.1374 ms;
0.1248 ms and 0.1236 ms (for 2,4,16 bytes data payload), or expressed as latency standard
deviation: 0.3670 ms; 0.3532 ms; 0.3515 ms. Here there is no significant difference between
the various payloads noticeable.
In accordance with the above-mentioned results there is a large difference between IN and
OUT transfers. OUT transfer latency times are more bounded and smaller than the IN
transfer.
Sensitivity for the data payload of the transfers is not present. This can be explained by
the fact that the USB protocol can support a large number of transfer pipes, each with a high
24
Adequacy of the Universal Serial Bus for real-time systems
amount of data. In carried out experiments the FX2 was the only device connected to the USB
port and besides that the FX2 was using only one transfer pipe.
The statistical results are summarized in tables Table 5 and Table 6.
Payload (bytes)
1
2
4
16
Mean (ms)
11,9569
11,9629
11,8071
11,8072
Variances (ms)
1,5428
1,4882
0,0928
0,0989
Worst-case (ms) 55
55
55
55
Table 5 Statistical summary for IN-transfers
Payload (bytes)
Mean (ms)
Variances (ms)
Worst-case (ms)
2
5,8959
0,1374
8
4
5,8844
0,1248
8
16
5,8806
0,1236
8
Table 6 Statistical summary for OUT-transfers
6 Conclusions and recommendations
In accordance with the general expectations about USB, the key benefit of the protocol is the
user-friendliness of it. If everything is correctly programmed, the setup of the USB device is
very easy. The drawback of this is the complicatedness of adapting the protocol for the
specific demands. Another drawback of USB is the unavailability of useful references and
examples of USB programs. Especially if an unusual function has to be implemented this is
very unfavorable.
Looking to the results, the temporal behavior of the protocol is not very strict. The reason
for this is large overhead of the used USB driver. Especially the IN-transfers have very
unbounded and unpredictable latency times (latencies of 12 ms with variance of 1,5 ms worstcase 55 ms). Fortunately the OUT-transfers achieve much better (latencies of 6 ms with
variances of 0.12 ms). Consistent with the theory of section 2.10 "Hard versus soft real-time"
one can conclude that the USB protocol only can be used in a soft real-time system. This has
the results that the protocol must compete with systems with a large size of transmitted data, a
degraded peak-load performance; the computer must control the pace.
Since the USB protocol is only feasible for soft real-time systems, one should keep in
mind the relative and quite unbounded latency times when opting for this protocol in a realtime system. The USB can achieve very well in for example a man-machine interface (see
section 2.1). Since the USB is first used in man-machine interface products (such as
keyboards, mouse's) this is not very shocking and agrees with the expectations.
Compared to the results of a former project with the CAN (latencies of about 8 ms with
variance of 0.5 ms) protocol, the USB shows quite corresponding results. Comparing the
other aspects for the adequacy of real-time systems is left out the scope of this report but is
also very important when a choice for a certain protocol has to be made.
Considering the (dis)advantages of the USB protocol one can conclude that this may be
an option for the use in a certain system if:
• the temporal demands of the system are not very strict.
• the star topology of the devices fits well in the desired application.
• an easy (hot pluggable) installation of the system to a computer is preferable.
25
•
a high mass-production of the devices can be achieved, because of the quite high
complexity of the hard- and software.
• no multicast messages are required.
The results show that the USB protocol has not very strict temporal behavior. Average
latency times are in the order of 10 ms with worst-case times till 55 ms. Further the OUT
transfers seems to achieve much better than the IN transfers. From this it follows that the USB
is only feasible in soft real-time systems.
Results obtained in this project are representative for a moderate USB system. The
expectation is that there are possibilities to achieve better performances from the USB
protocol than in this project are achieved. The performance of the protocol can be better if:
• another operating system (real-time Linux for example) is used instead of Windows 98,
which has not real-time behavior
• another driver than the standard EZ-USB General Purpose Driver is installed, with a
lower overhead, and faster performance.
• the PC as host is replaced by an autonomous master. The master can be specially
designed for its specific task.
• USB 2.0 instead of USB 1.0 is used. The key advantage of USB 2.0 compared to 1.0 is
the higher transfer speed. For the real-time behavior the availability of microframes
instead of frames can deliver more benefits. These microframes have the duration of 1/8
of the duration of the frames. Since the latencies in this project are supposed to be caused
by the delay of the operating system and the installed driver, the profit for the latencies
mentioned in this project are much smaller.
• one uses an additional transfer pipe, in such a way that there are two (or more)
transactions in one (micro)frame. In this way the waiting time for polling can be reduced.
Some of the above-mentioned solutions can be very expensive and are therefore not very
interesting.
The impact of another environment has not been investigated. One could investigate the
influences of using products of other brands, the tier level, additional attached devices,
slower/faster PC or other operating systems. Especially if profit from the high flexibility of
USB is desired, one should know how this influences the performance of the USB protocol.
26
Adequacy of the Universal Serial Bus for real-time systems
Appendix A Measurement results
Measurement realizations for the IN transfers:
Time - milliseconds
55
50
45
40
35
30
25
20
15
10
0
200
400
800
The realisations
1000
Realisation
1200
for 1:+, 2:o, 4:> and 16:< bytes payload
600
1400
1600
1800
2000
27
Measurement realizations for the OUT transfers:
Time - milliseconds
8
7.5
7
6.5
6
5.5
5
0
200
400
800
The realisations
1000
Realisation
1200
for 2:o, 4:> and 16:< bytes payload
600
1400
1600
1800
2000
28
Adequacy of the Universal Serial Bus for real-time systems
Histogram of the latency times for IN transfers with varying payload (1, 2, 4 and 16 bytes)
Realisations
1800
1600
1400
1200
1000
800
600
400
200
0
10
15
25
Histogram
30
35
Time - milliseconds
for 1, 2, 4 and 16 bytes payload
20
40
45
50
55
29
Histogram of the latency times for OUT transfers with varying payload (2, 4 and 16 bytes)
Realisations
1000
900
800
700
600
500
400
300
200
100
0
5
5.5
Histogram
6.5
Time - milliseconds
for 2, 4 and 16 bytes payload
6
7
7.5
8
30
Adequacy of the Universal Serial Bus for real-time systems
Appendix B User-guide for performing the
measurement tests
In order to be able to perform the measurement tests one can do the following things:
1) Download the software for the FX2 from the cypress site on:
http://www.cypress.com/cfuploads/support/developer_kits/EZUSB_devtools_version_261700.zip
2)
3)
4)
5)
Install this software according to the instructions in the software.
Attach the FX2 board to the USB port.
Unzip the developed software (from "Complete programs.zip") to the local drive.
There after one can start the EZ-USB Control Panel (installed by the cypress
software)
6) From the EZ-USB Control Panel download the required "isoin.hex" file from the right
directory (IN or OUT transfer measurement) (see figure)
7) The .hex file is automatically downloaded on the FX2.
8) Execute the "TestPerformance.exe" program. This program is intended to be easy to
understand and no additional information is required.
9) Open the .txt file which is created in an appropriate program, the times are in
milliseconds.
31
References
Cypress Semiconductor (1999), EZ-USB General Purpose Driver Specification,Cypress
Semiconductor Corporation.
Cypress Semiconductor (2001), EZ-USB FX2 technical reference manual, version 2.1,
Cypress Semiconductor Corporation, 2001
Dione, J (2000), When hard real-time goes soft, Metrowerks Linux Solutions.
Garney, J. et al (2000),Universal Serial Bus specification, revision 2.0, USB Implementers
Forum.
Kopetz, H.(1997) ,Real-time systems. Design principles for distributed embedded application,
Kluwer Academic Publishers.
Meijer, T.M.J.(1999), Kansrekening voor EL, deel statistiek, Enschede: Technical University
Twente, 1999
Irey IV, P.M.(1998), Harrison, R.D. & Marlow, D.T. Techniques for LAN performance
analysis in a real-time environment, Kluwer Academic Publishers.
Platform SDK (2003), High-resolution timer, Microsoft Corporation.
Http://www.relisoft.com/Science/CrcMath.html (2003), Reliable Software, Relisoft.
SAE (1995), Class C application requirements. Survey of known protocols,In: SAE
Handbook, Warrendale, PA, (pp 23.437-23.461)
32