есть 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. спасибо теперь хоть немного понятно куда двигатся



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

Сообщение отредактировал Ruslan85 - Dec 16 2013, 20:21

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

Сообщение отредактировал mantech - Dec 17 2013, 16:17

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

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

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

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

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