Драйвер виртуальных СОМ портов для win, СОМ-Ethernet Опции

[AlexandrY]

P.S. хотя в com0com есть исходники драйвера нульмодемного порта.

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

Короче, лучшее что TC остается - это качать WDK , брать сэмплы отсюда - https://github.com/Microsoft/Windows-driver...l/VirtualSerial
и пилить свой драйвер.

Можно назвать эту программу "драйвером", какая разница? - "хоть горшком назови, только в печь не ставь"

Разница в жесткости требований к совместимости с операционкой.
И хотелось бы посмотреть как из обычной программы в юзерспейсе вы перехватите обмен с портами у стороннего софта.

[Lagman]

Всё же написано, программа создает на компе 4 виртуальных COM-порта, потоки данных с этих портов обрабатывает по RFC2217 и отправляет/принимает по Ethernet. Можно назвать эту программу "драйвером", какая разница? - "хоть горшком назови, только в печь не ставь"
Первая версия пишется за день, если умеючи.

В том то и дело что программа не может создавать виртуальные порты (которые будут в системе видны как стандартные COM1...COM4 ... /dev/tty1...), она может только их использовать, а вот драйвер и создает виртуальный порт (которые ОС будет предоставлять как COM1...COM4... /dev/tty1 и т.д.) и плюс еще передает данные, а так же настройки скорости, четности и т.д. физическому устройству eth<->com.

[Ruslan1]

А, кажись понял.
То есть у ТС есть софт, в котором он выбирает до 4 СОМ-портов. И теперь он хочет, чтобы нечто прикидывалось этими портами и отсылало посланное этой программой в сеть, а не на локальный порт? и так же обратно, из сети в программу как будто из СОМ порта?
Я ж сразу сказал, без картинки тяжело доходит. Ко мне уже без картинок на работе и не идут, или мы вместе их рисуем с пришедшим

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

Я сначала тоже хотел такой "драйвер". А потом просто это в свой софт добавил, как опцию- хочешь через локальный порт, а хочешь- через IP адрес на удаленный. То есть обеспечивал канал передачи, а не перехват и перенаправление. И обошелся без драйвера и без виртуальных портов.
Кстати, драйвер подразумевает админский доступ. Я лично уже сталкивался, когда на чужой NT дают кусочек ресурсов и крутись как можешь, но свои драйверы не ставь. Конечно, вопрос доступа к админ уровню решается административно (извиняюсь за тавтологию), но было очень приятно просто поставить на том островке, который выделили, и не вступать в полемику

[zltigo]

Много лет уже для этих целей пользуемся Tibbo VSP Manager: http://tibbo.com/soi/software.html

Судя по скудному описанию гонит просто RAW поток как-то по своему разумению формируя фреймы. Надо будет попробовать на досуге для одной старой софтинки прикрутить, дабы не встраиваить в нее поддержку UDP/IP.

P.S.
Посмотрел.
1) Локальный порт назначить нелья - лезет только с портом назначенным системой. Это уже не есть хорошо.
2) На указаном UDP сокете пытается идентифицировать СВОИ устройства (Device Server), если их устройства нет, то все идет лесом.
Видимо только его Telnet может работать с чужими устройствами. Не интересно.

[Шаманъ]

Спасибо всем за обсуждение!

То есть у ТС есть софт, в котором он выбирает до 4 СОМ-портов. И теперь он хочет, чтобы нечто прикидывалось этими портами и отсылало посланное этой программой в сеть, а не на локальный порт? и так же обратно, из сети в программу как будто из СОМ порта?

Да, но на всякий случай уточню.

Изначально это было четыре отдельных устройства, которые управлялись сторонним ПО (на ПК) по четырем СОМ портам. Потом это стало одним устройством, которое есть желание подключить к ПК по сети, отсюда желание иметь 4ре виртуальных СОМ порта, которые отправляют-принимаю данные на устройство через сеть.

Не очень понятно - у Вас в одном приборе должно быть четыре виртуальных порта?
Используем китайские аналоги MOXA. Модули вставляемые. Дешевые. Писать ничего не надо самому.

Не, такое решение не подходит по разным причинам.

Тогда забирайте:
http://www.hw-group.com/products/hw_vsp/index_en.html
Совершенно рабочая вещь.

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

Всё же написано, программа создает на компе 4 виртуальных COM-порта, потоки данных с этих портов обрабатывает по RFC2217 и отправляет/принимает по Ethernet. Можно назвать эту программу "драйвером", какая разница? - "хоть горшком назови, только в печь не ставь"
Первая версия пишется за день, если умеючи.

Нет. Речь идет совсем о другом. В идеале никакого моего ПО на РС не нужно совсем - подключили по сети устройство, настроили драйвера виртуальных портов и все.

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

На счет написать свой драйвер - можно все, но потом его нужно подписывать, тогда уж проще купить драйвер

[Lagman]

Нет. Речь идет совсем о другом. В идеале никакого моего ПО на РС не нужно совсем - подключили по сети устройство, настроили драйвера виртуальных портов и все.

Ну а что будет управлять то устройством по последовательным портам?

[zltigo]

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

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

[jcxz]

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

А чем Tibbo не понравился? Он вроде бесплатный.

[zltigo]

А чем Tibbo не понравился? Он вроде бесплатный.

http://electronix.ru/forum/index.php?showt...t&p=1450203
Или я что то не понимаю?

[jcxz]

Судя по скудному описанию гонит просто RAW поток как-то по своему разумению формируя фреймы. Надо будет попробовать на досуге для одной старой софтинки прикрутить, дабы не встраиваить в нее поддержку UDP/IP.

Да - просто бинарный поток, да - TCP-фреймы формирует от фонаря (обычно режет на куски до 255 байт насколько помню).
А какая разница для задачи ТС какие размеры фреймов? Он на своей стороне их тоже в байтовый поток должен преобразовывать.

2) На указаном UDP сокете пытается идентифицировать СВОИ устройства (Device Server), если их устройства нет, то все идет лесом.
Видимо только его Telnet может работать с чужими устройствами. Не интересно.

UDP не использовал, TCP работает без проблем. Идентифицировать никого не пытается. Telnet-а там не видел.
В настройках: "On-the-fly commands:" должно быть == "Disabled"; "Transport provider:" == "TDI".

[Шаманъ]

Ну а что будет управлять то устройством по последовательным портам?

Стороннее (т.е. не моё) ПО.

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

Да есть плюсы и минусы, как всегда. В таком варианте и com0com подойдет.

UDP не использовал, TCP работает без проблем. Идентифицировать никого не пытается. Telnet-а там не видел.
В настройках: "On-the-fly commands:" должно быть == "Disabled"; "Transport provider:" == "TDI".

Надо будет поэкспериментировать, спасибо!