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

8

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?

MrBit
fuente
2
Con el FTDI, el programador para el AVR no tiene que implementar una pila USB, sino solo el soporte UART. Hay muchas otras diferencias que no sé, estoy seguro, es por eso que no estoy respondiendo sino simplemente comentando
Funkyguy
1
Además, los FTDI vienen con controladores firmados para la mayoría de las plataformas y VID y PID válidos codificados para que no tenga que pagar por 65536 direcciones cuando solo necesita una.
venny
Gracias por los comentarios Otra diferencia sobre el rendimiento? ¿Qué manera es mejor para la comunicación de PC y MCU? Para ser honesto, FTDI es MUCHO más fácil de los controladores usb incorporados.
MrBit
En el software para PC con modo FTDI, hay funciones difíciles muy bajas. Y no sé si vale la pena un esfuerzo con un solo AVR
MrBit
1
FTDI es una serie tonta. Una MCU puede preprocesar, activar canales laterales, admitir UMS, etc.
Ignacio Vazquez-Abrams

Respuestas:

11

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.

usuario36129
fuente
2
Incluso si un proyecto está en un microcontrolador que tiene una interfaz USB incorporada y el plan es usarlo, vale la pena tener un encabezado para acceder a los pines UART, ya que puede obtener trivialmente una salida de depuración útil al intentar obtener el USB código para trabajar.
Chris Stratton
44
El comentario de @ ChrisStratton señala otro problema: los dispositivos USB son un orden de magnitud más difícil de depurar que el simple serial UART. Por lo tanto, acelera el desarrollo y elimina las incógnitas para dejar el extremo USB de las cosas al chip FDTI depurado y funcional. Obviamente, la economía cambia con la cantidad, pero para una producción pequeña con presión de tiempo, la solución FDTI suele ser mejor.
markrages
Wow, tu tl;drpárrafo seguro fue un final sorpresa ... Has descartado pilas de USB / serie solo de firmware (aunque con puntos extremadamente válidos), y luego BAM ... "solo un idiota usaría FTDI". Divertidísimo. ¡A él le encanta!
alex gray
@alexgray: Wow, realmente estás hablando en extremos allí. No creo que estuviera hablando nada mal; Estos son solo los tipos típicos de objetivos que las personas tienen en el diseño de productos. He tratado con proyectos que se optimizan en torno a casi todas las combinaciones de estos puntos. Para los proyectos de pasatiempo, puede haber un enfoque de Trump vs. Sanders para resolver '¿tomo o no un puente FTDI RS-232?', Pero en ingeniería real, realmente debería considerar objetivamente todos los pros y los contras y llegar a un Conclusión óptima.
user36129
4

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.

gbulmer
fuente
en cuanto a la velocidad de transferencia AVR UART, sí, es realmente lenta ... entonces, (para solucionar esto) ¿qué forma diferente existe para hacer la comunicación entre AVR y FTDI Chips? Ahora estoy en 230,4kbps en modo
uart
@ user3829694 - No estoy seguro de lo que quieres decir. ¿Estás preguntando cómo ir más rápido que 230,4 kbps? ¿O estás diciendo que 230,4 kbps está bien para ti?
Gbulmer
Estoy preguntando, si quiero más velocidad, ¿qué más puedo hacer? Creo que FT245 FIFO puede subir hasta 1Mbps. Estoy tratando de hacer proyectos HID con "monitoreo en tiempo real" solo para recopilar datos de avr (con sensores, etc.) en forma de PC. Pero con UART incluso en la velocidad máxima (230,4 kbps), la velocidad de transferencia de todo el búfer (256 bytes) tarda aproximadamente 9 ms: 230,4 kbits = 28,8 kByte = 1 / 28,8 = 34,722us por byte * 256bytes = 8,88 ms / 256bytes, pensé que esta vez no es bueno para el monitoreo en tiempo real
MrBit
si deseo actualizar mi formulario cada 10-100 ms (envío y recepción de datos cada 10-100 ms) no hay tiempo restante para que AVR procese otras tareas.
MrBit
@ user3829694 - Bien, entonces quieres mover los datos rápidamente, con poca sobrecarga.
Gbulmer