[NikP 0]

Ну эксперименты с размером пакета мы начали после ответа :

Это видимо про контрольную точку было сказано, а у той, что данные сливает, должно быть больше.

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

Но суть не в этом. При размере пакета 64 байта - та же ерунда: предельный размер остаётся 2К.

 

[=AK= 10]

Ну эксперименты с размером пакета мы начали после ответа :

В FS размера трубы больше 64 байт нет в принципе, читайте спецификацию USB. Это в HS можно назначить трубы большего размера. А ваш проц работает на FS, так что завязывайте с экспериментами.

 

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

Чтобы понять, почему изначально нелегальные конфигурации почему-то вдруг как-то работают, надо влезть в самое нутро вашей МС, в аппаратную реализацию USB на уровне VHDL/Verilog, заодно копая исходники хоста и драйвера. Тогда, возможно, за несколько месяцев в этом вопросе разберетесь. А оно хоть кому-нибудь надо?

 

Или, может быть, вам кто-то обещал, что нелегальные конфигурации вообще работать не будут? Увы, никто вам этого не обещал. Вам обещали, что правильно сконфигурированное устройство будет работать, и не более того.

 

При размере пакета 64 байта - та же ерунда: предельный размер остаётся 2К.

Описывайте все что делаете в подробностях. Вы там где-то в деталях напортачили.

[NikP 0]

=АК= Спасибо за науку: установили размер пакета 64 байта, сделали запрос 16К , убрали несколько косяков и передача пошла на хорошей скорости.

[ten04031977 0]

=АК= Спасибо за науку: установили размер пакета 64 байта, сделали запрос 16К , убрали несколько косяков и передача пошла на хорошей скорости.

 

У меня была та-же проблема - не получалось оправлять/принимать больше одного пакета за фрейм. На девайсе (STM32F3Discovery) бесконечным циклом устанавливаю кол-во на отправку 64байта (SetEPTxCount((EP1_IN & 0x7F), 64) и валидность данных (SetEPTxValid(ENDP1)). Данные в буфере пока не обновляю для избежания задержки. По идее задержка на отправку должна быть минимальная и пакеты непрерывно отправляться, но в клиенте на PC за секунду принималось только 1000 пакета по 64байта, то есть шёл один пакет на фрейм. На PC в качестве драйвера использую DriverWizard WinDriver 10.10. Ситуация исправилась тем, что на PC стал принимать пакеты не по 64байта, а оптом значительно большее количество (к примеру 8192байта). Так что сделал вывод, что то самое тормозное место обрывающее транзакцию, это вызов процедуры принятия данных на ПК, и лучше за один вызов принять как можно больше данных. Фактически вызов функции - транзакция. У меня сейчас получается принять за фрейм не более 15 пакетов по 64байта - скорость 960000байт в сек.

 

[ten04031977 0]

Не могу сделать режим двойной буферизации. Отправляется первый пакет и затыкается. До обработчика прерывания завершения отправки (EP1_IN_Callback) не доходит. Может есть пример у кого? Просматривая исходники библиотеки USB, складывается впечатление, что она слабо приспособлена для режима двойной буферизации.