А какое поведение описано в стандарте на USB?

ZLP для других случаев.

Только вот как-то на LPC не сталкивался с такой проблемой... Как-то все гладко проходило.

Genadi Zawidowski, интересно пытали ли Вы свою реализацию CDC каким-нить "стресс-тестом"?

А то я вот скармливаю VCP по 5 и 6 символов, на "другой стороне" putty все это принимает. Шлю с такой скоростью как получается. В итоге на восьмерке работает уже 15минут (средняя скорость около 450кбит/с), а на ХР затыкается довольно быстро (менее 1 минуты). Сниффер сообщает про "buffer overrun".

Я коннектился как к "Кенвуду" с помощью ARCP-590. кое-какой трафик это обеспечивает. Сутками работало.
Можете попытать мой тестовый бинарник запросами IF; - в ответ получаем самую длинную строку.

Это я так понимаю под десяткой или семеркой? Под более старшими ОС у меня по всему тоже все ок (несколько часов девайс слал данные на скорости 450кбит/с пока восьмерка не упала в BSOD по случаю IRQ NOT LESS OR EQUAL в usbser.sys ).


Это надо будет еще писать что-то для "пыток". Думал может проверяли.

Обновил сегодня Reference Manual на stm32f746. Даже кол-во эндпоинтов у USB OTG HS увеличилось на 1IN и 1OUT ? Так их реально 1CTRL + 8IN + 8OUT? Смотрю везде поисправляли, надо ж так ошибиться было.

Кстати USB раздел претерпел существенные изменения.

Загрузи с Кенвуда ARCP 590 и пусть молотит... под XP запускается. Или любой ham radio log - и пусть тестирует.
Я как-то не забываю обновлять документы, потому не удивил (и не только от ST).
Да, в HS "их реально 1CTRL + 8IN + 8OUT". В FS 1+5+5.

Сообщение отредактировал Genadi Zawidowski - Mar 23 2017, 20:03

Я тоже, но почему-то был уверен, что он у меня новый, хорошо помню, что скачивал новый когда с DMA2D разбирался


Та не, на стресс-тест это никак не потянет.

Сообщение отредактировал Шаманъ - Mar 23 2017, 21:29

Шаманъ, почему не тянет? Одновременно с этим в случае радио я запускал на прием панораму через HDSDR, медиаплеер в режиме воспроизведения по кольцу концерта Depeche Mode, в трансивере включал режим play usb - и сутками в наушниках была музыка, ничего не отваливалось (USB CDC при этом исправно держал соединение).
Тестовый вариант что я предоставил, в компьютер не будет передавать аудиоданных но воспроизвести в него можно.

Сообщение отредактировал Genadi Zawidowski - Mar 25 2017, 10:07

Геннадий тут надо поделить - стресс тест для порта это одно, а для программы на МК в целом несколько иное. У Вас было скорее второе У меня тоже не сам по себе крутится CDC. Одна отрисовка панорамы/водопада 29к/с 800х480 в четырех слоях уже что-то, а еще управление DSP процессором, работа с тачем/клавиатурой/энкодерами и т.п.

В данном случае под восьмеркой все очень гуд - работает по много часов. Под ХР засада, причем очень странная какая-то. Все нашел засаду. Блин три дня истрачено, а всему виной кварц . Переключился на внутренний генератор и, о чудо, под ХР работает уже 20минут, причем два порта. Видимо в восьмерке более совершенное железо умеет поддерживать синхронизацию при бОльших отклонениях частоты.

Хочу высказать Вам отдельную благодарность, т.к. на эту мысль мена навело сравнение логов сниффера с Вашего и моего варианта CDC - обратил внимание, что у меня среднее время ответа было всегда меньше 1мс, иногда намного меньше, и как только оно сильно отклонялось обрывалась связь.

Кстати теперь надобность слать бесконечно ZLP (под ХР) пропала.

Эх жалко двух точек, которые болтаются без дела, они были бы очень кстати...

Сообщение отредактировал Шаманъ - Mar 25 2017, 18:34

Отлично, здорово что все сдвинулось вперед.
про мой тест: там нагружалось не только CDC, но и висящей на том же USB UAC1.
хотелось узнать, чем именно отличаются логи активности CDC в моем и вашем случае (со скриншотом).
ZLP: а через хаб оно такое будет работать?

Скиншот не очень информативен. Вот кусок моего лога с кварцем:

Вот от Вашего теста:


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


Да, работает. Более того, у Вас фактически шлются ZLP пакеты все время. У меня теперь уже не шлются .

Т.е, если нечего слать, в какое состояние переводите ендпоинт? В NAK?
upd: заменил передачу ZLP на USBD_LL_StallEP - все (и CDC и UAC) перестало работать... потом разберусь.

Сообщение отредактировал Genadi Zawidowski - Mar 25 2017, 20:55

Она сама переведется в NAK когда FIFO опустеет. Я так сделал в самом начале, потом из-за этой проблемы убил блин три дня и переделал на посылку ZLP.

Т.е. если надо послать что-то подняли EPENA и CNAK, когда посылка будет отправлена EPENA упадет, а на входящие запросы точка будет отвечать NAK.

Подумываю еще может на передачу тоже кольцевой буфер прикрутить, хотя и без него на восьмерке около 500000кбит/с получается на мелких пакетах (чередование пакетов в 1символ и 9символов) - под наши задачи более чем достаточно.

Кстати, а Suspend и Wakeup нужно обязательно обрабатывать?

Сообщение отредактировал Шаманъ - Mar 25 2017, 20:56

я не обрабатываю... как я понимаю, об обработке таких запросов мы сообщаем, отдавая бит что бы можем remote wakeup делать. Я не ставлю его.

Сообщение отредактировал Genadi Zawidowski - Mar 25 2017, 21:32