сниффер ком порта Опции

[Alex_2015]

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

[juvf]

2ТС Тут только аппаратный снифер поможет. Можно сделать MODBUS-RS485 to MODBUS-TCP. А вот тсп-модбас уже акулой смотреть, она знает модбас и может его парсить.

2jcxz Утопия. Ни фига не сможет вин/лин по таймаутам работать. Если только на скорости 100 бод. У нас MODBUS на 921600 работает, ОСи скромно отдыхают в сторонке.

Бред какой-то вы пишите.... Теоретически лошадь, практически упала. Я эти теоретические сказки про возможность реализации чистого модбаса на ПК слышу много лет. Все они разбиваются о попытки практической реализации модбаса на ПК. Попробуйте написать консольную программку, без гуи... которая просто бы принимала и считала кол-во пакетов с правильным црц? и в студию.

ps Ну если говорить про совсем чистый модбас, то по спецификации пакет, у которого внутри между байтами больше 1,5 символьного интервала считается не годным.

pps

Я не вижу никаких причин в современной системе, не загруженной тяжёлой работой, имеющей как правило несколько процессорных ядер с ГГц-выми тактовыми частотами, которые почти всё время просто тупо простаивают, не отреагировать на событие почти мгновенно, обработав например прерывание одним ядром и тут же переключить другое ядро на выполнение высокоприоритетного thread-а драйвера сис. уровня UART, а третьим ядром выполнить пользовательский высокоприоритетный код с ReadFile.

ВНЕЗАПНО в Qt 5.6 появился класс для работы с модбасом. Покопался в дебрях документации и нашел, что этот класс не может распознавать фреймы в 3.5 символа. В документации Qt5.7 не могу это ограничение найти. В libmodbus тоже не сказано, что у них не чистый модбас.... Гдето же были оговорки по таймаутам.... не могу найти..... может и вправду эти сказки реализовали и финты с RDA и CTI запилили? Кто пользовал эти либы? Сможет QtModbus или libmodbus распознать(разделить) 2 пакета RTU, идущих подряд и разделённых 3.5 символами тишины, на скорости 921600, на каком нить стареньком одноядерном компе, на котором еле-еле гуи ворочится и процессор занят кучей увесистых задач?

[Lagman]

Сможет QtModbus или libmodbus распознать(разделить) 2 пакета RTU, идущих подряд и разделённых 3.5 символами тишины, на скорости 921600, на каком нить стареньком одноядерном компе, на котором еле-еле гуи ворочится и процессор занят кучей увесистых задач?

В рекомендациях modbus сказано (MODBUS over Serial Line Specification and Implementation Guide V1.02, стр. 13)

The implementation of RTU reception driver may imply the management of a lot of interruptions due to the t1.5 and t3.5 timers. With
high communication baud rates, this leads to a heavy CPU load. Consequently these two timers must be strictly respected when the
baud rate is equal or lower than 19200 Bps. For baud rates greater than 19200 Bps, fixed values for the 2 timers should be used: it is
recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).

Но наверно даже с этими значениями без ОСРВ не поймать эти моменты, и если T1.5 почти никто не проверяет, то с T3.5 главное не начинать передачу пакета (запрос или ответ) раньше этого момента и можно "терпеть" с передачей вплоть до истечения времени ожидания ответа.

[juvf]

it is recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).

ЗАПЕЙСАЛ.