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

Hice un programa simple en Visual C # que se comunica con AVR a través del chip FT232RL.

PC <-> FTDI <-> MCU.

Estoy usando FTD2XX_NET.dll para acceder directamente al dispositivo USB.

Me pregunto, ¿cuál es la diferencia entre un par de FTDI-AVR y un solo AVR con controlador USB incorporado? Creo que debe haber alguna diferencia en la velocidad de comunicación. ¿Qué más es diferente?

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

Las razones que veo y he experimentado

• La elección de los AVR con 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 me viene a la mente son los AVR habilitados para PLL.
• Aunque el periférico USB está implementado en hardware, aún necesita colocar una pila USB en el firmware. Esto consume muchos 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 livianas)
• Las interrupciones USB y los eventos del bus USB ocupan recursos que pueden alterar el firmware de tiempo crítico. Por ejemplo: las mediciones de ADC de alta velocidad pueden estropearse mucho cuando se interrumpe una tarea USB.
• No todas las implementaciones de la biblioteca 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 utiliza 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 los usuarios finales sea más engorrosa.
• Algunas implementaciones tienen un rendimiento inferior, 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 USB FTDI (generalmente cuestan más que incluso AVR de muy alta gama) 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 tener control total sobre hardware y firmware.

Hay ventajas en usar un chip USB separado y dejar 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. Entonces es difícil ignorarlo. 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 AVR simple.

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

Por el contrario, el principal beneficio de usar un AVR con un periférico USB y una pila USB incorporados es que solo hay una parte para comprar y ensamblar.

No lo he verificado recientemente, pero creo que los chips FTDI más nuevos proporcionaron una mayor velocidad de transferencia de datos USB que el USB del AVR. Sin embargo, los AVART UART fueron tan lentos que un AVR con USB es una transferencia más rápida que la combinación de FTDI (o cualquier interfaz USB) que se comunique a través del UART del AVR debido al lento AVART UART.

Editar: FTDI crea otras interfaces que UART. Por ejemplo SPI. No tengo experiencia en usarlos. Algunos AVR admiten transferencias 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, ya que los FTDI tienen amortiguadores, pero recibir podría ser "como beber de una manguera de incendios". AFAIK, tendrá que trabajar en la PC host para que funcione.

La transferencia de mayor velocidad podría ser a través de una placa secundaria Ethernet de 100 Mbits, pero no he visto mediciones de rendimiento.

Estoy feliz de usar otros microcontroladores que AVR. Por lo tanto, 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 mire el Arduin Due, o mbed, el ST mbed se llama nucelo, que es de bajo costo.