Проблемы с USB могут быть и неразрешимыми. Параллельно заложите в проект возможность работы по UART, это будет вашей страховкой. Благо, это почти ничего не стоит. Зато вы всегда сможете соскочить с USB (а это почти наверняка придется сделать) и вернуться к более подходящему интерфейсу.

Ребята, оказывается есть большая проблема с USB CDC. Кратко суть: после прохождения помехи по USB, драйвер usbser.sys перестаёт слать BULK IN. Вот тут обсуждается.

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

Да там и вне больших помех проблем миллион. Основная (и она же не дает работать при сильных помехах) - это полное отсутствие обработки ошибок у Микрософта в драйверах USB. Уронить машину в синий экран тривиальной ошибкой в дескрипторе - раз плюнуть. И в других местах то же самое.

Еще Вам раз намекаю - если Вы не умеете работать с USB - не делайте поспешных выводов и не вводите народ в заблуждение.


1. Обработка основных ошибок в USB идет на аппаратном уровне.
2. Не используйте продукты от Microsoft в ответственных приложениях.

Так продукты-то не мои ! Примерно одинаковые по качеству результаты демонстрируют изделия самых разных производителей. А я всего лишь это отмечаю в своих сообщениях. При чем здесь я ?
Кстати, вам не кажется странным, почему я не нападаю, например, на PCI, на ETHERNET, на PCI Express ? А только лишь на USB ? А ? Может, все-таки не во мне дело ?

Загадка: Найдите два лишних термина: PCI, ETHERNET, PCI Express.

Очевидно Вы эти интерфейсы не знаете совершенно.

Возможно, не в Вас, а от вспышек на Солнце Но это не бросает тень на USB, как признанный во всем мире интерфейс. И это признание от ника kovigor совершенно не зависит.

Можно список производителей?

Читаю тему так, случайно. И никто не обмолвился про "надежность" в другом плане, а именно в разъёмах... Если усб есть в промышленности, может есть и "особые" гнезда и вилки usb, которые нормально работают, фиксируются и т.д? Если нет - пусть дома сидит такой интерфейс.

Google в помощь, куча пром-разъемов USB вплоть до IP65.

А меня в этой ветке позабавило утверждение ярого защитника USB, что при передаче по диф.паре (USB, RS485, ...) не нужна земля... Да, она не нужна, если если разность потенциалов "земель" устройств не превышает 60 вольт (завист от драйвера).

Кто работал с USB ATXMega, просветите пожалуйста, есть ли в них аппаратная поддержка OTG ?

Нету.

да, есть поддержка host (OTG) только в контроллере AT90USB1287.
Кто нибудь работал с ним? Есть ли библиотеки для работы с USB ?
Или не заморачиватся и использовать STM32 контроллеры, на которые есть куча примеров ?

Если нужен USB HOST, то стоит сразу использовать STM32 или подобное.
Очень уж слабое ядро AT90 для таких задач...

Я работала, с AT90USB647 (у него тоже есть OTG, только памяти вдвое меньше). Однако использовала его исключительно, как девайс, а не хост, поскольку последнее в мои задачи не входило.

Среди относящихся к данной теме демок известно это:
at90usb128-demo-cdc-1_0_3.zip
at90usb128-demo-host-cdc-1_0_1.zip
at90usb128-otg-dual_role-toggle-1_0_0-doc.zip
AT90USB128 Generic demo of the Dual role Embedded Host-Device Library.zip

Лично я начинала с первой (at90usb128-demo-cdc-1_0_3.zip), переделав ее на свой AT90USB647 (т.к. специально для AT90USB647 такой демки не было). Девайс и хост режимы преключаются там изменением в файле
Atmel\at90usb128-demo-cdc\at90usb128\demo\cdc\conf\config.h
по умолчанию там стоит:
//! Possible values ENABLE or DISABLE
#define USB_HOST_FEATURE DISABLED
#define USB_DEVICE_FEATURE ENABLED
А если нужно переключить на хост, меняешь оба дефайна на противоположные.

Вам, вероятно, лучше подойдет at90usb128-otg-dual_role-toggle-1_0_0-doc.zip ,
но я не разбиралась, чем он отличается от at90usb128-demo-cdc-1_0_3.zip ,
т.к. на беглый взгляд они выглядят одинаково.

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

Контролер AT90USB647 произвел на меня очень хорошее впечателение, несмотря на обширную эррату. И я даже загрустила, когда Atmel, поторопившись объявить о переходе AT90USBxxx на ATMegaxxxU6, взял свои слова назад (информация появилась в даташите ревизии H, а в ревизии K уже исчезла). Так они и остались в серии AT90, что обидно.


Если архитектура AVR вашему сердцу не близка , то я соглашусь с Копейкиным о целесообразности делать ставку на STM32F контроллеры, а не закладывать в проект AT90USB1287, тем паче, что сама компания Atmel не рекомендует его дальнешее применение.
Тем не менее, не соглашусь с его мнением, что ядро AT90 очень уж слабое для таких задач. Ядро у них, конечно, по нынешним временам сильным не назовешь (16 МГц предел), однако сама по себе передача по каналу USB не требует от ядра какой-то особенной производительности, поскольку сам трансфер производится аппаратно. Там даже буферы для обмена сделаны на памяти, более быстрой чем остальное ОЗУ, и работают они от частоты PLL, а не так, как вся остальная память (соответственно этому, этих буферов в адресном пространстве не видно, а заполнение и опустошение их происходит через соответствующие USB-регистры).