Перейти к содержанию
    

что нужно:

иметь возможность пробрасывать UART в LAN с собственной ембеддед-коробочки и чтобы этот UART на хосте отображался как виртуальный последовательный порт (/dev/ttyX; COMx).

в первую очередь для Linux, во вторую - для M$ XP/Vista

 

начал ковырять инфопространство по поиску такого стандарта:

http://en.wikipedia.org/wiki/Serial_over_LAN - implemented as a payload type under the RMCP+ protocol in IPMI (аппаратная поддержка материнками???.. из серии KVM-over-LAN?)

http://sourceforge.net/projects/serialoverip/ - 2002г, линукс-то-линукс (не создаётся виртуального девайса)

 

огромное число коммерческих решений, использующих проприетарные(?) протоколы??

http://www.netburner.com/products/serial_to_ethernet.html

http://www.dcbnet.com/datasheet/ss1ds.html

http://www.industrialethernet.com/net232-dte.html

http://www.moxa.ru/group/listAll/14890/

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

 

вот интересный продукт (Win & Lin) - http://www.virtualserialport.com/ :

 

serial_network.jpg

 

но как это реализовывать на стороне ембеддед-девайса???

 

 

 

 

UPD: http://en.wikipedia.org/wiki/COM_port_redi...ource_solutions - вот тут список решений еще, кто-нибудь использовал что-нибудь из этого?..

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

что нужно:

иметь возможность пробрасывать UART в LAN с собственной ембеддед-коробочки и чтобы этот UART на хосте отображался как виртуальный последовательный порт (/dev/ttyX; COMx).

 

но как это реализовывать на стороне ембеддед-девайса???

Может, я что не понимаю, но... Те решения, которые я видел, никакими особенными протоколами не страдали. Т.е. приходит пакет, и все его поле данных уходит на UART. Приходит с UART - укладывается в пакет и, по превышению границы и/или таймауту отправляется. Тупо и незатейливо. Беру, скажем, Xport, UART которого соединен с моим UARTом, на другом конце ихний же "Redirector", создающий виртуальный COM, и терминалом работаю со своим устройством как напрямую. Но не нравится мне этот редиректор, на самом деле. Взял TCP-COM от Taltech. Ну, чуток его "вылечил" от черезмерной жадности, и все так же работает (причем еще умеет и через UDP). Вместо Xport у меня сейчас SIM900 с встроенным GPRS-стеком в прозрачном режиме - а все так же работает, даже и на задумываюсь... Можно глянуть, как работает мост IP-UART вот в этой игрушке - http://trt.ru/design/solutions/trt-ethernet.htm (там все сырцы есть).

Однако, "кстати о птичках" - если мне кто подскажет альтернативу TCP-COM, правильно работающую через UDP (у него проблема - если на другом конце меняется порт, то он это не замечает, продолжает слать на тот, от которого пришло изначально, реагирует только на смену IP отправителя) - было бы весьма интересно...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

>> Можно глянуть, как работает мост IP-UART вот в этой игрушке - http://trt.ru/design/solutions/trt-ethernet.htm (там все сырцы есть).

 

спасибо, это вот уже близко к тому что надо

однако, в "Microchip TCPIP User's Guide" я не нашёл модуля STACK_USE_UART2TCP_BRIDGE (мост UART/TCP), т.е. это какая-то нестандартная штука, дописанная потом.

а хотелось бы более-менее стандартное решение, (и желательно более-менее нативное в линуксе - в плане нативных средств для поднятия "витруальных" tty оторбажённых на LAN)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

однако, в "Microchip TCPIP User's Guide" я не нашёл модуля STACK_USE_UART2TCP_BRIDGE (мост UART/TCP), т.е. это какая-то нестандартная штука, дописанная потом.

Ну, я не вчитывался, а исходник есть...

а хотелось бы более-менее стандартное решение, (и желательно более-менее нативное в линуксе - в плане нативных средств для поднятия "витруальных" tty оторбажённых на LAN)

Про линукс ничего сказать не могу, и под винды ничего не писал (обходился готовым софтом), но речь-то о другом - никаких особых протокольных тонкостей там нет (я, по крайней мере не встречал). Данные туда - данные обратно. И ничего кроме данных. Тривиально. Можно любым сниффером (Wireshark, к примеру) поглядеть, что там бегает...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А как же тогда скорость задавать, линии квитирования контролировать и управлять ими? Работать с 7 битными данными и сданными с битом четности (9-битовыми)? А если софтовый флоу контрол обрабатывать надо?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А как же тогда скорость задавать, линии квитирования контролировать и управлять ими? Работать с 7 битными данными и сданными с битом четности (9-битовыми)? А если софтовый флоу контрол обрабатывать надо?

Со стороны COM ->IP это в принципе не особо нужно нужно (можно игнорировать, в общем-то, байт данных есть - его достаточно), если только нет потребности манипулировать скоростью и режимами на лету (тогда облом, естественно), софтовый flow control пройдет прозрачно и будет работать (если его обеспечит клиентская часть). А обратно, IP->UART - это уже клиент должен сам настроить, иначе никак. Ну, может быть и есть такие решения - но я не встречал, обычно все прозрачно и незатейливо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Flow control вроде реализован в Stellaris® Serial-to-Ethernet Reference Design Kit http://www.luminarymicro.com/products/rdk-s2e.html . Исходники дают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Flow control вроде реализован в Stellaris® Serial-to-Ethernet Reference Design Kit http://www.luminarymicro.com/products/rdk-s2e.html . Исходники дают.

 

этот вообще судя по документации использует Telnet для обёртывания UARTов (RFC2217, RFC854)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

этот вообще судя по документации использует Telnet для обёртывания UARTов (RFC2217, RFC854)

А Telnet - это ведь все то же самое, за исключением того, что некоторые коды обрабатываются специальным образом. Я, кстати, так и не понял, почему байт 00 не проходит через Telnet, вроде бы все спецкоды в конце ? Или невнимательно читал ? А так - все то же (зацеплялся со своими устройствами с RAW-потоком)...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

что нужно:

иметь возможность пробрасывать UART в LAN с собственной ембеддед-коробочки и чтобы этот UART на хосте отображался как виртуальный последовательный порт (/dev/ttyX; COMx).

в первую очередь для Linux

 

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

http://lpccomp.bc.ca/remserial/

 

там кода 10 кб который работает и как сервер расшаривающий реальный uart и как "эмулятор" виртуального порта.

 

PS только что проверил на localhost Ubuntu с преобразрователем usb<->serial в качестве расшариваемого uart - работает.

Изменено пользователем sasamy

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Очень, очень давно успешно использовался ser2net ( sourceforge.net/projects/ser2net/ )

позволяет настраивать /dev/ttyXX, TCP port, (raw, rawlp, telnet, off) timeout, speed, parity-bits, stop-bits, data-bits, xonxoff rtscts

Для удобства на стороне Win использовался (Tibbo Device Server Toolkit на тот момент был последний релиз версии 3.x,

сейчас там поновее есть, (бесплатно с оговоркой) с последними "не знаком" (в то время и выбирать не пришлось на устройстве сетевом была интегрирована плата конвертер интерфейсов. (tibbo.com/downloads/soi/tdst.html)

 

 

 

 

Для удобства на стороне Win использовался (Tibbo Device Server Toolkit

Включает VSPD (Драйвер Виртуального COM-порта) и Мастер настройки подключения - для быстрой настройки нового соединения.

и прямо под ним в списке программ Драйвер Виртуального COM-порта для Linux (не знаком)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Очень, очень давно успешно использовался ser2net ( sourceforge.net/projects/ser2net/ )

позволяет настраивать /dev/ttyXX, TCP port, (raw, rawlp, telnet, off) timeout, speed, parity-bits, stop-bits, data-bits, xonxoff rtscts

Для удобства на стороне Win использовался Tibbo Device Server Toolkit

 

вот это уже ближе к теме. учитывая что ser2net входит в дистрибутив ред-хата,

а на виндовз стороне можно заюзать вот это, судя по комментариям (страничка ser2net): "connect it with com0com using com2tcp and You will get virtual comport under WinXp."

полный freeware :rolleyes:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

вот это уже ближе к теме. учитывая что ser2net входит в дистрибутив ред-хата,

а на виндовз стороне можно заюзать вот это, судя по комментариям (страничка ser2net): "connect it with com0com using com2tcp and You will get virtual comport under WinXp."

полный freeware :rolleyes:

 

 

Я заострил внимание на VSP Manager (используется для создания и управления Виртуального COM-порта (VSPs).) в принципе только этот компонент и требуется установить для подобной задачи

ввиду двух на тот момент важных для меня обстоятельствах (кроме прочих других "полизняшках")

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

 

-До 256 портов на одном компьютере.

-MAC-->IP Mapping позволяет привязать устройство по MAC-адресу (при включенном DHCP протоколе ip-адрес может поменяться).

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

Изменено пользователем Ostrov

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чет не соображу, каким образом происходит ограничение скорости передачи со стороны компа?

Т.е. допустим мы льем очень толстый файл в IP:Port преобразователя - каким образом он будет скорость льющего ограничивать?

Средствами TCP? квитки задерживать? Это значит что в преобразователе взаимодействие со стеком должно быть продуманное...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Средствами TCP? квитки задерживать? Это значит что в преобразователе взаимодействие со стеком должно быть продуманное...

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...