/ Serial

Why I use native USB and not a USB-UART Bridge

The USB protocol has grown to be widely accepted over the years because of ease of use, speed and its versatility in functions. The part I love most about USB is the descriptors. Using them I can change a device's functionality without a single change in hardware. The same port supporting your mouse can support you keyboard, camera etc.

Today if you buy a Logitech wireless products like the T400 mouse and the K360 keyboard, they both come with their own dongles. But if you do not have enough USB ports or do not want to use an external hub, you could configure any of those dongles to connect with both your wireless keyboard and mouse using only one dongle/port. Of course, Logitech has added their extra functionality to detect available wireless devices.

Using USB, our smartphones can behave multiply with options like Camera (PTP), Media devices (MTP), Mass storage devices like a flash (MSD) and more. If you connect a new Android device to your computer it most likely will appear as MTP or MSD, but if you switch on developer options the device gets another definition and immediately, you are informed of the new features.

In both these cases, you do not even need to reboot your device(s).

Most hobbyists mostly use USB to UART bridges, commonly FTDI232x, PL2303 and CP2012 among others. What if the data you want to transmit needs to be transmitted in a faster way than 115,200 or 230,400 baud. Consider the speeds using this graphic.

Image for speed

This is the reason I use USB. But using it is not the easiest task to accomplish. You need to concentrate on the USB stack, especially for power/memory-constraint devices. In other cases getting your driver to work properly on the host. At times when am not careful, it ended up taking most of the RAM and FLASH space available on my micro-controller. In such cases, I still had to use the UART bridge coupled with the standard C file I/O to retarget printf operations to my serial output. But when it comes to transferring of data for the final product or for a large data-log or something like an image, I use native USB. However, it is worth to note that most, not all chip manufacturers whose chips have inbuilt USB peripherals, provide free examples for their devices.

But with USB comes drivers. The confusion about KMDF and UMDF on Windows is another reason that keeps people off this area save for the fact that you will write it in C/C++.The history of Windows crashing or not booting due to driver issues is another reason. Thankfully, the USB organization defined a convenient class which you most likely use. They called it Human Interface Device (HID). Your mouse, keyboard, joystick and similar devices operate using this class. Most hobbyists and engineering students use programs built on the same. This class of devices does not need new drivers other than the ones that ship with the operating system, at least for Windows, Mac OS X and Linux.

Now the drivers' problem is down both for the device and operating system.
In upcoming posts, I will handle how to setup USB HID and also separately extending report beyond 64bytes on USB 2.0