Are used to communicate between peripheral devices and a computer?

Peripheral Implementation

The inclusion of other peripheral devices in the design should be carefully considered. Timers and serial I/O, for example, can be implemented in software when necessary. There is a greater load on software when each bit of serial communication has to be processed instead of having hardware handle a whole byte. However, if CPU processing power is available and hardware cost is a concern, having the software do the work is often a reasonable solution. After all, you pay for the software development just once, but an extra chip adds cost to every unit shipped. This trade-off must be made carefully, because the considerations of a low-volume application (where software development cost is dominant) differ from those for a product shipping in large volume (where unit cost is the issue).

Peripheral device management

Input/output and peripheral device management services were created to remove the physical details of use from user processes and to provide for more seamless and fair management of the resources. The goal of peripheral device management services is to make access clear, clean, and transparent to users. Management should remove all physical dependencies from users' access requirements and replace these with logical mechanisms that are already common in programming environments. The control is to make access device independent. The user should not have to know what type of device or where the device is located to access data or service software.

Management for peripheral devices is bound into two classes of operating systems service routines: I/O and device managers. The operating system strives to make all accesses appear the same. The typical method is to make all accesses have the look and feel of a file access. The I/O management process has the function to set up and maintain the logical channels or paths between CPU-resident processes and the outside world. The functions provided by this element include channel allocation and deallocation, channel setup, channel coordination, and remote data transfer and control. Included in this may be error detection and correction over the channel. In concert with this function is the device management function. Device management services provide mechanisms to perform device-dependent setup, allocation, control, synchronization, deallocation, and data transfer.

I/O and device management create the physical link and control the transfer. Included in this function is the request for buffer assets for the channel to utilize in transferring information from the secondary storage to the internal computer's memory. The buffers are used as the intermediary between the devices and the CPU. They allow for the concurrent operation of the I/O with applications processing within the system. The I/O channel control and device control are typically handled in an operating system as an independent process. The operating system initiates the I/O or device operation and departs, allowing the device and I/O managers to perform the task and, when completed, interrupt the operating system to indicate the completion of the task. The interrupt can be active, where it stops the operating system for immediate service, or it can be message oriented, where it sets some status indicator, which the operating system will check at its leisure.

When integrated with the operating system's file manager, these routines form a seamless link between the stored programs, data, and the run-time system. The file manager is used for the direct access of logical storage elements by the operating system and controlled processes. The file manager provides services to name files, address files, control access, select and coordinate access paths, perform background copying and backup for recovery, coordinate the allocation and deallocation of resources where file information is located, and manage the placement (logical) of stored information. An important function of the file management system is lock management. File managers create, issue, and control the locking and unlocking of files and records within files. This service is extremely important for concurrency control.

18.2.16 Universal software radio peripheral

The universal software radio peripheral device is a tunable transceiver for designing, prototyping, and deploying wireless communication systems. Paired with the LabVIEW development and GNU Radio [24] environment, National Instruments universal software radio peripherals (USRPs) [25] and Ettus USRPs [26] provide an affordable solution to validate wireless algorithms with OTA signals. Ettus USRPs come with the necessary Ettus Research’s software defined radio (SDR) software platform. All platforms support USRP hardware driver (UHD), which ensures cross-platform code portability. UHD also supports Linux, Windows, and mac OS. All USRP SDRs support GNU Radio, a free open-source software development framework. Most USRP SDRs also have support for the following:

RFNoC, an open-source software package from Ettus Research that integrates into GNU Radio, enabling field-programmable gate array (FPGA) development without having to write VHDL or Verilog.

LabVIEW, a graphical programming tool for managing complex system configurations, multirate digital signal processing design of the FPGA and float-to-fixed point conversion.

MATLAB and Simulink, which connect to the USRP family of SDRs to provide an environment for SISO and MIMO wireless system design, prototyping, and verification.

Example 1

Consider an application that manages peripheral devices remotely over a network. In this application, data related to a device is stored in a class named DeviceData. The methods for processing the device data are provided in a class named Device. What is interesting about these two classes is that DeviceData only has public data members with no methods, and device class holds an object of type DeviceData and provides methods for accessing and manipulating that data member (Figure 5.4). Clearly, since the data and methods that ideally should have been localized in a single class have been separated across Device and DeviceData classes, this design fragment is an instance of a Broken Modularization smell.

12.1.4 Bluetooth low energy

Bluetooth low energy (BLE) is intended for applications that have different requirements than the features provided by BR/EDR, using a physical layer with similarities to, but not compatible with, BR/EDR. However, BLE is easily integrated in the same device, or even the same chip, as legacy Bluetooth (BR/EDR) and BLE have lower and upper protocols in common, as shown in Fig. 12.1. Some typical applications are in health monitoring, sport and fitness, proximity location, and many others that use short bursts of small data packets, one way beacons, and which must operate for months and even years on a small lithium battery.

In contrast to BR/EDR, which has seventy nine 1 MHz spaced hopping frequencies over the band 2.4 to 2.4835 GHz, BLE operates over forty 2 MHz channels as shown in Fig. 12.9. In Version 5 (see Section 12.1.5) two modulation schemes are defined: a mandatory scheme at 1 Msps (symbols per second) and an optional scheme at 2 Msps. The 1 Msps scheme may be uncoded giving 1 Mbps or optionally coded with two symbols per bit for a data rate of 500 kbps or eight symbols per bit resulting in a data rate of 125 kbps. When the two symbols per bit coding is chosen, the access header in the packet is coded with 8 symbols per bit. The 2 Msps scheme supports only uncoded data supporting 2 Mbps. Transmission power must be in the range from 0.01 to 100 mW, and is classified as shown in Table 12.2.

Table 12.2. BLE power classes

Modulation type is GFSK with bandwidth- bit period product BT = 0.5 and an modulation index (instantaneous frequency deviation from the carrier divided by one half the symbol rate) between 0.45 and 0.55. Bandwidth is specified as having spurious power of no more than -20 dBm at 2 MHz offset from the channel center frequency for the 1 Msym/s rate and—20 dBm at 4 MHz offset for the 2 Msym/s rate [1].

BLE devices can have four different roles: broadcaster, observer, peripheral, and central. The role of a device dictates the requirements of its Controller (see LE controller in Fig. 12.1). A Broadcaster is designed for transmitter only applications, for example one-way beacons, whereas an Observer supports receiving only. Peripheral devices have low complexity and support a single connection. The most complex role is that of a Central device which can initiate and control multiple connections with peripherals. A smartphone is an example of a Central device, while a Peripheral device may be a low power sensor that connects to the central device, or a low power beacon.

The time domain physical channel is sub-divided into time units known as events. Data are transmitted between LE devices in packets that are positioned in these events. There are four types of events: advertising, extended advertising, periodic advertising, and connection events. Advertising and connection events are explained here.

Advertising packets are continuously transmitted from a peripheral device in order to be seen by other devices. Devices that transmit advertising packets on one or more of the three advertising PHY channels are referred to as advertisers. Advertisement provides a way for devices to broadcast their presence while making possible the setting up of connections. It can include a list of supported services and transmitter power levels. Parameters associated with the advertisement event are:

advertisement interval—the interval between advertisement events which can be 20 ms to 10240 ms.

which of three channels, index numbers 37, 38, and 39, or all of them, are used for the advertisement packets.

discoverability—how the advertiser is visible to other devices.

connectablility—whether or not the advertiser can be connected to other devices point-to-point.

payload—number of bytes, 0 to 31 that can be included in an advertisement packet.

Devices that receive advertising packets on the advertising channels without the intention to connect to the advertising device are referred to as scanners. Scanning can be passive or active. In passive scanning the scanner listens for advertisements packets from one channel to another. Active scanning means that the scanner sends a scan request packet to the advertiser to get more information about its services.

Transmissions on the advertising PHY channels occur in advertising events. See Fig. 12.10. At the start of each advertising event, the advertiser sends an advertising packet corresponding to the advertising event type. Depending on the type of advertising packet, the scanner may make a request to the advertiser on the same advertising PHY channel which may be followed by a response from the advertiser on the same advertising PHY channel. The advertising PHY channel changes on the next advertising packet sent by the advertiser in the same advertising event. The advertiser may end the advertising event at any time during the event. The first advertising PHY channel is used at the start of the next advertising event.

A connection is a continuing periodical data exchange of packets between two devices. Connections allow application data to be sent from one device to another. A connection event is a periodical exchange of data at certain specific points in time, shown in Fig. 12.11. First, a peripheral device sends connectable advertising packets periodically during advertising events. A central device, called initiator, scans the frequencies for connectable advertising packets, and when suitable, initiates a connection. Once the connection is established through acceptance by the advertiser, the initiator becomes the master device of a piconet and the advertiser becomes the slave device. The master manages the timing and initiates the beginning of each connection event. Adaptive frequency hopping (AFH) is used for robust transmission and reception. The connection event starts when the master sends a packet to the slave at a defined connection interval. The slave can respond 150 μs after it has received a packet from the master. If the slave has no data to send it can skip a certain number of connection events defined by a slave latency parameter. If no packets are received by the master or slave within the time defined by the supervision timeout, the connection is terminated. A key advantage of this arrangement is power saving - two devices can power up, exchange data, and then go to sleep until the next connection event.

Device master/slave pairs in a piconet each use a specific frequency hopping pattern, which is algorithmically determined by a field contained in the connection request sent by an initiating device. The hopping pattern used in LE is a pseudo-random ordering of the 37 non-advertising frequencies in the 2.5 GHz band (Fig. 12.9). The hopping pattern can be adapted to exclude a portion of the frequencies that are used by interfering devices. The adaptive hopping technique improves Bluetooth co-existence with static (non-hopping) ISM systems when these are co-located and there is access to information about the local radio environment, or interference is detected by other means.

Above the physical channel there are concepts of links, channels and associated control protocols (shown in Fig. 12.1). The hierarchy is physical channel, physical link, logical transport, logical link, and L2CAP channel. Within a physical channel, a physical link is formed between devices. As in legacy Bluetooth, the active physical link provides bidirectional packet transport between the master and slave devices. An LE physical channel can include multiple slave devices. There is a physical link between each slave and master. Slaves are permitted to have physical links to more than one master at a time and there is virtually no limit to the number of slaves associated with a master. A device is permitted to be master in one piconet and slave in another at the same time. Physical links are not formed directly between the slaves in a piconet. Role changes between a master and slave device are not presently supported. The advertising and periodic physical links provide a unidirectional packet transport from the advertiser to a potentially unlimited number of scanners or initiators.

The physical link is used as a transport for one or more logical links that support asynchronous traffic. Traffic on logical links is multiplexed onto the physical link assigned by a scheduling function in the Baseband Resource Manager (Fig. 12.1).

A control protocol for the link and physical layers is carried over logical links in addition to user data. This is the link layer protocol (LL). The Link Layer function uses the LL protocol to control the operation of devices in the piconet and provide services to manage the lower architectural layers (PHY and LL). Just as in BR/EDR, above the link layer the L2CAP layer provides a channel based abstraction to applications and services. It carries out fragmentation and de-fragmentation of application data and multiplexing and de-multiplexing of multiple channels over a shared logical link. L2CAP has a protocol control channel that is carried over the primary ACL logical transport.

In addition to L2CAP, LE provides two additional protocol layers that reside on top of L2CAP. The security manager protocol (SMP) uses a fixed L2CAP channel to implement the security functions between devices. The other is the attribute protocol (ATT) that provides a method to communicate small amounts of data over a fixed L2CAP channel. The attribute protocol is also used by devices to determine the services and capabilities of other devices. The attribute protocol may also be used over BR/EDR.

6.5 Wait State Generation

As we previously discussed, sometimes a peripheral device is too slow for a normal PC/XT bus cycle. The length of a bus cycle can be extended by generating wait states. These are additional clock periods inserted into a memory or I/O bus cycle. Wait states are inserted by pulling line IO CH RDY low (negated) for two or more clock cycles after the data transfer cycle has started.

Figure 6-5 shows a simple circuit for generating one additional wait state for an I/O cycle. When the I/O port is selected (for either a read or write) it sets a flip-flop that pulls IO CH RDY low. Note that the inverter driving the 10 CH RDY line is an open-collector device. This is because several peripherals on the PC/XT bus can drive this line simultaneously and will be OR-tied if they use open-collector outputs. This flip-flop output then goes to a two-stage shift register (using two additional flip-flops), which waits two clock cycles and then outputs a signal resetting the flip-flop and reasserting I0 CH RDY, ensuring that no additional wait states are injected into the cycle. For each additional wait state desired, an additional shift register stage should be added, for more clock cycle delays. The timing is very similar for generating memory cycle wait states, except only one clock cycle delay is required to generate the first wait state.

Publisher Summary

This chapter provides information related to general system security threat, hardware and peripheral devices, OS and application security, virtualization, and system-based security applications. Some security threats are specific to the environment. But there are many threats out there that are dangerous in any environment. Any environment can be susceptible to viruses, Trojans, root kits, and privilege escalation. It is important to take the necessary steps to protect the environment from these threats. The systems are the main components of the environment. System security is crucial in any environment. System protection should entail many layers. This is because system vulnerabilities exist at many layers. There are hardware, operating system, application, and peripheral device threats. Each type of threat requires a different defense and a different method of remediation. These threats have been further intensified by the adoption of virtualization. One of the key concerns with virtualization is where security should be done. Windows 7 and Windows Server 2008 R2 include a number of applications that help in securing the systems and protect against various threats.

7.3 Polled versus Interrupt-Driven Software

In Chapter 6 we looked at the trade-offs between accessing a peripheral device via polled software versus interrupt-driven software. If a peripheral device needs to be serviced relatively infrequently (for example, using only 10% of the available CPU time) and asynchronously (so the program cannot predict when the next service will be required), interrupt-driven software is in order. On the other hand, if interrupt servicing takes up too much CPU time (sometimes referred to as CPU bandwidth) for very frequent servicing, polled software would be preferable. In this case, there would be little CPU bandwidth left over for other processing anyway. One other general case is when the peripheral servicing is synchronous, as when the value of an ADC is read at preset time intervals and requires a small amount of CPU bandwidth. Again, interrupt-driven software is the best solution. If the peripheral (ADC) does not provide a hardware interrupt, the PC's timer could.

The following program listing, written in Microsoft Macro Assembler, shows the basic concepts for installing and using interrupt-driven software. It can be used with the data acquisition circuit from Chapter 6 (Figure 6-6), set to generate an IRQ7 hardware interrupt whenever a new ADC reading is ready. It is assumed that the 8259 interrupt controller already enables IRQ7 interrupts and that the system interrupt flag is set to enable the maskable interrupt input from the 8259. Otherwise, these functions must be taken care of in LOADVEC, the routine that prepares the system for the interrupt and loads the interrupt service routine INT7SVC, as

Since IRQ7 is interrupt type OFh, its vector is located at memory address OFh × 4 = 3Ch in segment zero (physical address 0000:003Ch). When the program is run by DOS, it starts execution at routine LOADVEC. This short program loads the address of the interrupt service routine, INT7SVC, into the vector location for IRQ7 (3Ch–3Fh). Then it allocates enough space for INT7SVC and its data and returns to DOS, leaving INT7SVC resident in memory. This type of software is called terminate-and-stay-resident, or TSR. It is useful here, allowing the servicing of the IRQ7 interrupt independent of other software. The DOS call to INT 21h Function 31h is used to load TSR programs. The value in DX is the amount of memory to preserve for the resident program. AL contains the value returned by the function, which is useful for error codes. AH contains the function number.

Once INT7SVC is loaded into memory, whenever it is called it reads the current value from the ADC and stores it in a data table, starting at location DVALUES and indexed by DINDEX. Both DVALUES and DINDEX are declared as public labels, so that other software can access them and retrieve the data. A typical program making use of INT7SVC would check the value in DINDEX, address the ADC, start a data conversion, and then go about other business. When it was ready to retrieve the data, it would check that DINDEX has incremented and then read the data out of the table, DVALUES. When it was done, it would decrement DINDEX.

Note that the above program is merely an illustrative example of the use of interrupt-driven software for data acquisition. It is still fairly rough and incomplete for practical use, lacking refinements. INT7SVC does show some important aspects of interrupt service routines. They should be as fast as possible, to avoid interfering with other system interrupts. That is why they are usually written in Assembler (although short C programs are sometimes used). The working system registers (AX, BX, CX, DS, SI) should be saved, by PUSHing onto the stack at the routine's start, and restored, by POPing, at its end. Otherwise, any use of these registers by the interrupt service routine will corrupt the interrupted program, on return. For hardware interrupt service, the routine must send an EOI command to the 8259 interrupt controller. Otherwise, new hardware interrupts will not be enabled. The service routine should end with an IRET statement for a proper return from the interrupt.

An interrupt routine to service a software interrupt is somewhat simpler, since the 8259 does not have to be serviced and hardware interrupts do not need to be unmasked. In addition, there is little danger of monopolizing the CPU's bandwidth (unless hardware interrupts are masked off). Software interrupts are a convenient way to install and call software functions in memory.

To illustrate polled software used to retrieve an ADC value, the following is a function written in Microsoft C:

Note that this is a very short and simple subroutine. The main program calls it whenever it has started an ADC conversion and wants to retrieve the results. It assumes that I/O port 301h contains a value of 1 only when the conversion is complete. This is the status required by a polling routine such as read_adc().

In this simple example, there is no provision for the error condition when something goes wrong and the ADC status port never returns a 1, as when there is a hardware failure or a software bug calling read_adc() at the wrong time. A more practical program would have a time-out provision in the while(…) statement. Otherwise, the PC will remain stuck in that loop indefinitely.

11.5.1 UART

One of the oldest and most common devices for communications between computers and peripheral devices is the Universal Asynchronous Receiver/Transmitter, or UART. The word “universal” indicates that the device is highly configurable and flexible. UARTs allow a receiver and transmitter to communicate without a synchronizing signal.

The logic signal produced by the digital UART typically oscillates between zero volts for a low level and five volts for a high level, and the amount of current that the UART can supply is limited. For transmitting the data over long distances, the signals may go through a level-shifting or amplification stage. The circuit used to accomplish this is typically called a line driver. This circuit boosts the signal provided by the UART and also protects the delicate digital outputs from short circuits and signal spikes. Various standards, such as RS-232, RS-422 and RS-485 define the voltages that the line driver uses. For example, the RS-232 standard specifies that valid signals are in the range of +3 to +15 volts, or −3 to −15 volts. The standards also specify the maximum time that is allowable when shifting from a high signal to a low signal and vice-versa, the amount of current that the device must be capable of sourcing and sinking, and other relevant design criteria.

The UART transmits data by sending each bit sequentially. The receiving UART re-assembles the bits into the original data. Fig. 11.8 shows how the transmitting UART converts a byte of data into a serial signal, and how the receiving UART samples the signal to recover the original data. Serializing the transmission and re-assembly of the data is accomplished using shift registers. The receiver and transmitter each have their own clocks, and are configured so that the clocks run at the same speed (or close to the same speed). In this case, the receiver's clock is running slightly slower than the transmitter's clock, but the data is still received correctly.

To transfer a group of bits, called a data frame, the transmitter typically first sends a start bit. Most UARTs can be configured to transfer between four and eight data bits in each group. The transmitting and receiving UARTs must be configured to use the same number of data bits. After each group of data bits, the transmitter will return the signal to the low state and keep it there for some minimum period. This period is usually the time that it would take to send two bits of data, and is referred to as the two stop bits. The stop bits allow the receiver to have some time to process the received byte and prepare for the next start bit. Fig. 11.8A shows what a typical RS-232 signal would look like when transferring the value 5616 (the ASCII ‘V’ character). The UART enters the idle state only if there is not another byte immediately ready to send. If the transmitter has another byte to send, then the start bit can begin at the end of the second stop bit.

Note that it is impossible to ensure that the receiver and transmitter have clocks which are running at exactly the same speed, unless they use the same clock signal. Fig. 11.8B shows how the receiver can reassemble the original data, even with a slightly different clock rate. When the start bit is detected by the receiver, it prepares to receive the data bits, which will be sent by the transmitter at an expected rate (within some tolerance). The receive circuitry of most UARTs is driven by a clock that runs 16 times as fast as the baud rate. The receive circuitry uses its faster clock to latch each bit in the middle of its expected time period. In Fig. 11.8B, the receiver clock is running slower than the transmitter clock. By the end of the data frame, the sample time is very far from the center of the bit, but the correct value is received. If the clocks differed by much more, or if more than eight data bits were sent, then it is very likely that incorrect data would be received. Thus, as long as their clocks are synchronized within some tolerance (which is dependent on the number of data bits and the baud rate), the data will be received correctly.

The RS-232 standard allows point-to-point communication between two devices for limited distances. With the RS-232 standard, simple one-way communications can be accomplished using only two wires: One to carry the serial bits, and another to provide a common ground. For bi-directional communication, three wires are required. In addition, the RS-232 standard specifies optional hand-shaking signals, which the UARTs can use to signal their readiness to transmit or receive data. The RS-422 and RS-485 standards allow multiple devices to be connected using only two wires.

The first UART device to enjoy widespread use was the 8250. The original version had 12 registers for configuration, sending, and receiving data. The most important registers are the ones that allow the programmer to set the transmit and receive bit rates, or baud. One baud is one bit per second. The baud is set by storing a 16 bit divisor in two of the registers in the UART. The chip is driven by an external clock, and the divisor is used to reduce the frequency of the external clock to a frequency that is appropriate for serial communication. For example, if the external clock runs at 1 MHz, and the required baud is 1200, then the divisor must be 833.3‾≈833. Note that the divisor can only be an integer, so the device cannot achieve exactly 1200 baud. However, as explained previously, the sending and receiving devices do not have to agree precisely on the baud. During the transmission and reception of a byte, 1200.48 baud is close enough that the bits will be received correctly even if the other end is running slightly below 1200 baud. In the 8250, there was only one 8-bit register for sending data and only one 8-bit register for receiving data. The UART could send an interrupt to the CPU after each byte was transmitted or received. When receiving, the CPU had to respond to the interrupt very quickly. If the current byte was not read quickly enough by the CPU, it would be overwritten by the subsequent incoming byte. When transmitting, the CPU needed to respond quickly to interrupts to provide the next byte to be sent, or the transmission rate would suffer.

The next generation of UART device was the 16550A. This device is the model for most UART devices today. It features 16-byte input and output buffers, and the ability to trigger interrupts when a buffer is partially full or partially empty. This allows the CPU to move several bytes of data at a time, and results in much lower CPU overhead and much higher data transmission and reception rates. The 16550A also supports much higher baud rates than the 8250.

6.7.4 Universal Serial Bus

Besides high performance components, computers need to communicate with relatively low-speed attached peripheral devices such as keyboards and printers. While these needs have been addressed in the past by a number of both specialized (such as IBM's PS/2 connector for mouse and keyboard) and industry-standard (e.g., serial and parallel communication ports) interfaces, their usefulness was limited when new types of attached devices became available. Among the shortcomings of previous solutions were bulky connectors, reduced interchangeability and interoperability, lack of an option to provide power to the attached devices, minimal or no ability to retrieve the type and operating parameters of connected peripherals, limited support for automatic configuration, no straightforward way to expand the number of available access ports, and, in some cases, insufficient communication speeds.

The USB standard [12] introduced in the mid-1990s successfully resolved these issues. It is currently guided by USB Implementers Forum Inc., a nonprofit corporation involving representatives of 894 hardware and software companies, including among others Intel, Hewlett–Packard, NEC, Renesas, Samsung, ST Microelectronics, Infineon, Philips, Sony, Apple, and Microsoft. The standard has been designed with low cost and simplicity as the primary features. The USB standard defines the architecture, data-flow model, mechanical and electrical properties of connectors and cables, signaling and physical layer, power supply and management, and transaction protocols. It is currently implemented in many categories of peripheral devices, including keyboards, mice, printers, scanners, cameras, mobile phones, media players, mass storage, modems, network adapters, game controllers, and more. The standard underwent updates in three major revisions that successively increased the communication bandwidth, detailed new connector types, defined multihost communication mode (USB On-The-Go), and specified additional power management and battery-charging protocols. The most recent version 3.1 was released in 2013.

USB provides a bidirectional communication link that originally operated at 1.5 Mbps (“low-speed”) and 12 Mbps (“full-speed”) signaling rates. Due to only one differential pair of wires dedicated to data transfer (the other two pins being ground and +5 V supply rail), the communication only supported half-duplex mode. The USB 2.0 update in 2000 increased the raw data rate to 480 Mbps (“hi-speed” mode), but due to protocol overheads the sustained data rate achieved was only 25–40 MB/s, i.e., less than 70% of the peak. USB 3.0 introduced “superspeed” of up to 5 Gbps, signified by blue-colored receptacles. Some USB 3.0 connectors are backwards compatible with USB 2.0, and the increased data rates are achieved by using an additional four pins (two differential line pairs for transmit and receive, thus permitting full-duplex operation) on the opposite side of the connector. In USB 3.1, doubling the maximal signal rate to 10 Gbps required introduction of an entirely new connector format, Type-C. An overview of various USB connectors and receptacles is presented in Fig. 6.19. The specification limits the cable length of low-speed devices to 5 m, full-speed devices to 3 m, and 5 m for hi-speed devices. USB 3.0 currently does not impose cable length constraints.

USB uses a tiered star topology with a single host at the top level, shown in Fig. 6.20. To overcome the limited number of host ports, multiple hubs may be inserted to add additional tier levels for up to seven tiers total and a maximum of 127 USB devices. Functionally, each USB device conforms to the same organizational scheme. Individual logical subdevices are called functions and communicate with the host via pipes. Pipes are logical channels that connect the host with an endpoint of a specific subdevice. A maximum of 16 input and 16 output endpoints per device are permitted. Endpoints are initialized in a process called enumeration (performed right after device power-up) and stay assigned as long as the device is connected. Pipes convey messages and streams: the first are relatively short commands that generate status response, while the latter are unidirectional and support isochronous (repeated communication with guaranteed bandwidth), interrupt (bounded latency communication), or bulk (asynchronous communication that may use the remaining link bandwidth) transfers. USB distinguishes several device classes, such as printer or mass storage, to facilitate loading the appropriate driver software on the host. Common features shared by devices in the same class are frequently supported by the operating system without the need for device-specific manufacturer software.

USB makes provisions for powering or charging peripheral devices through the same socket that facilitates the data transfer. Separate 5 V power and ground lines are included for that purpose. Nominally the current draw has to be negotiated with the host, and is limited to 100 mA for low-power devices (0.5 W) and 500 mA for high-power devices (2.5 W). These limits have been raised for superspeed devices to 150 and 900 mA, respectively. Unfortunately, not all devices comply with the specifications and draw more current than permitted, which on occasion may lead to their erratic behavior. The proliferation of mobile gadgets prompted the creation of a new port type, a charging port, which must deliver at least 1.5 A of current. It exists in a version that supports data communication (charging downstream port) and one that does not (dedicated charging port). A separate specification, USB Power Delivery, intends to extend this support to other devices such as laptops or hard drives by providing six power profiles to supply up to 100 W at three voltage levels using a dedicated power configuration protocol.