В описании работы USB в режиме Bulk сказано, что макс. размер пакета 64 байта для этого режима. Мне надо передать 4 К данных. Так как данные передаются фреймами 1 мс, то получается, что на передачу 64 байтов уходит 2 мс (фрейм 1 мс - запрос от хоста, фрейм 1 мс - пакет данных), т.е. на 4096 байтов -128 мс. Другими словами, максимальная реальная скорость передачи данных - 32 К / сек. И это всё, что можно выжать из заявленных 12 Мбит/с для full speed? Явно что-то я не учёл, где ошибка, как на практике передавать данные с максимальной скоростью?

В одном фрейме не обязательно передается только один пакет.

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

Даже старушка AT90USB647, и та имеет размер буфера под 1-ю end-point до 256 байт. И это, заметьте, в режиме двойного буферования! Т.е. на самом деле там по меньшей мере два таких буфера, что позволяет одному заполняться в то время, пока с другого идет передача. А у современных МК предельный размер буфера должен быть еще больше.

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

А зачем запрос от хоста? Настраиваете канал передачи типа BULK и Хост будет сам ловить ваши данные и запихивать их в буфер потом только успевай их из буфера доставать и новый подсовывать.
По крайней мере это так для реализации Хоста типа OHCI.

Хост контроллер планирует транзакции в кадре (фрейме) и распределяет полосу.
Полоса распределяется следующим образом.
Вначале идут до определенного времени непереиодические передачи типа Controlи BULK.
Затем передачи прерываний после них изохронные передачи и если еще осталось время в кадре то снова передаем BULK и Control.

Другими словами если у вас на хосте висит одно устройство и оно передает только BULK то весь канал будет отдан ему и только ему.
Поэтому вы получите Full Speed за минусом накладных расходов на заголовки пакетов и прочее.

В течении одного фрейма устройство может передать по балку до 19 пакетов данных, т.е. до 1.2к. Для этого должны выполняться два условия:
- Другие устройства, если они есть, молчат и не пытаются передать что-то свое в то же время
- Устройство обслуживает запросы быстро. Если устройство замешкается, то планировщик хоста отложит обмен и продолжит его в следующем фрейме.

Второе условие является наиболее критическим. Чтобы его выполнить, желательно обрабатывать запросы по прерываниям и использовать двойной буфер ("пинг-понг"), мгновенно подставляя заранее подготовленый пакет.

Я делаю устройство на SiLabs C8051F320 (для определённости). В принципе, там есть ЕР3 с буфером 512 байт (можно использовать двойную буферизацию - 2х256). Прошу подсказать , как организуется передача нескольких пакетов за фрейм? И что за это отвечает - драйвер или компьтерная программа , которая работает с устройством? Я считал до сих пор, что передачу инициирует хост своим запросом. В ответ устройство передаёт из In Еndpoint пакет данных объёмом , который задаётся при конфигурировании устройства, т.е. это задаёт программист . И объём этот не может быть больше величины фифо Еndpoint, из которой идёт передача. Или это не так?
Задача возникла из того, что сделали систему сбора информации, где 4 К данных собираются за 10 мкс в микросхему памяти. Как то обидно , когда основное время устройство тратит на передачу, а не на сбор и первичную обработку данных. Фирмвару и программу писали по образцу примера, который был приведён фирмой Cygnal (непосредственным разработчиком C8051F320).

Сообщение отредактировал NikP - Dec 16 2012, 17:47

Вот и используйте двойную, режим "пинг-понг". Тогда ваш проц автоматически будет по очереди подставлять буфера по мере поступления запросов.


Хост контроллер. Это организовано на программном и аппаратном уровне, максимально близко к железу. Еще до всяких драйверов, на более низком уровне. Пользователя к этому ни под каким видом не подпускают.


Это так. Вот только запросов за один фрейм может быть много, на FS - до 19 штук, см. спецификацию USB 2.0 Table 5-9. Full-speed Bulk Transaction Limits. И если устройство в ответ на запрос мгновенно начинает выдавать пакет, то планировщик хоста не выкидывает его из очереди, а перекачивает пакет и дает новый запрос. А пока пакет перекачивается, устройство должно успеть заполнить второй буфер. Если не успеет, то в ответ на очередной запрос хоста оно (т.е. его SIU, тоже на низком уровне, аппаратно) ответит NACK-ом, и планировщик хоста в этом фрейме данных с него больше запрашивать не будет.

При 12 Мбит/сек пакет в 64 байта передается за 42.6 мкс. Если ваш девайс жует сопли и не успевает заполнять второй буфер за это время, то вместо 1.2 Мбайт в секунду будете иметь скорость перекачки 64 кбайт в секунду, или даже меньше.

И еще надо учитывать, как работает верхняя программа в PC. Если она запрашивает 64 байта, дожидается ответа и запрашивает следующие, то скорость также будет очень маленькая. Для большой скорости передачи нужно сразу запрашивать данные большим куском.

Спасибо за советы! Дело сдвинулось после конфигурирования под двойную буферизацию ЕР3 (пробовали 2х128 и 2х256) и изменения верхней программы, всё заработало , скорость возросла . Не так, как хотелось, но с этим будем разбираться дальше. При этом проявилась новая напасть. При запросе верхней программой 1К и 2К (а мне надо 4К) всё работает, при запросе 4К - комп падает в синий экран. По сообщению - ошибка обслуживания USB. Посмотрели исходник драйвера (предоставленный Силабом) - там заполняется некий буфер 4096 байт - вроде должно хватать. Попробовали немного подредактировать драйвер - эффект остался. В чём может быть причина?

Наверняка это баг в драйвере. Написать драйвер без ошибок очень сложно. Поэтому я предпочитаю использовать драйверы класса, которые входят в комплект поставки Винды. Судя по всему ваша задача нормально ляжет под CDC. Тогда ваша прикладуха будет просто работать с виртуальным COM портом. Правда, в Винде и этот драйвер не без греха, он начинает портить данные при передаче массивов размером более 8К. Но он хотя бы не падает.

А почему сразу баг. Если вы передаёте пакеты по 64 байта, драйвер их собирает и ждёт окончания запросов (неполный пакет или нулевой пакет) если его небудет он заполнит свой буфер (по умолчанию 4к) и только после этого отдаст данные в windows. Данные нужно выставлять на отправку сразу после пакета sof и заканчивать нулевым пакетом в пределах кадра.

Мы пробовали передавать пакеты по 128 и 256 байт. По идее, драйвер должен набрать заданные разработчиком драйвера 4К (или меньше- сколько запросили из прикладной программы) и отдать их прикладной программе. Я писал, что когда программа просит 1К и 2К - всё работает (при пакетах и 128, и 256 байт). При запросе 4К- синий экран. Проверили "кривой" вариант- запросили 3К - всё рухнуло. Что может происходить?

По статистике вообще большинство BSOD происходит из-за багов в драйверах,. А уж когда падает при отладке девайса с каким-то подозрительным драйвером - то уж точно из-за бага в драйвере. Иначе не получишь BSOD.


Это где-то описано СиЛабсом, или вы из головы придумываете?


С нормальными драйверами таких ограничений нет.


Пакеты должны быть того размера, какой прописан в дескрипторе и задан при настройке. Если вы задали 64 байта, то и посылать должны кусками не более 64 байт. Трудно предсказать что произойдет, если вы будете стараться впихнуть пакеты 128 или 256 байт в трубу размером 64 байта. У вас, наверное, в процессоре SIU с ума сходит, после чего и драйвер в конце концов падает. Ведь вы же на FS работаете, а не на HS? На FS максимальный размер пакета 64 байта.

При трубе 64 байта вы свой файл 4К должны кусочками по 64 байта закидывать в буфера. Последний кусок должен иметь длину 0 байт, это означает, что транзакция закончена.

Все варианты сделаны честно: при переходе на другой размер пакета переделываем всё ( т.е. для пакета 128 байт перешиваем контроллер и переделываем прикладную программу и т.д.). Во всех вариантах с разными размерами пакетов пока верхняя программа требует 2 К и меньше - работа идёт, требует 4К - синий экран.

Я в принципе не способен понятть, что это за "честность" такая, если вы в трубу с размером пакета 64 байта (а в FS больше этого не бывает в принципе) пытаетесь всунуть пакет 128 байт. Хост контороллер ни при каких обстоятельствах не будет запрашивать пакет размером больше 64 байт. А у вас в буфере после этого останется еще кусок информационного мусора в 64 байта. И как SIU вашего микроконтроллера будет себя после этого вести - никто вам не скажет, разве что к гадалкам пойдете.

Неудивительно, что СиЛабовский драйвер в ситуации, когда SIU девайса ведет себя неадекватно, не способен долго жить и в конце концов падает. Формально говоря это баг, но я их понимаю - они не могут разруливать все варианты варварского изнасилования USB.