Перейти к содержанию
    

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

• NAK indicates that a function was unable to accept data from the host (OUT) or that a function has no

data to transmit to the host (IN). NAK can only be returned by functions in the data phase of IN

transactions or the handshake phase of OUT or PING transactions. The host can never issue NAK.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Можете попытать мой тестовый бинарник запросами IF; - в ответ получаем самую длинную строку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Можете попытать мой тестовый бинарник запросами IF; - в ответ получаем самую длинную строку.

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Загрузи с Кенвуда ARCP 590 и пусть молотит... под XP запускается. Или любой ham radio log - и пусть тестирует.

Я как-то не забываю обновлять документы, потому не удивил (и не только от ST).

Да, в HS "их реально 1CTRL + 8IN + 8OUT". В FS 1+5+5.

Изменено пользователем Genadi Zawidowski

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я как-то не забываю обновлять документы, потому не удивил (и не только от ST).

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

 

Загрузи с Кенвуда ARCP 590 и пусть молотит...

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

Изменено пользователем Шаманъ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Изменено пользователем Genadi Zawidowski

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Шаманъ, почему не тянет? Одновременно с этим в случае радио я запускал...

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Изменено пользователем Шаманъ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Отлично, здорово что все сдвинулось вперед.

про мой тест: там нагружалось не только CDC, но и висящей на том же USB UAC1.

хотелось узнать, чем именно отличаются логи активности CDC в моем и вашем случае (со скриншотом).

ZLP: а через хаб оно такое будет работать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

хотелось узнать, чем именно отличаются логи активности CDC в моем и вашем случае (со скриншотом).

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

post-39839-1490472860_thumb.png

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

post-39839-1490472856_thumb.png

 

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

 

ZLP: а через хаб оно такое будет работать?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Т.е, если нечего слать, в какое состояние переводите ендпоинт? В NAK?

upd: заменил передачу ZLP на USBD_LL_StallEP - все (и CDC и UAC) перестало работать... потом разберусь.

Изменено пользователем Genadi Zawidowski

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Т.е, если нечего слать, в какое состояние переводите ендпоинт? В NAK?

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

 

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

 

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

 

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

Изменено пользователем Шаманъ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем Genadi Zawidowski

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...