есть usb device реализованный на процессоре Cortex-M3 NXP LPC1768, при подключении к компьютеру как виртуальный ком порт, usb там реализован на МК. Требуется сделать для него хост. у меня есть отладка на STM32F207ZET6 решил начать с неё , первое с чем столкнулся это вот http://gyazo.com/b3b84ac864b6e089c610db52759cf8a0
в документе UM1021
User manual STM32F105xx, STM32F107xx, STM32F2xx and STM32F4xx USB On-The-Go host and device library. Правильно ли я понимаю что хост можно сделать ТОЛЬКО ДЛЯ :
1 Mass storage
2 HID (keyboard + mouse)
3 FAT FS file system

и соответственно с помощью этой библиотеки я не смогу сделать нужный хост?? STM32F207ZET6 на этом проце можно както быстро реализовать хост который мне нужен?

Быстро ? Сомнительно. Если надо быстро, то берите отладочную плату с предустановленным Линуксом, там уже все реализовано. Но только на этом МК Линукс не заработает. Вот российские отладочные платы:
http://www.starterkit.ru
А так придется или писать самому (а это очень сложно и совсем не быстро), или искать какие-то библиотеки сомнительного качества.
Кстати, а чем вам обычная персоналка в роли хоста не нравится ?

Да, думаю, вы все правильно понимаете. HID или Mass-Storage для МК в качестве дивайса для МК вполне естественны. А вот виртуальный COM - порт - нет. У МК этих портов и без того куча, причем реальных ...

А LPC 1768 вам почему как хост не нравится? Зачем элементную базу плодить?
у него стандартный железный хост интерфейс, который много чего делает сам, и к нему написано куча оберток упрощающих жизнь.

на уровне приконектился - отконектился, такие контрольные точки, такие данные пришли, такие данные отправить...

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


так то оно так, только те кто делал то с чем мне конектится надо, решили уйти от устаревших ком портов, и передавать данные размером в 10ки байт по USB. и объяснять им, что это маразм оказалось бесполезно.




так получилось что из ARMов я только с stm работал и то не плотно, поэтому решил на них, но если вы говорите что на LPC это может оказаться
намного быстрее и проще наверно стоит посмотреть в эту сторону, а так называемые обёртки , они на оф сайте есть или надо рыскать на просторах интернета?

просто кроме FTDI я вообще USB никакой не делал, и соответственно даже не знаю с чего и начать???
HOST поднимать это не по UARTу в FTDIку данные кидать

Ну тогда вам надо немного ободрится.

Совсем недавно УСБ - был мрак, и лет 5 назад я бы за хост интерфейс вообще не взялся бы. Хосту надо следить за огромным количеством всего и вся, слать пакеты по таймеру, следить за аками и наками и прочее...

Был такой же мрак как лет 7-10 назад с усб девайсами, но благодаря стараниям производителей процов УСБ - хост повернулся к нам человеческим лицом.

В частности LPC1768 имеет внутри host controller, совместимый с OHCI, это прям такой стандарт, что на него даже нет описания в мануале на проц, потому что описание надо на OPEN HOST CONTROLLER INTERFACE (см. файл open_hci_1.pdf)

И я вам скажу - это просто чудо%)... Этот контроллер сам все делает, только забей в регистры что хочешь, и смотри что с ними делается... Все втыкания, вытыкания, енумерация, все само)...


и вот чтобы стало еще легче, некий
Copyright © 2010 Peter Barrett
написал хорошую обертку, как мне кажется, ее стоит прочитать, там есть вопросики, но в целом очень и очень...
http://mbed.org/users/peterbarrett1967/not...troller-for-mb/

http://mbed.org/users/peterbarrett1967/code/USBHostShell/
вот это оберточка, USBHost.cpp, USBHost.h, AutoEvents.cpp

ну и прочие что захотите использовать.


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

для работы надо вызывать USBInit()
а потом дергать периодически
USBLoop().

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

Про USB все таки придется почитать, так чтоб ваще с нуля наверное не выйдет...


Да забыл, в конце файла USBHost.cpp есть API функции, имеет смысл пользовать их, а не класс крутить, но это как вам больше нравится...

Тогда объясните им, что в разумный срок и с разумным качеством эта задача неразрешима. Может, тогда они поймут, что стрелять из гаубицы по воробьям не стоит. От этого выиграют все: они получат вовремя качественную и предсказуемо работающую систему, а вы избавитесь от множества проблем и сохраните себе зрение и нервы.
Кстати, COM - порт устарел только в их воображении, не более того.
P.S.
Личный опыт: ARM9. Нужно было реализовать двухпортовый хост без ОС и подключить к нему HID - устройства. До этого я реализовывал только разные дивайсы на разных МК, но никак не хосты. Так вот, задачу я решил, за 4 месяца, или около того. Если бы у меня не было опыта реализации дивайсов, задачу лично я отнес бы к неподъемным. Да, еще я использовал аппаратный "логический анализатор", который позволял захватывать транзакции на шине. Без него к этим четырем месяцам можно было бы смело прибавить еще месяца два - три.
Так что ...

Golikov A. спасибо теперь хоть немного понятно куда двигатся



к сожалению не все это понимают(((

ну ком порт реально устарел, найдете хоть один современный ноутбук с ком портом, обсудим его новизну%)...
Для конечного пользователя делать сейчас продукт с подключением по ком порту - мне кажется стыдно, UART как средство внутренней связи - да имеет право жить, но как выходной интерфейс уж увольте....

Из того же личного опыта
В начале года ставили задачу подключения джойстика чужого HID + внутренний интерфейс к нашему прибору, и я смотрел на задачу примерно также как вы, оценивая ее на полгодика. Мой напарник сказал найдем что-то из готового, и попробуем, может все не так страшно. Через неделю джойстик функционировал, я даже офигел.
Дальше я думал будет читка чужого кода и разбор того что там да как, оказалось читать то и нечего особо, все решено на железном уровне, как раз тот проц 1768 стоял.
легкий тюнинг, добавка реакций на ошибки, и вуаля, решена задача менее чем месяц. Разветвители я подключать не пробовал, ровно как и обрабатывать несколько приборов, так как ТЗ этого не требует. Но как я понимаю у ТС тоже самое, 1 устройство, просто организовать канал данных.

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

эх... прошли времена ручного разбора пакетов USB....

Подтверждаю ваш опыт для LPC, причём этот хост настолько стандартный, что мне удалось сделать Mass Storage Device для его предшественника LPC2478, который вышел тремя годами ранее, у него аж два USB host порта, а потом путём условной компиляции через CMAKE заставить работать пример и на LPC2478 и на LPC1768.

В итоге USB Mass Storage + Fat Fs от чанга -- и всё работает.

А что, лаптоп является показателем устареваемости интерфейса? Я не припомню лаптопов с CANbus, RS-485 etc..
Но они ведь не устарели.
И почему подключение обязательно к компьютеру должно быть.
2. Если нет задачи "встраивания в ОС" то вполне может быть и COM port.

+1
До сих пор выпускаются измерительные приборы с RS-232, хотя , надо признать, и в меньших количествах. При этом альтернативный интерфейс всё же ethernet, а не USB.

C USB приборов очень много, почти все современные мультиметры и генераторы Agilent, очень хорошо управляются через PC - LabView, но ethernet на них тоже есть.

Согласен полностью - COM выкинули с ноутов потому, что это бытовка (домохозяйкам эти порты не нужны), а в реальности COM гораздо стабильнее USB, к тому же в нем легко сделать гальваноразвязку (попробуйте сделать ее на USB ) Так же легко подключить RS-485 и т.д. Поэтому вся пром. аппаратура имеет COM порты и только как альтернативу - USB. Если ваше устройство является элементом промавтоматики, постарайтесь убедить свое руководство использовать COM порты, уж поверьте - они будут намного стабильнее в работе!

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

Ну если пром автоматика, то езернет или rs485/422
Если бытовуха для людей, то USB (даже не езернет, он в быту сложноват, хабы там всякие, настройки), BlueTooth может быть...

Для R232 уже как - то не модно, когда находиться приборчик с таким портиком, от него вет 20 веком, ну это мое мнение, я не навязываю...

Да, наверное, не стоило априори считать устройство подключаемым к компьютеру, просто R232 у меня очень с бытом ассоциируется, а пользователя надо жалеть и уважать, не фига их заставлять искать переходники и старые компьютеры, где сохранился КОМ порт, и искать терминалы для новых виндоусов...

На наших приборах 232 остались только как отладочные порты, для внутреннего использования...

Именно это и хотел сказать. В своих устройствах USB использую только как временное подключение (скачать логи на флешку, залить файл с настройками и пр...), а для работы 24\7 только RS-485, или 232.
Сколь перепробовал USBшных девайсов, с библиотеками от СТМ, Prolific, FT232... только последние еще более-менее могут работать долгое время без зависаний компа или "отваливания" соединения...

в моём случае мой хост будет работать с девайсом долгое время возможно и 24/7 .

При реализации и хоста и девайса на микроконтроллере велика ли вероятность "отваливания" и зависания???

Вероятность "зависания" или "отваливания" 50%: либо зависнет либо нет.
При работе необслуживаемого устройства в режиме 24/7 следует принимать вероятность зависания 100%. Если не зависнет за день - значит зависнет через неделю / месяц, но зависнет обязательно. Интерфейс усб изначально не предназначен для безотказной работы и отличие к примеру от эзернета.

Именно так. Мой совет всем, кто делает устройства с USB в режиме 24\7 делайте обязательную проверку приема\передачи данных, пусть даже ничего не надо передавать - посылайте что-то типа пинг-пакетов, и если приема нет - сразу перегружайте хост-контроллер, причем с временным отключением питания девайса (зависон может идти по причине него) после этого, когда пройдет переинициализация, снова гоняйте "пинги", и т.д. Только так можно добиться какой-либо стабильной работы в необслуживаемом устройстве.

Эта.. А зачем посылать? Оно там само посылается. Не помню навскидку, 1 или 3 миллисекуды для фуллспид.
А если не присылается, то девайс будет саспендед.
Само по себе оно не отвалится, но тут зависит как хост имплементирован.
И как он подсединятся будет. Через внешний хаб или нет и так далее.
То бишь в теории подключение чего нибудь к другому порту хаба или хоста может спровоцировать саспенд
и USB ваш будет "обесточен".
В опчем, надо внимательно рассматривать грабли.
И никакие "пинги" тут не помогут, да и бесполезны они. И редандант

На вскидку должно быть не более 50мсек или суспенд.
Был случай, когда ответ девайс посылал, но видать его стек на уровне приложения завис, и пакеты данных не шли...
Да, хаб будет обесточен, НО во первых - я ооочень редко встречал что-то подключаемое через хабы (все-таки это контроллер, а не комп, к нему редко что-либо гирляндами подключают )

1 ms



Хаб может быть не только внешним, но и внутренним, АФАИК.
То что, на уровне приложения зависло, не должно влиять на USB фреймы.

На счёт com-порта... Сейчас актуально, когда в приборе присутствует их несколько: RS-232, Ethernet, USB. До сих пор ставят GPIB в измерительное оборудование.

На счёт USB host. В целом сейчас всё действительно стало проще, чем было раньше. Куча разного готового софта (про качество молчу) на lpcware.com, mbed.org и на других наверно ресурсах.

Сам в августе этого года поднимал (правильнее сказать прикручивал готовых) USB host к lpc1768. Правда ему только MSC надо обслуживать. Подъём занял 1 неделю, и ещё одну - на вылизывание мелких проблем.

по USB еще и грабли на Windows стороне могут быть.
Я примерно пару недель убил на то, чтобы доказать что косяки не на моей стороне, а со стороны виндоус.
Гуглил, пальцем тыкал, компилил примеры.
Месяца 2-3 было - у нас проблема с USB firmware.

На маке все работало без всяких танцев с бубном, сразу как положено.

сделали каку для мака, и давай на честный виндус гнать

меня особо угнетает когда одной USB устройство работающее на win xp перестает работать или определяться на vista, да еще так себя ведет как будто железка погорела...

Это же все бытовуха, работает в зависимости от погоды и настроения, сам намучался, когда сделал терминалку для вендингового аппарата, она работала под виндой, через УСБ с ПЛК собственной разработки. Так вот винда глючила раз в месяц, плюс криворукие пользователи ей еще неплохо в этом "помогали" и отваливался усб, причем виндовый хост, а ПЛК ни разу не заглючил, хотя все расчеты и управление автоматом были именно на нем, винда была только для показа картинок и настройки

ЗЫ. вот теперь делаю все с использованием COM порта и ДОСа(вполне серьезно!), т.к. сделанные полтора года назад, табло, до сих пор работают и не виснут!
Вот и делайте выводы...

Может это , а не пробывали делать тоже самое на Colibri ? Всё-таки графика и поддержка USB кстате тоже есть но скорее всего нестабильная.

Нет, Мак там вообще никаким боком. Стадартный USB stack виртуального COM порта.
Если на Виндоус не закрыть соединение, а чисто дисконнектнутся, то все. Больше не законнектишся.
Я уж как не искал, ничего найти не мог.
Попробовал с Мака - как часы, хоть когда дергай, выдергивай, всегда все работает.
Пришлось гуглить, тыкать пальцем вот такие ссылки:

http://social.msdn.microsoft.com/Forums/wi...backs-in-winusb

и доказывать, что это их косяк.
Сейчас работает как часы. На виндоус 7, на 8ке вроде у них проблемы.

Если честно, вообще незнал про такую ОС, и пока трудно представляю, как под нее что-то писать, и вообще доки где брать... Да и вот это слегка смущает - "а также в использовании языка ассемблера, как основного языка разработки KolibriOS и программ для неё." - как-то привык писать больше на си и паскале под х86...
По досу все-таки опыт поболее... и с портами и с графикой, да и все-таки есть уже годами проверенные компиляторы и сама дос уже "вылизана" вдоль и поперек