La-Tecnología
ARM
Velocidades de transferencia USB de referencia

Velocidades de transferencia USB de referencia

[Paul Stoffregen], Creador de la serie Teensy de programadores de microcontroladores, notó recientemente muchos proyectos que conducen a enormes matrices de LED y decidió considerar la rapidez con la que los programadores de microcontroladores pueden obtener datos de una computadora. Más bits por segundo significa LED más brillantes, por supuesto, por lo que sus esfuerzos de comparación ciertamente tendrán éxito con cualquiera que planee proyectos de microcontroladores a gran escala.

Los microcontroladores [Paul] probados incluyeron Teensy 2.0, Teensy 3.0, Leonardo y Due Arduinos, y Fubarino Mini y Leaflabs Maple. Estos se probaron en Linux (un CD en vivo de Ubuntu 12.04), OSX Lion y Windows 7, todos con MacBook Pro 2012. Cuando no consideras Teensy 2.0 y 3.0, los resultados de la prueba fueron los que esperabas: dispositivos más rápidos podrían obtener más bytes por segundo. Sin embargo, cuando los Teensys se incorporaron a la mezcla, los resultados cambiaron drásticamente. El Teensy 2.0, con el mismo microcontrolador que el Arduino Leonardo, pudo superar todas las placas excepto el Teensy 3.0.

[Paul] También trató de evaluar los diferentes sistemas operativos que utilizaba. A continuación, si transfieres muchos bytes a la vez, realmente no importa qué sistema uses. Para transmitir pequeñas cantidades de datos, es posible que desee utilizar OS X. Windows es increíble para transmitir bytes individuales; en un byte para la transmisión, Windows solo administra 4kBps. Con la misma tarea, Linux y OS X gestionan aproximadamente 53 y 860 (!) KBps, respectivamente.

Así que aquí tienes. Si está construyendo una gran matriz de LED, use Teensy 3.0 con una MacBook. Por supuesto [Paul] creó todo el código para sus fuentes abiertas de referencia, así que repita este experimento.

Chris dice:
¡Completamente asombroso! Acabo de actualizar un proyecto a ATMega32U4 y tenía curiosidad por lo mismo.
Starbucks dice:
Con el soporte USB nativo, no me sorprende que Teensy patee tanto traseros. Todo lo demás está limitado por un deber a TTL serial-> USB y presumiblemente bloqueado a una velocidad de 115200 bits. Amo a mis adolescentes.
- baobrien dice:
  El STM32 en Maple al menos tiene USB nativo, solo está configurado como una serie virtual de libMaple y wirish. Estoy seguro de que si usara las capacidades USB directamente, sería más rápido.
  - baobrien dice:
    De hecho, parece que todo el mundo tiene USB directamente al MCU.
wieland dice:
No quiero llamar "eso es una mierda" pero ... ya sabes.
Si tiene una MCU con hardware nativo y todavía usa USB-CDC para transmitir datos, es una prueba casi sólida de que es tonto.
Usando una clase USB personalizada (SÍ, eso * incluye * leer y comprender USB y lleva su elegante proyecto de cubo LED soldando dos LED a un proyecto en el que necesita pensar), puede lograr velocidades de transferencia mucho más altas con menos código en el MCU.
- wieland dice:
  Como referencia: logré acercarme a 3 MB / s mediante transferencias masivas en XMega. Por supuesto, sin algunas de esas cosas de Arduino.
  - Paul Stoffregen dice:
    ¿Está apuntando a 3 megabytes / segundo o 3 megabytes / segundo?
    3 megabytes / segundo sería bastante increíble, ya que los chips XMega tienen USB de 12 Mbit / seg, que tiene una velocidad de cable sin procesar de solo 1,5 megabytes / seg. la sobrecarga adicional dependiente de los datos del algoritmo bit a bit).
    3 megabits / segundo serían 375000 bytes / seg. Eso es bastante bueno, aproximadamente en el medio del rango de las 6 tablas que probé.
    - omegacs dice:
      FWIW con mi propia pila (IMO LUFA es desordenado y ASF es aún peor), obtuve un cabello de menos de 10 Mbps (~ 1.1 MB / seg) con lecturas masivas del Xmega, muchas preguntas pendientes del host, pero ninguna ping - pong en la MCU (paquetes vacíos, por lo que no hay pérdidas significativas).
- NsN dice:
  Una gran ventaja de USB CDC es la facilidad de uso. Además de Win 8, requiere un juego mínimo con controladores, es compatible con casi cualquier lenguaje de programación y tiene excelentes herramientas para inspeccionar, registrar y manipular datos.
  Una vez que haya configurado su biblioteca (usando lufa, eso es bastante fácil), es trivial de usar y hacerlo correctamente para mantener velocidades que deberían ser suficientes para la mayoría de las aplicaciones.
  Claro, si tiene un proyecto grande con software de soporte personalizado en el host, grandes cantidades de datos y límites rápidos, elija un dispositivo personalizado, pero en mi opinión, la interfaz serial sigue siendo el idioma francés de la electrónica doméstica. mundo.
- cazador dice:
  Nunca subestime la utilidad de los controladores disponibles. CDC-ACM se puede encontrar tanto en Windows como en Linux, no se limita rápidamente y es bastante simple.
  Entonces, sí, uso CDC-ACM, escribí código para CDC-EEM (modelo de emulación de Ethernet). Ambos son simples, ambos tienen controladores fácilmente disponibles y podrían controlarse con herramientas estándar (una gran ventaja en mi opinión). No confío en mi capacidad para escribir un buen código de bajo nivel, por lo que dejo la escritura de controladores o problemas de soporte a quienes lo hacen, y prefiero terminar la tarea en lugar de depurar el código útil del controlador / complemento durante años.
  Ignorando una clase USB estándar existente, que tiene controladores, eso es tonto en mi opinión. En mi opinión, elegir una solución no estándar en caso de protocolos debería ser un último recurso y no el resultado de un síndrome de "no inventado aquí, por lo que es tonto".
  - mike hage dice:
    ¿Puede compartir el código CDC-EEM?
  - Jordán dice:
    También me interesaría el código CDC-EEM. ¿Puedes compartirlo?
servicial dice:
si la constelación transmite solo a 11k. ¿Por qué se conecta a 1500000 en un minicom a través del puerto de depuración?
minicom -D / dev / ttyACM0 -b1500000
Se relaciona y se transfiere bien a pesar de que no hice un punto de referencia real.
- servicial dice:
  También debe establecer la velocidad del puerto en su código.
  UARTStdioInitExpClk (0,1500000);
- Paul Stoffregen dice:
  ¿Por qué no hace una referencia real? He publicado todo el código, por lo que puede hacerlo con bastante facilidad. El puerto de depuración en esa placa Launchpad parece estar conectado a través de hardware UART, por lo que 1500000 baudios deberían dar una velocidad de 150000 bytes / seg, que sería al menos más rápida que las 2 placas más lentas de la prueba.
  - servicial dice:
    Así que compilé y ejecuté su programa y lo conseguí.
    puerto / dev / ttyACM0 abierto
    ignorando el inicio del almacenamiento en búfer ...
    ignorando el inicio del almacenamiento en búfer ...
    ignorando el inicio del almacenamiento en búfer ...
    ignorando iniciar almacenamiento en búfer ...
    ignorando el inicio del almacenamiento en búfer ...
    Bytes por segundo = 11516
    Bytes por segundo = 11516
    Bytes por segundo = 11516
    Bytes por segundo = 11516
    Bytes por segundo = 11527
    Bytes por segundo = 11516
    Bytes por segundo = 11516
    Bytes por segundo = 11516
    Bytes por segundo = 11516
    Bytes por segundo = 11527
    Bytes por segundo = 11515
    Bytes por segundo = 11516
    Bytes por segundo = 11516
    Bytes por segundo = 11516
    Bytes por segundo = 11527
    Bytes promedio por segundo = 11518
    ¿Es esta toda la velocidad que obtengo?
    - servicial dice:
      he cambiado
      #define BAUD 115200
      Alabama
      #define BAUD 1500000
      y corrí a hacer
      entonces lo tengo
      Bytes promedio por segundo = 64101
      - Paul Stoffregen dice:
        Si está probando Stallaris o cualquier otra placa que implique una conexión en serie de dispositivo entre 2 chips, mida la frecuencia en el pin 2 durante la prueba. Si obtiene una medición significativamente diferente en el pin 2 (que indica la velocidad recibida de kbit / segundo) que la velocidad informada en su computadora (que indica la velocidad de transmisión de kbit / segundo), entonces el búfer en serie se anula. Una serie de hardware ordinaria no necesariamente tiene un control de flujo de extremo a extremo como USB, por lo que es realmente importante medir la velocidad en ambos lados. Puse ese código en la referencia para activar el pin 2 exactamente por esa razón, para que se pueda controlar la velocidad en ambos lados del enlace.
Jurgen dice:
Tal vez no entiendo el punto principal de esto en relación con impulsar grandes matrices de LED. ¿Por qué querría hacer eso a través de USB? Para pantallas pequeñas, ciertamente no hay problema. Para pantallas más grandes, probablemente optaría por FPGA para convertir la salida de video digital de una computadora / Mac para controlar la matriz de LED. Las pantallas de gran formato probablemente requieran varias zonas de actualización independientes para mantenerse al día con las actualizaciones rápidas. Quizás solo estoy pensando en un objetivo de proyecto diferente al de la publicación original.
- Zac dice:
  es posible que no desee utilizar usb para tabletas grandes, pero otras podrían hacerlo. pasar de usb a fpga es un gran paso que tiene una curva de aprendizaje pronunciada.
Brad australiano dice:
El ChipKit Max32 puede admitir velocidades USB de hasta 3 Mbs, lo uso para manejar una tira de LED RGB 2800
Simoninns dice:
Yo diría que el titular de HaD es un poco engañoso, ya que el punto de referencia es claramente solo para USB CDC (serie virtual), que no está diseñado para la transmisión de datos al por mayor de alta velocidad (y también las comparaciones del sistema operativo son solo en serie en lugar de USB en general). USB admite otros protocolos (muchos de los cuales son compatibles con la biblioteca USB LUFA), que ofrecen velocidades de transferencia mucho mejores. Si desea controlar una matriz de LED grande, usar un CDC es una mala opción de implementación para comenzar con en mi humilde opinión. Un cordial saludo a Paul por publicar las pruebas y los resultados, como parte de Virtual Serial via USB son muy interesantes.
- Paul Stoffregen dice:
  La serie CDC utiliza un protocolo de transmisión masiva USB. De hecho, después de alguna configuración con transferencias de control para parámetros seriales, casi solo asigna las operaciones de E / S a las operaciones de venta al por mayor de USB. En Macintosh, el controlador obviamente hace algunas cosas inteligentes para combinar pequeños scripts. Linux solo parece transmitir sus lecturas y scripts como grandes transmisiones de protocolo al chip controlador del host. ¿Quién sabe qué hace que Windows sea tan lento?
  No asumiría necesariamente que LUFA sea rápido. Hasta que no se tomen buenas medidas, nadie lo sabe realmente. LUFA ciertamente tiene MUCHO código realmente complejo que podría construirse cuidadosamente para mejorar su velocidad, o quizás sintácticamente azúcar que es mejorado por el ejecutante, o que puede atraer mucha parte superior.
  - Simoninns dice:
    Haces algunos puntos válidos, Paul. Aunque todavía diría que CDC no es el camino a seguir (para aplicaciones como la unidad de matriz LED) porque puede superar a la luz del host y del dispositivo, optimizando ambos lados en términos del tamaño de los datos que transmite. Con CDC, confía en el sistema operativo host para adivinar el tamaño de bloque correcto para usted (lo que probablemente explica la gran diferencia de velocidades según la cantidad de datos que transmita). CDC también significa que pasa por el código de interfaz del puerto serie del sistema operativo, que puede o no estar optimizado para el mayor rendimiento disponible a través de USB y agrega más código de acuerdo con el IO. Sin embargo, me interesaría ver una referencia de LUFA CDC.
    - Paul Stoffregen dice:
      Su punto es que CDC depende del controlador de host. Por eso traté de probar los 3 hosts diferentes con 3 tamaños de fuente diferentes. Seguramente podría crear mejor una solución completamente personalizada tanto en el host como en el dispositivo que requiera MUCHO trabajo. ¡Pero mire lo bien que el controlador de Mac maneja pequeños scripts! Si sus datos son naturalmente muchos mensajes pequeños, creo que tendrá que trabajar muy, muy duro para obtener algo que funcione como CDC con el controlador de Apple con Teensy3 y una programación extremadamente fácil en Arduino. Nuevamente, si está apuntando a Windows, el controlador es tan malo que realmente está trabajando duro para usar scripts grandes o desarrollar una solución completamente personalizada.
      También me gustaría ver a alguien ejecutar esta referencia en LUFA. Obviamente, LUFA no puede lanzar mis bocetos de Arduino, pero tal vez alguien podría llevar mi código a LUFA y probarlo con el código de host que publiqué.
octava dice:
¡Teensy es simplemente increíble!
gezedo dice:
Usando el mismo chip que un Arduino DUE (Atmel SAM3U) en una computadora normal, obtuve 30 MB / s (sí, megabytes) usando CDC ACM Linux por otro lado. Estoy bastante seguro de que puedo obtener un rendimiento adicional del 30 al 50% optimizando ambos extremos de la conexión USB.
Este chip ATMEL tiene un (asombroso) USB 2.0 HS (480Mb), mientras que la mayoría de los demás solo tienen un USB 2.0 FS (12Mb), esa es la diferencia.
- DJ_MIB dice:
  Puedo respaldar esta afirmación porque he encontrado tasas de bits similares con mis placas ATMEL (la mayoría de los microcontroladores que he probado cumplen con el estado USB 2.0 pero solo implementan Full Speed 12Mbit). Por lo general, uno tiene que obtener un chip USB separado como Cypress EZ-USB FX2 o FTDI FT2322H para obtener esos dulces datos USB de alta velocidad.
  Dicho esto, me gustan mucho las implementaciones de puertos COM virtuales porque están integradas en la mayoría de los sistemas operativos y, por lo tanto, no requieren controladores especiales y se pueden crear en casi cualquier proyecto de software que realmente no necesite esa cantidad de datos.
- Folts dice:
  En mi antiguo empleador (HCC-Embedded) pudimos obtener ~ 20-25 MiB / s mediante almacenamiento masivo conectado a ramdrive en microcontroladores con capacidad de alta velocidad.
  Se puede lograr una velocidad similar con CDC, aunque Windows (XP y Win7) ha insertado grandes espacios entre las transferencias. Principalmente debido al tamaño de los búferes del lado del núcleo (64 KB para almacenamiento masivo y ~ 16 KiB para CDC).
  El almacenamiento masivo fue probado por dd (cygwin) con un tamaño de bloque de 2M. CDC se probó con una copia (copy data.bin COMx).
Paul. dice:
Algunos de los micrófonos Cypress tienen un dispositivo lateral USB que puede manejar al menos 24 MBytes / s. Saleae construyó un analizador lógico (24 Msps, 8 canales) alrededor de este chip. Estos chips + computadora + carcasa + conector usb + búfer 74HCxx se venden por menos de USD10 en ebay / aliexpress.
http://sigrok.org/wiki/File:Mcu123_saleae_logic_clone_pcb_top.jpg
Por ahora, todavía estoy un poco forzado para comenzar un zig-zag.
- Paul Stoffregen dice:
  Ese chip de ciprés impresiona. De hecho, hay muchos chips USB increíbles en el mercado. Pero, ¿pueden ejecutar bocetos de Arduino y bibliotecas de Arduino, y esta referencia que muestra la velocidad que obtiene utilizando una programación sencilla al estilo de Arduino?
  - Remy Dyer dice:
    “Ese Chip Cypress” es la serie fx2, ¿y tanto como una parecida a Arduino? INFIERNO NO.
    Son una bestia de tres cabezas con complejidad, con una cabeza la interfaz USB 2.0 personalizable, la otra es una máquina de estado programable que puede llegar al mundo exterior hasta 48 MHz, 16 bits (¡96 MB / s!), Y el ¿tercera? Un microcontrolador 8051 "mejorado", von no tripulado, que necesita ser programado para luego configurar los otros dos "cabezales".
    Solo para confundir las cosas (¡MUCHO!) Estos chips tienen un firmware preprogramado incorporado. Algunos de estos firmware se ocupan de parte del protocolo de solicitud USB, y es bastante fácil pensar que tienes control total sobre él, aunque en realidad parte del código original todavía funciona ... Sin embargo, esta característica también hace que estos chips sean "inmanejables" porque Siempre se puede desconectar o acortar temporalmente el chip eeprom mientras se conecta, para forzar la condición original del firmware.
    Existe una versión de este chip que puede hablar con voltajes más bajos (hasta ~ 1.8V) que elimina esta característica, pero solo está disponible en BGA de 56 pines. (también tenga en cuenta: el pin ifclk siempre se ejecutará a 3.3v si se configura como salida de reloj; también maté mi ButterflyOne).
    Con mucho, los paquetes de desarrollo más puros para esto son zpl de ztex.de: venden algunas placas con fx2 + fpga y ram.
    (La RAM es mucho más necesaria de lo que pensaría si quisiera un ancho de banda duradero).
    Lo mejor que realmente podrá obtener (suponiendo que vaya a ejecutar una gran cantidad en el drama) es de aproximadamente 30 a 40 MB / s. También asumiendo que está utilizando uno de los mejores concentradores raíz de Intel, bajo linux, con el programa “fx2pipe” que escribió Wolfgang Wieser (vea triplespark.net). El SDK de ztex se implementa principalmente en Java, y usa libusb para hablar, que no es tan rápido como ir directamente a un kernel de Linux como fx2pipe.
    Por cierto, un BW persistente es difícil de manejar: libusb suele dejar caer la pelota durante> 4 milisegundos o más a menudo. El USB está controlado por el host, el host está hablando y los dispositivos están hablando solo cuando uno está hablando con él. Esto significa que si el sistema operativo del host no se molesta en este momento, los datos no van a ninguna parte. El archivo de 4 KB se agota a ~ 40 MB / s.
    
    Las placas cy7c68013a baratas están disponibles para su compra en eBay por alrededor de $ 10 cada una, sin embargo, tenga en cuenta que, dependiendo del chip que reciba, es posible que los pines de entrada principales de GPIF parezcan misteriosamente desconectados y solo actúen porque siempre están altos. ¿Falsificaciones quizás? Afortunadamente, necesitará al menos fpga para impulsar el drama necesario para cubrir el tiempo libre de la computadora durante el almuerzo, y el modo esclavo-quince sigue funcionando perfectamente.
    Desafortunadamente, fx2pipe no es totalmente compatible con las placas ztex (todavía ...) porque fx2 también es responsable de restaurar y configurar fpga, y fx2pipe espera poder simplemente cargar su propio firmware a fx2 cada vez que se inicie ...
    Dicho esto, los tableros ztex son tan baratos (en comparación con encontrar otro tablero fx2 + fpga + drama) que no sirve de mucho hacer el tuyo propio. Realmente quiero revisarlos antes; son, con mucho, la forma más fácil de obtener fácilmente una gran cantidad de ancho de banda. (al menos hasta la marca de ~ 30 MB / s).
    Cuidado, estoy hablando de la mayoría de host -> computadora de banda ancha, pero la dirección opuesta encontrará problemas similares.
    Cypress también fabrica un USB 3.0 "FX3", que será interesante. La forma más fácil en uno de estos sería actualmente el motor de arranque BladeRF. El FX3 es completamente diferente: es un SoC ARM completo, solo está disponible en un paquete BGA y tiene un SDK compatible con Linux.
    (PS, freeSoC también tiene fx2, pero está cableado solo como un convertidor usb-> serie, y los pines de ancho de banda alto no están conectados en absoluto):
    - Paul. dice:
      Hola Remy,
      gracias por la descripción general de la curva de aprendizaje de estos chips de ciprés. Otro tema importante sería la disponibilidad de un compilador de C asequible / gratuito para estos problemas.
      Y cuando el rendimiento de mis proyectos avr se convierte en placas problemáticas como Raspi o Beaglebone Black, es mucho más probable que cambie a los controladores Cypress. Pero esas más de 4000 páginas de hoja de datos para esos procesadores son una visión general de mierda ... Probablemente sea mejor leer un libro sobre linux / kernel embebidos.
R dice:
Para aquellos que se preguntan por qué OSX supera a Linux, aparentemente los desarrolladores principales lo están analizando.
https://plus.google.com/111049168280159033135/posts/iGEcktD99NS
- AMS dice:
  Es porque una Mac en realidad almacena en búfer para enviar sus pequeñas solicitudes como un paquete más grande. Sin embargo, juega un infierno gay con latencia para cualquier cosa que intente fingir que es en tiempo real.
  - Paul Stoffregen dice:
    Tienes razón sobre el almacenamiento en búfer.
    Sin embargo, en términos de latencia, también he realizado bastantes comparativas allí. Estos resultados muestran que OS-X también logra las latencias más bajas. Algunos de los primeros puntos de referencia se publicaron en neophob.com hace aproximadamente 2 años y se mencionan aquí en HaD. Las pruebas más recientes se han discutido en los foros de pjrc. Probablemente volveré a hacer esas pruebas en mi creciente colección de tableros y publicaré otra página en uno o dos meses.
    Sé que esto ve un rendimiento excelente y contradictorio con un búfer, así como la latencia más baja. La única explicación que se me ocurre es que Apple necesita algunos desarrolladores inteligentes que se preocupen por los buenos resultados.
    - Remy Dyer dice:
      Creo que eso se debe a que Apple es realmente una empresa de ingeniería informática. Tienen que usar osciloscopios para medir el rendimiento, y están muy preocupados por el rendimiento de esa manera específica para los ingenieros ...
      Es sorprendente si cree que la simple presentación lo es todo para Apple.
      Bueno, aquí tienes una prueba experimental verificada de forma independiente.
      (Descargo de responsabilidad: no trabajo para Apple, pero he sido un usuario durante mucho tiempo y claramente podría describirse como un fanático. Sin embargo, aparte de mi teléfono, solo tengo una Macbook. Actualmente tienen 9 sistemas operativos Linux separados, en su mayoría Ubuntu con una pizca de Mint).
Angus dice:
Jugué con Teensy 2.0. Puede realizar transferencias de tamaño USB tan rápido como lo maneja el bus USB de alta velocidad, si está dispuesto a trabajar directamente con USB, tal vez escriba algún código de conexión y deje poco tiempo para una informática eficaz.
- Paul Stoffregen dice:
  Con la nueva versión de Teensyduino 1.14, también puede tener casi esa velocidad usando solo Serial.readBytes (). No se requiere una programación difícil.
igor dice:
Parece que la interfaz USB natural para controlar un montón de LED sería OCULTA.
El cubo se encuentra en algún lugar entre la mitad de los LED típicos de un
controlador de juego y la matriz de valores en la pantalla LCD.
El uso de HID no debería crear un controlador de sistema operativo.
¿Cómo compara HID la velocidad con la CDC?
¿Alguna limitación significa que no funciona con muchos LED?
- Paul Stoffregen dice:
  HID funciona muy bien para algunos LED, como los 3 LED de su teclado. Podría funcionar bien para cubos LED de tamaño pequeño a mediano. Pero HID no es adecuado para mover grandes cantidades de datos, como mostrar 30 o 60 cuadros / seg. A partir de video o datos derivados de video (por ejemplo, Ambilight) en grandes instalaciones de LED.
  USB tiene 4 tipos de crossover, cada uno con diferentes estrategias de asignación de ancho de banda utilizando el chip controlador de host (en su computadora o Mac). El protocolo HID utiliza el tipo de transmisión de interrupción USB, que garantiza la latencia, pero un ancho de banda muy limitado. Puede leer más sobre los 4 tipos de transferencia en la especificación USB, o cualquier número de artículos escritos por personas que se basan en la especificación con una explicación menos técnica.
  - Folts dice:
    Si utiliza "mejores informes", el tráfico HID cruza el canal de control. Este es más lento que grueso, pero mucho más rápido que interrumpir. En un bus de alta velocidad, el grosor puede realizar ~ 19 transacciones por fotograma, aproximadamente 1,2 MiB / seg. El punto final de control tiene un diseño adicional y un protocolo de enlace que, según el tipo de controlador de host, podría encajar en un marco dedicado. Por lo tanto, tiene un aumento de 2 mS en el tiempo de transferencia en comparación con el grosor. Esto no es tan malo. Por otro lado, los controladores sobre el tamaño se optimizan de manera diferente. Tener un búfer del lado del núcleo más grande, una lógica de control ligeramente diferente y aumenta la brecha entre tamaño y control. En los dispositivos de alta velocidad, la brecha es mucho mayor porque el grosor usa paquetes de 512 bytes y domina solo 64.
Joost dice:
Texto útil. Con el Arduino Due tuve el mismo mal desempeño.
Aunque cambiar un poco el boceto, eso marca una gran diferencia.
Con el siguiente código y usando bloques de 4k obtuve una velocidad de 2.0MBytes / seg. Más de 15 veces más rápido.
#define USBSERIAL SerialUSB // Arduino Due, Maple
configuración vacía () {
USBSERIAL.begin (115200);
}
bucle vacío () {
char buf[4069];
mientras que (USBD_Available (CDC_RX)) {
USBD_Recv (CDC_RX y buf, 4096);
}
udd_ack_fifocon (CDC_RX);
}
Remy Dyer dice:
Para un verdadero USB 2.0 de alta velocidad, necesita tres chips: un chip FIFO USB compatible con HiSpeed, FPGA y DRAM.
Manera fácil: obtenga DSLogic cuando esté disponible.
Si quieres uno ahora, consigue una placa usb-fpga de ztex.de
Utilice la DRAM como una tubería muy profunda. (búfer de anillo, deberá implementar el controlador para ello en la FPGA).
No existe ningún chip USB 2.0 con suficiente búfer para mantener la transferencia continua en cualquier otro sistema que no sea un sistema operativo en tiempo real creado para no perderse nunca una votación del bus USB.
Incluso Linux dejará caer la pelota de forma predeterminada, pero sigue siendo mucho más grande que Windows:
Linux parece un tipo que está enfermo durante un día aproximadamente una o dos veces al año, Windows parece un tipo que tiene alrededor de 6 meses a la vez sin previo aviso. La situación es como si la gerencia no se diera cuenta, porque el tipo de Windows todavía trabaja un poco cada año, y todo el mundo espera lo que hace. Reemplace * año * en este ejemplo con “intervalo de ~ 8 ms” y es la situación con USB 2.0 HiSpeed en pocas palabras. El resultado práctico es que necesita al menos 8 MB de búfer como mínimo absoluto si está utilizando linux.
Implementando aproximadamente 2 segundos de búfer, alcanzará velocidades continuas de 240 Mbps, hasta que se solidifique hasta que su disco esté lleno. (Si sigues así, intenté esto hasta que el conjunto RAID de 11 TB se llenó, usé XFS. Pensé que me tomó alrededor de 101 horas). En realidad, administrará un poco más, tal vez 256 o más, pero no será estable. Necesita el exceso de BW para que el búfer se vacíe entre los problemas del sistema operativo.
Oh, tendrá que usar un concentrador raíz de Intel; puede haber otro concentrador raíz que pueda funcionar, pero la mayoría de los que he probado no lo están. (Si tienes curiosidad, ras-pi gestiona unos 140 Mbps, pero solo en memoria ...). Todavía no he probado los concentradores raíz USB 3.0 ...
Falta el búfer de varios MB, podrá admitir tal vez 20 MB / s durante unos segundos a la vez, si tiene suerte ...
Pero en serio, si está un poco interesado en enviar o extraer datos a través de USB 2.0 a su proyecto, vaya a apoyar el iniciador DSLogic.
Recuerde que realmente solo necesita un par trenzado para enviar datos entre FPGA con velocidades mucho más altas, y hay dos pares en un título de expansión en DSLogic.
Si está buscando una placa de desarrollo FPGA específicamente para realizar transferencias rápidas, entonces las placas ztex son sus aliadas. Si no necesita tanta velocidad, pero aún desea una FPGA, entonces los foros de xess XuLA son mi elección.
¡Buena suerte!
Bill Cox dice:
¡Acabo de probar la velocidad de envío (en una computadora portátil con Linux Ubuntu) a través de USB 3.0 y obtuve más de 1.2 MB / seg! Bela! Tengo la intención de usar esto para generar datos aleatorios reales a una velocidad bastante alta.
apodado dice:
Una vez hice 5 megabits / s en un PIC16F1938 overclockeado a 64Mhz. Podría transmitir datos de tiempo MFM en disquete a unos 250 KB / s sin ningún problema. Usé el chip PL-2303 serial a USB 🙂 El PL-2303 puede alcanzar los 12Mbit según la hoja de datos, pero el controlador está limitado a 6Mbit desafortunadamente. Estoy interesado en cómo funciona el USB rápido PIC32MZ.