msp430 + ENC28J60

Пакеты с BAD CRC.
Их надо как-то регистрировать. Как?

Ну это ничем не отличается от любой_камень+ENC28J60. Это мы уже обсудили на первой странице



Регистрировать? Отбрасывать да и все.

Сторона, отправившая плохой пакет, должна знать о том, что пакет не прошел. Получается сложняк, который не умещается в концепцию модбас-моста.

Чето я там такого не припомню. Можно дословную цитату, что делать с пакетом, у которого плохо с CRC?

Да это понятно - через таймауты все откинется.



Получается, нужна обязательная поддержка диагностических команд и счетчиков. А это - разбор пакетов и, в общем, никакой прозрачной реализации репитера не будет.
Т.е. application layer нужен?

Ну не целиком же. По-быстреньком посмотреть, нет ли ахинеи в принятом пакете и дропнуть его, если что не так.
А можно конечно и совсем тупо транслировать его в 485, пусть там разбираются. Хотя, а вот вопрос - в обратную сторону, из 485 в TCP надо смотреть CRC или нет?

Я бы сделал все-таки эти проверки.

Поговорили. Я этот случай и имел ввиду.

Резюме: будет две ипостаси: тупой репитер и как полноценная аппликуха для диагностики и поддержки конфигурируемого адресного пространства в ведомом сегменте RS-485. Дабы трафик был гуманный.

Объясню. Я просто с MODBUS не сталкивался вплотную, по причине того, что мне эта система виртуальных веревочек (т.е. каждая веревочка говорит о состоянии какого-либо устройства) в приборы совсем не ложится - я работаю со своими протоколами, которые ориентированы на передачу событий. Поэтому глупые вопросы задаю. Сделайте на это скидку мне, окей?

Откуда взято ограничение длины?


В обе стороны сделать CRC. В модбасовую сторону по modbus полиному "0xA001",
в Eth сторону - по любому оговоренному способу.

Нормальный конвертер должен распознавать правильность принятых пакетов входного протокола, отцеплять служебную информацию (в данном случае CRC), перепаковывать сообщение в соответвии с требованиями выходного протокола и отправлять перепакованный пакет.

IMHO совсем не обязательно делать over TCP.
На мой взгляд, over UDP будет ничуть не хуже и даже быстрее, при этом значительно проще, плюс можно броадкастом общаться сразу с несколькими конвертерами. Гарантировать доставку - фиксированным числом ретрансмитов.

1. Modbus_over_serial_line_V1_02.pdf

С учетом адреса.

2. Хочется простого репитера, не вникающего даже в CRC. Хотя, с другой стороны, если прикрутить именно UDP, то и аппликуха влезет достаточно умная

3. +1

Падаждытэ

Насколько я понимаю, есть спецификация Modbus over TCP, а вот over UDP как-то не встречал.

это не повод. Речь же вроде шла о туннелировании пакетов Modbus over serial line через сие устройство. А Modbus over TCP говорит, что CRC относится у него не к просто к инкапсулированному пакету Modbus over serial line, а к пакету в рамках TCP, где мухи отдельно и котлеты отдельно, потому это не есть туннелирование в чистом виде. ИМХО, туннелировать через UDP будет всё же попроще

Может я чего-то не вкурил? Я понял так, что хочется преобразователь Modbus over TCP <-> Modbus over serial line, чтобы и то и то согласно спецификации работало.

Хм... думаю, что речь всё же шла об туннелировании Modbus over serial line <->TCP/UDP <->Modbus over serial line. При этом преобразование Modbus over serial line <->TCP/UDP может делаться как в устройстве, подключенном по RS к PC (чтобы не писать нового софта - вариации на тему Modbus over serial line гораздо более распространены), так и в самом PC.