Есть задача - передать поток данных от 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 в ОС и библиотеках тоже оставляет желать лучшего.

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

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 не поддерживает изохронную передачу.

не соглашусь с вами.
полный буфер 1023 байта, позволяет передавать только 1 микрофрайм согласно стандарту USB 2.0, в то время как
256 позволяет передать 5, 128 - 10, 64 - 20 микрофраймов. Отсюда скорость максимальной будет как раз на буферах 64-182-256.
Даже буфер 512 позволяет передавать только 2 микрофрайма, больше 1023, но меньше 1280 что получается с меньшими буферами.

Это согласно стандарта, про конкретную реализацию в процессоре не говорю

Это только для bulk. Для Iso положение в кадре выделяется заранее и планироваться может только одна Iso транзакция за кадр. Так что тут чем больше размер точки, тем больше суммарная скорость.

И для 64 байт bulk максимум 19 транзаций, а не 20.

Цитирую официальный документ
стандарт USB 2.0

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. Table 5-4 lists information about
different-sized full-speed isochronous transactions and the maximum number of transactions possible in a
frame. The table is shaded to indicate that a full-speed isochronous endpoint (with a non-zero wMaxpacket
size) must not be part of a default interface setting. The table does not include the overhead associated with
bit stuffing.

Table 5-4. Full-speed Isochronous Transaction Limits
Protocol Overhead (9 bytes) (2 SYNC bytes, 2 PID bytes, 2 Endpoint + CRC bytes,
2 CRC bytes, and a 1-byte interpacket delay)
Data Payload | Max Bandwidth(bytes/second)| Frame Bandwidth per Transfer | Max Transfers | Bytes Remaining| Bytes/Frame Useful Data
1 150000 1% 150 0 150
2 272000 1% 136 4 272
4 460000 1% 115 5 460
8 704000 1% 88 4 704
16 960000 2% 60 0 960
32 1152000 3% 36 24 1152
64 1280000 5% 20 40 1280
128 1280000 9% 10 130 1280
256 1280000 18% 5 175 1280
512 1024000 35% 2 458 1024
1023 1023000 69% 1 468 1023
Max 1500000 1500

извиняюсь за вид таблицы.

И? Для FS только одна iso транзакция, для HS можно попросить еще 2 дополнительных.

таблица приведенная для FS, для HS идет таблица далее...


High-speed - через черточку тип устройства
A high speed, high bandwidth endpoint - без черточки просто высокоскоростные

Table 5-4. Full-speed Isochronous Transaction Limits - это таблица для фулспида.
обмен буферами меньше 1023, позволяет слать несколько микрофраймов...

я как то не так трактую формат?

Само понятие "микрофрейм" определенно только для HS.

Черточку они попеременно используют, люди-же пишут.

USB establishes a 1 millisecond time base called a frame on a full-/low-speed bus and a 125 μs time base
called a microframe on a high-speed bus. A (micro)frame can contain several transactions. Each transfer
type defines what transactions are allowed within a (micro)frame for an endpoint. Isochronous and interrupt
endpoints are given opportunities to the bus every N (micro)frames. The values of N and other details about
isochronous and interrupt transfers are described in Sections 5.6 and 5.7.

микро у них в скобочках имеется ввиду фрейм-микрофрейм?, и опять ссылка на ту же таблицу, в которой для фулспида 1280 байт в секунду обещают...

может имеется ввиду что можно несколько конечных точек замутить на передачу? фиг его знает вообщем, я чет уже запутался.

"(micro)frame" - это microframe в HS и frame в FS.

FS может держать 1 изохронную транзакцию за кадр. Максимальный размер - 1023 байт. Таким образом 1000*1023 = 1023000 байт/ сек - это максимальная пропускная способность в режиме FS.

HS сам по себе содержит 8 микрокадров в кадре. При этом можно дополнительно попросить хост планировать до 3-х тразнакций за кадр. Таким образом имеем 1000*8*1024*3 = 24576000 байт/ сек - это максимальная пропускная способность в режиме HS.

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

Ну и несколько точек тоже можно сделать, но тогда сложнее будет их синхронизировать при приеме.

Фигня какая то получается. Тогда у STM32 нету реальной поддержки FS USB из за ограничений буфера. Зачем народ обманывать???

Это по спецификации USB. В windows поддерживается только передача в одном микрофрейме за фрейм, так что скорость в 8 раз ниже.

На FX2 совершенно спокойно получаю ISO-поток 160Мбит/с на драйверах от производителя (мог бы и полные 196Мбит/с, да нет нужды), что я делаю не так?

я тоже так понял



а вот стандарт говорит что для буфера 512 может быть 2 передачи за фрейм для FS.
а для буфера 256 может быть 5, и тогда получается тот самый 12 МБит, что требуется для спецификации...


Что винда не поддерживает, допускаю, и что конкретный проц может не поддерживать тоже. Но по спецификации так...

Как иначе FS устройства могут дать 12 МБит, если 1000*1023 = всего то 10?

а вот 256*5 = 12.8....


ну в целом ТС эти теоретически рассуждения не помогут...

Не может:

Примеры загрузки шины приведены для передач через разные конечные точки.

тогда я ничего не понимаю окончательно
что такое
high-bandwidth?

может в FS устройстве она может быть high-bandwidth?

потому что в стандарте реально есть таблица для FS с числом передач отличной от 1, и число байт считается в сообщении...

Точка, передающая до трех пакетов за микрофрейм.


Нет, только в HS.


Есть, но нигде не говорится, что эти передачи идут через одну точку.

Для всех практических целей она есть, но есть и ограничения. Так сделано у многих производителей.

Следующее ограничение, которое есть почти у всех - ограничение на число endpoint-ов. По стандарту максимально можно 32 (16 in + 16 out). На практике - часто в районе 8.

Это не так важно для большинства приложений, но 8 CDC устройств уже не сделать, например.

понятно. В этом наверное и отгадка...