[_3m 9]

Суть проблемы: есть stm32f105, работает в режиме FS device, используется библиотека от st. stm32 должен передавать данные в писюк со скоростью до 500кб/сек.

Протестировал bulk in обмен с libusb-1.0 под линуксом. Желаемая скорость достигается, но нужно передавать блоки размером не менее килобайта, причем обязательно без разывов (если в середине будет выдан NAK - отдыхаем до следующего фрейма).

Чтобы это обеспечить нужно завести не менее двух буферов (один передается по усб, другой в это время накапливает поступающие данные), причем буферов лучше иметь более двух. Налицо двойная буферизация а это плохо - увеличивается латентность, кроме того в моем случае данные поступают в рваном темпе, может быть то 1% от максимального объема а может быть все 100%.

Есть ли какие нибудь способы избежать двойной буферизации ?

 

[Axel 1]

...нужно передавать блоки размером не менее килобайта...

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

 

Есть ли какие нибудь способы избежать двойной буферизации ?

Если процессы асинхронные - не думаю. Я использую кольцевые FIFO.

[_3m 9]

Для надежности даже больше (учитывая 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

Почему так непонятно, с моей точки зрания б) должен быть быстрее, ну уж точно не хуже чем а).

Изменено 27 марта, 2013 пользователем _3m

[Axel 1]

Почему так непонятно, с моей точки зрания б) должен быть быстрее, ну уж точно не хуже чем а).

 

По-моему логично: незаконченный блок - автоматом пауза до окончания sof, потом еще до 2-х sof между пакетами.

[_3m 9]

По-моему логично: незаконченный блок - автоматом пауза до окончания sof, потом еще до 2-х sof между пакетами.

Если я хоть что-то понимаю в спецификации usb то незаконченный блок - автоматом конец обмена.

Сегодня измерил период непрерывной передачи при размере блока 2112 байт - 4мс. По расчету эти данные должны укладываться в 2 фрейма. Кто жует сопли еще 2 ??? Девайс для теста скорости передает мусор так что задержек с подготовкой данных быть не может в принципе.

 

[Axel 1]

...незаконченный блок - автоматом конец обмена.

 

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