Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: USB в AVR
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
A_MIKE
Хочу попросить помощи. Нужно разобраться с USB в XMega (в любой AVRке).
Ситуация такая, разработкой на AVR занимаюсь давно. Все устройства сливают данные в ПК. Всегда все решалось через UART > RS232. Потом использовался мост UART > USB. Но это уже не проходит.
Как к проблеме подступиться? Буду ОЧЕНЬ признателен за наставления, советы и любые материалы (особенно на русском языке).
kovigor
Цитата(A_MIKE @ Mar 12 2013, 18:14) *
Хочу попросить помощи. Нужно разобраться с USB в XMega (в любой AVRке).
Ситуация такая, разработкой на AVR занимаюсь давно. Все устройства сливают данные в ПК. Всегда все решалось через UART > RS232. Потом использовался мост UART > USB. Но это уже не проходит.
Как к проблеме подступиться? Буду ОЧЕНЬ признателен за наставления, советы и любые материалы (особенно на русском языке).

На русском - книжка ГукаЖ
http://rutracker.org/forum/viewtopic.php?t=2466185
и книги Jan Axelson (все, которые найдете). На английском - прежде всего спецификация. Ну и еще поищите в сети "USB in a nutshell". А дальше - поиск и анализ готовых примеров для вашего МК ...
bob1
В Atmel Studio 6.0 есть готовые примеры.
A_MIKE
Спасибо большое. Но может кто подскажет какую нибудь "квинтэссенцию". sm.gif
Очень нужно быстро проект сделать. Может даже пока "как обезьяна" не вдаваясь глубоко в детали.
kovigor
Цитата(A_MIKE @ Mar 13 2013, 12:15) *
Спасибо большое. Но может кто подскажет какую нибудь "квинтэссенцию". sm.gif
Очень нужно быстро проект сделать. Может даже пока "как обезьяна" не вдаваясь глубоко в детали.

Ничего не выйдет. Или выйдет, но так, что лучше бы вообще никак не выходило. USB - не UART. Очень быстро можно только купить готовый переходник USB<->COM.
Да. Выбирая USB для связи с машиной, вы должны помнить о надежности такого решения. Для реализации надежного обмена, способного работать без вмешательства человека хоть сколько-нибудь продолжительное время, USB не годится. И для необслуживаемых (или труднодоступных) систем/объектов USB тоже не подойдет...
A_MIKE
Цитата(kovigor @ Mar 13 2013, 12:33) *
Ничего не выйдет. Или выйдет, но так, что лучше бы вообще никак не выходило. USB - не UART. Очень быстро можно только купить готовый переходник USB<->COM.
Да. Выбирая USB для связи с машиной, вы должны помнить о надежности такого решения. Для реализации надежного обмена, способного работать без вмешательства человека хоть сколько-нибудь продолжительное время, USB не годится. И для необслуживаемых (или труднодоступных) систем/объектов USB тоже не подойдет...


Это я понимаю. Но нужно только USB. Сейчас все работает через мост (переходник USB<->COM, микросхема встроенная в само устройство). Раньше хватало. А вот сейчас срочно понадобился USB в нормальном виде sad.gif
kovigor
Цитата(A_MIKE @ Mar 13 2013, 12:53) *
Но нужно только USB

Пусть работает, как есть. Быстро вы не сделаете, забудьте об этом. А заодно разъясните вашему работодателю, что USB и надежность - понятия несовместимые. А если он будет упорствовать, используйте ИС преобразователя вроде FT232BM, пусть он кушает свое USB с маслом и вкушает последствия, так сказать ...
A_MIKE
Цитата(kovigor @ Mar 13 2013, 13:07) *
Пусть работает, как есть. Быстро вы не сделаете, забудьте об этом. А заодно разъясните вашему работодателю, что USB и надежность - понятия несовместимые. А если он будет упорствовать, используйте ИС преобразователя вроде FT232BM, пусть он кушает свое USB с маслом и вкушает последствия, так сказать ...


Да сейчас так и происходит. Только микросхема другая sm.gif. Но все дело в том что нужно на нормальном USB сделать. Про надежность речи пока не идет...
kovigor
Цитата(A_MIKE @ Mar 13 2013, 12:59) *
Да сейчас так и происходит. Только микросхема другая sm.gif. Но все дело в том что нужно на нормальном USB сделать. Про надежность речи пока не идет...

Тогда придется разбираться, а это займет время ...
A_MIKE
Цитата(kovigor @ Mar 13 2013, 14:12) *
Тогда придется разбираться, а это займет время ...


В том то и вопрос... Какой нибудь быстрый ликбез на 10 страницах... (может чудеса иногда случаются?)
kovigor
Цитата(A_MIKE @ Mar 13 2013, 18:50) *
В том то и вопрос... Какой нибудь быстрый ликбез на 10 страницах... (может чудеса иногда случаются?)

Забудьте. Спешка нужна при охоте на блох. Если нужен результат, придется потрудиться основательно, тема сложная. Можно, конечно, надергать отовcюду "либ", "сорцов" (терпеть не могу эти слова), кусков кода, слепить все это в кучу без понимания сути и выдать за работающий проект. Но тогда готовьтесь к тому, что в один прекрасный момент "это" откажется работать, и вы в этой ситуации будете совершенно беспомощны ...
A_MIKE
Цитата(kovigor @ Mar 13 2013, 19:04) *
Забудьте. Спешка нужна при охоте на блох. Если нужен результат, придется потрудиться основательно, тема сложная. Можно, конечно, надергать отовлюду "либ", "сорцов" (ненавижу эти слова), кусков кода, слепить все это в кучу без понимания сути и выдать за работающий проект. Но тогда готовьтесь к тому, что в один прекрасный момент "это" откажется работать, и вы в этой ситуации будете совершенно беспомощны ...


Уговорили... Придется напрячься. Спасибо за участие и потраченное время.
Diusha
О-па! Наткнулся на уже заданный вопрос, который сам хотел задать. Причем ситуация у A_MIKE почти слово-в-слово моя! sm.gif
Похоже, единственное отличие, что я еще FT232 не успел использовать.

Хочется прояснить некоторые вещи.

Цитата(kovigor @ Mar 13 2013, 11:33) *
Выбирая USB для связи с машиной, вы должны помнить о надежности такого решения. Для реализации надежного обмена, способного работать без вмешательства человека хоть сколько-нибудь продолжительное время, USB не годится. И для необслуживаемых (или труднодоступных) систем/объектов USB тоже не подойдет...

Цитата(kovigor @ Mar 13 2013, 12:07) *
USB и надежность - понятия несовместимые. А если он будет упорствовать, используйте ИС преобразователя вроде FT232BM, пусть он кушает свое USB с маслом и вкушает последствия, так сказать ...

Почти каждое слово требует пояснений.
1. USB ненадежен? В чем это выражается?
2. Что значит "вмешательство человека" и что значит "хоть сколько-нибудь продолжительное время"?
3. Что значит "необслуживаемых"? (возможно, этот вопрос можно объединить со 2-м)
4. Какие последствия использования именно FT232 (по сравнению со, скажем, встроенным в AVR)?
maksimp
Цитата(Diusha @ Jul 17 2013, 21:19) *
1. USB ненадежен? В чем это выражается?
2. Что значит "вмешательство человека" и что значит "хоть сколько-нибудь продолжительное время"?

Через некоторое время работы, особенно при коммутации электрических цепей подключённых к устройству (вилку в розетку воткнули, магнитный пускатель щёлкнул), устройство может исчезать из списка устройств в компьютере.
Чтобы возобновить работу, нужно выдернуть USB разъём и вставить обратно.
Цитата(Diusha @ Jul 17 2013, 21:19) *
3. Что значит "необслуживаемых"? (возможно, этот вопрос можно объединить со 2-м)

Расположенных там, куда люди не ходят - обычно не ходят, не должны ходить, для прохода требуется сложная процедура (переодевание во всё белое например), далеко идти, и так далее.
Raven
Можно попробовать еще решение на родственных FT245 / FT2232. Оба имеют 8-битный FIFO-интерфейс, передача по USB осуществляется BULK транзакциями, и не по 1 байту уж точно sm.gif. А FT2232 еще лучше штуку для вашего случая имеет: среди его MPSSE опций есть MCU Host Bus Emulation Mode, т.е. он может отрабатывать транзакции на 8-битной микропроцессорной шине. В общем, я бы присмотрелся - для переходного варианта и быстрого освоения может оказаться самое то.
ЛеонидК
А это не может помочь:
_http://www.gaw.ru/html.cgi/txt/app/micros/avr/AVR309.htm
_http://microsin.ru/content/view/605/
kovigor
Цитата(Diusha @ Jul 17 2013, 20:19) *
1. USB ненадежен? В чем это выражается?
2. Что значит "вмешательство человека" и что значит "хоть сколько-нибудь продолжительное время"?
3. Что значит "необслуживаемых"? (возможно, этот вопрос можно объединить со 2-м)
4. Какие последствия использования именно FT232 (по сравнению со, скажем, встроенным в AVR)?

Это значит, что в любой (как правило, самый неподходящий) момент обмен по USB может сбойнуть или ваше устройство может исчезнуть из системы. При этом почти все равно, на чем именно оно сделано - на FT232 или на AVR. В офисных условиях это не так важно - вынуть разъем и вставить обратно большого труда не составит. Но если устройство задействовано для управления чем-то серьезным, или размещено в труднодоступном или необслуживаемом месте, то такой сбой сулит массу неприятностей. В то же время хорошая мультипортовка с COM - портами может годами работать вообще без всякого вмешательства человека.
А еще USB для реализации COM порта потрясающе сложен и невероятно избыточен. А чем сложнее система, тем менее она надежна. Если бы эта сложность была оправдана, но в данном случае никаких разумных оправданий я не нахожу. Нет у ноутбука COM - портов ? Ну так не используйте ноутбук для серьезных задач. А для подключения какой-нибудь ерунды в офисе или дома сгодится и переходник COM-USB ...
rudy_b
Про ненадежность USB сказано совершенно справедливо. Но есть варианты.
1. Внешнее устройство, не получая некоторое время данные, отключает и снова включает USB. Это эквивалент вынимания/вставки USB устройства.
2. Программа в PC закрывает и снова открывает соединение в аналогичной ситуации.

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

Все равно заморочно, но хоть что-то.
Diusha
Спасибо! В этом смысле ненадежность тогда не так страшна: девайс будет использоваться для воткнуть–переписать–отключить.
Но все же непонятно это:
Цитата(rudy_b @ Jul 18 2013, 01:34) *
делать так, чтобы программа в PC обнаруживала отсутствие связи раньше, чем устройство и закрывала канал. Только потом устройство должно отключиться и включится вновь до того, как программа попробует снова открыть канал.

в виду этого:
Цитата(rudy_b @ Jul 18 2013, 01:34) *
1. Внешнее устройство, не получая некоторое время данные, отключает и снова включает USB. Это эквивалент вынимания/вставки USB устройства.

(мы же вынимаем/вставляем когда захотим)

До кучи еще вопрос (возможно, у меня в голове сейчас полная каша).
Как быть с VID / PID? О том, чтобы зарегистрировать для маленькой фирмочки – нет и речи. Насколько понимаю, для FT232 (и иже ним) есть свой готовый VID. А как поступают при использовании AVR c USB на борту? Придумать свой «от балды»? Какие могут быть проблемы при случайном совпадении (кроме технических)?
Видел, что некоторые маскируются под клавиатуры/мыши/модемы. Этот путь как, совсем через … или нормально?
rudy_b
Тут есть проблемы с виндюками. Если канал открыт а устройство вынули - то драйвер подвисает и без вытыкания/втыкания устройства, а иногда и без перезапуска программы не обойтись.

Поэтому сначала программа должна закрыть канал, потом устройство должно выключится/включится и только потом программа должна снова попытаться открыть канал. Например, программа закрывает канал если нет связи 3 сек, устройство отключает USB через 5 сек после потери связи и снова его включает еще через 2 секунды. Программа пробует восстановить связь через 10 сек после закрытия канала.

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

При этом само устройство может снова перезапускаться через большой и некратный интервал времени если после отключения/включения не прошла енумерация и связь не установлена. Но этого лучше избегать.

Да, потеря связи и отключение устройства - это разные вещи. При отключении виндюки выгружают драйвер.

Можно использовать стандартный атмеловский драйвер CDC устройств и их VID/PID. Все это есть в их примерах.
evsx1
Цитата(A_MIKE @ Mar 13 2013, 19:42) *
Уговорили... Придется напрячься. Спасибо за участие и потраченное время.

Ну почему у того же атмела, есть ASF (Atmel Software Framework),есть аплеухи и примеры моста UART-USB(CDC), HID, MSD. Есть свободный проект LUFA вроде сейчас портанули и на Xmegu. Однако минимальное понимание работы с USB шиной,все же необходимо. Кроме того все готовые решения будут громоздкими(память) и медленными. Но это не говорит об их негодности и тем более,что из-за программных глюков,что-то рабочее вдруг может отвалиться,если уже запустилось. Сам реализовал простое управление RGB на меге ATmega32U4 с помощью ASF. В последствии прикрутил dmx
Diusha
Цитата(rudy_b @ Jul 18 2013, 10:09) *
Например, программа закрывает канал если нет связи 3 сек, устройство отключает USB через 5 сек после потери связи и снова его включает еще через 2 секунды. Программа пробует восстановить связь через 10 сек после закрытия канала.

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

Это стандартный подход, применяемый везде, или "хорошо было бы"?

Цитата(rudy_b @ Jul 18 2013, 10:09) *
Можно использовать стандартный атмеловский драйвер CDC устройств и их VID/PID. Все это есть в их примерах.

Слово "можно" подразумевает НЕединственность решения. А как еще поступают?

Цитата(evsx1 @ Jul 19 2013, 17:14) *
есть ASF ... Есть свободный проект LUFA ...
Однако минимальное понимание работы с USB шиной,все же необходимо. Кроме того все готовые решения будут громоздкими(память) и медленными.

Согласен. Буду потихоньку изучать матчасть
dvm11111111
А если использовать USB HID то драйвера вообше не нужны никакие. Vid pid можно взять из поэктов, есть выкупленные и в свободный доступ выложенные, работа через репорты не очень сложна. Поищи проэкт в нете usb розетка для ноутбука еазывается, там авольно все разжевано и понятно.
piroman
Нужен выкупленный, свободный VID&PID. Где?
kovigor
Цитата(piroman @ Nov 2 2013, 21:54) *
Нужен выкупленный, свободный VID&PID. Где?

Покупать надо. Это если делаете серию и на продажу. А если один, для опытов, то возьмите, например, "1234" и "4321" ...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.