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 режим обмена есть.

Именно так.



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