- Shopping Bag ( 0 items )
Axelson takes the pain out of designing for USB by ...
Axelson takes the pain out of designing for USB by showing how to write applications that communicate with USB devices using Visual Basic (or any programming language that can call Win32 API functions). There's no need to write low-level device drivers; you can use the drivers included with Windows 98/2000.
Unlike other books that only rehash specifications and manufacturers' marketing materials, this book has original examples, hands-on guidance, and practical tips that developers can put to use right away. USB Complete is an independent guide that isn't obligated to promote one manufacturer's products.
This book will help you decide whether or not USB is the right choice for a peripheral. You'll find tips on selecting the controller chip that matches your design's needs and enables you to get your peripheral up and running quickly. An example project shows how to develop a custom USB peripheral from start to finish, including device firmware and application programming.
As in her previous best-selling Serial Port Complete and Parallel Port Complete, Axelson's simple, direct style and attention to detail help make a complex topic understandable.
Axelson did a great job of presenting the difficult topic of USB peripheral development. With her depth of knowledge, she leaves the reader with a sense of knowing enough about USB to actually do related design work.(Karl W. Pfalzer, enterprise-zone.com)
Fortunately, the host controller's hardware and the USB support in Windows do much of the work of managing the bus. Each USB device attached to the host must have a device driver, which is a software component that enables applications to communicate with the device. Some peripherals can use device drivers included with Windows, while others require custom drivers. Other system-level software components manage communications between the device driver and the host controller.
Applications don't have to worry about the details of USB communications. All they have to do is send and receive data using standard operating-system functions that are accessible from just about all programming languages.
These are tasks that the host performs with little or no support required from applications:
Transfers that must occur at specific rate are guaranteed to have the amount of time they need in each frame. During enumeration, a device's driver requests the bandwidth it will need for transfers that must have guaranteed timing. If the bandwidth isn't available, the host doesn't allow communications with the device. The driver can then request a smaller portion of the bandwidth, or wait until the requested bandwidth is available. Transfers that have no guaranteed rate use the remaining portion of the frames, and may have to wait.
The host may receive other error indicators that indicate that a device can't send or receive data. The host can then inform the device's driver of the problem, and the driver can notify the application so it can take appropriate action.
A device can't begin USB communications on its own. Instead, it must wait and respond to a communication from the host. (An exception is the remote wakeup feature, which enables a device to request a communication from the host.)
The USB controller in the device handles many of the USB's duties automatically. The amount of support required in the device's program code varies with the chip.
All USB devices must respond to the eleven standard request codes that query the capabilities and status of the device and select a configuration. On receiving a request, the device places the information to send in response in its transmit buffer. In some cases, such as setting an address or configuration, the device takes other action in addition to responding with information.
The device doesn't have to carry out every request, however; it just has to respond to the request in an understandable way. For example, when the host requests to use a configuration that the device doesn't support, the device responds with an indicator that the request is unsupported.
When the host enters a low-power state, such as Windows 98's Standby state, all communications on the bus cease, including the timing markers the host normally sends each millisecond. When the devices that connect to the bus detect the absence of bus activity for three milliseconds, they must enter the Suspend state and limit the current they draw from the bus. A host may also request to suspend communications with a specific device. When bus activity resumes, the device must exit its Suspend state.
Devices that don't support the remote-wakeup feature can consume no more than 500 microamperes from the bus in the Suspend state. With the remote-wakeup feature available and enabled by the host, the limit is 2.5 milliamperes. These are average values over a 1 second; the peak current can be greater.
For most transfer types, the device must respond to each poll by sending an acknowledge code (ACK) that indicates that it received the data, or a negative acknowledge (NAK) to indicate that it's too busy to handle the data. The device's hardware sends the appropriate response automatically. Some transfers don't use acknowledgements and the host just assumes that the device has received all transmitted data.
The controller chip's hardware handles the details of formatting the data for the bus. This includes adding error-checking bits to data to transmit, checking for errors in received data, and sending and receiving the individual bits on the bus.
Of course, the device must also do anything else it's responsible for. For example, a mouse must always be ready to detect movement and mouse clicks, a data-acquisition unit has to read the data from its sensors, and a printer must translate received data into images on paper....