Microcontroller – Do You Need to Program a USB Communication Protocol?

embeddedmicrocontrollerprogrammingusb

I have usb communication set up between a microcontroller I have and a VB.Net script. I am somewhat familiar with how the USB protocol works.

My question is: Do I need to program in start frames, tokens, and handshaking, or is this all done by the device hardware? I see on Microsoft's vb wiki that the serialport.Readline method reads a buffer up to the first new line character, and to me that looks like it does more than the USB protocol allows for. You shouldn't be able to continuously stream data to the port, it should be sent discretely in frames.

Thanks in advanced.

Best Answer

Like any protocol stack, USB incorporates components representing various layers. High-level drivers and libraries provide higher-layer functionality on top of lower layers, effectively abstracting those lower layers away and out of sight.

In the case of USB, there are a number of so-called device classes which provide standardized interfaces on top of USB, with a coordinated protocol on the host side (implemented by a driver or a stack of drivers) and on the peripheral side (implemented by firmware or drivers). Examples of these device classes include HID devices like keyboards/mice, mass storage devices such as flash drives, image storage using PTP/MTP, and so on. These abstract away the USB protocol - for example, the FAT filesystem driver used to mount a flash drive sees a block storage device and doesn't need to worry about USB framing, packetization, etc, thanks to the USB drivers lower in the stack.

In your case, the relevant class is USB CDC (Communications Device Class). The CDC drivers present a serial port to user-land programs on your computer, which can read and write a stream of data. Meanwhile, the CDC driver will do the work of converting a stream of serial bytes and control signals into USB packets, and it will receive help from the underlying USB drivers down the stack for even lower level tasks such as establishing pipes to endpoints.

Because the specification is standardized, you benefit from knowing that your application on top of USB CDC should work regardless of what vendor your CDC-compatible device is from (as long as they follow the spec), because your system's drivers are likely implemented to the spec1.

Meanwhile, your application can use the serial port without needing to worry about what physical hardware underpins it. It could be serial over USB, it could be a nine-pin D-sub connector serial port implemented with a UART on your motherboard's IO controller, it could be a virtual serial port on Linux, or it could perhaps be a serial link on top of TCP/IP.

1 or more loosely, to give leeway for devices that may not follow the spec exactly.

Related Topic