Есть задача - передать поток данных от ADC через USB на комп.
Два ADC генерируют по больше 20 мбит. Вопрос в том сколько может пропустить USB.

Правильно ли я понял что ограничения такие:
1 фрейм за 1 милисек
за 1 фрейм можно передать один буфер из EndPoint.
Максимальный размер буфера = 512 -0x18 (BTAB) - 2 * 0x40 (END0 buff) = ~ 350 байт

Т.е. максимальная скорость STM32 USB будет 3,5 мбайта?

Для устройств USB 2.0 регламентировано три режима работы:
Low-speed, 10—1500 Кбит/c (клавиатуры, мыши, джойстики)
Full-speed, 0,5—12 Мбит/с (аудио-, видеоустройства)
High-speed, 25—480 Мбит/с (видеоустройства, устройства хранения информации)

этот проц фул спид, значит до 12 мегабит должен качать.

просто есть разные виды передачи, и максимум будет в изохронном режиме, правда без гарантий... и это 1.5 МБайта,

Максимум будет в Bulk, если шина не нагружена и хост сможет поставить 19 запросов за кадр.

Bulk - 19*64 байт = 1216 байт/мс = 1.2 МБ/c.
Iso - 1023 байт / мс = 1.023 МБ/c.

Edit: На практике ни винда ни линукс 19 запросов на моем железе не ставят, получается 13-15 только.

Поддержка Iso в ОС и библиотеках тоже оставляет желать лучшего.

Сообщение отредактировал Taradov Alexander - Jan 23 2014, 07:34

вот потому максимум и будет в изохроне%

15*64 Кбайт = 960 Кбайт/мс = 0.93 МБ/c, все же я настаиваю что в МБайте 1024 КБайта

балк он как бы без потерь потому из-за приемной стороны могут быть прососы по скорости, ну как оно и получается.

Потери, они если и есть, то незначительные.

Тут просто хост не успевает столько запланировать за 1 мс.

Iso поддержка в стандартных универсальных драйверах винды вообще никакая, только свой драйвер писать. В libusb поддержка есть только в каком-то запущенном форке.

Под линуксом с libusb iso получается полные 1023000 б/c.

А можешь объяснить или дать ссылку - как сделать больше одного запроса за кадр?


Мне нужна конкретная реализация на STM32F103 идеально если есть пример.
Абстрактные ограничения протокола или драйверов Win это вторично если до этого дойдет.

Пока я вижу - только 350 байт за 1 милисек. Это 350 кбайт/сек или 2.7 мбит/сек.

запросы делает HOST, то есть компьютер, как у него есть на это силы. Так что никак вы его больше запросов чем он хочет сделать не заставите.

Может я что-то не так помню, но вроде википедия со мной согласна:

Изохронный канал позволяет доставлять пакеты без гарантии доставки и без ответов/подтверждений, но с гарантированной скоростью доставки в N пакетов на один период шины (1 КГц у low и full speed, 8 КГц у high speed)

Поточный канал дает гарантию доставки каждого пакета, поддерживает автоматическую приостановку передачи данных по нежеланию устройства (переполнение или опустошение буфера), но не дает гарантий скорости и задержки доставки.

последний это Bulk они так назвали.

Александр, можешь дать пруф? Ссылку на доку или пример реализации?



Т.е по Изохронный каналу можно отправлять свой буфер несколько раз за фрейм? А размер буфера ограничен?
Буду благодарен за конкретный пример или описание.

Потери пакетов допустимы, главное передать максимум возможного.

Я понимаю что вопросы глупые и решаются чтением доки. Но она огромная, не конкретная и дело движется очень медленно. А еще разбираться как кодировать это в STM32. У меня вторую неделю мозги кипят

стандарт говорит
The USB limits the maximum data payload size to 1,023 bytes for each full-speed isochronous endpoint.
High-speed endpoints are allowed up to 1024-byte data payloads. A high speed, high bandwidth endpoint
specifies whether it requires two or three transactions per microframe.

вот, дальше в стандарте таблички, и получается что для Full Speed, если пихаеш
1023 байта, то максимум 1 транзакция в кадр, который раз в миллисекунду.
а вот если пихать по 64 байта, то можно сделать до 20 посылок во фрайм
128 байт - 10 посылок
256 байт - 5 посылок
и получить скорость 1280 байт в кадр. вот так и получается 12 МБит обещанные в секунду.


для балка максимальный размер данных 64 байта, максимальное число посылок 19 и скорость 1216. Но как вам правильно сказали выше, хрен вы эти 19 запросов получите. Балк - это режим передачи при котором пакеты не должны теряться, потому если хост не готов их принять, он приостановит передачу, так же как и вы, если кончатся данные. и реальность будет ниже ожидаемых 19 запросов.

Golikov A.
Спасибо! Изохронный больше подойдет мне. Буду копать его реализацию в STM32.

Столкнулся с такой же проблемой реализации USB изохронной передачи на STM32. Как то не понятно, как через 512 байтный буфер (где еще должны размещаться другие буферы эндпоинтов) передать 1023. Был бы благодарен если бы кто то вывалил пример кода в котором передавалось бы 1023 байта за Фрейм.

Я с этим чипом не знаком близко, но если максимальный размер памяти под endopoint 512 байт, то никак. Это странное ограничение в современном мире, но встречается.

Так что тут максимальная производительность будет с bulk и скорость - какая уж получится.


Это от хоста зависит. Самый простой способ ему намекнуть - просто запросить сразу много байт переслать. Я обычно запрашиваю 64кБ.

C STM не работал, примеров нет.

Дойдет сразу. Если вам тут сейчас дадут пример, то как вы его испытывать будете?

1023 никак.
Как я понял, можно использовать двойной буфер и тогда можно передавать за 1 фрейм несколько посылок. И в изохронном и в балк режиме.
При этом можно выбрать всю возможную ширину канала. Сейчас разбираюсь с реализацией.

Прием синхронизируется по стартовым синхро-битам.
При увеличении размера посылки растет вероятность рассинхронизации.
По этому размер ограничен. В стандарте FULL устройств была максимально допустимая посылка 64 байта, для HIGH увеличили до 512.

Для передачи больших данніх используют дробление на короткие посылки и двойную буферизауцию



На FULL прокачивается 1 мегабайт.
Только нужно качать "большим куском".
Если если работать в режиме запрос/ответ то скорость значительно упадет.
При прокачке программа зависает.
Если нужно чтобы прграммма реагировала на управление, нужно или отдельную нить запускать или использовать OVERLAPPED метод обмена.



Я бы сказал от операционной системы.
Хост все равно посылает/принимае пакеты не более 512 байт.

Windows XP позволяет закачивать частями по 128кБайт

Вот проект для SAM7 которым я изучал
http://njnmnp.narod.ru/proj/usb_bulk_sam7/usb_bulk_sam7.html

Сейчас я пользуюсь libusb.
Работает устойчиво, скорость я не измерял.

Для максимальной производительности на Iso нужен полный буффер на 1023 байта. Комментарий был про это ограничение.

Опять-же на винде libusb не поддерживает изохронную передачу.