15

So I know about the USB 2.0 spec located at the USB.org site.

I am a little lazy and impatient. Can someone tell me where to go to find out exactly what is expected of my peripheral device when the USB cable is connected?

For example, if my peripheral device is a printer, how do I tell the computer at the other end that a printer (with a specific model description, I suppose) has just been connected? Than, in the computer, how does the printer driver know which USB port was connected to the printer?

My application is actually USB MIDI. I have also gotten this USB-MIDI doc, but I am deficient with the more fundamental USB protocol.

Just for people's information, the USB chip I am using is the FTDI FT220x and it's hooked up to the SPI of an ADSP-21479 SHArC. We now use it simply for text communications using the PC (running TeraTerm) as a "console". i have access to the code that sets up the SPI port and connects to the FTDI chip, but there is no code that does any initial communications. I do not know what the FT220x does when it's first connected to the PC.

I am not unhappy to read and learn, but i would like to know where to start reading, and a 100 MB USB spec is too big of a target to shoot at. Sincere thanks to anyone for actionable help.

Community
  • 1
robert bristow-johnson
  • 1,645
  • 1
  • 12
  • 29
  • 1
    So you're just curious about what the FTDI FT220x is doing behind the scenes, right? Since FTDI takes care of a lot of the USB stuff for you, there are also some limits to what it will let you do. I've used the FT2232H family for awhile, will try to explain what I know... – MarkU Nov 25 '17 at 06:47
  • what i am ultimately trying to do is use this USB port that already is smart enough to send text back-and-forth to the PC running TeraTerm, what i was hoping to do is use the same USB connector to do USB MIDI. i need to understand how to *"packetize"* the data into 32-bit packet, but i thought (and still think) that there must be some protocol that tells the other end that this is a USB MIDI device. (so far, i just don't have a grip on the USB essentials and your answer appears very helpful to get me going.) – robert bristow-johnson Nov 25 '17 at 19:25

2 Answers2

22

USB has several layers, which are described in the USB 2.0 Specification. If you're familiar with the OSI layered network model, you can think of it like this:

  • Session layer = Chapter 10 USB Host Hardware and Software (device drivers)
  • Transport layer = Chapter 9 USB Device Framework
  • Network layer = Chapter 8 Protocol Layer (bitstream)
  • Data Link layer = Chapter 7 Electrical (circuit)
  • Physical layer = Chapter 6 Mechanical (cable and connector)

Conceptually USB is based on streams of data, called Endpoints, which can be either IN (to the host) or OUT (from the host). Every device has Endpoint 0, which is used for control and status. A device may have additional endpoints for application data. Each endpoint behaves like a FIFO buffer.

Data is transferred on an endpoint either as Bulk (like TCP/IP, guaranteed that every byte arrives and in the correct order), or Isochronous (like UDP/IP, guaranteed to be fresh but may drop packets). There is a misleadingly named "Interrupt" transfer type, which is really just polled by the host.

USB 2.0 uses a differential pair for datalink. I won't go into much detail as this is covered by the USB 2.0 spec chapter 7. Generally on the PCB layout we treat this as a matched-length, differential pair, and put in the series resistors required by whatever USB PHY (Physical Interface) is being used. USB peripheral uses a high value resistor on one of the D+ or D- lines to notify the host that it is a high-speed or low-speed peripheral.

Soon after the USB host discovers that a device is present, the host requests a bunch of descriptors from the device. This is taken care of behind the scenes by the FTDI chip. The descriptos are described in Chapter 9.5. These include Device Descriptor, Configuration Descriptor, Interface Descriptors, Endpoint Descriptors, String Descriptors, maybe even HID Report Descriptors.

The Device Descriptor includes the USB VID (Vendor Identification) and PID (Product Identification) numbers. The operating system uses this pair of numbers, VID_PID, to determine which device driver shall be used for this device. Note that the VID number is issued by having membership in the USB implementors forum, so that's kind of a problem if you're an individual inventor.

Additionally, there is the HID (Human Interface Device) class driver, which provides somewhat generic input for keyboard/mouse/etc, as well as any generic input/output. One advantage of HID is that it does not require providing a custom device driver, but its throughput is somewhat limited compared to a custom bulk driver. There is a whole other specification document about the HID descriptors; and a HID Usage Table document that details all of the code numbers that describe the various features available on a given human interfaced device.

FTDI chip such as FT220X datasheet provides the USB "serial interface engine" (not to be confused with SPI serial or RS232 serial). This takes care of most of the low-level stuff described in chapters 6, 7, and 8.

FTDI uses an EEPROM (offchip on the FT2232H, on-chip on the FT220X) to contain a little bit of the information that goes into the descriptors. You can customize the VID/PID values, and provide custom description strings.

MarkU
  • 14,413
  • 1
  • 34
  • 53
  • 6
    I liked the summary. I had to read THE ENTIRE 2.0 spec (over 1000 pages as I recall) over a several-week period because I had to figure all this crap out by myself. It was NOT a pleasant experience, I have to say. (Couldn't use HID in my case.) No good books on the topic, either. I ***hated*** Jan Axelson's book on USB and consider her book "almost entirely useless" for someone trying to do this work as an embedded micro from the ground up. It's actually mostly worthless, elsewise. If you know of a good book for an implementer (custom hardware), I'd be happy to hear a title!! +1 – jonk Nov 25 '17 at 07:36
  • 1
    Depending on Op's potential market the VID/PID is the largest challenge. Using Axelsons methodology works in the sense you can use her VID (which costs $3.5k for your own) and request one or more of her PID's for free. You can also request PID's from organizations like Microchip/Atmel, FTDI and TI (based on their VID). The best book IMO is Intels "USB design by example", it's a bit long in the tooth, but good for USB 2.x. Unfortunately many of the code examples break because of changes in Visual Studio through its revisions. – Jack Creasey Nov 25 '17 at 17:39
  • 1
    The best way to get access to VID/PID for hobbyist is to use LUFA (which is free): http://www.fourwalledcubicle.com/files/LUFA/Doc/130303/html/_page__v_i_d_p_i_d.html .....these cannot be used in commercial product but are good for home/demo use where you can control collisions to a large extent. – Jack Creasey Nov 25 '17 at 17:43
  • 1
    PS. A great introduction is to use the "Embedded USB design by example: that FTDI released: http://www.ftdichip.com/Support/Documents/TechnicalPublications/USBDesignByExample.htm ...this has many useful examples (based on FTDI devices of course) and all of the associated work files including use of PSOC controllers. – Jack Creasey Nov 25 '17 at 17:58
  • compare the helpfulness of the kind folks here to [that of the Software Engineering SE group](https://softwareengineering.stackexchange.com/questions/361239/usb-essentials-where-exactly-is-the-usb-spec-that-explains-what-to-do-when-cabl). $$ $$ geepers. $$ $$ thanks @MarkU for being so helpful. i will be reading, i surely hope i don't have to read the whole goddamn spec. (whatta fright!) – robert bristow-johnson Nov 25 '17 at 18:44
  • Bits me how PCB differential layout and matched length is important to OP's question. And OSI layers. – Ale..chenski Nov 25 '17 at 21:43
  • 1
    Note that if the USB device is self-powered, it must wait until the VBUS voltage is detected before applying the D+ or D- pull-up resistor. I've failed certification over this. – Adam Haun Nov 26 '17 at 05:28
4

Behavior and interaction of USB "partners" (a host and a device) is scattered across USB specification. The best way to get some grounds is to look at "device framework", Chapter 9, which describes the possible (mandated) device states (Figure 9-1), and Host (and Hub) framework, in Chapters 10 and 11. Ignoring protocol details (pipes/transaction types/abstract OSI protocol layers, PCB layout, etc.), a better grip on initial interaction can be achieved by studying the port state diagram (Figure 11-10).

In essence, if cable is not connected between host and device, the host ports are in "Powered State" (VBUS is ON), but "Disconnected". D+ and D- wires are held low with 15k pull-downs.

When the cable is connected, the VBUS goes into device. The device recognizes that it is being connected, and signals a "connect" event by pulling HIGH one of D wires, D+ if it is FS/HS device, and D- if it is LS device.

Pull on D+/- wires on a certain port gives an interrupt to host software, reporting "port status change". The host software (usually ehci.sys) then initiates "port reset" sequencing on that particular port. Upon successful completion of "USB port reset", the host port is enabled for USB communication. The port becomes active (frame packets starts flowing out).

Using USB protocol, the host assigns unique address to this device, and reads "device descriptor". This starts "device enumeration" process. The device descriptor contains information about which device class it belongs to (HID, COM, MIDI, Printer, etc.), and VID/PID of that particular device, plus a bunch of other info, see Table 9-8.

After getting the device class and VID/PID, the host software tries to match this information in device registry, and loads the corresponding DEVICE driver, either a generic one, or vendor-specific (if it exists). The device driver then finishes the enumeration process by selecting device interface ending with setting "device configuration". Obviously the entire USB communication gets recognized behind this particular port only, even if all packets are broadcasted to all enabled ports.

The above is the general framework of USB connect protocol. Packetizing data for any particular purpose (like MIDI) is a different story, and it is handled either at application level, or at device driver level, if the system get proper device class. To get native MIDI communication, the device must have this class in its descriptor and follow all MIDI class definitions.

Ale..chenski
  • 38,845
  • 3
  • 38
  • 103