Jump to content

    

ATXMEGA и USB

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

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

 

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites
... буферы конечно выделены и тактируются от PLL, но ещё ведь вопрос обработки данных.

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

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

 

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

 

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

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

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

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

 

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

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

 

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

Share this post


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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

спасибо

Share this post


Link to post
Share on other sites
Если мне не изменяет память, то, согласно спецификации, хост должен опрашивать девайс не реже, чем девайс заявил в дескрипторе,

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

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

Share this post


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

Поле 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-хост делать не стал-бы.

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

Share this post


Link to post
Share on other sites
Да я не собирался ругать AVR.

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

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

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

 

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

 

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

Share this post


Link to post
Share on other sites
Скажите, а как все-таки делают хосты на 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

Share this post


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

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

Share this post


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

 

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

Share this post


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

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

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

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

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

Share this post


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

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

 

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this