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

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

PC <-> FTDI <-> MCU.

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?

• With the FTDI, the programmer for the AVR doesn't have to implement a USB stack but rather just UART support. There are many other differences that I don't know I'm sure, thats why I'm not answering but rather just commenting Aug 21, 2014 at 16:44
• Also FTDIs come with signed drivers for most platforms and valid hard-coded VID&PIDs so you do not have to pay for 65536 addresses when you need just one. Aug 21, 2014 at 16:49
• Thanks for comments. Other difference about performance? Which way is better for PC and MCU communication? To be honest, FTDI is MUCH easier from buil-in usb controllers. Aug 21, 2014 at 16:53
• In PC software with FTDI way, there's very low difficult functions. And i don't know if an effort with single AVR worth it Aug 21, 2014 at 16:56
• FTDI is dumb serial. A MCU can preprocess, activate side channels, support UMS, etc. Aug 21, 2014 at 16:56

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.

• Even if a project is on a microcontroller which has built in USB interface and the plan is to use that, it's still worth having a header to access the UART pins, as you can trivially get useful debug output from that while trying to get the USB code to work. Aug 21, 2014 at 17:20
• @ChrisStratton's comment points out another issue: USB devices are an order of magnitude harder to debug than simple UART serial. So it speeds development and removes unknowns to leave the USB end of things to the debugged, working FDTI chip. Obviously the economics changes with quantity, but for small production with time pressure the FDTI solution is usually better. Aug 21, 2014 at 18:47
• Wow, your tl;dr paragraph sure was a surprise ending... You trash-talked firmware-only USB/serial stacks (albeit with extremely valid points), and then BAM... "only an idiot would use FTDI". Hilarious. Loves it! Mar 8, 2016 at 18:57
• @alexgray: Wow, you're really talking in extremes there. I don't think I was trash-talking anything; these are just the typical kinds of objectives people have in product design. I've dealt with projects that optimized around pretty much all combinations of these points. For hobby projects there may be a Trump vs. Sanders approach to resolving 'do I or do I not take an FTDI RS-232 bridge?', but in real engineering you should really just objectively consider all the pros and cons and come to an optimal conclusion. Mar 11, 2016 at 8:04

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.

• as about AVR UART transfer rate, yes it's really slow... so, (to fix this) which different way exist to do communication between AVR & FTDI Chips? Now i'm in 230,4kbps in uart mode Aug 21, 2014 at 18:53
• @user3829694 - I am unsure what you mean. Ae you asking how to go faster than 230,4kbps? Or are you saying that 230,4kbps is okay for you? Aug 21, 2014 at 22:57
• I'm asking, if i want more speed what else can i do? I thinking FT245 FIFO, it can go up to 1Mbps. I'm trying to make HID projects with "real-time monitoring" just to to collect data from avr (with sensors etc) to PC form. But with UART even in max speed (230,4kbps) the transfer rate of whole buffer (256byte) it takes about 9ms: 230,4kbit = 28,8kByte = 1/28,8 = 34,722us per byte * 256byte = 8.88ms/256byte i thought this time its not good for real-time monitoring Aug 22, 2014 at 8:00
• if i want to refreshing my form every 10-100ms (sending-receiving data every 10-100ms) there's no left time for AVR to process others tasks. Aug 22, 2014 at 8:06
• @user3829694 - Okay, so you want to move the data fast, with little overhead. Aug 22, 2014 at 9:34