studio - usb otg android.hardware.usb.host.xml missing lg
Android USB Host-bulkTransfer() está perdiendo datos (5)
@Greg estoy teniendo el mismo problema con un dispositivo usb de velocidad completa y la solución fue incluir un retraso de 50 ms entre cada votación en el buffer USB interno de ANdroid.
Estoy tratando de recibir datos de un dispositivo personalizado basado en un chip FTDI 2232H.
Estoy usando un modo Async FIFO simple, y la velocidad de datos entrantes es de 3.2MB / seg.
Todo funciona perfectamente con el código de prueba en mi PC, pero estoy teniendo problemas para recibir datos en mi Toshiba Thrive.
El controlador de Android de TDI falla, entonces estoy codificando usando Java.
Puedo recibir el 95% + de los datos a la perfección, pero de vez en cuando los datos ''sputters'' y yo recibimos porciones de los mismos 4-5K de datos dos o tres veces, luego volvemos a los buenos datos.
No voy demasiado rápido para Thrive o Android, porque anteriormente tenía los datos en doble (6.4MB / seg) y obtuvo aproximadamente el 95% de eso también. (Entonces no debería haber problema a la mitad de la tasa).
Parece que hay algún tipo de error en el almacenamiento en búfer (o doble buffering) que ocurre dentro de Android. (No es el buffer dentro del FTDI 2232H porque los datos repetidos son más grandes que el buffer interno 4K del chip).
El código de configuración es simple, y de nuevo está funcionando ~ casi ~ perfectamente.
El bucle donde se produce la captura de datos es muy simple:
while(!fStop)
if(totalLen < BIG_BUFF_LEN-IN_BUFF_LEN)
{
len=conn.bulkTransfer(epIN, inBuff, IN_BUFF_LEN, 0);
System.arraycopy(inBuff, 0, bigBuff, totalLen, len);
totalLen+=len;
}
En caso de que piense que es la demora de tiempo para la matriz, todavía pierdo los datos, incluso si comento esa línea.
IN_BUFF_LEN es 16384 (bulkTransfer no devolverá más que eso aunque aumente el tamaño del inBuff).
El bigBuff es varios megabytes.
Como una pregunta secundaria: ¿alguien sabe cómo pasar un puntero a bulkTransfer que poblará bigBuff directamente, en un desplazamiento (que no comienza en la posición ''0''?
Debe asegurarse de que no haya otro tráfico, en el mismo autobús, con mayor prioridad que su tráfico.
En Nexus Media Importer, puedo avanzar consistentemente a través de 9 MB / s, por lo que es posible. No estoy seguro si tienes el control de la fuente, pero es posible que desees dividir la fuente en bloques de 16K con algún tipo de encabezado secuenciado para que puedas detectar los bloques faltantes y la corrupción.
Además, no está verificando len <0. No estoy seguro de lo que tendrá si la pila subyacente obtiene un NAK o NYET del otro extremo. Entiendo esto lo suficiente como para que tenga un código de recuperación para manejar esto.
He buscado por mucho tiempo una manera de compensar el búfer de destino bulkTransfer, pero aún no lo he encontrado. FYI: USBRequest.queue () no respeta la ByteBuffer.position ().
Estoy sorprendido de que podamos hacer 16K en bulkTransfer de todos modos. De acuerdo con la especificación USB 2.0, se supone que el máximo es de 512 bytes para un punto final bulkTransfer. ¿Android está agrupando bulkTransfers o estamos incumpliendo las reglas?
Solo para aclarar algunas de las aproximaciones que probé ... El código USB funcionaba en su propio hilo y se le daba máxima prioridad (sin suerte) - Probé las llamadas API, libUSB, C nativo y otros métodos (sin suerte) - I amortiguado, y encuestado, y puesto en cola (sin suerte) - finalmente decidí que Android no podía manejar los datos del USB a "alta velocidad" (constantes de 3.2MB / seg con ningún control de flujo). Construí un buffer FIFO de hardware de 8MB en mi diseño para compensarlo. (Si cree que tiene una respuesta, piense en algo que alimente datos a 3.2MB / seg y vea si Android puede manejarlo sin CUALQUIER inconveniente. Estoy bastante seguro de que no puede).
UsbConnection.bulktransfer (...) tiene errores. Use UsbRequest.queue (...) Api. Muchas personas han informado que el uso de bulktransfer directamente falla alrededor del 1% o 2% de las transferencias de entrada.