Android USB Host - навалом () теряет данные

Question

Я пытаюсь получить данные с нестандартного устройства на основе микросхемы FTDI 2232H.

Я использую простой режим FIFO с асинхронной синхронизацией, и скорость входящих данных составляет 3,2 МБ / с.

Все отлично работает с тестовым кодом на моем ПК, но у меня возникают проблемы с получением данных на моем Toshiba Thrive.

Сбой драйвера Android от TDI, поэтому я кодирую с использованием Java.

Я могу получить более 95% данных, но время от времени они «распыляются», и я получаю порции тех же 4-5 КБ данных два или три раза, а затем возвращаюсь к хорошим данным.

Я не буду слишком быстрым для Thrive или Android, потому что ранее у меня были данные с удвоенной скоростью (6,4 МБ / с), и они также получали около 95% от этого.(Так что у него не должно быть проблем с половинной скоростью.)

Кажется, что есть какая-то ошибка в буферизации (или двойной буферизации), которая происходит в Android.(Это не буфер в FTDI 2232H, потому что повторяющиеся данные больше, чем внутренний буфер чипа 4K.)

Код установки прост, и снова он работает ~ почти ~ отлично.

Цикл, в котором происходит захват данных, очень прост:

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;
  }

Если вы считаете, что это задержка для массива - я все равно теряю данные, даже если я закомментирую эту строку.

IN_BUFF_LEN - 16384 (массовый перенос не вернет больше, чем этот, даже если я увеличу размер inBuff).

БольшойBuff составляет несколько мегабайт.

Как дополнительный вопрос - даКто-нибудь знает, как передать указатель на bulkTransfer, который будет заполнять bigBuff напрямую - со смещением (не начиная с позиции '0'?

Answer 1

UsbConnection.bulktransfer (...) содержит ошибки. Используйте UsbRequest.queue (...) Api. Многие люди сообщают, что при непосредственном использовании массового перевода происходит сбой около 1% или 2% входных переводов.

Answer 2

@ Грег. У меня та же проблема с полноскоростным USB-устройством, и исправление должно было включать задержку в 50 мс между каждым опросом внутреннего буфера ANdroid.

Answer 3

Просто чтобы прояснить некоторые из подходов, которые я пробовал ... Код USB работал в своем собственном потоке и получил максимальный приоритет (не повезло) - я пробовал вызовы API, libUSB, native C и другие методы (не повезло) - Я буферизовал, опросил и поставил в очередь (не повезло) - в конце концов я решил, что Android не может обрабатывать данные USB на «высокой скорости» (постоянная скорость 3,2 МБ / с без контроля потока).Я встроил 8 МБ аппаратный буфер FIFO в свой дизайн, чтобы восполнить это.(Если вы думаете, что у вас есть ответ, придумайте что-то, что передает данные со скоростью 3,2 МБ / с, и посмотрите, сможет ли Android справиться с этим без каких-либо отклонений. Я почти уверен, что это невозможно.)

Answer 4

В Nexus Media Importer я могу последовательно выдавать около 9 МБ / с, так что это возможно.Я не уверен, что у вас есть контроль над источником, но вы можете разбить канал на 16K блоков с каким-то последовательным заголовком, чтобы вы могли обнаружить отсутствующие блоки и повреждения.

Кроме того, вы непроверка на len <0. Я не уверен, что будет, если базовый стек получит NAK или NYET с другого конца.Я получаю это достаточно того, что у меня есть код восстановления, чтобы справиться с этим. </p> 1004 * Я искал долго и упорно способ смещения буфера назначения bulkTransfer, но я до сих пор найти его.К вашему сведению: USBRequest.queue () не относится к ByteBuffer.position ().

Я немного удивлен, что мы все равно можем сделать 16K на массовом переносе.Согласно спецификации USB 2.0, максимальное значение должно составлять 512 байт для конечной точки массового переноса.Android связывает массовые переводы или мы нарушаем правила?

Answer 5

Вы должны быть уверены, что на той же шине нет другого трафика с более высоким приоритетом, чем ваш трафик.