How exactly does USB integration work from the micro controller end?

Question

I have no prior USB integration and about 8 months of learning embedded systems on Atmel devices. I am trying to use an Atmel SAM L series to connect over USB to a computer. The use case is for data transfer. Specifically, the MCU will be gathering data from it's sensors and packaging it for USB transfer.

I have searched through and read up on all of Atmel's included USB examples. I have also started reading through usb.org's class specifications for CDC.

I have running now something that lets me send data along one com port, into the target usb and then out the debugger usb to another com port. However, I don't think this is real USB.

My problem is two fold.

1. I do not fully understand what differentiates USB from serial communication on a com port.
2. Even if I were doing it correctly, I'm not sure how to test and verify that I have indeed created a legitimate USB device that can be accepted by a host computer.

Links to documentation(Atmel or generic) or example code would be appreciated.

Answer 1

A regular com port is a very 'close to the metal' communication hardware and protocol.

USB is significantly more complicated. There are strict requirements on timing, who talks when, addressing, and a variety of other aspects. It is so complicated there exist entire companies who's main job is hiding that complexity with specialized ICs, such as FTDI.

An advantage of that complexity is that you have both an in-band and out-of-band communication with your USB devices. With com ports, the only way I can tell if a device is present is to ping all devices, try talking to them, and determine if any are there, a process that may take a fair amount of time. With USB, all of that stuff is defined in the standard, and I can ask the USB controller what all is hooked up, and make my decision almost instantly.

The CDC device is an abstraction over USB to allow communication over USB using software that predates USB or that wants to just use the mature and available Serial Port libraries. Other device classes, and custom devices, use different communications schemes within the design of USB to implement their communication.

As for your second question, "legitimate" can have a variety of meanings, but if you can send bytes and get responses in an expected fashion, your device works and you're good to go, and it's "real USB". If you want a certified USB device there are many other hoops to jump through and qualifications to meet that are too broad to cover here.

When people implement USB on an embedded project they do one of two things: they either use one of the mentioned ICs earlier, or they have to implement the entire USB stack on their microcontroller. Perusing the source to Atmel's samples or the open USB stacks should give you a clue as to how enjoyable an experience that is.