STM32f103 USB speed Опции

[Utyff]

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

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

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

[Golikov A.]

стандарт говорит
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 запросов.

[Utyff]

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

[Rikoesev]

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

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

[ataradov]

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

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

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

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

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

Мне нужна конкретная реализация на STM32F103 идеально если есть пример.

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

Абстрактные ограничения протокола или драйверов Win это вторично если до этого дойдет.

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

[misyachniy]

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

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

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

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

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

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

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

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

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

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

[ataradov]

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

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

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

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

[Golikov A.]

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

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

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

[ataradov]

в то время как 256 позволяет передать 5, 128 - 10, 64 - 20 микрофраймов.

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

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

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