[Копейкин 0]

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

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

 

[Falkon_99 0]

Спасибо, архитектура AVR ближе, поэтому и смотрю в их сторону.

Но знаний по USB не достаточно, поэтому паралельно просматриваю STM32, где куча примеров в сети...

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

Вот и дилема...

А вообще, задача простейшая, необходимо подключить USB флешку, и работать с файловой системой!

 

[Копейкин 0]

Falkon_99, Обратите внимание на STM32CubeMX.

Это генератор скелета программы, подключающий драйвера и библиотеки, назначающий выводы.

Довольно дружелюбный.

После установки дайте ему скачать библиотеки (CubeF2, CubeF4, ...) для соответствующего контроллера.

[Xenia 35]

... буферы конечно выделены и тактируются от PLL, но ещё ведь вопрос обработки данных.

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

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

 

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

 

Спасибо, архитектура AVR ближе, поэтому и смотрю в их сторону.

Но знаний по USB не достаточно, поэтому паралельно просматриваю STM32, где куча примеров в сети...

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

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

 

А вообще, задача простейшая, необходимо подключить USB флешку, и работать с файловой системой!

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

 

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

[Копейкин 0]

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

Если мне не изменяет память, то, согласно спецификации, хост должен опрашивать девайс не реже, чем девайс заявил в дескрипторе,

обычно единицы миллисекунд.

Обмен типа interrupt вообще с интервалом 1 или 2 мс, не помню точно.

SW библиотеки хоста требуют таймер, периодом в 1 мс.

Хотя, для самодельной системы, если нет потока данных, может и нет смысла всё строго соблюдатью

[Falkon_99 0]

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

спасибо

[Xenia 35]

Если мне не изменяет память, то, согласно спецификации, хост должен опрашивать девайс не реже, чем девайс заявил в дескрипторе,

обычно единицы миллисекунд.

Обмен типа 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, якобы, может справиться с работой только в качестве девайса, а работа в качестве хоста им не под силу. Тем более, что прием и передача потребляют практически одинаковое количество ресурсов.

[Копейкин 0]

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

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

Interval for polling endpoint for data transfers.

Expressed in frames or microframes depending on the

device operating speed (i.e., either 1 millisecond or

125 μs units).

Да я не собирался ругать AVR.

Сам на них много чего делаю.

Но USB-хост делать не стал-бы.

Думаю дальше спорить не будем ;) правда?

[Xenia 35]

Да я не собирался ругать AVR.

Сам на них много чего делаю.

Но USB-хост делать не стал-бы.

Думаю дальше спорить не будем ;) правда?

 

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

 

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

[Копейкин 0]

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

1) Линии D+ и D- не 5-вольтовые, а существенно меньше, и могут принимать несколько значений.

Поэтому 3,3 или 5 вольт питание - неважно.

2) Для USB3 есть спец. микросхемы физического уровня ULPI<-> USB

3) Хост должен обладать собственным мощным 5-вольтовым источником - никуда не деться...

Это питание, через ключи с токовой защитой, а в последнее время, часто просто через термопредохранители (самовосстанавливающиеся) подаётся на питание - линию VBUS.

 

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

The ISP1705 can transmit and receive USB data at high speed (480 Mbit/s), full speed

(12 Mbit/s) and low speed (1.5 Mbit/s), and provides a pin-optimized, physical layer

front-end attachment to the USB host, peripheral or OTG controller with Single Data Rate

(SDR) or Dual Data Rate (DDR) ULPI link

[DmitryM 0]

1) Линии D+ и D- не 5-вольтовые, а существенно меньше, и могут принимать несколько значений.

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

[Xenia 35]

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

 

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

[Копейкин 0]

Но не погорит ли 3-вольтовый МК, если ему подадут 5-вольт на линии D+ и D-?

Максимальное напряжение на выводах D+ и D- м.б. 3,6 вольта, при штатном использовании.

Большее напряжение можно только принудительно подать, в обход USB.

Тем не менее, защита от статики обычно имеет верхнюю опору VBUS,

так что при кратковременной подаче +5 вольт сгореть не должны.

[Xenia 35]

Максимальное напряжение на выводах D+ и D- м.б. 3,6 вольта, при штатном использовании.

Большее напряжение можно только принудительно подать, в обход USB.

 

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

 

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