IP over RS422

SLIP

Linux serial line PPP

А он разве не point-to-point?

Мне необходимо, чтобы все три железяки общались между собой, как будто они все подключены в один хаб. Как я понял, ppp ( point-to-point) это сделать не позволяет.

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

Зачем такие извращения? Почему не modbus?

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

Почитай про rs-422 - чтобы организовать там мультимастер надо придумывать какой-то протокол для разрешения коллизий. Типичный сценарий использования - один мастер а все остальные слушают, тот кто узнал свой адрес в запросе тот отвечает и снова слушает пока его не спросят. Про modbus уже написали - используй его и не мучайся.

Надумаешь писать свой L2 - смотри в сторону tty line discipline.

P.S. google://slattach.busybox

Потому, что часть системы связана между собой Ethernet и там уже все работает через TCP/IP. Если бы эту среду удалось исопльзовать в качестве замены Ethernet в основном коде не пришлось бы ничего менять.

Посмотрел modbus - не совсем то, что нужно.

P.S. Добавил дополнение в первопост с более подробным описанием проблемы.

часть системы связана между собой Ethernet и там уже все работает через TCP/IP. Если бы эту среду удалось исопльзовать в качестве замены Ethernet в основном коде не пришлось бы ничего менять.

Только конвертер из tap.

6LoWPAN не подойдёт?

Только конвертер из tap.

Это самая простая часть, причем не обязательно tap использовать, виртуальный изернет элементарно пишется, разве что при наличии драйвера tty - tap проще будет при таких черепаших скоростях как у rs-422. А что делать если два узла начинают передачу одновременно ? а если все три ? нужен какой-то протокол - в ethernet он реализован аппаратно, а как тут быть да еще на радиоканале.

не обязательно tap использовать, виртуальный изернет элементарно пишется

Не уверен насчет элементарности, но в любом случае - зачем его писать, если он есть?

А что делать если два узла начинают передачу одновременно ?

Если это не разруливается на уровне аппаратуры - ХЗ.

Не уверен насчет элементарности

а я уверен

http://lxr.free-electrons.com/source/drivers/net/ethernet/mipsnet.c?v=3.2

зачем его писать, если он есть?

в данном случае - незачем, просто хотел показать что не в перебросе пакетов проблема основная.

а я уверен

Вижу.

http://lxr.free-electrons.com/source/drivers/net/ethernet/mipsnet.c?v=3.2

Нерелевантно.

хотел показать что не в перебросе пакетов проблема основная.

Может быть не основной (в зависимости от среды передачи).

Может быть не основной (в зависимости от среды передачи).

Если радиоканал сам разруливает коллизии - то в общем задача через TAP решается в 10 строк :) опрос двух дескрипторов через poll/select + read/write.

Вот и я о том же. И даже если канал не разруливает коллизии - думаю, на небольших скоростях это не будт мешать.

думаю, на небольших скоростях это не будт мешать

Без разницы какая скорость - все что получишь после первой же коллизии - постоянные ошибки CRC в данных.

Почему постоянные?

Почему постоянные?

Ну не постоянные - в конце концов разрыв соединения получишь :) при повторах никто из передатчиков не уступит если они не придерживаеются какого-то протокола.

при повторах никто из передатчиков не уступит

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

Уступка получится сама

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

хватит ли таких уступок для устойчивой связи

однозначно не хватит, иначе бы не изобретали специальные протоколы

Уступка получится сама

Тогда следуя твоей логике

Это твое понимание моей логики.

иначе бы не изобретали специальные протоколы

Специальные протоколы изобретали для скоростной передачи.

Впрочем, в рассматриваемом случае тоже никто не мешает делать случайную задержку при обнаружении ошибки CRC.

никто не мешает делать случайную задержку при обнаружении ошибки CRC

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

никто не мешает делать случайную задержку при обнаружении ошибки CRC

Ну и что это если не изобретание своего протокола ?

Всё изобретено до нас - это повторение раннего Ethernet на примитивном уровне (и, повторюсь, не факт, что это вообще нужно).

Есть 3 железки

Купи еще один модем, попарно настрой на разные каналы(частоты). 2 PPP + маршрутизация. И скорость больше и мороки меньше.

физический уровень уже есть, теперь хотелось бы поверх этого организовать все остальные уровни TCP/IP

2 (канальный) уровень пропустил.

Из руководства по настройке радиомодема: «Если из 20 сообщений маяка ретранслировано не менее 18, то радиоканал можно считать устойчивым.»

Маяк шлет несколько байт.

это повторение раннего Ethernet

В ethernet коллизия определялалсь по наличию несущей, а как ты собираешься здесь определить ошибки CRC если тут полудуплекс и пока передаешь на передающей стороне ничего не принимается в принципе.

и, повторюсь, не факт, что это вообще нужно

повторять можно сколько угодно, только так как ты предлагаешь никто не делает :)

так как ты предлагаешь никто не делает :)

okay.jpg

А напомни, твое-то предложение в чем состоит?

В modbus инициатор передачи (мастер) всегда один, он и является арбитром на шине.

А напомни, твое-то предложение в чем состоит?

modbus

IP over RS422 (комментарий)

IP over RS422 (комментарий)

Да он просто не понимает с чем имеет дело - только про tcp/ip видимо слышал :)

А напомни, твое-то предложение в чем состоит?

Кстати, я забыл - бывают трансмиттеры rs-422/485 с аппаратным квитированием, т.е. выставляют некий сигнал «занято» когда в линии есть передача (аналог несущей в ethernet), тогда можно какой-нибуть протокол простенький придумать, только в Linux с точными програмными задержками проблематично - если только небольшие скорости делать.

AX25 - не то ли, что тебе нужно?

RS422
по этому протоколу

facepalm.png. Схему накидайте пожалуйста, что как подключено и как хотелось бы.

Купи еще один модем

Дорого

Согласен. Может быть просветите, как можно безболезненно внедрить modbus в существующую схему?

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

один адаптер делаем задающим метки времени

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

решение то элементарное. делим каждую секунду на таймслоты

Угу, на RTOS - элементарно.

Может быть просветите, как можно безболезненно внедрить modbus в существующую схему?

Я бы проще сделал: не лезет - не пихай. Выбирай подходящие техноглогии. Не знаю чего там у вас но возможно Zigbee подойдет.

Т.е. как сделать вы не знаете, но оскорблять других готовы?

Я бы советовал ТС таки приготовить правильно modbus. Не обязательно делать все там по букве - достаточно взять общий принцип. Из модбаса нужен только сам пакетный протокол и арбитраж, реализаций таковых есть. Поверх работающего modbus можно гонять IP через tun или tap. Решение проверенное и работающее на «сетях» RS485, думаю, должно взлететь и на RS422. Писать свои коллизии и тп при низкой скорости передачи - совершенно неэффективный расход времени.

Таймслоты, кстати, имеют вполне практический смысл, номер таймслота можно при такой конфигурации хардкодить, а разбивать не секунду, а минуту. Имеет смысл в этом плане посмотреть как работает LAPB и AX.25 через него. Но это уже мне кажется перебором для конфигурации из трех нод.

Т.е. как сделать вы не знаете, но оскорблять других готовы?

Как сделать не зная что за модемы вам никто не скажет. Может там есть разделение на таймслоты в модемах как писал скотинко и нужно просто сконфигурировать модемы. Тогда делаете влоб проброс фреймов через TAP и все. Если нет такого - проще всего общаться через modbus-подобный протокол как написал шаляпин - 100% должно работать, у вас rs-422 только до модема.