Приветствую.

Появилась задачка добавить функционал контроллера модулем uart-ethernet, раньше использовали отдельные модули "тиббо", сам модуль и драйвер ком-порта под винду.

Контроллер - vybrid mvf61nn
стек - LWIP
в данный момент используется как web-сервер. В сети есть несколько проектов, как "прикрутить" к стеку функционал посл. порта, НО не смог найти к ним "вторую часть" - программный драйвер под винду(не важно какую, хрюшу или семерку), написанием драйверов под винду никогда не занимался, и честно говоря, нет большого желания и времени, а пытаться использовать тот-же драйвер от тиббо - нет документации.
Может кто знает, где посмотреть или поискать эти творения??

Не очень понятно чего вы хотите найти за драйвер

Ethernet -ТСP/UDP поддерживается виндой нативно. Задача обмена по ним заключается в создании сокета и чтения-записи данных через него. Для данного действа есть уже написанные классы С++, и С#. Для С# класс входит в комплект и весьма удобен. Или вы хотите чтобы у вас был виртуальный ком порт? ну тогда ручками ручками, стандарта на формат такого рода данных нет.

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

А как вы хотите его использовать? Если у вас не просто удлинитель ком порта, то наверное есть ваше приложение управления всей этой байдой, так может в нем реализовать нормальный режим через сокеты?

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

Ага, а потом заменить логотип Tibbo на "Вася Пупкин и Ко"

Ну тогда я бы не задавал этих глупых вопросов, логично

Все дело в том, что софтина сложная и специфичная, писана х.з кем, работает только по rs232. Вот дело-то в чем...

А ничего там хитрого нет: берете UDP порт и гоните/принимаете данные.
На компьютере ставите программу что-то типа "Virtual COM UDP TCP Port" (это ключ для гугления, их много разных в интернете), настраиваете ее не Ваш UDP порт и у Вас в системе появляется виртуальный порт, привязанный к данному UDP.
Я не помню что именно мы использовали для экспериментов, так как в результате отказались от идеи виртуальных портов и я просто в исходники добавил все нужное напрямую (поддержку канала связи через Езернет). Но оно работало и через такой виртуальный порт тоже.
Помню что искал пару часов что-то приличное, нашлось не сразу и не уверен что оно бесплатное было (но стоит дешево)

Upd: нашел, это пользовали
http://www.hw-group.com/products/hw_vsp/index_en.html
там есть фриварная VSP3, кажется ее и использовали.

Еthernet, стек за присест не изучишь и за десяток тоже. Такой модуль uart-ethernet сам посебе не имеет смысла. Смысл в структуре и софте с обоих сторон. Сначала с этим нужно разобратся. Выражение: "... добавить функционал контроллера модулем uart-ethernet" переводится знающими как - масло масленое.
"прикрутить" к стеку функционал посл. порта только через сокеты, порты и проброс. Golikov пояснил как. А какого драйвера компа тебе нужно? А вот и не так просто удлинитель ком-порта по сети. Обычно все через виртуальные работают, а там свои заморочки.

UDP порт в LWIP еще поднять нужно правильно, и то я по UDP делал, понимая что потеря данных обеспечивается. Не все данные погонишь таким каналом. По TCP/IP предпочтительнее.

Ну вообще-то это само сабой разумеется, и я не первый год в "теме"... Писал, что не делал драйверов под винду.



Я полностью согласен, что в самописной программе использовать эти рудименты, как VCP - глупо, но если софт без исходников и работает только с комом, то что тут поделаешь?...



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

Извините, но я сомневаюсь что вы "В теме". Дело в том, что не существует исходников того "что должен ответить мой контроллер на запрос драйвера". Почитайте хоть что такое UDP, что ли. И, заодно, что такое TCP. Иначе следующим будет вопрос "исходники драйвера чтобы понять как установить TCP соединение". TCP тоже, кстати, с полпинка поднимается в LwIP (telnet, например).

2Aner: А что именно сложного в LwIP с "поднятием" UDP?
вот выдрал из своего проекта пару строк, где упоминаются нужные функции LwIP, это передача.

Или Вы про сложность реализации в PC? там тоже ничего хитрого. А если нужен именно честный видимый операционкой виртуальный порт- вообще не вижу смысла писать то что уже написано и отлажено другими.

И про необходимость надежной передачи: вы вообще-то эмулируете компорт, в котором никаких надежных передач и переповторов не предусмотрено, поэтому не вздумайте отсебятиной заниматься. Контролем целостности и валидности данных уже следующий уровень занимается, который и так должен быть реализован в софте, ориентированном на RS232.

Если честно, Вы сами писали подобные драйвера?? Если да, тогда вопрос, каким образом передаете конфиг порта, скорости и пр...?? Причем "котором никаких надежных передач и переповторов не предусмотрено" в этом случае?? И второе, как драйвер порта вообще узнает, что подключен именно мост уарт-эзернет, а не просто любяа шняга, которая слушает и устанавливает соединение по порту хххх udp??

У меня есть решение.
Берете проц и делаете USB - CDC -> Ethernet
А на своей плате делаете Ethernet -> UART

USB - CDC - стандартный класс который будет виден в винде как виртуальный ком порт автоматом.
а езернет будет ваш.


Я так понимаю если использовать уже показанный выше hw-group что Руслан показал, то там скорее всего описано что по UDP к вам придет. То есть они написали драйвер который виден как виртуальный ком порт и шлет понятные данные по UDP.

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



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

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

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

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

А я понял, что у них есть 2 проги под 1 порт - свободно распространяемая и мультипортовая - с лицензией. Мне хватило б и однопортовой, но док по протоколу я не нашел, а может плохо искал - глаза устали...

Писать им, думаю пустая затея - они же не опенсорсом занимаются, а продают железки, спрашивается, зачем рассказывать конкуренту? Может я продавать потом захочу все это

ЗЫ. Поищем еще, уж больно с всякими ддк масдайными не охота связываться

mantech, механизм такой:
1. UDP передатчик передает сообщение в указанный UDP порт.
2. Сообщение летит по линии Ethernet
3. UDP приемник слушает этот UDP порт.
4. Все принятые байты перенаправляются в приемный буфер виртуального COM-порта.

если не хотите пользоваться готовым и пИшите сами VSP- то Вы должны выдержать правила операционки, создать порт, зарегистрировать и обеспечить необходимый интерфейс с операционной системой. Если Вы работаете напрямую- то просто ждете данные с UDP порта и обрабатываете их так же как принятые из буфера КОМ-порта.

Что именно Вы хотите услышать больше от создателей программы "виртуальный порт"?

Я уже писал, что использовал готовый софт со стороны компьютера для организации виртуального порта и, как альтернативу, ввел эту работу с UDP в мой исходник, чтобы не иметь чужой прослойки в ненужном месте. Из моих слов следует что полный виртуальный ком-порт на PC я не писал, в этом не было никакого смысла- либо юзал готовый, либо вообще обходился без него.

ну значит просто данные гоняют и все.
А контроль потока как осуществляется? RTS CTR и прочие сигналы просто отсутствуют? Или на другом порту?

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

ЗЫ. Я почему вообще затеял эту тему, просто думал, что есть какие-то опенсорсовые разработки, но видимо нет, придется и дальше ставить свич с тиббой...

в целом можно и прослушать, может это и не так нудно как казалось сначала

установить RTS, DTR, CTR, CTS или как они там называются по одному, поглядеть что шлется.
Скорость устанавливается думаю просто так, все равно будет на максимальной гнать, на выходе то ethernet. Это в FTDI на выходе был UART и установка скорости имела смысл. Тут это не важно.
Потом послать данные в устройство и обратно.
Потом открытие закрытие порта поглядеть как сделано.

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

Я ничего не понял. Что именно Вам не дает делать виртуальный порт, написанный кем-то другим?
У Вас в устройстве теперь есть Езернет, какие еще RTS/DTR?
Или Вы хотите просовывать все служебные сигналы с удаленного порта (например, модема) на компьютер так, чтобы этот виртуальный порт их показывал и транслировал в обе стороны?
Тогда, конечно, нужно свое писать как надстройку над UDP или TCP пакетом, так как такой хитрый ход мало кому нужен, готовое не найдете.

Или использовать вместо своего устройства ту же Тиббу, или раскрутить через Шарк ее надстройки. Но проще с Тиббой созвониться-поговорить, может за малую денюжку и согласятся поделиться-разрешить использование их драйверов.
Кстати, а сама Тибба что, в Линуксе не поддерживается? может, сделали уже.

Кстати, надо посмотреть, может и есть такое дело



Да х.з. только пробовал прогу с девайсом соединить по линиям rxd, txd - не работает, зараза, нужно еще dtr и rts, наверно еще и аппаратный контроль передачи, конечно, можно попробовать сэмулировать...

Потом, раз драйвер посылает пакеты для настройки параметров порта, а я буду тупо гнать в уарт весь этот мусор вместе с данными, как это скажется на работе всей системы - тоже непонятно...



Как какие, обычные, как в уарте
Хорошо, постараюсь объяснить по-другому:
Есть промышленная железяка, сушилка, которая управляется по уарту с компа, на котором управляющая прога под винду, и есть мой контроллер, для сопутствующего оборудования, управляется по веб морде через сеть. Раньше было 2 компа, сушилкой управлял комп рядом, а контроллером удаленно, теперь захотелось все делать с одного компа, а след. нужно завести уарт от сушилки в мой контроллер, который эмулирует вирт. ком порт, а прога и веб морда висят на одном компе.

В данный момент, это сделано установкой свича, в который воткнут контроллер и тиббо, с последнего идет уарт в сушилку. Как-то так...

Да, теперь понял. И понял, почему мои советы Вам совсем не подходят
Задача нетривиальная, но интересная. Я сомневаюсь, что Вы найдете готовое.
Тут придется делать с двух сторон:
1. поддержка в LwIP
2. написание драйвера в PC.
Или если удастся найти исходники или описание интерфейса хоть с одной стороны- тогда работы гораздо меньше.

Думаю, достаточно UDP для эмуляции доступа к служебных регистрам этой удаленной виртуальной 16550, тут уже нет никакого потока данных, а запись-чтение регистров. Если нужно будет TCP- позже переделаете, сначала и так проблем хватит и без сеансовости.

Если что-то найдете- напишите, пожалуйста. Мне тоже интересно в перспективе.

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

И что поддерживается, какой чип эмулируется с FIFO (16550) или без, какие сигналы RS-232 поддерживают, на чем сделано (TCP или UDP)?

Хотя может я усложнил все. Драйвер с компа может просто в езернет валить команды установки/опроса пинов порта и иметь поток данных RX/TX. только как-то все это небыстро и ненадежно выглядит в работе.

Как в том коде, что у Вас есть, это сделано?

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

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



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

Если правильно понимаю, нужно прокинуть виртуальный RS232 порт с ПК в реальный порт на контроллере. Делал такое кажется при помощи
http://www.eterlogic.com/Products.VSPE.html
утилита эта кажется есть в местных закромах, давно это было не помню.
Судя по исходнику на плате создается netconn_new( NETCONN_TCP ) , соответственно программа эта tcp клиент + создает на ПК виртуальный ком-порт,который доступен при удачном подключении к серверу.
Возможно в программе и udp режим обмена есть.

Именно так.



Надо посмотреть, прога больно наворочена, наверно это надолго