Приветствую всех!

Есть девайс, который традиционно управлялся сторонним ПО через СОМ порты. В новом варианте девайса хочу сделать управление по Ethernet. Ищется драйвер который может создать четыре или более виртуальных СОМ порта с перенаправлением данных в сеть на мой девайс (по RFC2217 или другому протоколу). Проект не коммерческий, поэтому ищется бесплатное решение.

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

В PC "драйвер" - это просто нечто, отправляющее(принимающее) байты в указанный IP в указанный порт. Я писал под Билдером, но это можно на чем угодно сделать, задача стандартная.
в устройстве-аналогично, но можно и готовое использовать, с нужным интерфейсом (например, GSM модем с RS-485)
У меня есть системы, которые так Моддбас-RTU гоняют через Интернет.

Upd:
в Интернете есть кучка готовых программ (гуглите " Virtual Serial Port"), как бы обеспечивающих виртуальный COM-порт. Есть и платные, и бесплатные.
Я потратил кучу времени чтобы понять кто из них работает, кто нет, и какие особенности. А потом махнул рукой и за половину этого потраченного на разборки времени написал свое, которое понятно как работает и может работать именно так как мне нужно.

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

Есть что-то подобное http://com0com.sourceforge.net/, com2tcp.

А вот гугле говорит, что под билдером драйвер Windows написать невозможно.
Кому верить ?

Сам искал исходники такого драйвера. Вменяемых не нашел.



Это древний фейк, сделанный той же Eltima
Исходников нет.

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

Бесполезно.
Никто на халяву драйвер для нескольких портов да еще с сорсами не выложит.

Просьба внимательно читать, что хочет Автор. Ему нужен драйвер, не не исходники. Дрвйвер есть. Для многопортового нужна лицензия, но она тоже бесплатная.
Для любителей исходников берутся исходники COM порта WIN2000 и по образу и подобию вперед.

Читайте Summary - http://www.hw-group.com/products/hw_vsp/in...en.html#licence

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

У меня со стороны сервера- PC и программа на Билдере. Я использовал компоненты из iNDY пакета, на него уже мое навешивал. Дубово работает уже сколько-то лет.

Если зайти на страничку проекта на SF https://sourceforge.net/projects/com0com/fi.../?source=navbar то загружая архивы (без цифр 386 в названии) вы получите исходники, только это не драйвера, а программы. А автору как я понял нужен драйвер (наверно даже в исходниках), чтобы старая программа, без внесения изменений в код, могла видеть эти виртуальные последовательные порты.
P.S. хотя в com0com есть исходники драйвера нульмодемного порта.



А можно этот однопортовый драйвер запустить 4 раза для доступа к разным устройствам?

Вы полагаете, что там написано о том, что Автору нужны исходники .





Можно получить БЕСПЛАТНО коммерческую лицензию и на многопортовый. Условия на сайте изложены.


Что имеет в виду Автор, более, чем понятно, как и то, что Вы поняния не имеете о чем пытаетесь писать

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

Ась? ну тогда растолкуйте, пожалуйста и мне, чтобы и я "поняние" имел. И желательно без хамства (если умеете).

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

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

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



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

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

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

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

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

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

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

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


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

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


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


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


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

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

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

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

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

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

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

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


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

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


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


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