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

[Alex_2015]

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

[juvf]

для любителей растяжек НИКОГДА не работавших с длинными реальными линиями.

А что такое длинная реальная линия? с линией в 1200 метров не работал..... но несколько сотен метров - был опыт. Ни чего в линию не дули, ни до ни после передачи... линия была на растяжках.

За такую "подтяжку" криворуким дизайнерам надо отрывать гениталии. Она КАТОСТРОФИЧЕСКИ гробит дальность передачи.

Так в даташитах на драйвера эти растяжки в схемах как ..... Typical Half-Duplex RS-485 Network.

zltigo, а вы как с 485-ым работаете? вообще без растяжек? Иногда разработчики забывали растяжку на линии сделать... так, когда линия свободна - все на линии непрерывно ловят мусор... непрерывно по уарту а процессор идёт мусор и связи толком нет.

[zltigo]

zltigo, а вы как с 485-ым работаете? вообще без растяжек?

Разумеется без.
Предпочтение отдается, как уже писал, Failsafe приемникам (разумеется тем, которые True), но это для уменьшения помех, а не для того что бы мечтать, что помех не будет.
Растяжки опциональные в железе предусмотрены, но ТОЛЬКО на случай подключений чужого железа которое делали убогие программисты не поддерживающие активное состояние линии перед началом передачи. Увы, сие не редкость и Вы тому живое свидетельство. Для систем в котором используется гарантрованно свое оборудование на своем протоколе - нет и этой опции за полной ненадобностью.

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

Все это совершенно нормально БЕСПРОБЛЕМНО фильтруется. Для фильтрации, например, в случае MODBUS и заложены те самые 1,5 и 3,5 интервалы АКТИВНОГО состояния, но без передачи, и само собой обработка ошибок собственно UART.

[juvf]

Все это совершенно нормально БЕСПРОБЛЕМНО фильтруется. Для фильтрации, например, в случае MODBUS и заложены те самые 1,5 и 3,5 интервалы АКТИВНОГО состояния, но без передачи, и само собой обработка ошибок собственно UART.

не ради холевара.... а ради прокачки скила.... как допустим, ПК БЕСПРОБЛЕМНО делает интервал активного состояния без передачи данных? как в покупных преобразователях усб-485 или 232-485 ПК делает активные паузы? это раз

2)но понятно.... что перед отправкой пакета сделать паузу, то вероятность ошибок будет меньше.... линяя будет "нешумная" и слейв получит пакет нормально. Но если линяя брошена... растяжек нет... то в УАРТ постоянно сыплет мусор. Понятно, что слейв считает црц и вероятность что получился из мусора годный пакет бесконечно мала.... Слейв в мусоре годного пакета не найдет. Но мусор то есть... и слейву нужно этот мусор обрабатывать... т.е. слейв непрерывно копается в мусоре и тратит свои ресурсы. Кто-то скажет - что эти ресурсы ничтожно малы.... но на каком нить АтТини не так уж и малы. с растяжками мусора нет.... может и могут быть помехи.... но они очень редки

в случае MODBUS и заложены те самые 1,5 и 3,5 интервалы АКТИВНОГО состояния

эээээ.... в MODBUS вроде нет ни каких интервалов активного состояния. там есть интервалы тишины.


ps я всегда в своих устройствах делаю счетчик пакетов с битыми црц, и счетчик пакетов адресованных "мне". всегда интересно.... на сколько качественная связь.... сколько пакетов потеряно? каковы помехи? Приятно увидеть через год, что счетчик битых либо не изменился, либо инкрементировался на 1.

[zltigo]

не ради холевара.... а ради прокачки скила.... как допустим, ПК БЕСПРОБЛЕМНО делает интервал активного состояния без передачи данных? как в покупных преобразователях усб-485 или 232-485 ПК делает активные паузы? это раз

Мне безразлично кто и что НЕ делает и по какой причине. Я говорю о том, как НАДО делать и как делаю сам.

но понятно.... что перед отправкой пакета сделать паузу, то вероятность ошибок будет меньше.... линяя будет "нешумная" и слейв получит пакет нормально. Но если линяя брошена... растяжек нет... то в УАРТ постоянно сыплет мусор.

Ну и пусть сыпет. Всегда возможна, пусть даже и нештатая ситуация, когда посыпется мусор и с такой ситуацией надо уметь БЕСПРОБЛЕМНО справляться.

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

Тем не менее тот же MODBUS начинался тогда, когда помянутая Вами тини была-бы более, чем крута на фоне чего либо типа 8080 мегагерцового. Тратить ресурсы на самом деле не приходится особо, поскольку первоначальный отсев мусора идет уже по ошибкам фиксируемым UART, потом по тем тому самому 1,5 интервалу. В случае MODBUS контроль адреса и так далее....

эээээ.... в MODBUS вроде нет ни каких интервалов активного состояния. там есть интервалы тишины.

Которые гарантированно обеспечиваются активизацией передатчика а не навешиванием сопливых растяжек.

Про 1,5 байта в начале не понял.
Там ведь и в начале и в конце 3,5 байта, а от 1,5 до 3,5 - это признак битого пакета.

Вот в начале и делается 1,5 байтовая пауза, кторая
1) Обепечивает признак битого пакета для любого мусора возможно идущего из линии.
2) Обеспечивает гарантрованный стоп бит и соответственно захват байтовой синхронизации UART-ом.
Для других протоколов может быть достаточно однобайтовой паузы только для синхронизации.

Кстати про FAILSAFE - большая их часть нифига не FAILSAFE (т.е. без смещённого порога).

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