Can anyone explain how device drivers work? I have seen Arduino and other development boards communicating with the PC's USB port with the help of a FTDI chip. This thing can be made to work after we install the device driver. So, what's the role of the FTDI chip and the driver here? Why can't we do this job without a FTDI chip, directly connecting the Atmel MCU(I have worked with AVR MCUs only) and having some proper driver for it.
Electronic – How device drivers work
deviceftdiusb
Related Solutions
At my last company we found that USB-to-RS-232 converters can have a problem when they expect an almost instant responce from the RS-232 device. I was advised by the design engineer for our equipment that USB uses data packets. So when using USB, unless the software/drivers force a USB packet of data to be sent, the USB driver can hang around for more than a second (5000 ms) waiting for the packet to be filled before sending the incomplete data packet.
This meant that a lot of older DOS/Windows programs where they monitored RS-232 status lines would time out. The older programs often used timing loops based on looping a certain number of times... So as the PCs got faster, the polling got faster. As the length of time the polling continued to effectivly get shorter, USB came along.
The polling effectively became a memory location... (The drivers are usually optimised for maximum data packet throughput and didn't pass the status information on, because it was waiting to fill a packet). The drivers can sometimes be adjusted to help with this. FTDI drivers can adjust a lot of values in their configuration file. (Great for non-standard data rates.)
This meant we often had to run programs on desktops with RS-232 ports or drag the laptop base station out to the equipment to get it to work.
Additional information
See page 6 of the application note Advanced Driver Options for USB time out adjustments...
And for odd baud rates up to 3 Mbit/s, see Configuring FT232R, FT2232 and FT232B Baud Rates.
There are quite some reasons, but they are, at least for most people, fairly niche.
The reasons that I see and have experienced
- The choice in USB enabled AVRs is quite limited, especially the TINY family. If for some reason an AVR is required that does not have a combination of USB and some other peripheral, this is an easy option. One example that springs to mind is PLL-enabled AVRs.
- Even though the USB peripheral is implemented in hardware, you still need to put a USB stack in firmware. This takes up quite a lot of resources (e.g. LUFA requires at least 6kB flash and 1.5kB RAM for a full CDC implementation, and this is one of the most lightweight libraries)
- USB interrupts and USB bus events take up resources that can mess with timing-critical firmware. For instance: high-speed ADC measurements can get messed up very badly when a USB task interrupts.
- Not all USB library implementations work as well with all USB-enabled AVRs. For example: USB bootloaders using LUFA do not work with XMEGA devices.
- FTDI uses signed drivers that automatically install using Windows Update, whereas many USB libraries, for instance ASF and LUFA, do not. This makes deployment to end-users more cumbersome.
- Some implementations have lower performance, for instance FT2232H is able to bridge a FIFO to USB at 8MiB/s, which is impossible to do with an AVR.
- Many projects do not have full control over hardware and software, e.g. 3D printers have completely separate hardware projects and firmware projects. In order to keep the level of interoperability as high as possible, USB and microcontroller functions are separated.
However, with ready-to-use USB libraries, the significant cost of FTDI USB bridges (they usually cost more than even very high-end AVRs) and no performance penalty in most applications, it is very hard to justify FTDI chips nowadays if you have full control over hardware and firmware.
Best Answer
The FTDI chip connects on one side via a USB interface to a PC, and on the other presents a UART interface to the microcontroller; to the latter it looks as if a RS232 cable had been plugged into the device through an RS232-UART level shifter.
This has two advantages. On the PC side, the USB interface becomes a virtual COM port, which makes it easier for programs to communicate with it, since they don't need to go through a special USB driver -- they just have to talk to the COM port, and are thus not even aware a USB port is involved at all and do not need to have code to talk to a special USB driver.
Normally the driver for the FTDI chip doesn't need to be installed -- since thee are so many devices using variations of the FTDI chip, the newer versions of Windows and Linux come with an USB/FTDI driver already built-in.
On the microcontroller side, the same is true -- instead of having to write software to function as a USB device (assuming the microcontroller even has a USB port), the firmware program in the microcontroller only has to deal with interfacing with the UART which is much easier. So at both ends, the PC and the microcontroller, the software thinks there is an RS232 cable between the PC and the board, and is not aware at all there is a USB cable instead.
If an FTDI chip is not used, and the microcontroller has a USB interface, then a USB cable can be connected directly between the microcontroller cable and the PC. One can then write firmware on the microcontroller to present a USB "device" interface to the PC. (This is in contrast to USB "host" interface, which would be used for example if a USB device such as a memory stick or mouse was plugged into the microcontroller.)
If possible, programmers writing this sort of firmware try to make use of the HID (human interface device) interface, which was initially intended to be used by devices like keyboards and mice. However since the USB HID driver is always included in the OS (otherwise your keyboard wouldn't work when booting!), it never needs to be loaded, and it is relatively easy to write software on the PC to interface with it.
The most difficult situation is where a special USB protocol is needed. This makes life much more complicated for both the firmware (microcontroller side) and software (PC side) implementers. When the USB device is plugged in and enumerated, the OS (Windows or Linux etc.) will be unable to find a built-in driver for it. So the software for the device must include a special USB driver, which the user will have to install before using the device.