Так продукты-то не мои ! Примерно одинаковые по качеству результаты демонстрируют изделия самых разных производителей. А я всего лишь это отмечаю в своих сообщениях. При чем здесь я ?
Кстати, вам не кажется странным, почему я не нападаю, например, на 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-регистры).

Xenia, буферы конечно выделены и тактируются от PLL, но ещё ведь вопрос обработки данных.
Как функция AT90 ещё нормально, но хост должен быть готов к трансферу каждую мс - может и не успеть.

Спасибо, архитектура AVR ближе, поэтому и смотрю в их сторону.
Но знаний по USB не достаточно, поэтому паралельно просматриваю STM32, где куча примеров в сети...
С другой стороны, те кто пробовал USB в STM32, в один голос твердят, что слишком уж запутано там всё, и новичку проще начать осваивать USB на других контроллерах.
Вот и дилема...
А вообще, задача простейшая, необходимо подключить USB флешку, и работать с файловой системой!

Falkon_99, Обратите внимание на STM32CubeMX.
Это генератор скелета программы, подключающий драйвера и библиотеки, назначающий выводы.
Довольно дружелюбный.
После установки дайте ему скачать библиотеки (CubeF2, CubeF4, ...) для соответствующего контроллера.

Хост ничего такого делать не должен, поскольку именно он - активное начало в трансфере. Только хост может обратиться к девайсу и чего-то от него потребовать, а девайс обязан дать ответ не позднее, чем наступит таймаут. Более того, даже при всем своем желании девайс не имеет возможности вызвать хост или хотя бы подать ему какой-то сигнал без вопроса с его стороны, даже когда девайсу это очень нужно. В этом смысле USB чуточку похож на I2C, где мастер может быть только один, и именно он управляет всей шиной. Поэтому быть хостом просто лепота , поскольку никто тебя не подгоняет: не можешь шевелиться быстро - шевелись медленно.

Ну, а обработка данных - совершенно иной вопрос, а потому и не должен обсуждаться в отношении разницы хост-девайс.


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


Ничего себе простейшая. Да это очень трудная задача! Сама файловая система невразумительна - приходится чужой код вживлять, поскольку самой такого не написать. А разговор с флешкой - отдельная премудрость.

Я сама до сих пор файловую систему освоить не могу, хотя уже больше 10 лет с AVR-ками вожусь. Ну, работает она у меня, хоть кровь из носу.

Если мне не изменяет память, то, согласно спецификации, хост должен опрашивать девайс не реже, чем девайс заявил в дескрипторе,
обычно единицы миллисекунд.
Обмен типа interrupt вообще с интервалом 1 или 2 мс, не помню точно.
SW библиотеки хоста требуют таймер, периодом в 1 мс.
Хотя, для самодельной системы, если нет потока данных, может и нет смысла всё строго соблюдатью

Простейшая задача - это в кавычках )))) я себя так утешаю, но делать прийдётся...
спасибо

Верно, 1 мс, если это "full-speed". Однако это требование установили от балды, поскольку ниоткуда эта цифра не вытекает. В спецификации USB 2.0 сказано: "The Host Controller produces SOF tokens at a period of 1 ms when operating with full-speed devices, and at a period of 125 μs when operating with high-speed devices." Т.е. это чистая условность, которую даже девайс не может попросить изменить в передаваемых хосту дескрипторах (я там такого поля даже не нашла).

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

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

Поле bInterval дескриптора Endpoint 1 байт.

Да я не собирался ругать AVR.
Сам на них много чего делаю.
Но USB-хост делать не стал-бы.
Думаю дальше спорить не будем правда?

Я бы тоже USB-хост делать не стала бы, не важно на чем .

Скажите, а как все-таки делают хосты на 3-вольтовых контроллерах? Ведь вроде бы по стандарту положено, чтобы USB был 5-ти вольтовым. Где он возьмет 5 вольт для Ubus, чтобы кормить девайсов? Да и у большинства современных контроллеров даже толерантности к 5-ти вольтам нет. У AT90 таких проблем нет, поскольку они сами пятивольтовые, а как решается вопрос совместимости 3-вольтового хоста и 5-вольтовых девайсов?

1) Линии D+ и D- не 5-вольтовые, а существенно меньше, и могут принимать несколько значений.
Поэтому 3,3 или 5 вольт питание - неважно.
2) Для USB3 есть спец. микросхемы физического уровня ULPI<-> USB
3) Хост должен обладать собственным мощным 5-вольтовым источником - никуда не деться...
Это питание, через ключи с токовой защитой, а в последнее время, часто просто через термопредохранители (самовосстанавливающиеся) подаётся на питание - линию VBUS.

Для USB3 можно посмотреть ISP1705AET

Мало того, при подаче уровня выше +3,3В на эти линии - устройство может не определяться в системе. Ведь Low, Full, High определяются подтягивающими резисторами к +3,3В и защитные элементы тоже.

Не определяться - ладно. Но не погорит ли 3-вольтовый МК, если ему подадут 5-вольт на линии D+ и D-? Ведь указание об отсутствии толерантности к 5-ти вольтам не оговаривает исключений для линий D+ и D-.

Максимальное напряжение на выводах D+ и D- м.б. 3,6 вольта, при штатном использовании.
Большее напряжение можно только принудительно подать, в обход USB.
Тем не менее, защита от статики обычно имеет верхнюю опору VBUS,
так что при кратковременной подаче +5 вольт сгореть не должны.

Кажется, я поняла причину своих опасений. Это я по аналогии с Xmega, где линии D- и D+ являются альтернативными функциями порта D (буква D там и там - просто случайность), подумала, что и у AT90 это так. Ведь ничто не мешает контроллеру использовать порт по прямому назначению. Вот и испугалась, что AT90 тоже может выставить на этом порту высокий уровень, чем и повредить присоединенным к его линиям USB другим устройствам, толерантности к 5-вольтам не имеющим.

Полезла в даташиты и обнаружила, что у AT90 линии D- и D+ не являются портами. Т.е. подать на них 5 вольт, в результате програмистской ошибки, на них невозможно. Правда у AT90USB82/162 эти линии совмещены с линиями I2C (SDA и SCL), но это не страшно, т.к. там "открытый коллектор".