Why FTDI and not AVR with built-in USB controller?

Question

I made a simple program in Visual C# which communicates with AVR via FT232RL chip.

PC <-> FTDI <-> MCU.

I am using FTD2XX_NET.dll for direct access to USB Device.

I'm wondering, what's the difference between a pair of FTDI-AVR and a single AVR with built-in USB Controller? I think there must be some difference in communication speed. What else is different?

Answer 1

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.

Answer 2

There are advantages in using a separate USB chip, and letting the AVR communicate via its UART.

A USB stack has to respond to polling from the host PC. This happens at least every millisecond. That means that it is even more difficult to guarantee hard real-time response to events, as the MCU might get interrupted to respond to the hosts USB poll.

When there is nothing to communicate, or the MCU wants to focus fully on a real-time task, it still has to respond to some host USB polling events, or the host will 'lose' the device. So it is hard to ignore. A dedicated USB chip, like an FTDI offloads those tasks from the AVR.

A small issue is the USB stack will consume a reasonable amount of flash memory and RAM, so the chip needs more resources than a simple AVR.

Also, the two parts can be separated onto two boards, so the USB isn't a fixed cost, but might be shared across multiple boards.

On the converse side, the major benefit of using an AVR with a built in USB peripheral and USB stack is there is only one part to buy, and assemble.

I have not checked recently, but I believe the newer FTDI chips provided a higher USB data transfer rate than the AVR's USB. However, AVR UARTs were so slow that an AVR with USB is faster transfer than the combination of FTDI (or any USB interface) communicating via the AVR's UART because of the slow AVR UART.

Edit: FTDI do make other interfaces than UART. For example SPI. I have no experience using them. Some AVR's do support 9 (maybe 12) megabit SPI transfer. The FTDI is the SPI master, which isn't ideal. If the AVR is transmitting, it might be fine.as the FTDI's do have buffers, but receiving might be 'like drinking from a fire-hose'. AFAIK, you'll have to do work on the host PC to get it to work.

The highest speed transfer might be via an 100mbits Ethernet daughterboard, but I have not seen measurements of throughput.

I am happy to use other microcontrollers than AVR. So I might use something with a fast UART and a DMA controller which could move characters without CPU involvement. If that is a useful approach, maybe look at the the Arduin Due, or the mbed, the ST mbed is called nucelo which is low-cost.