ATXMEGA и USB Опции

[Дмитрий_Мигачев]

Решил начать работать с USB. Очень много начитался, понял, что наверное это будет освоить самому не просто и решил использовать готовую либу - LUFA.
USB нужно CDC.
Библиотека очень достойная, много примеров, не вижу смысла изобретать свой велосипед.
Но есть одна не понятность. Там в примере VirtualPort тактировка USB идет от внутренних 2 МГц с использованием DFLL на 48 МГц (если правильно описал).
У меня внешний кварц на 16 МГц, PLL блок выдает на процессор 32 МГц. Вот тут я не понимаю, этот же PLL может выдать 48 МГц для USB или мне нужно идти таким же путем как LUFA. Нашел информацию, что в XMEGA все источники тактирования (все доступные) могут работать одновременно. Но вроде как внешний кварц должен быть самым точным, но нигде не нашел как его использовать для USB fullspeed.

[Xenia]

На сколько я представляю (больше по старым AT90USBxxx) частоту сначала делят прескайлером до 2 МГц, а уж только потом подают на блок USB, у которого есть своя PLL. Причем, это приходится делать даже тогда, когда, казалось бы, основная частота вполне подходящая. Казалось бы, бери 16 МГц да умножай на 3, - вот тебе и 48 МГц. Ан нет - сначала эти 16 МГц поделят на 8, чтобы получить 2 МГц, а уж только потом USB превратит их в нужные ей 48 МГц.

Как теперь это сделано на XMega точно не знаю, но судя по тому, что там тоже стоит USBCTRL с делителями 1, 2, 4, 8, 16, 32, то похоже, что тут тоже надо делить до 2 МГц, т.к. иначе зачем стоит делитель, а не умножитель?

[Duhas]

на сколько я помню как раз таки встроенный 32МГц генератор с помощью DFLL догоняют до 48 МГц, хотя вероятно возможны варианты.

[Дмитрий_Мигачев]

...а уж только потом подают на блок USB, у которого есть своя PLL

Спасибо за ответ.
Была такая мысль, а именно мысль - а зачем же там делитель...
Не могу только найти в даташите регистр PLL для USB. Может плохо смотрю?

на сколько я помню как раз таки встроенный 32МГц генератор с помощью DFLL догоняют до 48 МГц, хотя вероятно возможны варианты.

Ну не только 32 МГц встроенный, также 2 МГц'вый

Или быть может достаточно 1) Поделить частоту прескайлером 2) В CLK.USBCTRL выбрать USB clock source -> PLL 3) В USB.CTRLA выбрать Speed Select (Bit 6) Ну и включить USB? В любом случае буду сейчас пробовать

[Дмитрий_Мигачев]

Пока не фига не работает..Но при инициализации USB вижу какие-то импульсы очень короткие на осциллографе. Чтото не так делаю

[prottoss]

На сколько я представляю...

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

Пока не фига не работает..

Почитайте внимательно даташит на контроллер.
Раздел System Clock and Clock Options->Overview, рисунок The clock system, clock sources, and clock distribution

Там все наглядно показано.

[ArtemKAD]

Оттуда следует, что запустить USB можно и на разогнанном и подстроенном 32МГц RC-генераторе. Т.е. теоретически можно вообще без кварца? Кто-то такое пробовал?

[Дмитрий_Мигачев]

[/b]Там все наглядно показано.

К сожаление, наверное я туповат, я не понимаю как мне получить 48 МГц из PLL, если из того же PLL идет 32 МГц для ЦПУ.

[DmitryM]

Оттуда следует, что запустить USB можно и на разогнанном и подстроенном 32МГц RC-генераторе. Т.е. теоретически можно вообще без кварца? Кто-то такое пробовал?

Atmel AVR1017: XMEGA - USB Hardware Design Recommendations

The 12Mbit/s USB FS signal rate specification requires 0.25% accuracy. In addition,
the data recovery mechanism requires an internal Ч4 oversampling mechanism.
Thus, the device should be able to generate an accurate, 48MHz signal clock to the
USB module.
To ensure proper signal quality, the Atmel AVR XMEGA provides different ways to
generate the 48MHz oversampling frequency:
• External crystal and the on-chip PLL
• Internal RC oscillator
The most convenient method is to use the on-chip, 32MHz RC oscillator calibrated at
48MHz. To ensure 0.25% signal rate accuracy, the internal RC oscillator should be
auto-calibrated using an internal DFLL. This solution allows the external BOM cost to
be reduced (no need for an external crystal).
NOTE The USB module for XMEGA requires a minimum 12MHz CPU clock to send and
receive data. Be sure to configure the XMEGA system clock with a minimum 12MHz
clock when using the USB module. This clock can be stopped when USB is in
suspend mode.

[Duhas]

Оттуда следует, что запустить USB можно и на разогнанном и подстроенном 32МГц RC-генераторе. Т.е. теоретически можно вообще без кварца? Кто-то такое пробовал?

DFU bootloader такое пробует и не плюется..
и как уже посоветовали - читайте документацию, товарищи, тем более что у атмела она вполне приятная и читаемая

[prottoss]

К сожаление, наверное я туповат, я не понимаю как мне получить 48 МГц из PLL, если из того же PLL идет 32 МГц для ЦПУ.

Нет не туповат. На самом деле не это не возможно. Дело все в том, что делители в XMEGA могут делить только на степень двойки, в то время как отношение 16 МГц и 48 МГц равно 1 к 3. Есть два пути:

1. Использовать для тактирования USB кварц а для тактирования ЦПУ - встроенный генератор 32 МГц.
2. Использовать для тактирования USB кварц и тактировать ЦПУ от 24 МГц.

Я не рассматриваю пути с разными извратами типа разгона встроенного генератора.

Сам использую в проекте кварц на 7,3728 МГц, так как использую еще и USART. PLL умножает на 13 и имеет выходную частоту 95,8464 МГц. Дальше для USB делим на 2 (47,9232 МГц) а для ЦПУ на 4 (23,9616 МГц).

[Duhas]

ну степень извращенности данного решения под большим вопросом, т.к. по сути
для этого встроенного RC генератора производитель дает таблицу калибровочных значений, для точного выставления целой группы частот, в том числе и 48МГц. И на сколько я понимаю атымелы считают данный вариант не менее чем 100% работоспособным и достаточно точным для корректной работы USB.

[Дмитрий_Мигачев]

Сам использую в проекте кварц на 7,3728 МГц, так как использую еще и USART. PLL умножает на 13 и имеет выходную частоту 95,8464 МГц. Дальше для USB делим на 2 (47,9232 МГц) а для ЦПУ на 4 (23,9616 МГц).

Спасибо большое, понял.
Наверное действительно пойду путем как говорит Duhas, ибо сам в даташите вычитал что RC генератора для USB целей за глаза
Да, Duhas Вам тоже спасибо, мне просто иногда нужен "волшебный пинок" в правильном направлении ))

[Дмитрий_Мигачев]

Пока запустить не удалось. Разбираюсь. Кстати контроллер у меня ATXMEGA128A1U.
В документации LUFA версии 130901 написано:

Early silicon revisions of the ATXMEGA128A1U are incompatible with LUFA, due to their various errata relating to the USB controller

Как узнать какая у меня ревизия ( после названия контроллера на микросхеме есть только цифры 1311 ), и с какими ревизиями не совместима LUFA, в документации этого не нашел.
Микроконтроллеры куплены пол года назад, думаю что ревизия не должна быть старой.

Кстати, пришла мысль в голову, что возможно нет поддержки в ядре (gentoo linux)
Выхлоп dmesg:

Код

[24379.985684] hub 1-1.4.1:1.0: state 7 ports 4 chg 0000 evt 0004
[24379.986251] hub 1-1.4.1:1.0: port 2, status 0101, change 0001, 12 Mb/s
[24380.090367] hub 1-1.4.1:1.0: debounce: port 2: total 100ms stable 100ms status 0x101
[24380.101357] hub 1-1.4.1:1.0: port 2 not reset yet, waiting 10ms
[24380.163288] usb 1-1.4.1.2: new full-speed USB device number 119 using ehci-pci
[24380.175245] hub 1-1.4.1:1.0: port 2 not reset yet, waiting 10ms
[24380.237154] usb 1-1.4.1.2: device descriptor read/64, error -32

Т.е вроде как какое-то новое full-speed устройство обнаруживается, но вот последний error чтото не нравится

Сообщение отредактировал Дмитрий_Мигачев - Sep 18 2013, 10:28

[Duhas]

а зачем вам собственно LUFA? разве нет в ASF примера CDC устройства ?

[zombi]

Как узнать какая у меня ревизия ( после названия контроллера на микросхеме есть только цифры 1311 )

Можно на пузе посмотреть. У моих ревизия "L".




А вот это вообще капец, 1313

[Xenia]

Скажите, а вот выходят даташиты, у каждого из которых тоже есть номер ревизии, - эта ревизия имеет отношение к ревизии микросхемы?

Сейчас, например, последний даташит на ATxmega128A1U/64A1U маркирован ревизией "E". А у zombi на чипах уже ревизия "L". Даже завидки берут .

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

P.S. Заглянуть под брюхо своей ATxmega128A1 (без U) я не могу - она припаяна (не мной) . Но есть у этого семейства такой регистр - MCU.REVID. Читается, как обычный регистр (не fuse). Вот что про него написано в мануале:

REVID – Revision ID
Bit 7:4 – Reserved. These bits are unused and reserved for future use.
Bit 3:0 – REVID[3:0]: Revision ID. These bits contains the device revision. 0 = A, 1 = B, and so on.

Только что прочла у себя этот бит - в нем число 7. Считаю буквы по порядку:
0 = A
1 = B
2 = C
3 = D
4 = E
5 = F
6 = G
7 = H (это моя, ура!)

[zombi]

7 = H (это моя, ура!)

Срочно меняйте это старьё на A1U!!! Не пожалеете.

[Дмитрий_Мигачев]

а зачем вам собственно LUFA? разве нет в ASF примера CDC устройства ?

Интернеты сказали, что она лучше по всем параметрам

[Дмитрий_Мигачев]

Можно на пузе посмотреть. У моих ревизия "L".

Да, у меня тоже L

[Xenia]

Срочно меняйте это старьё на !!! Не пожалеете.

Интернеты сказали, что она лучше по всем параметрам

Я и сама знаю, что A1U лучше, чем A1, но плата у меня не самодельная, а у Olimex купленная (AVR-PX128A1). А уж сменить МК, да еще в таком корпусе, и на уже готовой плате, - это целая эпопея. Трудности на этом пути сильно превосходят мои возможности . А вот готовых плат на A1U я что-то не вижу, даже у самого Atmel'а.

Ни у кого из присутствующих нет желания подарить мне платку с A1U? Или хотя бы продать по себестоимости?

[Duhas]

у меня остались платки от древнего проекта на А1, там по сути все порты выведены на гребенки с шагом 2.54 только с аналоговыми немного муть ..

ежели сильно надо могу выслать одну "по себестоимости"..

ПС вместе с A1U конечно же )

Сообщение отредактировал Duhas - Sep 19 2013, 13:01

[zombi]

Ни у кого из присутствующих нет желания подарить мне платку с A1U?

Без проблем.
Для экспериментов делал.
Сейчас просто валяются.
Питание разведено и почти все остальные все пины на гребёнки выведены.
В Киеве.

[Дмитрий_Мигачев]

Обнаружил небольшие косячки в своем коде. Исправил и увидел импульсы прямоугольные с разным чередованием на осциллографе.
Но что-то к сожалению пока все равно не так. Когда моя плата подключена к компьютеру, он даже из-за этого после биоса не загружается, видимо постоянно с USB чтото опрашивает.
В логах такое:

CODE

[ 1338.314407] usb 1-1.3.3: new full-speed USB device number 10 using ehci-pci
[ 1343.307366] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d82
[ 1343.307375] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1348.300453] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d80
[ 1348.300461] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1353.293663] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d82
[ 1353.293672] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1353.356599] usb 1-1.3.3: device descriptor read/64, error -110
[ 1358.450522] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d82
[ 1358.450557] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1363.443483] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d82
[ 1363.443495] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1368.436695] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d82
[ 1368.436711] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1368.447682] hub 1-1.3:1.0: port 3 not reset yet, waiting 10ms
[ 1368.509598] usb 1-1.3.3: device descriptor read/64, error -110
[ 1368.621441] hub 1-1.3:1.0: port 3 not reset yet, waiting 10ms
[ 1368.683355] usb 1-1.3.3: new full-speed USB device number 11 using ehci-pci
[ 1373.676439] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d82
[ 1373.676447] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1378.669525] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d82
[ 1378.669554] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1383.662611] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d82
[ 1383.662619] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1383.673610] hub 1-1.3:1.0: port 3 not reset yet, waiting 10ms
[ 1383.735513] usb 1-1.3.3: device descriptor read/64, error -110
[ 1388.829456] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d80
[ 1388.829491] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1393.822417] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d80
[ 1393.822452] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1398.815629] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80400d80
[ 1398.815665] usb 1-1.3.3: khubd timed out on ep0in len=0/64
[ 1398.826617] hub 1-1.3:1.0: port 3 not reset yet, waiting 10ms
[ 1398.888532] usb 1-1.3.3: device descriptor read/64, error -110
[ 1399.051306] usb 1-1.3.3: new full-speed USB device number 12 using ehci-pci
[ 1404.044389] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80008d80
[ 1404.044542] usb 1-1.3.3: khubd timed out on ep0out len=0/0
[ 1409.238195] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80008d82
[ 1409.238224] usb 1-1.3.3: khubd timed out on ep0out len=0/0
[ 1409.438656] usb 1-1.3.3: device not accepting address 12, error -110
[ 1409.449908] hub 1-1.3:1.0: port 3 not reset yet, waiting 10ms
[ 1409.511824] usb 1-1.3.3: new full-speed USB device number 13 using ehci-pci
[ 1414.504902] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80008d80
[ 1414.504937] usb 1-1.3.3: khubd timed out on ep0out len=0/0
[ 1419.698710] usb 1-1.3: clear tt buffer port 3, a0 ep0 t80008d82
[ 1419.698744] usb 1-1.3.3: khubd timed out on ep0out len=0/0
[ 1419.899174] usb 1-1.3.3: device not accepting address 13, error -110
[ 1419.899457] hub 1-1.3:1.0: unable to enumerate USB device on port 3
[ 1419.899685] hub 1-1.3:1.0: state 7 ports 4 chg 0000 evt 0008

Быстрое гугление пока не дало результата в поиске ошибки. Сейчас на месяц вынужден прерваться на другой важный проект, но эту задачу все равно рано или поздно решу.

Сообщение отредактировал IgorKossak - Sep 23 2013, 11:25

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!

[ReMaster]

а зачем вам собственно LUFA? разве нет в ASF примера CDC устройства ?

Использую данную библиотеку и по ней есть вопрос: иногда проект входит в режим, когда прерывание ISR(USB_BUSEVENT_vect) вызывается постоянно, а не с 1 мс периодичностью, с заходом в
udd_ctrl_interrupt_error()
в часть:
// Underflow only managed for control endpoint
прямо внутрь:
if (udd_control_in_underflow()) {
udd_ctrl_underflow();
}

не могу понять, почему флаг опустошения постоянно формируется... посоветуете что-нибудь по этому поводу?

[Duhas]

я - нет, я просто знаю что есть в ASF ) сам не ковырялся с USB еще..

[piroman]

USB сложен. У меня тоже проблема: периодическое нарушение работы экспериментального девайса после отключения холодильника на кухне. Проходит импульс по питанию. Но суть не в импульсе, а в том что работа USB не восстанавливается полностью, а должна вроде? Ну типа прислать Clear Feature для проблемной конечной точки и т.д.

[Дмитрий_Мигачев]

USB сложен. У меня тоже проблема: периодическое нарушение работы экспериментального девайса после отключения холодильника на кухне. Проходит импульс по питанию. Но суть не в импульсе, а в том что работа USB не восстанавливается полностью, а должна вроде? Ну типа прислать Clear Feature для проблемной конечной точки и т.д.

Я все больше начинаю задумываться, что может быть не стоит в серьезных проектах браться за USB. Но с другой стороны смущает, что на новых материнках все реже встречается rs-232

P.S. Вот даже не знаю, что дальше делать. Главный инженер говорит давай USB. Я ему объяснил чем USB плох, он говорит может тогда wifi или bluetooth, тоже кажется в промыленных условиях не совсем надежно, данных надо гнать не много, но нужна хорошая надежность и обязательно гальваническая развязка с компьютером. Если например гальваническую развязку RS-232 сделать не проблема, скорости небольшие через оптопары, то USB я так понимаю там даже при передаче 1 байта, частота передачи все равно большая (?????). Есть в наличии WIFI модуль WF121-A-v1, входные данные по UART на выходе радиоканал. Или все-таки надо отстаивать мнение что RS-232 самое надежное??

Сообщение отредактировал Дмитрий_Мигачев - Nov 14 2013, 04:59

[dimka76]

и обязательно гальваническая развязка с компьютером. Если например гальваническую развязку RS-232 сделать не проблема, скорости небольшие через оптопары, то USB я так понимаю там даже при передаче 1 байта, частота передачи все равно большая (?????).

Analog Device выпускает специальные микросхемы для гальванической развязки USB FULL SPEED.

http://www.analog.com/en/interface-isolati...ucts/index.html

[kovigor]

Я все больше начинаю задумываться, что может быть не стоит в серьезных проектах браться за USB. Но с другой стороны смущает, что на новых материнках все реже встречается rs-232

В промышленных условиях нужно использовать не USB, а тот же RS232 или RS485. Оптически развязанная версия RS232 - это "токовая петля" ("Current Loop", она же "CL"). Если скорости позволяют, конечно. Покупаете качественный компьютер и мультипортовку от той же MOXA. Ну или промышленный компьютер покупаете с соотв. портами. USB для серьезных применений не годится. То, что "на современных материнках нет COM-портов" - не аргумент. Это офисные компьютеры, вот COM - портов там и нет. Для офисных - да, сгодится и USB. Но не более того.

P.S. Если позволяют скорости - я бы однозначно отстаивал один из вариантов RS232. Только мультипортовку качественную купите ...
P.P.S. Вам, кстати, на какое расстояние нужно данные передавать ?

[Дмитрий_Мигачев]

В промышленных условиях нужно использовать не USB, а тот же RS232 или RS485. Оптически развязанная версия RS232 - это "токовая петля" ("Current Loop", она же "CL"). Если скорости позволяют, конечно. Покупаете качественный компьютер и мультипортовку от той же MOXA. Ну или промышленный компьютер покупаете с соотв. портами. USB для серьезных применений не годится. То, что "на современных материнках нет COM-портов" - не аргумент. Это офисные компьютеры, вот COM - портов там и нет. Для офисных - да, сгодится и USB. Но не более того.

P.S. Если позволяют скорости - я бы однозначно отстаивал один из вариантов RS232. Только мультипортовку качественную купите ...
P.P.S. Вам, кстати, на какое расстояние нужно данные передавать ?

2 -3 метра, не более

P.S. А нет ли сейчас тенденции вытеснения RS-232 не только с офисных компьютеров??? Все любят сэкономить, и мы не исключение Для наших целей порой за глаза материнки на каком-нибудь intel atom, они тоже иногда встречаются без RS-232. И как дела обстоят с передачей большого количества информации в ПК, через что для надежности?

Сообщение отредактировал Дмитрий_Мигачев - Nov 14 2013, 08:09

[kovigor]

Все любят сэкономить, и мы не исключение Для наших целей порой за глаза материнки на каком-нибудь intel atom, они тоже иногда встречаются без RS-232.

Вы готовы к проблемам, связанным с потерей связи через USB в самый неподходящий момент ? Готовы нести за это ответственность ? Если да, то пользуйтесь USB. Если нет - не экономьте, и применяйте для ответственных задач соотв. аппаратуру.
Если произойдет авария, никто, поверьте, не похвалит вас за то, что вы сэкономили 200 баксов на оборудовании.

[prottoss]

Вы готовы к проблемам, связанным с потерей связи через USB в самый неподходящий момент ?

А Вы готовы к потерям связи по RS232/485/CAN/Ethernet и т.п. в самый не подходящий момент? От обрыва проводов никто не застрахован.

Моя работа связана с горной промышленностью/подземным оборудованием. Порты USB на этом оборудовании тоже имеются, правда не в самых ответственных приложениях. Для ответственных приложений используется CAN/Ethernet/RS485 ну и в придачу надежные протоколы.
RS232 вообще в горной промышленности не используется, т.к не надежен из-за привязанности к "земле" и по надежности на порядок ниже чем USB, ибо USB это все таки дифф.пара, при чем с защитой данных на железном уровне. USB на расстояние 2-3 метра на много лучше чем RS232.
Конечно все это ИМХО

[kovigor]

А Вы готовы к потерям связи по RS232/485/CAN/Ethernet и т.п. в самый не подходящий момент?

RS232 надежнее USB на порядок из-за своей простоты (как минимум). На практике у нас системы с RS232 работали по году вообще без всякого вмешательства. Нужна развязка ? Не вопрос. Мультипортовка с Current Loop полностью решает проблему.
А вот личный опыт общения с USB у меня совсем не такой приятный, к сожалению. А практика - критерий истины, как вам, конечно же, известно ...

[prottoss]

RS232 надежнее USB на порядок из-за своей простоты (как минимум).

1. Если говорить о линиях связи, то RS232 и USB одинаково просты - в обоих интерфейсах необходимо минимум три провода - земля и две линии данных.
2. Если говорить о помехозащищенности, то как раз RS232 проигрывает USB во многом. Плюсы USB - дифф. пара, NRZI, жесткий протокол, при чем на железном уровне. У RS232 - единственная защита - бит четности/паритета.
3. Если говорить о стоимости, то на сегодняшний момент стоимость приемопередатчика для USB дешевле, т.к. он обычно встроен в микроконтроллер. Для RS232 нужно ставить внешний драйвер.
4. Если говорить о программном уровне, то у USB он относительно сложный по сравнению с RS232, что компенсируется надежностью самого протокола в пользу USB. Для тех кто понимает USB нет проблем создать такой интерфейс в своей программе.
Если Ваш личный опыт общения с USB неприятный, не значит что он таков у всех.
Опять же ИМХО - RS232 - в промышленности давно уже раритет как по помехоустойчивости так и по скорости передачи данных.

По поводу вышесказанного про холодильники. Возможно, проблема не в USB а в том, что плата не верно разведена.

[kovigor]

1, 2, 3, 4

И несмотря на это RS232 годами работает без сбоев, а USB сбоит чуть ли не при первом же удобном случае.
Ладно. Похоже, сейчас начнется очередная "религиозная война". Ни вы меня не убедите, ни я вас. Предлагаю на этом закончить ...

[prottoss]

Предлагаю на этом закончить ...

Согласен

[ArtemKAD]

2. Если говорить о помехозащищенности, то как раз RS232 проигрывает USB во многом. Плюсы USB - дифф. пара, NRZI, жесткий протокол, при чем на железном уровне. У RS232 - единственная защита - бит четности/паритета.

Крайне спорное утверждение. Главная защита RS232 это громадные по сравнению с USB зоны гистерезиса плюс большие допуски по времени фронтов. Даже без контроля чётности вероятность ошибки в RS232 многократно ниже чем в USB с диф.парой, контрольной суммой и всеми подстройками. Как результат USB при кабеле больше 10м это почти наверняка труп, при том, что RS232 свободно работает и больше 100м.

[prottoss]

Крайне спорное утверждение.

Это бесспорное утверждение

Главная защита RS232 это громадные по сравнению с USB зоны гистерезиса плюс большие допуски по времени фронтов.

Главный недостаток RS232 - передача сигналов относительно земляного провода. В промышленности однозначно используется передача данных по дифф. паре, не зависимой от земли.

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

RS232 свободно работает и больше 100м.

Работает. Только на "золотом" кабеле и на ооочень маленькой скорости. Никто его на таких длинах не использует, потому как для таких длин есть симметричные RS422/485.

[zombi]

Работает. Только на "золотом" кабеле и на ооочень маленькой скорости. Никто его на таких длинах не использует, потому как для таких длин есть симметричные RS422/485.

Не хочу вступать в дискуссию.
Скажу только что видел в работе на обычном 4-х жильном телефонном кабеле длиной ~75м обычный RS232.
На скорости 56кбод, правда только в одну сторону. Работало без нареканий.

[piroman]

По поводу холодильника. Сижу за компьютером, плату с USB проверяю, для ускорения процесса помеху по сети создаю вкл/выкл бытового вентилятора. В компьютерных динамиках слышно "ЩЁЛК"! У меня корпус ограничен в габаритах, не могу я там фильтров дополнительных поставить. Я ж энергию беру с сетевого адаптера 12 В. 3 штуки попробовал разных ентих адаптеров. На самом простом - сбоит почти каждый раз, а на других ничего вроде - редко. В худшем случае всё ж продолжает работать, акромя USB - приходится реконнектить. Тяжко разбираться, кабы был у мени аппаратный USB-протоколёр.
Вообще, реально этот импульс по питанию подавить напрочь? Он, как я понимаю, короткий и мощный. Использую цепочку TVS-диод на 14В -> ферритовую бусину -> LM78L33 c керамическими кондёрами -> TVS-диод на 5В -> XMEGA c USB.
У нас тут модернизировали одно старое устройство с RS232 на max232. Убрали max232 c обвязкой, добавили 2 оптрона+FT232RL = модный USB + опторазвязка.

[kovigor]

Скажу только что видел в работе на обычном 4-х жильном телефонном кабеле длиной ~75м обычный RS232.
На скорости 56кбод, правда только в одну сторону. Работало без нареканий.

У нас через простейший преобразователь RS232 в токовую петлю запросто и надежно получалось и 500 метров. Скорость 19200. Больше просто не пробовали ...

[ArtemKAD]

Любой интерфейс, использующий дифф. пару (в том числе и USB), т.е. симметричный, на порядок помехоустойчив чем RS232.

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

Работает. Только на "золотом" кабеле и на ооочень маленькой скорости.

Никакого "золотого" кабеля - на 100м RS232 работает практически на всём. Вот если надо больше - вот там уже возникают вопросы.

[prottoss]

kovigor, ArtemKAD
Я не буду с Вами спорить. Можете передавать по RS232 хоть на 5 километров. По поводу USB - на большие дистанции он и не предназначен - 5 метров, наверное, максимум. Но на 100 метров и RS232 в серьезных приложениях не используют - для этого есть RS422/485, если нужно очень много и очень быстро, то Ethernet, если еще быстрее, то оптоволокно.

[Дмитрий_Мигачев]

Спасибо большое всем за ответы. Прошу не судить строго, но решили все-таки пробовать дальше USB. Прогресс на месте не стоит, и я думаю если будут проблемы со связью найдем как их решить.

[kovigor]

Спасибо большое всем за ответы. Прошу не судить строго, но решили все-таки пробовать дальше USB. Прогресс на месте не стоит, и я думаю если будут проблемы со связью найдем как их решить.

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

[piroman]

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

[kovigor]

Вот тут обсуждается.

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

[Alex11]

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

[prottoss]

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

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

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

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

[kovigor]

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

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

[prottoss]

Кстати, вам не кажется странным, почему я не нападаю, например, на PCI, на ETHERNET, на PCI Express ?

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

Кстати, вам не кажется странным, почему я не нападаю, например, на PCI, на ETHERNET, на PCI Express ?

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

А только лишь на USB ? А ? Может, все-таки не во мне дело ?

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

Так продукты-то не мои ! Примерно одинаковые по качеству результаты демонстрируют изделия самых разных производителей.

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

[Ruslan.B]

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

[DmitryM]

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

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

[TriD]

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

[Falkon_99]

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

[Xenia]

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

Нету.

[Falkon_99]

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

[Копейкин]

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

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

[Xenia]

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

Я работала, с 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, что обидно.

Или не заморачиватся и использовать STM32 контроллеры, на которые есть куча примеров ?

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

[Копейкин]

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

[Falkon_99]

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

[Копейкин]

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

[Xenia]

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

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

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

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

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

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

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

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

[Копейкин]

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

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

[Falkon_99]

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

[Xenia]

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

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]

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

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

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

[Копейкин]

Скажите, а как все-таки делают хосты на 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]

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

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

[Xenia]

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

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

[Копейкин]

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

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

[Xenia]

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

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

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