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

Question

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

PC <-> FTDI <-> MCU.

Estoy usando FTD2XX_NET.dll para el acceso directo 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é otra cosa es diferente?

Answer 1

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

Las razones que veo y he experimentado

• La oferta de AVRs con USB es bastante limitada, especialmente la familia TINY. Si por alguna razón se necesita 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 AVRs con PLL.
• Aunque el periférico USB esté implementado en el hardware, todavía hay que poner una pila USB en el firmware. Esto ocupa bastantes recursos (por ejemplo, LUFA requiere al menos 6kB de flash y 1,5kB de RAM para una implementación completa de CDC, y esta es una de las bibliotecas más ligeras)
• Las interrupciones del USB y los eventos del bus del USB ocupan recursos que pueden interferir con el firmware de tiempo crítico. Por ejemplo, las mediciones de ADC de alta velocidad pueden verse muy afectadas cuando se interrumpe una tarea USB.
• No todas las implementaciones de librerías USB funcionan igual de bien con todos los AVRs con USB. Por ejemplo: Los bootloaders USB que utilizan LUFA no funcionan con los dispositivos XMEGA.
• FTDI utiliza controladores firmados que se instalan automáticamente mediante Windows Update, mientras que muchas librerías USB, por ejemplo ASF y LUFA, no lo hacen. Esto hace que el despliegue a los usuarios finales sea más engorroso.
• Algunas implementaciones tienen menor rendimiento, por ejemplo el FT2232H es capaz de puentear un FIFO a USB a 8MiB/s, lo que es imposible de hacer con un AVR.
• Muchos proyectos no tienen un 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 del USB y del microcontrolador están separadas.

Sin embargo, con las librerías USB listas para usar, el coste significativo de los puentes USB de FTDI (suelen costar más que incluso los AVRs de muy alta gama) y la ausencia de penalización en el rendimiento en la mayoría de las aplicaciones, es muy difícil justificar los chips FTDI hoy en día si se tiene un control total sobre el hardware y el firmware.

Answer 2

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 del PC anfitrión. Esto ocurre al menos cada milisegundo. Esto significa que es aún más difícil garantizar una respuesta en tiempo real a los eventos, ya que la MCU puede ser interrumpida para responder al sondeo USB del host.

Cuando no hay nada que comunicar, o la MCU quiere centrarse 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 tanto, 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 pueden separarse en dos placas, por lo que el USB no es un coste fijo, sino que podría compartirse entre varias placas.

Por otro lado, la mayor ventaja de utilizar un AVR con un periférico USB y una pila USB integrados es que sólo hay que comprar y montar una pieza.

No lo he comprobado recientemente, pero creo que los nuevos chips FTDI proporcionan una mayor velocidad de transferencia de datos USB que el USB del AVR. Sin embargo, las UART del AVR eran tan lentas que un AVR con USB es una transferencia más rápida que la combinación de FTDI (o cualquier interfaz USB) comunicándose a través de la UART del AVR debido a la lentitud de la UART del AVR.

Edición: FTDI hace otras interfaces además de la UART. Por ejemplo SPI. No tengo experiencia en su uso. Algunos AVR's soportan transferencias SPI de 9 (quizás 12) megabits. El FTDI es el maestro SPI, lo que no es ideal. Si el AVR está transmitiendo, podría estar bien, ya que los FTDI tienen búferes, pero recibir podría ser "como beber de una manguera". Según parece, tendrás que trabajar en el PC anfitrión para que funcione.

La mayor velocidad de transferencia puede ser a través de una placa hija Ethernet de 100mbits, pero no he visto mediciones de rendimiento.

Me parece bien utilizar otros microcontroladores que no sean AVR. Así que podría usar algo con una UART rápida y un controlador DMA que pudiera mover los caracteres sin la participación de la CPU. Si ese es un enfoque útil, tal vez mirar el Arduin Due, o el mbed, el ST mbed se llama nucelo que es de bajo costo.