university of twente - connecting repositories · 2013-07-12 · university of twente p.o.box 217...

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


Table of contents 1 Introduction _____________________________________________________1

1.1 Real-time systems __________________________________________________ 1

1.2 Universal Serial Bus ________________________________________________ 2

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

3 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

4 Experimental Setup ______________________________________________14

4.1 Introduction to USB device _________________________________________ 14

4.2 Introduction to USB port on PC _____________________________________ 15

4.3 Approach________________________________________________________ 16

5 Results_________________________________________________________20

5.1 Meaning of results ________________________________________________ 20

5.2 Statistical analysis_________________________________________________ 20

6 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 Control Area Network CRC Cyclic Redundancy Check FX2 A certain programmable USB device HC Host Controller HUB A device that provides additional connections IN Data flow in the direction to the computer from the USB device IRP Interrupt Request Packet LAN Local Area Network MCU Microprocessor Control Unit OUT Data flow in the direction from the computer to the USB device PC Personal Computer PCI Peripheral Component Interconnect SOF Start Of Frame USB Universal Serial Bus USBD Universal Serial Bus Driver WCET Worst-Case Execution Time

iv


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 real-time 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


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 real-time 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

Figure 1 Real-time system layout

Operator Embedded System

Controlled Object

Man-Machine Interface

Instumentation Interface

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


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-to-point 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 real-time 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


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 Full-speed 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


• 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 (Garney, 2000). Table 1

10


Speed Service times Max payload (bytes) Max bandwidth (bytes/s) Low *1) 8 24 000 Full *1) 64 832 000 High *1) 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) Low *2) *2) *2)

Full *1) 64 1 216 000 High *1) 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 (Garney, 2000). Table 3

Table 3 Interrupt transfer specifications

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 125 µs - 4096 ms 1024 32 256 000 *3) 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.

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

(Garney, 2000). Table

4

Table 4 Isochronous transfer specifications

Speed Service times Max payload (bytes) Max bandwidth (bytes/s) Low *4) *4) *4)

Full 1 – 32768 ms 64 1 216 000 High 125 µs – 4096 ms 1024 57 344 000 *5) 4) Low speed Isochronous transfers are not allowed on the USB bus. 5) 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.

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


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 (Garney, 2000) Figure 5

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, EZ-USB 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


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 high-speed 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 gives a demonstration of a specific handle to a FX2 device (Cypress, 1999).

Figure 7

Figure 7 Creating a handle to a FX2 device

HANDLE DeviceHandle; DeviceHandle = CreateFile("\\\\.\\ezusb-0", GENERIC_WRITE, FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);

After a handle to the device is created, a DevieIOControl function call is specified. This function call requires a number of arguments (see ) in order to be able to transfer data over a certain USB pipe (Cypress 1999).

Figure 8

Figure 8 Specification of argument required for a I/O control

BOOL DeviceIoControl( HANDLE hDevice, // handle to device of interest DWORD dwIoControlCode, // control code of operation to perform LPVOID lpInBuffer, // pointer to buffer to supply input data DWORD nInBufferSize, // size of input buffer LPVOID lpOutBuffer, // pointer to buffer to receive output data DWORD nOutBufferSize, // size of output buffer LPDWORD lpBytesReturned, // pointer to variable to receive output

// byte count LPOVERLAPPED lpOverlapped // pointer to overlapped structure for

// asynchronous operation );

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:

) 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®).

Introduction to USB port on PC

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


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 ) are: Figure 10

Figure 10 Schematically representation of the various parameters.

• 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.

jitter

worst case

average latency

Send

t

Receive

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.

PC USB Device OUT transfer

IN transfer

Figure 11 Definitions of IN and OUT transfers

Time measurements of the IN-transfers (see Figure 11) are performed with the pseudo-code fragment scenario as shown in Figure 12. In this scenario (see ) 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.

Figure 13

PC give interrupt; start timer; while (data != 3) recv(pipenum, mesg_size); stop timer;

FX2-board if (int_recvd) bufferdata = 0x03bufferdata = 0x00;

;

USB

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 data on PC

Receive interrupt on FX2

Bufferdata = 3

Stop timer on PC

if (data=3)

Initiate IN-transfer on

PC

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);

FX2-board if (int_recvd) start timer; if (bufferdata=0x03) stop timer;

USB

Interrupt

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

Parallel interrupt from PC

Start timer on

FX2

Send data=3 from PC

Receive interrupt on FX2

Stop timer on FX2

if (data=3)

Read buffer on

FX2

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


∑=all

ilatencytsmeasuremenamount

latencyaverage_

1_

• Latency time variance and standard deviation can be found using (Irey, 1998),(Meijer, 1999):

∑ −=all

i latencyaveragelatencytsmeasuremenamount

iancelatency 2)_(_

1var

iancelatencydeviationstandardlatency var___ =

• 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):

%100.__

___transfersofamount

transferserrorlessdataerrorlesspercent =

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 and ; 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.

Figure 16 Figure 17

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


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.

0 200 400 600 800 1000 1200 1400 1600 1800 200010

15

20

25

30

35

40

45

50

55

Realisation

Tim

e - m

illis

econ

ds

The realisations

for 1:+, 2:o, 4:> and 16:< bytes payload

Figure 16 Latency times for IN transfers with varying data payload

21

0 200 400 600 800 1000 1200 1400 1600 1800 20005

5.5

6

6.5

7

7.5

8

Realisation

Tim

e - m

illis

econ

ds

The realisations

for 2:o, 4:> and 16:< bytes payload

Figure 17 Latency times for OUT transfers with varying data payload

Figure 17Looking at the results of Figure 16 and , 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 and ). Figure 18 Figure 19

22


10 15 20 25 30 35 40 45 50 550

200

400

600

800

1000

1200

1400

1600

1800

Time - milliseconds

Rea

lisat

ions

Histogram

for 1, 2, 4 and 16 bytes payload

Figure 18 Histogram of the latency times for IN transfers with varying data payload

5 5.5 6 6.5 7 7.5 80

100

200

300

400

500

600

700

800

900

1000

Time - milliseconds

Rea

lisat

ions

Histogram

for 2, 4 and 16 bytes payload

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


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) 2 4 16 Mean (ms) 5,8959 5,8844 5,8806 Variances (ms) 0,1374 0,1248 0,1236 Worst-case (ms) 8 8 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 worst-case 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 real-time 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


Appendix A Measurement results Measurement realizations for the IN transfers:

0200

400600

8001000

12001400

16001800

200010 15 20 25 30 35 40 45 50 55

Realisation

Time - milliseconds

The realisations

for 1:+, 2:o, 4:> and 16:< bytes payload

27

Measurement realizations for the OUT transfers:

0200

400600

8001000

12001400

16001800

20005

5.5 6

6.5 7

7.5 8

Realisation

Time - milliseconds

The realisations

for 2:o, 4:> and 16:< bytes payload

28


Histogram of the latency times for IN transfers with varying payload (1, 2, 4 and 16 bytes)

1015

2025

3035

4045

5055

0

200

400

600

800

1000

1200

1400

1600

1800

Time - m

illiseconds

Realisations

Histogram

for 1, 2, 4 and 16 bytes payload

29

Histogram of the latency times for OUT transfers with varying payload (2, 4 and 16 bytes)

55.5

66.5

77.5

80

100

200

300

400

500

600

700

800

900

1000

Time - m

illiseconds

RealisationsH

istogram

for 2, 4 and 16 bytes payload

30


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/EZ-USB_devtools_version_261700.zip

2) Install this software according to the instructions in the software. 3) Attach the FX2 board to the USB port. 4) Unzip the developed software (from "Complete programs.zip") to the local drive. 5) 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

http://www.cypress.com/cfuploads/support/developer_kits/EZ-USB_devtools_version_261700.zip

http://www.cypress.com/cfuploads/support/developer_kits/EZ-USB_devtools_version_261700.zip

32

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)

http://www.relisoft.com/Science/CrcMath.html (2003

university of twente - connecting repositories · 2013-07-12 · university of twente p.o.box 217...

Documents