New USB 3.0 UVC Class Bridge ICs

FTDI Chip recently introduced a new series of USB 3.0 UVC class bridge ICs. The FT602 devices support streaming of video from HD camera equipment. Imaging systems that once could only deliver low-resolution material can now have improved video quality while still running at 60-fps frame rates.FTDIPR74 FTDI

The FT602 devices’ characteristics, benefits, and specs:

  • Improved performance while viewing captured imaging data via standard UVC-enabled hardware and common media player platforms
  • Plug-and-play implementationl; custom drivers aren’t required
  • Complements FTDI’s FT600 and FT601 capable of providing both USB 3.0 SuperSpeed (5 Gbps) and USB 2.0 High Speed (480 Mbps) interfacing
  • Key applications: surveillance/security, machine vision, home/building automation, metrology, and real-time microscopy

Source: FTDI Chip

Intelligent Displays from Riverdi and FTDI Chip (Sponsored)

Riverdi is a company that is solely concentrated on the development and creation of high quality TFT modules, utilising optimal parts from both the European and Asian markets. Collaborating with display manufacturers in China and Taiwan, the complete modules are then assembled in Europe. This allows Riverdi to offer high quality products that can be delivered quickly and still retain competitive pricing in comparison to its associate distributors. The company has invested in new technology from FTDI Chip with its Embedded Video Engine (EVE) series, the FT8xx range of graphics controller ICs, to power its wide range of intelligent TFT modules.FTDI Img

Display Offering

Riverdi offer a number of different display resolutions, providing the engineer with the ability to choose the right one for their project. The user is then able to choose add-ons to modify the functionality of their display as required. The table below provides the full information on the range available:
FTDI Riverdi Table

For each resolution, there are three options with regard to touch screen type. When an application is being created whereby the end user does not need to input any information, the best choice is the version without a touch screen, which makes the project more cost-efficient. In an environment where the end user would use gloves or requires a hard wearing solution (i.e., in an industrial environment) the best choice would be resistive touch. If the engineer is creating an application which requires multi touch (up to 5 points simultaneously) or the project has specific aesthetic demands, the capacitive touch panel should be selected. Riverdi offers a TFT module with PCT (Projected Capacitive Touch), which uses decorative glass in its default version, uxTouch. Additionally, there is an option to customize the cover glass even further when required.

The TFT module evades the need for complicated drivers by utilising the FT8xx graphics controller IC. All that is needed is the proper calibration to allow direct touch coordination from the IC chip register.

All Riverdi’s modules use a FFC 20-pin connector, and feature built-in LED inverters.  Communication is made possible via SPI / I²C interface for those utilising the first generation EVE (FT80x) and SPI/QSPI for the use of second generation EVE (FT81x). Input voltage levels of 3.3V make it possible to use the same FFC for supplying the power and communication to the module. The displays work in a wide temperature range – 20°C to 70°C – and have 70/50/70/70 vison angles. Fast and easy mounting to customers own housing is possible using just four screws.

Riverdi supply ready to use development platforms for utilizing in users own projects. A Hermes board creates the USB connection for the TFT module to work with a PC class controller. Based on FTDI Chip’s FT232HQ, USB can be converted to SPI for fast testing and prototyping applications, without the requirement of any additional hardware. Utilising an Arduino Shield means that a standard board will work directly with the TFT module, allowing the creation of applications in the Arduino IDE. For standalone microcontroller set up, the Riverdi Revelation Board based on the STM32F0 MCU can be used, allowing the engineer to create a project with an optimal structure directly on the ARM processor.FTDI Riverdi 2

Advantage of EVE Touch Controller ICs

The FT8xx series of display controllers are designed to offer access to high quality colour display solutions for a wide range of applications. The devices offer 3 functions – visual display creation (up to 800 x 600 pixel resolution), touch control (resistive or capacitive) and an audio output ideal for providing clicks and beeps in response to human interaction with the devices. As an SPI peripheral to a system MCU, the heavy processing tasks for creating a visual display or calculating a touch point is handled efficiently by the FT8xx, allowing Riverdi displays to be paired with a wide variety of embedded processors: ARM, PIC,  Arduino and many more.

The devices simplify construction of display data through the placing of objects on a display list including the most basic elements when conducting a list: what to draw, where to draw and the size and colour of each object. It is then processed by the FT8xx for driving the display line by line, with no frame grabbing required.  Additional algorithms such as alpha blending and anti-aliasing all help to improve the image quality, while the FT812 and FT813 variants found within the FT81x second generation EVE range offer true 24 bit colour depth.

As all items displayed are treated as individual objects, the FT8xx devices are also able to simplify coding of touch events by ensuring each object returns a unique ”tag” value if a touch point is detected within the area of the object. This simplifies an end users application code as there is no need to calculate whether a touched point is within a specific display area or not.

While the FT80x variants are best suited to menu style displays or simple animations, the FT81x variants enhance this capability by adding video playback and the ability to rotate a display, thus ensuring that the Riverdi solution will work well in both portrait or landscape designs.FTDI Riverdi Table2

Summary

Riverdi is among the first manufactures to take advantage of the ground breaking technologies found within the EVE display controller series, and is proud to have created the first complete module utilising the FT81x. By specializing in the creation of premium TFT modules, and providing high quality, ready to use solutions, the benefits of EVE technology from FTDI Chip is realised. Additionally, Riverdi is pleased to be able to strengthen its offering with a wide range of development tools to assist in the development of new project in the chosen IDE.

Download a PDF of this article


About Riverdi

Riverdi is an innovative company which uses cutting-edge technologies to provide solutions which meet today’s end user demands. Within its first few years on the market, the company  developed its’s own process of TFT module production in Shenzhen and Poland, allowing for guaranteed high quality and cost efficiency.

All of Riverdi’s products use industrial grade materials and components, thus they can be used in both consumer and industrial projects. Riverdi guarantee that each and every product has been produced and shipped in line with its maintained quality procedures.

Riverdi keeps a permanent stock of basic products, and are thus able to offer a competitive delivery time of a few days as maximum. For more information please visit www.riverdi.com.

About FTDI Chip

FTDI Chip develops innovative silicon solutions that enhance interaction with today’s technology. To meet its ‘USB Solutions Specialist’ status, the company works to support engineers with highly sophisticated, feature-rich, robust and simple-to-use product platforms. These enable creation of electronic designs with higher performance, fewer peripheral components, lower power budgets and diminished board real estate.

FTDI Chip’s long-established, continuously expanding Universal Serial Bus (USB) product line boasts such universally recognised product brands as the ubiquitous R-Chip, X-Chip, Vinculum and H Series.

FTDI Chip is a fab-less semiconductor company partnered with the world’s leading foundries. The company is headquartered in Glasgow, UK with research and development facilities located in Glasgow, Singapore and Taipei (Taiwan) plus regional sales and technical support sites in Glasgow, Taipei, Portland (Oregon, USA) and Shanghair (China).For more information please visit www.ftdichip.com.

New Ecosystem to Accompany 8-bit FT51A MCUs

FTDI Chip recently announced an array of board level products to support its FT51A microcontroller. It executes an 8051 feature set that can operate at 48 MHz. In addition, it features a variety of interfaces, including USB client, UART, SPI, I2C, 245 FIFO, PWM, and GPIO. The USB hub feature enables multiple USB-enabled devices to be combined. The FT51A’s data conversion capabilities comprise of an 8-bit ADC. Its 16-KB shadow RAM accelerates read access of the core. The device draws 20 mA (typical) while active and 150 µA (typical) when in suspend mode.

The FT51A microcontroller is suitable for a variety of applications, including industrial test instrumentation and sensor control.

The FT51A-EVM evaluation module offers you several functions for learning about the FT51A MCU.  It includes a 2 × 20 LCD display and several sensor mechanisms for data acquisition. Also included are a heart-rate monitor (with filtered and amplified analo output), a force sensitive resistor, and a SPI-enabled temperature sensor.

Source: FTDI

Evaluation Boards for SuperSpeed USB-to-FIFO Bridge ICs

FTDI recently launched a new family of evaluation/development modules to encourage the implementation of its next-generation USB interfacing technology. Its FT600/1Q USB 3.0 SuperSpeed ICs are in volume production and backed up by the UMFT60XX offering. The family comprises four models that provide different FIFO bus interfaces and data bit widths. With these modules, the operational parameters of FT600/1Q devices can be fully assessed and interfacing with external hardware undertaken, such as FPGA platforms.

At 78.7 mm × 60 mm, the UMFT600A and UMFT601A each have a high-speed mezzanine card (HSMC) interface with 16-bit-wide and 32-bit-wide FIFO buses, respectively. The UMFT600X and UMFT601X measure 70 mm × 60 mm and incorporate field-programmable mezzanine card (FMC) connectors with 16-bit-wide and 32-bit-wide FIFO buses, respectively.

The HSMC interface is compatible with most Altera FPGA reference design boards, while the FMC connector delivers the same functionality in relation to Xilinx boards. Fully compatible with USB 3.0 SuperSpeed (5 Gbps), USB 2.0 High Speed (480 Mbips), and USB 2.0 Full Speed (12 Mbps) data transfer, the UMFT60xx modules support two parallel slave FIFO bus protocols with an achievable data burst rate of around 400 MBps. The multi-channel FIFO mode can handle up to four logic channels. It is complemented by the 245 synchronous FIFO mode, which is optimized for more straightforward operation.

Source: FTDI

Turn Your Android Device into an Application Tool

A few years ago, the Android Open Accessory initiative was announced with the aim of making it easier for hardware manufacturers to create accessories that work with every Android device. Future Technology Devices International (FTDI) joined the initiative and last year introduced the FTD311D multi-interface Android host IC. The goal was to enable engineers and designers to make effective use of tablets and smartphones with the Android OS, according to Circuit Cellar columnist Jeff Bachiochi.

The FTD311D “provides an instant bridge from an Android USB port(B) to peripheral hardware over general purpose input-out (GPIO), UART, PWM, I2C Master, SPI Slave, or SPI Master interfaces,” Bachiochi says.

In the magazine’s December issue Bachiochi takes a comprehensive look at the USB Android host IC and how it works. By the end of his article, readers will have learned quite a bit about how to use FTDI’s apps and the FT311D chip to turn an Android device into their own I/0 tool.

Bachiochi used the SPI Master demo to read key presses and set LED states on this SPI slave 16-key touch panel.

Bachiochi used the SPI Master demo to read key presses and set LED states on this SPI slave 16-key touch panel.

Here is how Bachiochi describes the FT311D and its advantages:

The FT311D is a full-speed USB host targeted at providing access to peripheral hardware from a USB port on an Android device. While an Android device can be a USB host, many are mobile devices with limited power. For now, these On-The-Go (OTG) ports will be USB devices only (i.e., they can only connect to a USB host as a USB device).

Since the USB host is responsible for supplying power to a USB peripheral device, it would be bad design practice to enable a USB peripheral to drain an Android mobile device’s energy. Consequently, the FT311D takes on the task of USB host, eliminating any draw on the Android device’s battery.

All Android devices from V3.1 (Honeycomb) support the Android Open Accessory Mode (AOAM). The AOAM is the complete reverse of the conventional USB interconnect. This game-changing approach to attaching peripherals enables three key advantages. First, there is no need to develop special drivers for the hardware; second, it is unnecessary to root devices to alter permissions for loading drivers; and third, the peripheral provides the power to use the port, which ensures the mobile device battery is not quickly drained by the external hardware being attached.

Since the FT311D handles the entire USB host protocol, USB-specific firmware programming isn’t required. As the host, the FT311D must inquire whether the connected device supports the AOAM. If so, it will operate as an Open Accessory Mode device with one USB BULK IN endpoint and one USB BULK OUT endpoint (as well as the control endpoint.) This interface will be a full-speed (12-Mbps) USB enabling data transfer in and out.

The AOAM USB host has a set of string descriptors the Android OS is capable of reading. These strings are (user) associated with an Android OS application. The Android then uses these strings to automatically start the application when the hardware is connected. The FT311D is configured for one of its multiple interfaces via configuration inputs at power-up. Each configuration will supply the Android device with a unique set of string descriptors, therefore enabling different applications to run, depending on its setup.

The FT311D’s configuration determines whether each application will have access to several user interface APIs that are specific to each configuration.

The article goes on to examine the various interfaces in detail and to describe a number of demo projects, including a multimeter.

Many of Bachiochi's projects use printable ASCII text commands and replies. This enables a serial terminal to become a handy user I/O device. This current probe circuit outputs its measurements in ASCII-printable text.

Many of Bachiochi’s projects use printable ASCII text commands and replies. This enables a serial terminal to become a handy user I/O device. This current probe circuit outputs its measurements in ASCII-printable text.

Multimeters are great tools. They have portability that enables them to be brought to wherever a measurement must be made. An Android device has this same ability. Since applications can be written for these devices, they make a great portable application tool. Until the AOAM’s release, there was no way for these devices to be connected to any external circuitry and used as an effective tool.

I think FTDI has bridged this gap nicely. It provided a great interface chip that can be added to any circuit that will enable an Android device to serve as an effective user I/O device. I’ve used the chip to quickly interface with some technology to discover its potential or just test its abilities. But I’m sure you are already thinking about the other potential uses for this connection.

Bachiochi is curious to hear from readers about their own ideas.

If you think the AOAM has future potential, but you want to know what’s involved with writing Android applications for a specific purpose, send me an e-mail and I’ll add this to my list of future projects!

You can e-mail Bachiochi at jeff.bachiochi@imaginethatnow.com or post your comment here.

 

Arduino-Based Hand-Held Gaming System

gameduino2-WEBJames Bowman, creator of the Gameduino game adapter for microcontrollers, recently made an upgrade to the system adding a Future Technology Devices International (FTDI) FT800 chip to drive the graphics. Associate Editor Nan Price interviewed James about the system and its capabilities.

NAN: Give us some background. Where do you live? Where did you go to school? What did you study?

Bowman-WEB

James Bowman

 JAMES: I live on the California coast in a small farming village between Santa Cruz and San Francisco. I moved here from London 17 years ago. I studied computing at Imperial College London.

NAN: What types of projects did you work on when you were employed by Silicon Graphics, 3dfx Interactive, and NVIDIA?

JAMES: Always software and hardware for GPUs. I began in software, which led me to microcode, which led to hardware. Before you know it you’ve learned Verilog. I was usually working near the boundary of software and hardware, optimizing something for cost, speed, or both.

NAN: How did you come up with the idea for the Gameduino game console?

JAMES: I paid for my college tuition by working as a games programmer for Nintendo and Sega consoles, so I was quite familiar with that world. It seemed a natural fit to try to give the Arduino some eye-catching color graphics. Some quick experiments with a breadboard and an FPGA confirmed that the idea was feasible.

NAN: The Gameduino 2 turns your Arduino into a hand-held modern gaming system. Explain the difference from the first version of Gameduino—what upgrades/additions have been made?

Gameduinofinal-WEB

The Gameduino2 uses a Future Technology Devices International chip to drive its graphics

JAMES: The original Gameduino had to use an FPGA to generate graphics, because in 2011 there was no such thing as an embedded GPU. It needs an external monitor and you had to supply your own inputs (e.g., buttons, joysticks, etc.). The Gameduino 2 uses the new Future Technology Devices International (FTDI) FT800 chip, which drives all the graphics. It has a built-in color resistive touchscreen and a three-axis accelerometer. So it is a complete game system—you just add the CPU.

NAN: How does the Arduino factor into the design?

GameduinoPCB-WEB

An Arduino, Ethernet adapter, and a Gameduino

 JAMES: Arduino is an interesting platform. It is 5 V, believe it or not, so the design needs a level shifter. Also, the Arduino is based on an 8-bit microcontroller, so the software stack needs to be carefully built to provide acceptable performance. The huge advantage of the Arduino is that the programming environment—the IDE, compiler, and downloader—is used and understood by hundreds of thousands of people.

 NAN: Is it easy or possible to customize the Gameduino 2?

 JAMES: I would have to say no. The PCB itself is entirely surface mount technology (SMT) and all the ICs are QFNs—they have no accessible pins! This is a long way from the DIP packages of yesterday, where you could change the circuit by cutting tracks and soldering onto the pins.

I needed a microscope and a hot air station to make the Gameduino2 prototype. That is a long way from the “kitchen table” tradition of the Arduino. Fortunately the Arduino’s physical design is very customization-friendly. Other devices can be stacked up, adding networking, hi-fi sound, or other sensor inputs.

 NAN: The Gameduino 2 project is on Kickstarter through November 7, 2013. Why did you decide to use Kickstarter crowdfunding for this project?

 JAMES: Kickstarter is great for small-scale inventors. The audience it reaches also tends to be interested in novel, clever things. So it’s a wonderful way to launch a small new product.

NAN: What’s next for Gameduino 2? Will the future see a Gameduino 3?

 JAMES: Product cycles in the Arduino ecosystem are quite long, fortunately, so a Gameduino 3 is distant. For the Gameduino 2, I’m writing a book, shipping the product, and supporting the developer community, which will hopefully make use of it.

 

Debugging USB Firmware

You’ve written firmware for your USB device and are ready to test it. You attach the device to a PC and the hardware wizard announces: “The device didn’t start.” Or, the device installs but doesn’t send or receive data. Or, data is being dropped, the throughput is low, or some other problem presents itself. What do you do?

This article explores tools and techniques to debug the USB devices you design. The focus is on USB 2.0 devices, but much of the information also applies to developing USB 3.0 (SuperSpeed) devices and USB hosts for embedded systems.

VIEWING BUS TRAFFIC

If you do anything beyond a small amount of USB developing, a USB protocol analyzer will save you time and trouble. Analyzers cost less than they used to and are well worth the investment.

A hardware-based analyzer connects in a cable segment upstream from the device under test (see Photo 1).

Photo 1: The device under test connects to the analyzer, which
captures the data and passes it unchanged to the device’s host. The
cable on the back of the analyzer carries the captured data to the
analyzer’s host PC for display.

You can view the data down to each packet’s individual bytes and see exactly what the host and device did and didn’t send (see Photo 2).

Photo 2: This bus capture shows the host’s request for a configuration
descriptor and the bytes the device sent in response. Because the endpoint’s
maximum packet size is eight, the device sends the first 8 bytes in one
transaction and the final byte in a second transaction.

An analyzer can also decode data to show standard USB requests and class-specific data (see Photo 3).

Photo 3: This display decodes a received configuration descriptor and its subordinate descriptors.

To avoid corrupted data caused by the electrical effects of the analyzer’s connectors and circuits, use short cables (e.g., 3’ or less) to connect the analyzer to the device under test.

Software-only protocol analyzers, which run entirely on the device’s host PC, can also be useful. But, this kind of analyzer only shows data at the host-driver level, not the complete packets on the bus.

DEVELOPMENT STRATEGIES

The first rule for developing USB device firmware is to remember that the host computer controls the bus. Devices just need to respond to received data and events. Device firmware shouldn’t make assumptions about what the host will do next.

For example, some flash drives work under Windows but break when attached to a host with an OS that sends different USB requests or mass-storage commands, sends commands in a different order, or detects errors Windows ignores. This problem is so common that Linux has a file, unusual_devs.h, with fixes for dozens of misbehaving drives.

The first line of defense in writing USB firmware is the free USB-IF Test Suite from the USB Implementers Forum (USB-IF), the trade group that publishes the USB specifications. During testing, the suite replaces the host’s USB driver with a special test driver. The suite’s USB Command Verifier tool checks for errors (e.g., malformed descriptors, invalid responses to standard USB requests, responses to Suspend and Resume signaling, etc.). The suite also provides tests for devices in some USB classes, such as human interface devices (HID), mass storage, and video.

Running the tests will usually reveal issues that need attention. Passing the tests is a requirement for the right to display the USB-IF’s Certified USB logo.

LAYERED COMMUNICATIONS

Like networks, USB communications have layers that isolate different logical functions (see Table 1).

Table 1: USB communications use layers, which are each responsible for a
specific logical function.

The USB protocol layer manages USB transactions, which carry data packets to and from device endpoints. A device endpoint is a buffer that is a source or sink of data at the device. The host sends data to Out endpoints and receives data from In endpoints. (Even though endpoints are on devices, In and Out are defined from the host’s perspective.)

The device layer manages USB transfers, with each transfer moving a chunk of data consisting of one or more transactions. To meet the needs of different peripherals, the USB 2.0 specification defines four transfer types: control, interrupt, bulk, and isochronous.

The function layer manages protocols specific to a device’s function (e.g., mouse, printer, or drive). The function protocols may be a combination of USB class, industry, and vendor-defined protocols.

CONTROLLER ARCHITECTURES

The layers supported by device firmware vary with the device hardware. At one end of the spectrum, a Future Technology Devices International (FTDI) FT232R USB UART controller handles all the USB protocols in hardware. The chip has a USB device port that connects to a host computer and a UART port that connects to an asynchronous serial port on the device.

Device firmware reads and writes data on the serial port, and the FT232R converts it between the USB and UART protocols. The device firmware doesn’t have to know anything about USB. This feature has made the FT232R and similar chips popular!

An example of a chip that is more flexible but requires more firmware support is Microchip Technology’s PIC18F4550 microcontroller, which has an on-chip, full-speed USB device controller. In return for greater firmware complexity, the PIC18F4550 isn’t limited to a particular host driver and can support any USB class or function.

Each of the PIC18F4550’s USB endpoints has a series of registers—called a buffer descriptor table (BDT)—that store the endpoint buffer’s address, the number of bytes to send or receive, and the endpoint’s status. One of the BDT’s status bits determines the BDT’s ownership. When the CPU owns the BDT, firmware can write to the registers to prepare to send data or to retrieve received data. When the USB module owns the BDT, the endpoint can send or receive data on the bus.

To send a data packet from an In endpoint, firmware stores the bytes’ starting address to send and the number of bytes and sets a register bit to transfer ownership of the BDT to the USB module. The USB module sends the data in response to a received In token packet on the endpoint and returns BDT ownership to the CPU so firmware can set up the endpoint to send another packet.

To receive a packet on an Out endpoint, firmware stores the buffer’s starting address for received bytes and the maximum number of bytes to receive and transfers ownership of the BDT to the USB module. When data arrives, the USB module returns BDT ownership to the CPU so firmware can retrieve the data and transfer ownership of the BDT back to the USB module to enable the receipt of another packet.

Other USB controllers have different architectures and different ways of managing USB communications. Consult your controller chip’s datasheet and programming guide for details. Example code from the chip vendor or other sources can be helpful.

DEBUGGING TRANSACTIONS

A USB 2.0 transaction consists of a token packet and, as needed, a data packet and a handshake packet. The token packet identifies the packet’s type (e.g., In or Out), the destination device and endpoint, and the data packet direction.

The data packet, when present, contains data sent by the host or device. The handshake packet, when present, indicates the transaction’s success or failure.

The data and handshake packets must transmit quickly after the previous packet, with only a brief inter-packet delay and bus turnaround time, if needed. Thus, device hardware typically manages the receiving and sending of packets within a transaction.

For example, if an endpoint’s buffer has room to accept a data packet, the endpoint stores the received data and returns ACK in the handshake packet. Device firmware can then retrieve the data from the buffer. If the buffer is full because firmware didn’t retrieve previously received data, the endpoint returns NAK, requiring the host to try again. In a similar way, an In endpoint will NAK transactions until firmware has loaded the endpoint’s buffer with data to send.

Fine tuning the firmware to quickly write and retrieve data can improve data throughput by reducing or eliminating NAKs. Some device controllers support ping-pong buffers that enable an endpoint to store multiple packets, alternating between the buffers, as needed.

LOST DATA

In all but isochronous transfers, a data-toggle value in the data packet’s packet identification (PID) field guards against missed or duplicate data packets. If you’re debugging a device where data is transmitting on the bus and the receiver is returning ACK but ignoring or discarding the data, chances are good that the device isn’t sending or expecting the correct data-toggle value. Some device controllers handle the data toggles completely in hardware, while others require some firmware control.

Each endpoint maintains its own data toggle. The values are DATA0 (0011B) and DATA1 (1011B). Upon detecting an incoming data packet, the receiver compares its data toggle’s state with the received data toggle. If the values match, the receiver toggles its value and returns ACK, causing the sender to toggle its value for the next transaction.

The next received packet should contain the opposite data toggle, and again the receiver toggles its bit and returns ACK. Except for control transfers, the data toggle on each end continues to alternate in each transaction. (Control transfers always use DATA0 in the Setup stage, toggle the value for each transaction in the Data stage, and use DATA1 in the Status stage.)

If the receiver returns NAK or no response, the sender doesn’t toggle its bit and tries again with the same data and data toggle. If a receiver returns ACK, but for some reason the sender doesn’t see the ACK, the sender thinks the receiver didn’t receive the data and tries again using the same data and data toggle. In this case, the repeated data receiver ignores the data, doesn’t toggle the data toggle, and returns ACK, resynchronizing the data toggles. If the sender mistakenly sends two packets in a row with the same data-toggle value, upon receiving the second packet, the receiver ignores the data, doesn’t toggle its value, and returns ACK.

DEFINING A TRANSFER

All USB devices must support control transfers and may support other transfer types. Control transfers provide a structure for sending requests but have no guaranteed delivery time. Interrupt transfers have a guaranteed maximum latency (i.e., delay) between transactions, but the host permits less bandwidth for interrupt transfers compared to other transfer types. Bulk transfers are the fastest on an otherwise idle bus, but they have no guaranteed delivery time, and thus can be slow on a busy bus. Isochronous transfers have guaranteed delivery time but no built-in error correction.

A transfer’s amount of data depends in part on the higher-level protocol that determines the data packets’ contents. For example, a keyboard sends keystroke data in an interrupt transfer that consists of one transaction with 8 data bytes. To send a large file to a drive, the host typically uses one or more large transfers consisting of multiple transactions. For a high-speed drive, each transaction, except possibly the last one, has 512 data bytes, which is the maximum-allowed packet size for high-speed bulk endpoints.

What determines a transfer’s end varies with the USB class or vendor protocol. In many cases, a transfer ends with a short packet, which is a packet that contains less than the packet’s maximum-allowed data bytes. If the transfer has an even multiple of the packet’s maximum-allowed bytes, the sender may indicate the end of the transfer with a zero-length packet (ZLP), which is a data packet with a PID and error-checking bits but no data.

For example, USB virtual serial-port devices in the USB communications device class use short packets to indicate the transfer’s end. If a device has sent data that is an exact multiple of the endpoint’s maximum packet size and the host sends another In token packet, the endpoint should return a ZLP to indicate the data’s end.

DEBUGGING ENUMERATION

Upon device attachment, in a process called enumeration, the host learns about the device by requesting a series of data structures called descriptors. The host uses the descriptors’ information to assign a driver to the device.

If enumeration doesn’t complete, the device doesn’t have an assigned driver, and it can’t perform its function with the host. When Windows fails to find an appropriate driver, the setupapi.dev.log file in Windowsinf (for Windows 7) can offer clues about what went wrong. A protocol analyzer shows if the device returned all requested descriptors and reveals mistakes in the descriptors.

During device development, you may need to change the descriptors (e.g., add, remove, or edit an endpoint descriptor). Windows has the bad habit of remembering a device’s previous descriptors on the assumption that a device will never change its descriptors. To force Windows to use new descriptors, uninstall then physically remove and reattach the device from Windows Device Manager. Another option is to change the device descriptor’s product ID to make the device appear as a different device.

DEBUGGING TRANSFERS

Unlike the other transfer types, control transfers have multiple stages: setup, (optional) data, and status. Devices must accept all error-free data packets that follow a Setup token packet and return ACK. If the device is in the middle of another control transfer and the host sends a new Setup packet, the device must abandon the first transfer and begin the new one. The data packet in the Setup stage contains important information firmware should completely decode (see Table 2).

Table 2: Device firmware should fully decode the data received in a control transfer’s Setup stage. (Source: USB Implementers Forum, Inc.)

The wLength field specifies how many bytes the host wants to receive. A device shouldn’t assume how much data the host wants but should check wLength and send no more than the requested number of bytes.

For example, a request for a configuration descriptor is actually a request for the configuration descriptor and all of its subordinate descriptors. But, in the first request for a device’s configuration descriptor, the host typically sets the wLength field to 9 to request only the configuration descriptor. The descriptor contains a wTotalLength value that holds the number of bytes in the configuration descriptor and its subordinate descriptors. The host then resends the request setting wLength to wTotalLength or a larger value (e.g., FFh). The device returns the requested descriptor set up to wTotalLength. (Don’t assume the host will do it this way. Always check wLength!)

Each Setup packet also has a bmRequestType field. This field specifies the data transfer direction (if any), whether the recipient is the device or an interface or endpoint, and whether the request is a standard USB request, a USB class request, or a vendor-defined request. Firmware should completely decode this field to correctly identify received requests.

A composite device has multiple interfaces that function independently. For example, a printer might have a printer interface, a mass-storage interface for storing files, and a vendor-specific interface to support vendor-defined capabilities. For requests targeted to an interface, the wIndex field typically specifies which interface applies to the request.

INTERRUPT TRANSFER TIMING

For interrupt endpoints, the endpoint descriptor contains a bInterval value that specifies the endpoint’s maximum latency. This value is the longest delay a host should use between transaction attempts.

A host can use the bInterval delay time or a shorter period. For example, if a full-speed In endpoint has a bInterval value of 10, the host can poll the endpoint every 1 to 10 ms. Host controllers typically use predictable values, but a design shouldn’t rely on transactions occurring more frequently than the bInterval value.

Also, the host controller reserves bandwidth for interrupt endpoints, but the host can’t send data until a class or vendor driver provides something to send. When an application requests data to be sent or received, the transfer’s first transaction may be delayed due to passing the request to the driver and scheduling the transfer.

Once the host controller has scheduled the transfer, any additional transaction attempts within the transfer should occur on time, as defined by the endpoint’s maximum latency. For this reason, sending a large data block in a single transfer with multiple transactions can be more efficient than using multiple transfers with a portion of the data in each transfer.

DEVICE FUNCTIONS

Most devices’ functions fit a defined USB class (e.g., mass storage, printer, audio, etc.). The USB-IF’s class specifications define protocols for devices in the classes.

For example, devices in the HID class must send and receive all data in data structures called reports. The supported report’s length and the meaning of its data (e.g., keypresses, mouse movements, etc.) are defined in a class-specific report descriptor.

If your HID-class device is sending data but the host application isn’t seeing the data, verify the number of bytes the device is sending matches the number of bytes in a defined report. The device should prepend a report-ID byte to the data only if the HID supports report IDs other than the zero default value.

In many devices, class specifications define class-specific requests or other requirements. For example, a mass storage device that uses the bulk-only protocol must provide a unique serial number in a string descriptor. Carefully read and heed any class specifications that apply to your device!

Many devices also support industry protocols to perform higher-level functions. Printers typically support one or more printer-control languages (e.g., PCL and Postscript). Mass-storage devices support SCSI commands to transfer data blocks and a file system (e.g., FAT32) to define a directory structure.

The higher-level industry protocols don’t depend on a particular hardware interface, so there is little about debugging them that is USB-specific. But, because these protocols can be complicated, example code for your device can be helpful.

In the end, much about debugging USB firmware is like debugging any hardware or software. A good understanding of how the communications should work provides a head start on writing good firmware and finding the source of any problems that may appear.

Jan Axelson is the author of USB Embedded Hosts, USB Complete, and Serial Port Complete. Jan’s PORTS web forum is available at www.lvr.com.

RESOURCES

Jan Axelson’s Lakeview Research, “USB Development Tools: Protocol analyzers,” www.lvr.com/development_tools.htm#analyzers.

This article appears in Circuit Cellar 268 (November 2012).

CC268: The History of Embedded Tech

At the end of September 2012, an enthusiastic crew of electrical engineers and journalists (and significant others) traveled to Portsmouth, NH, from locations as far apart as San Luis Obispo, CA,  and Paris, France, to celebrate Circuit Cellar’s 25th anniversary. Attendees included Don Akkermans (Director, Elektor International Media), Steve Ciarcia (Founder, Circuit Cellar), the current magazine staff, and several well-known engineers, editors, and columnists. The event marked the beginning of the next chapter in the history of this long-revered publication. As you’d expect, contributors and staffers both reminisced about the past and shared ideas about its future. And in many instances, the conversations turned to the content in this issue, which was at that time entering the final phase of production. Why? We purposely designed this issue (and next month’s) to feature a diversity of content that would represent the breadth of coverage we’ve come to deliver during the past quarter century. A quick look at this issue’s topics gives you an idea of how far embedded technology has come. The topics also point to the fact that some of the most popular ’80s-era engineering concerns are as relevant as ever. Let’s review.

In the earliest issues of Circuit Cellar, home control was one of the hottest topics. Today, inventive DIY home control projects are highly coveted by professional engineers and newbies alike. On page 16, Scott Weber presents an interesting GPS-based time server for lighting control applications. An MCU extracts time from GPS data and transmits it to networked devices.

The time-broadcasting device includes a circuit board that’s attached to a GPS module. (Source: S. Weber, CC268)

Thiadmer Riemersma’s DIY automated component dispenser is a contemporary solution to a problem that has frustrated engineers for decades (p. 26). The MCU-based design simplifies component management and will be a welcome addition to any workbench.

The DIY automated component dispenser. (Source: T. Riemersma, CC268)

USB technology started becoming relevant in the mid-to-late 1990s, and since then has become the go-to connection option for designers and end users alike. Turn to page 30 for Jan Axelson’s  tips about debugging USB firmware. Axelson covers controller architectures and details devices such as the FTDI FT232R USB UART controller and Microchip Technology’s PIC18F4550 microcontroller.

Debugging USB firmware (Source: J. Axelson, CC268)

Electrical engineers have been trying to “control time” in various ways since the earliest innovators began studying and experimenting with electric charge. Contemporary timing control systems are implemented in a amazing ways. For instance, Richard Lord built a digital camera controller that enables him to photograph the movement of high-speed objects (p. 36).

Security and product reliability are topics that have been on the minds of engineers for decades. Whether you’re working on aerospace electronics or a compact embedded system for your workbench (p. 52), you’ll want to ensure your data is protected and that you’ve gone through the necessary steps to predict your project’s likely reliability (p. 60).

The issue’s last two articles detail how to use contemporary electronics to improve older mechanical systems. On page 64 George Martin presents a tachometer design you can implement immediately in a machine shop. And lastly, on page 70, Jeff Bachiochi wraps up his series “Mechanical Gyroscope Replacement.” The goal is to transmit reliable data to motor controllers. The photo below shows the Pololu MinIMU-9.

The Pololu MinIMU-9’s sensor axes are aligned with the mechanical gyro so the x and y output pitch and roll, respectively. (Source: J. Bachiochi, CC268)

Tech Highlights from Design West: RL78, AndroPod, Stellaris, mbed, & more

The Embedded Systems Conference has always been a top venue for studying, discussing, and handling the embedded industry’s newest leading-edge technologies. This year in San Jose, CA, I walked the floor looking for the tech Circuit Cellar and Elektor members would love to get their hands on and implement in novel projects. Here I review some of the hundreds of interesting products and systems at Design West 2012.

RENESAS

Renesas launched the RL78 Design Challenge at Design West. The following novel RL78 applications were particularly intriguing.

  • An RL78 L12 MCU powered by a lemon:

    A lemon powers the RL78 (Photo: Circuit Cellar)

  • An RL78 kit used for motor control:

    The RL78 used for motor control (Photo: Circuit Cellar)

  • An RL78 demo for home control applications:

    The RL78 used for home control (Photo: Circuit Cellar)

TEXAS INSTRUMENTS

Circuit Cellar members have used TI products in countless applications. Below are two interesting TI Cortex-based designs

A Cortex-M3 digital guitar (you can see the Android connection):

TI's digital guitar (Photo: Circuit Cellar)

Stellaris fans will be happy to see the Stellaris ARM Cortex -M4F in a small wireless application:

The Stellaris goes wireless (Photo: Circuit Cellar)

NXP mbed

Due to the success of the recent NXP mbed Design Challenge, I stopped at the mbed station to see what exciting technologies our NXP friends were exhibiting. They didn’t disappoint. Check out the mbed-based slingshot developed for playing Angry Birds!

mbed-Based sligshot for going after "Angry Birds" (Photo: Circuit Cellar)

Below is a video of the project on the mbedmicro YouTube page:

FTDI

I was pleased to see the Elektor AndroPod hard at work at the FTDI booth. The design enables users to easily control a robotic arm with Android smartphones and tablets.

FTDI demonstrates robot control with Android (Photo: Circuit Cellar)

As you can imagine, the possible applications are endless.

The AndroPod at work! (Photo: Circuit Cellar)