¿Por qué FTDI y no AVR con controlador USB incorporado?

Hay bastantes razones, pero son, al menos para la mayoría de las personas, bastante especializadas.

Las razones que veo y he experimentado

• La elección de los AVR habilitados para USB es bastante limitada, especialmente la familia TINY. Si por alguna razón se requiere un AVR que no tenga una combinación de USB y algún otro periférico, esta es una opción fácil. Un ejemplo que viene a la mente son los AVR habilitados para PLL.
• A pesar de que el periférico USB está implementado en hardware, aún necesita poner una pila USB en el firmware. Esto requiere una gran cantidad de recursos (por ejemplo, LUFA requiere al menos 6kB flash y 1.5kB RAM para una implementación completa de CDC, y esta es una de las bibliotecas más ligeras)
• Las interrupciones de USB y los eventos del bus USB consumen recursos que pueden interferir con el firmware crítico para la sincronización. Por ejemplo: las mediciones de ADC de alta velocidad pueden ensuciarse mucho cuando se interrumpe una tarea de USB.
• No todas las implementaciones de bibliotecas USB funcionan tan bien con todos los AVR habilitados para USB. Por ejemplo: los cargadores de arranque USB que usan LUFA no funcionan con dispositivos XMEGA.
• FTDI usa controladores firmados que se instalan automáticamente con Windows Update, mientras que muchas bibliotecas USB, por ejemplo, ASF y LUFA, no lo hacen. Esto hace que la implementación para usuarios finales sea más complicada.
• Algunas implementaciones tienen un rendimiento más bajo, por ejemplo, FT2232H puede conectar un FIFO a USB a 8MiB / s, lo que es imposible de hacer con un AVR.
• Muchos proyectos no tienen control total sobre el hardware y el software, por ejemplo, Las impresoras 3D tienen proyectos de hardware y proyectos de firmware completamente separados. Para mantener el nivel de interoperabilidad lo más alto posible, las funciones de USB y microcontrolador están separadas.

Sin embargo, con las bibliotecas USB listas para usar, el costo significativo de los puentes FTDI USB (generalmente cuestan más que los AVR de muy alta calidad) y no hay penalización de rendimiento en la mayoría de las aplicaciones, es muy difícil justificar los chips FTDI hoy en día, si tiene control total sobre hardware y firmware.

Hay ventajas en usar un chip USB separado y permitir que el AVR se comunique a través de su UART.

Una pila USB tiene que responder al sondeo desde la PC host. Esto sucede al menos cada milisegundo. Eso significa que es aún más difícil garantizar una respuesta dura en tiempo real a los eventos, ya que la MCU podría interrumpirse para responder a la encuesta USB del host.

Cuando no hay nada que comunicar, o la MCU quiere enfocarse completamente en una tarea en tiempo real, todavía tiene que responder a algunos eventos de sondeo USB del host, o el host "perderá" el dispositivo. Por eso es difícil de ignorar. Un chip USB dedicado, como un FTDI, descarga esas tareas del AVR.

Un pequeño problema es que la pila USB consumirá una cantidad razonable de memoria flash y RAM, por lo que el chip necesita más recursos que un simple AVR.

Además, las dos partes se pueden separar en dos tarjetas, por lo que el USB no es un costo fijo, sino que se puede compartir en varias tarjetas.

En el lado inverso, la principal ventaja de usar un AVR con un periférico USB y una pila USB integrados es que solo hay una parte para comprar y ensamblar.

No lo he comprobado recientemente, pero creo que los nuevos chips FTDI proporcionaron una tasa de transferencia de datos USB más alta que la del AVR. Sin embargo, los UART AVR fueron tan lentos que un AVR con USB es más rápido que la combinación de FTDI (o cualquier interfaz USB) que se comunica a través de la UART del AVR debido a la UART AVR lenta.

Editar: FTDI hace otras interfaces que UART. Por ejemplo SPI. No tengo experiencia en usarlos. Algunos AVR admiten la transferencia SPI de 9 (quizás 12) megabits. El FTDI es el maestro SPI, que no es ideal. Si el AVR está transmitiendo, podría estar bien. Los FTDI sí tienen búferes, pero la recepción podría ser "como beber de una manguera de bomberos". AFAIK, tendrá que trabajar en la PC host para que funcione.

La transferencia de velocidad más alta podría a través de una tarjeta hija de 100 Mbits Ethernet, pero no he visto mediciones de rendimiento.

Estoy feliz de usar otros microcontroladores que no sean AVR. Así que podría usar algo con un UART rápido y un controlador DMA que podría mover personajes sin la participación de la CPU. Si ese es un enfoque útil, quizás vea el Arduin Due o el mbed, el ST mbed se llama nucelo, que es de bajo costo.