USB CDC: Ayuda con Zero Packets

Question

Estoy tratando de comprender la necesidad de Cero paquetes en USB-CDC transmisiones. Por lo que pude ver, esto parece tocar algunas zonas grises de la USB especificaciones técnicas, o en las diferencias en la aplicación de host USB drivers. Estoy interesado tanto en el 'correcto' comportamiento (según la especificación USB) y la conducta típica como medida de como regular los puertos USB (Linux, Windows, OSX). Cualquier los conocimientos pertinentes, se agradecería.

1. Un ejemplo hipotético de un dispositivo USB sería aquella que se transmite a través de una simple conexión USB-CDC extremo, simplemente continuamente la generación y transmisión de bytes infinitamente. Para este ejemplo, se asume que la generación de datos es considerablemente más lento que el USB-CDC transmisión. El enfoque me gustaría usar es recoger 64 bytes de datos (dispositivo de tamaño de paquete), y cuando de 64 bytes están listos, transmitir un solo paquete. No cero paquetes jamás se envía, no hay paquetes cortos se ha enviado. Cualquier host-iniciada la votación va a estar Desnudo cuando no hay ningún paquete completo listo.

   1. Es este un camino válido para transmitir los datos de los CDC?

   2. Hay alguno de los puertos USB que se sabe que tienen problemas con este enfoque?

   3. Si el dispositivo USB es un dispositivo USB compuesto, y uno de los extremos es un CDC extremo como se describe, ¿hay algún cambio a las respuestas de. y b.?

2. En el dispositivo de 1., si, en lugar de enviar NAKs cuando no hay nada que enviar, el dispositivo envía una 0 de paquetes, es probable que todavía funcionan? ¿Cómo funciona el total de la transmisión, cambio - en términos de cómo se interpreta el emulador de puerto serie y/o el ancho de banda efectivo?

3. Si el dispositivo, en cambio, transmite un par de bytes, a la espera de una respuesta. La longitud de estos "pocos" los bytes no es conocido apriori. El host debe ser capaz de recibir, procesar y responder a estos pocos bytes - que no puede simplemente sentarse en un hardware / buffer del controlador de espera para la transmisión final. Supongamos por el momento que el USB-CDC recibe-por-el-dispositivo de alguna manera es trabajando y estable. Lo único que me interesa en cero la transmisión de paquetes desde el dispositivo.

   1. Si el número de bytes que se envían no es un múltiplo de 64 bytes (tamaño de paquete), luego simplemente termina con el 'short' de paquetes sería suficiente para marcar el final de la transmisión, ¿sí?

   2. Si el número de bytes a enviar es un múltiplo de 64 (tamaño de paquete), entonces, ¿qué sucede si un cero paquete no es recibido después de la última transmisión de paquetes para marcar el final de la transmisión?

Answer 1

Al parecer, algunos de host de controladores de dispositivo, como en Windows, utilice la indicación de que usted no tiene más datos inmediatamente para pasar los datos acumulados hasta la aplicación. Sin que, al parecer Windows búferes de los datos y los pasa a la aplicación únicamente cuando algunos se alcanza el límite de (que parece ser de 64 bytes, pero no estoy seguro).

USB tarda menos EN (recibido desde el dispositivo) de paquetes como la indicación de no más inmediata de los datos. Esto significa que si usted no tiene más datos y el anterior EN el paquete llena el buffer, entonces usted tiene que enviar un 0 paquete de longitud en respuesta a la siguiente token. Se podría pensar que NACKing el siguiente token indica claramente que usted no tiene inmediata de los datos, pero al parecer eso no es correcto para USB.

Sólo me encontré con este problema de frente. He estado usando mi foto 18 USB código durante muchos años, y más de una docena de proyectos sin problemas. Hasta ahora, he utilizado de 64 bytes tapones para los datos de la aplicación extremos. Acabo de hacer otro dispositivo USB, pero esta vez con un pequeño PIC 18 donde yo no podía permitirse el tres de 64 bytes búferes para cada extremo. He usado de 16 bytes búferes en su lugar.

Esta foto fue recibir información a través de una conexión en serie, luego de enviarlo al host a través de USB. En ocasiones, la comunicación se estancó. Esto se remonta a suceder después de un total de 16 bytes de paquete fue enviado, entonces no hay más datos disponibles. Windows mantiene el 16 bytes sin pasarlos a la aplicación.

Nos temporalmente kludged todo esto a través de la secuencia de datos de serie contener NULL comandos ocasionalmente cuando nada estaba pasando. Estos son sólo 1 byte de longitud. Si el caso anterior sucedió, Windows mantendría el 16 bytes. A continuación, un paquete vendría en breve que contiene sólo el comando NULL byte. Ya que no es un paquete completo, Windows considera que el fin de inmediato a datos y libera el acumulado de 17 bytes para las aplicaciones.

Cuando vuelvo la próxima semana, voy a arreglar mi PIC 18 USB código para enviar un paquete vacío cada vez que el paquete anterior estaba lleno y no hay nada nuevo para enviar. A continuación, se NACK posterior EN fichas. En la actualidad se Niega EN tokens, siempre que no tiene nada de inmediato a enviar.

Ya que no he hecho el cambio sin embargo, yo no puedo decir con seguridad que este era el problema y que la solución deseada direcciones. Sin embargo, ocasionalmente, el comando NULL solución trabajado, y el USB especificación no parecen estar de acuerdo en que se debe enviar un no-paquete completo cuando no hay más inmediata de los datos.

Todavía no entiendo por qué NACKing el siguiente token DE no transmitir la misma información, pero al parecer no.

Answer 2

Esta es la forma en que los datos de control de flujo es históricamente implementadas en la CDC. De esta forma el estándar de flujo de datos modelo de USB tuberías, véase la Sección 5.3.2 "Tubos" de las Especificaciones USB 2.0:

"Un cliente de software, normalmente, las solicitudes de transferencias de datos a través de e/S de los Paquetes de Solicitud (Irp) a un tubo y luego espera o se advierta del momento en que se completan.

[snip]

Un IRP puede requerir múltiples cargas de datos para mover los datos de cliente a través del bus. Los datos de cargas para un múltiple de los datos de carga útil IRP se espera que el tamaño máximo de paquete hasta la última carga de datos que contiene el resto de la general IRP. Ver la descripción de cada tipo de transferencia para obtener más detalles. Para tal IRP, paquetes cortos (es decir, menos que el máximo tamaño de cargas de datos) en la entrada que no llene por completo IRP un búfer de datos puede tener uno de dos posibles significados, dependiendo de las expectativas de un cliente:

• Un cliente puede esperar de un tamaño variable cantidad de datos en un IRP. En este caso, un corto de paquetes que no se llene un IRP de búfer de datos puede ser utilizado simplemente como una banda de delimitador para indicar "fin de la unidad de datos." El IRP debe ser retirado sin error y el Controlador de Host debe avanzar a la siguiente IRP.

• Un cliente puede esperar un determinado tamaño cantidad de datos. En este caso, un corto de paquetes que no se llene un IRP buffer de datos es una indicación de un error. El IRP debe ser retirado, el tubo debe ser detenido, y los pendientes de Irp asociado con el tubo debe también ser retirado.

Debido a que el Controlador de Host debe comportarse de forma diferente en los dos casos y no puede saber sobre su propia manera de comportarse de una determinada IRP; es posible indicar por IRP que el comportamiento que el cliente desea.

Un extremo puede informar a los host que está ocupado por responder con NAK. NAKs no se utilizan como una retirarse condición para el retorno de un IRP a un cliente de software. Cualquier número de NAKs pueden ser encontrados durante el procesamiento de un determinado IRP. Un NAK respuesta a una transacción no constituye un error y no se cuenta como uno de los tres errores descritos anteriormente."