Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: stm32f105 usb device - какие есть способы повысить скорость bulk передачи ?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
_3m
Суть проблемы: есть stm32f105, работает в режиме FS device, используется библиотека от st. stm32 должен передавать данные в писюк со скоростью до 500кб/сек.
Протестировал bulk in обмен с libusb-1.0 под линуксом. Желаемая скорость достигается, но нужно передавать блоки размером не менее килобайта, причем обязательно без разывов (если в середине будет выдан NAK - отдыхаем до следующего фрейма).
Чтобы это обеспечить нужно завести не менее двух буферов (один передается по усб, другой в это время накапливает поступающие данные), причем буферов лучше иметь более двух. Налицо двойная буферизация а это плохо - увеличивается латентность, кроме того в моем случае данные поступают в рваном темпе, может быть то 1% от максимального объема а может быть все 100%.
Есть ли какие нибудь способы избежать двойной буферизации ?
Axel
Цитата(_3m @ Mar 22 2013, 12:24) *
...нужно передавать блоки размером не менее килобайта...

Для надежности даже больше (учитывая 12Мb full speed)

Цитата(_3m @ Mar 22 2013, 12:24) *
Есть ли какие нибудь способы избежать двойной буферизации ?

Если процессы асинхронные - не думаю. Я использую кольцевые FIFO.
_3m
Цитата(Axel @ Mar 23 2013, 12:31) *
Для надежности даже больше (учитывая 12Мb full speed)
Если процессы асинхронные - не думаю. Я использую кольцевые FIFO.

Прикрутил кольцевые фифо, пришлось написать свою реализацию DCD_WriteEmptyTxFifo.
В процессе обнаружил что библиотека (+железо) не посылают zero length packet автоматически в случае если размер блока кратен размеру эндпойнта и последний пакет был передан полным.
Если добавить отправку ZLP как предлагают в USB CDC Device hung fix то на мой взгляд может быть разрыв до следующей передачи в как минимум 1 sof (а скорее 2).
Гадаю, как будет быстрее:
а) реализовать в DataIn callback отправку ZLP как предлагают или
б) при формировании блока данных следить чтобы размер блока всегда был не кратен размеру эндпойнта чтобы ZLP вообще никогда не посылался.


----
Добавлю:
Проверил оба варианта.
Вариант а) немного быстрее - выдает около 550000 байт/с в то время как по варианту б) получается 535000
Почему так непонятно, с моей точки зрания б) должен быть быстрее, ну уж точно не хуже чем а).
Axel
Цитата(_3m @ Mar 27 2013, 15:56) *
Почему так непонятно, с моей точки зрания б) должен быть быстрее, ну уж точно не хуже чем а).


По-моему логично: незаконченный блок - автоматом пауза до окончания sof, потом еще до 2-х sof между пакетами.
_3m
Цитата(Axel @ Mar 28 2013, 09:08) *
По-моему логично: незаконченный блок - автоматом пауза до окончания sof, потом еще до 2-х sof между пакетами.

Если я хоть что-то понимаю в спецификации usb то незаконченный блок - автоматом конец обмена.
Сегодня измерил период непрерывной передачи при размере блока 2112 байт - 4мс. По расчету эти данные должны укладываться в 2 фрейма. Кто жует сопли еще 2 ??? Девайс для теста скорости передает мусор так что задержек с подготовкой данных быть не может в принципе.
Axel
Цитата(_3m @ Mar 28 2013, 19:17) *
...незаконченный блок - автоматом конец обмена.


"Да, но нет!"©. Незаконченность блока определяется (вероятно) по таймауту - непоступлению данных до конца текущего sof. Далее пустой блок, далее запрос хоста на передачу. Видимо как-то так...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.