Comprender el procesamiento USB y el retraso de sondeo en el controlador de host USB

Estoy haciendo mediciones relacionadas con el retraso USB con el chip convertidor USB-UART (chip de laboratorio de silicio CP2102). Estoy enviando una matriz de datos, cuando 0xeese recibe, el microcontrolador hará eco del byte. Estoy tomando marcas de tiempo entre el instante en que empiezo a enviar los datos hasta que recibo el archivo 0xee. Para averiguar el tiempo de procesamiento en el chip CP2102, he medido el retraso de reconocimiento del chip (es el tiempo entre el paquete de punto y el paquete de reconocimiento instantáneo recibido del chip). El chip USB-UART es un dispositivo a granel con dos puntos finales (ENTRADA y SALIDA) con un tamaño máximo de paquete de 64 bytes, se utiliza USB 2.0 de velocidad completa (12 Mbps). Estoy tomando 500 muestras para cada tamaño de datos (1 byte enviado 500 veces y se toman medidas, de manera similar 2 bytes hasta 127 bytes).

Tracé tres gráficos, uno para total_delay, chip_ack_delayy total_delay_without_uart_delay_chip_ack_delay = total_delay - chip_ack_delay - 86.6*data_sizeEste retraso debería representar el retraso de procesamiento y el retraso de sondeo USB en la computadora host. Estoy usando una PC con Linux con Ubuntu 16.04, la tasa de baudios de UART es 115200 (por lo tanto, 86,6 microsegundos por byte). Es comprensible que el retraso en el reconocimiento del chip aumente a medida que el tamaño del paquete supera los 64 bytes, ya que tiene que esperar dos transacciones. No puedo interpretar el segundo gráfico. Muestra que el sondeo del lado del host y la demora de procesamiento disminuyen a medida que el tamaño del paquete supera los 64 bytes. ¿Alguien puede explicar cómo interpretar esto? ¿O me estoy perdiendo algo aquí?

Por cierto, medí el retraso del reconocimiento del chip usando el registro USBmon. En el gráfico, el eje x es el tamaño de los datos, el eje y es el diagrama de caja de MATLAB que muestra el rango de valores de retraso medidos para un tamaño de datos particular.

ingrese la descripción de la imagen aquí

Para comprender el tiempo, debe darse cuenta de que está tratando con la siguiente cadena: aplicación host -> controlador host -> protocolo USB -> conversión UART -> transmisión UART> controlador MCU UART> aplicación MCU que busca el marcador EE -> MCU UART transmisión -> Conversión de UART a USB -> Protocolo USB -> Controlador de host USB -> aplicación de host. Podría haber muchas peculiaridades en la interacción/sincronización entre todos estos límites a lo largo de esta tubería.
Además, debe aprender un poco más sobre el protocolo USB, también conocido como SIE: motor de interfaz en serie. ¿Qué quiere decir "paquete de punto" y "paquete de acuse de recibo instantáneo recibido del chip"? El paquete ACK instantáneo llega en menos de 1,7 us desde el chip; de lo contrario, el host detectará un "error de transacción".
@Al tengo la configuración exacta como explicaste. Resto el retraso relacionado con la transacción UART que es de 86,6 microsegundos/byte y el retraso del reconocimiento del chip. La aplicación MCU es muy simple, he escrito la lógica dentro del controlador de interrupción de uart. Tan pronto como se recibe el byte, lo comparo con 0xeesi coincide, hago eco del byte. Con respecto al instante de tiempo, tomo la marca de tiempo antes de escribir datos en el puerto serie, nuevamente tomaré la marca de tiempo después de recibir el eco. Resto la marca de tiempo anterior de la nueva. Con respecto al retraso de la pila USB, entiendo que la pila y el controlador agregan algo de retraso, pero eso debería ser algo constante.
¿Ack tiene que venir dentro de 1.7us? No estoy seguro de que USBmon muestre mucho retraso antes de que se reciba el acuse de recibo. Puedo adjuntar un USBmon, si desea echar un vistazo.
Estoy hablando del protocolo USB ACK a nivel de paquete USB. No sé a qué "ack" te refieres, es por eso que sugerí ser más preciso en la terminología cuando el título de tu pregunta dice "Retrasos de USB", y arrojas algunos términos desconocidos como "paquetes de puntos".
Estoy hablando de acks en USBmon log en Linux. Estos se envían una vez que se transmiten los datos completos. No veo ACKs para cada paquete USB transmitido. No por cada 64 bytes. Se envía por esclavo una vez recibidos los datos completos aunque sea superior a 64 bytes.

Respuestas (1)

La hoja de datos del CP210x menciona FIFO grandes tanto en el lado de transmisión como en el de recepción.

Sospecho firmemente que también optimizan la utilización de usb (y host cpu) al "recolectar" datos uart en paquetes USB más grandes.

Esto significaría que los datos se retienen hasta que haya 64 bytes en el FIFO o el receptor no estuvo activo durante algunos bits.

Tenga en cuenta que los paquetes masivos de 64 bytes son especiales: no finalizan una transacción en el host (a menos que el búfer sea demasiado pequeño).

En realidad, puede ver una "caída alta" para las transacciones de 64 bytes, ya que podrían ejecutarse como un paquete de 64 bytes seguido de un paquete de cero bytes.

Nota al margen: podría valer la pena volver a verificar los tiempos con un concentrador USB 2.0 de alta velocidad entre el host de la PC y el CP210x. Esta configuración podría usar el0,25 msTemporización de mircoframe de 0,125 ms disponible en alta velocidad.

No tengo ningún rastreador de hardware, estoy midiendo todos los tiempos en el software. ¿Quiere decir que el controlador de host espera los siguientes bytes durante algún tiempo antes de enviar un paquete USB si tiene menos de 64 bytes?
La temporización de microtramas en modo HS es de 0,125 ms, no de 0,25.
No creo que ninguno de los chips CP210x admita el modo de alta velocidad. La hoja de datos especifica solo la velocidad máxima. El ancho del marco USB a toda velocidad es de 1 ms, no estoy seguro de si el ancho del marco juega un papel en el caso de los puntos finales masivos.
Comprender el procesamiento USB y el retraso de sondeo en el controlador de host USB
RespuestasAquíPolítica de privacidad1y, 0v