Dudas USB y 12Mbps

[migsantiago]

Hola

Llevo ya varias semanas estudiando y echando a andar los ejemplos de USB que hay, el bulk mode y el cdc con el PIC18F2550 @ 48MHz y usando CCS 4.084. Mi objetivo es obtener una velocidad de transferencia de mínimo 100000Bps, o dicho de otra forma, transmitir del PIC a la PC 4bytes cada 40us. De esos 40us, 20us se usan en la medición ADC y 20us en el envío USB.

Estoy muy frustrado porque en ningún modo he logrado llegar a 100kBps.

- En el modo bulk usando 1 endpoint he llegado a transmitir con velocidad de 5.85kBps.
- En modo cdc con velocidad de conexión de 921600bps y con conexión Hyperterminal he llegado a transmitir 1 byte cada 3.4us usando usb_cdc_putc(), pero el envío no es constante, hay tiempos "muertos" de 500us aprox. entre envíos.
- Después usando cdc bajo las mismas condiciones pero esta vez usando printf(usb_cdc_putc,"12345678901"); logré enviar 12 bytes en 63.2us, con el mismo tiempo "muerto" entre envíos cada n envíos.
- Mejoré los 63.2us a 40.2us enviando los 12 caracteres uno por uno con usb_cdc_putc() (12 veces seguidas) con el mismo tiempo muerto entre envíos.
- Luego implementé un timer0 para forzar el envío cada 40us pero no funciona, incluso poniendo prioridades de interrupciones.
- Por último intenté usar manualmente la función usb_isr() (atención a la interrupción) para evitar los tiempos muertos entre envíos, pero ni siquiera se enumera el pic ante windows.

Todos estos tiempos los medí con un osciloscopio que se conecta a un led que indica mediante ceros y unos la ejecución del usb (a modo de breakpoint).

Quisiera saber si alguien me puede asesorar para lograr llegar a los 100kBps (4bytes cada 40us) que requiero, ya sea usando el modo Bulk o el modo Isócrono, que creo que es el más apropiado.

Si es el caso del modo Bulk, no sé cómo llegar a los 12Mbps virtuales usando los 15 endpoints al mismo tiempo. Para el modo isócrono no tengo ni idea de cómo implementarlo en CCS.

Muchas muchas gracias al que se anime a ayudarme.

[Suky]

Yo también he hecho pruebas de este tipo y con resultados similares, baja velocidad de transferencia. Me dedique a buscar información de cómo utilizar el modo isócrono con PIC, pero no encontré absolutamente nada. Así que estoy muy interesado en este hilo, y estaré atento a sus experiencias.
Saludos!

[migsantiago]

Sí, ese es el problema cuando se intenta implementar algo complejo de forma empírica... prueba y error. 

Estoy estudiando la especificación USB2.0 pero voy lento. Espero que alguien pueda ayudarnos con un ejemplo.

[jeremylf]

El modo isocrono solo se usa video, audio y ese tipo de informacion que no es necesaria que se modifique algun bit de algun byte. Lo que intento decir, es que si necesitas enviar informacion sin tener la posibilidad de que se modifique o se pierda algun bit de todo los datos es mejor usar el modo Bulk, aun que tiene menos velocidad ya que solo usa tramas que le sobran al USB, algo asi...

La cosa va asi, el modo isocrono es el que te garantiza mayor rapidez pero no te garantiza que algun bit o byte se modifique o se pierda, es mas nisiquiera tiene recuperacion de dato. El modo bulk es el mas lento pero te garantiza que todos los datos llegaran sea como sea sin ningun error y tiene hasta recuperacion de dato. El modo interrupcion, no estoy seguro si es mas rapido que el bulk, pero es menos seguro que el bulk pero mas seguro que el isocrono. Aun que el pickit 2 usa este modo para comunicarse asique debe ser tan seguro como el bulk digo yo, aunq esta mas pensando para dispositivos como mouse's, teclados y esas cosas, quea diferencia del modo bulk este esta pensando para impresoras que hasta el ultimo bit es importante.

Espero que se entienda esto 
Ahora, lo de mejorar la velocidad pues es habilitando todos los enpoints del pic, cosa que nose como se hace, pero tengo la duda de como migsantiago logras capturar los datos en la PC simplemente enviandolos desde el pic ? que software estas usando o pensando usar para la adquisicion de datos en la PC?

Otra cosa, en el modo bulk la transmicion de datos lo has echo byte por byte? porque se puede enviar en un paquete hasta 64 bytes cosa que reduce lso tiempos si necesitas enviar mucha informacion. Es mas, existe una funcion, que no la he usado, llamada usb_puts(...) que dicen ser mas eficiente para enviar mas paquetes en un solo mensaje.


Salu2.

[migsantiago]

Sí, se entiende.

Ya conocía las características del modo isócrono y del bulk. Para el modo bulk envío 12 bytes por paquete y 1 endpoint y obtengo las velocidades que menciono en el primer post.

Lo ideal es implementar el modo isócrono pero CCS no trae ejemplos con ese modo. Y la otra opción es habilitar los otros 15 endpoints para el envío bulk, pero ni idea de cómo hacerlo.

[Suky]

Yo también conocía las características del modo isócrono. Estoy trabajando con LabWindows y NI-VISA, y para manejar este modo de comunicación se necesita  “USB Test and Measurement Class” (USBTMC). Este está diseñado para emular el estándar IEEE 488.1, y se pueden programar instrumentos que soportan USBTMC, como sus homólogos GPIB. Esta clase de dispositivo simplifica enormemente el control de instrumentos, ya que se pueden usar interfaces de programación estándar (APIs) como NI-VISA para enviar y leer comandos de instrumentos sin tener que implementar protocolos de comunicación de bajo nivel.(Sin crear driver!)
Pero por más que busque información no encontré nada.   

[PalitroqueZ]

Oye como que está dificil llegar a esa velocidad. Yo no he podido medir la velocidad con presición.

usando VB6 inserté un código especialmente para medir la velocidad de los datos, según los resultados, llego a 5kbps en transmitir y como 500kbps en recibir. Pero no me fío porque el vb6 es monoproceso 

la pregunta que te iba hacer santiago es como estas midiendo la velocidad, de cuanto es el ancho del endpoint? porque si lo configuras por ejemplo a 64bytes y envias 11, entonces los calculos podrian ser erroneos.

...
Todos estos tiempos los medí con un osciloscopio que se conecta a un led que indica mediante ceros y unos la ejecución del usb (a modo de breakpoint).
...

y ¿cuando empiezas a contar el tiempo de inicio de transmisión?

[migsantiago]

Ah, es fácil Pali. Usando un osciloscopio conectado a un pin del pic y enviando datos por usb cíclicamente modo bulk...

Código: [Seleccionar]

            do{
               output_high(USBOK);
               MideMCP3201(); //Hace medición de los 5 ADC's
               output_low(USBOK);           
               transOK=0; //No ha enviado paquete
               while(transOK==0) //No pudo enviar, intenta de nuevo
                  transOK=usb_put_packet(1, doutprima, 12, USB_DTS_TOGGLE);
               }while(ByteRec[1]--);

Cuando el led está encendido está llevándose a cabo la medición ADC. Cuando el led está apagado se está intentando enviar el paquete de 12 bytes a la pc.

La función usb_put_packet entrega un 1 cuando el paquete ya llegó a la pc. Cuando el paquete sigue en espera en el endpoint del pic (ya se pasó al buffer pero no ha llegado a la pc) entonces usb_put_packet entrega un 0.

Esta rutina en particular es la que me entrega 5.85kBps (kilo Bytes por segundo). El cálculo es el siguiente...

Tiempo ADC = 10us (medido con osciloscopio y confirmado contando instrucciones en ensamblador).
Tiempo envío paquete 12 bytes = 2ms (medido con osciloscopio)

Tadc + Tusb = 2.01ms

12bytes / 2.01ms = 5970.1 Bytes / s = 5.9kBps

Ahora una rutina cdc...

Código: [Seleccionar]

      if(usb_cdc_kbhit()) //Si se recibe petición
         {
         comando=usb_cdc_getc();
         //Si el comando es 'a'
         if(comando=='a')
            {
            while(1)
               {
               //Para medir el tiempo desde la medición hasta que ya se envió por USB
               //enciendo la terminal RB7 (solo para debug)
               //Tiempo en alto = Medición ADC (se espera que sea 10us)
               //Tiempo en bajo = Lectura y envío USB (se espera que sea 40.2us)
               output_high(USBOK);
               MideMCP3201(); //Hace medición de los 5 ADC's
               output_low(USBOK);
               usb_cdc_putc(doutprima[0]);
               usb_cdc_putc(doutprima[1]);
               usb_cdc_putc(doutprima[2]);
               usb_cdc_putc(doutprima[3]);
               usb_cdc_putc(doutprima[4]);
               usb_cdc_putc(doutprima[5]);
               usb_cdc_putc(doutprima[6]);
               usb_cdc_putc(doutprima[7]);
               usb_cdc_putc(doutprima[8]);
               usb_cdc_putc(doutprima[9]);
               usb_cdc_putc(doutprima[10]);
               usb_cdc_putc(doutprima[11]);
               }
            }
         }
De la misma forma, cuando el led está encendido se está midiendo el ADC (10us). El tiempo que tarda enviar 12 bytes usando usb_cdc_putc es de 40.2us (led apagado), pero no es constante, hay unos tiempos "muertos" de 550us entre envíos que sospecho son los tiempos en que la pc le manda el token de petición de datos al usb; sospecho que el pic atiende esa interrupción para escuchar a la pc.

No hay forma de calcular la velocidad ya que los 550us se presentan de forma aleatoria entre envíos. Si esos 550us no existieran o los despreciara entonces me aventuraría a calcular la velocidad así...

Tadc = 10us
Tusb = 40.2us

Tadc + Tusb = 50.2us

12bytes / 50.2us = 239043 bytes/s

Te darás cuenta que el método que implemento es a modo de breakpoint, pero no detengo la ejecución del programa, con un led veo exactamente cuándo el pic pasa por cada instrucción y qué tiempo toma llevar a acabo varias.

Edito:

Y contestando tu pregunta de cuándo empiezo a contar el tiempo, no cuento tiempo de inicio... saco una velocidad con un solo envío de paquete (bulk) o byte (cdc). El método funciona al 100% con el modo bulk ya que los envíos son casi constantes, pero no funciona con el cdc porque hay tiempos muertos aleatorios entre envíos.

Lo que puedo hacer es implementar una rutina como la tuya en la que se cuentan los bytes recibidos y se dividen entre el tiempo transcurrido, de esa forma sacaría una velocidad promedio.

Mi problema es que no puedo trabajar con una velocidad promedio, necesito una velocidad constante ya que no puedo retrasar o adelantar la toma de muestras del adc. Los tiempos muertos de 550us son los que me ponen en jaque mate. 

[PalitroqueZ]

he revisado un poco los drivers de ccs y configuran el ancho de los datos a 64 bytes

usb_cdc.h

...
//pic to pc endpoint config
...
#define USB_CDC_DATA_IN_SIZE           64
#define USB_EP2_TX_ENABLE  USB_ENABLE_BULK
...


asi que tendrás que enviar el máximo de datos disponible ó fijar el size que necesites, (yo creo que es mejor enviar los mas que se pueda)

para asegurarte que funciona de esta manera, usa algún sniffer usb, puede ser el snoopy o el USBTrace. allí te mostrará los paquetes de datos que recibe el host.

Lo que queda de momento es mirar secciones de código donde se cambien los parámetros, porque del resto es hacer ensayos y ensayos 

[migsantiago]

De todas formas el cdc que emula serial no me va a servir. La máxima velocidad que la hyperterminal puede emplear con el puerto virtual es de 921600bps. Si eso lo paso a bytes "reales"...

921600bits/s = 92160bytes / s (8 bits + bit inicio + bit stop = 10 bits por byte enviado)

92.1kBps

Apenas y llego a la velocidad deseada, pero bueno haré la prueba de enviar 64 bytes juntos y te aviso.

[MGLSOFT]

No se supone que USB 2.0 funciona a 10 o 12 Mbit/seg ???

[migsantiago]

12Mbps con el hardware y el software apropiado. A mi me falta el software (firmware) apropiado para el pic.

[jeremylf]

Recuerdo que habia algo llamado PING PONG, no soportado en las librerias del ccs pero si implementado en el hardware de los pic18 con usb. Lei tb que esto hacia que la velocidad sea mas rapida ya que era algo como que enviaba mientras guardaba o algo asi, no recuerdo bien. Pero quiza habilitando esto se pueda llegar o aproximarse mas a los 12mbps del USB que tienen los pic18. No he nisiquiera intentado usar el PING PONG tampoco, losiento. 

Salu2.

[migsantiago]

Cierto, he leído sobre el ping pong y su posible mejora de velocidad pero usando CCS no podremos llegar lejos...

http://www.todopic.com.ar/foros/index.php?topic=2348.msg203749#msg203749

[PalitroqueZ]

No se supone que USB 2.0 funciona a 10 o 12 Mbit/seg ???

12Mbps solo por el tránsito en el cable, más no el tiempo que tarda que el pic en enviar el dato, hasta que lo recibe la aplicación en el PC. El mismo microchip lo advierte en uno de sus documentos.

El otro problema Santiago es el tiempo de latencia, como sabrás en USB nada se hace sin que el host pregunte, bueno hay un tiempo en el que el host debe preguntar para que el device le envíe nuevos datos.

Hay que buscar en la maraña de codigos del stack usb del ccs la parte donde debe ajustarse ese tiempo.

Te voy a poner un ejemplo en el que estoy trabajando ahorita.

con la clase HID a full speed, se puede enviar 64000 bytes/segundo, esto sería un poco mas de 500kbps, pero las preguntas(reportes) tienen un tiempo de latencia que cuando mucho 10ms para el low speed.

Bién, en el archivo usb_desc_hid.h aparece la configuración de este tiempo:

Código: C

1. ...
2.     #if USB_USE_FULL_SPEED
3.          1,  //polling interval, in ms.  (cant be smaller than 10)      ==34
4.       #else
5.          10,  //polling interval, in ms.  (cant be smaller than 10)      ==34
6.       #endif
7. ...

es decir, que para full speed podemos tener 1ms de pérdida de tiempo cuando máximo!!

si envias 64 bytes por transacción, tal vez puedas compensar los tiempos de retraso para lograr una transmisión contínua.

¿porque no intentas usar HID?, no se pierde nada con intentar