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

[Alex_2015]

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

[bolden]

Добрый день,
если вы ловите запрос+ответ и если не принципиально ловить паузы между ними, то разделить запрос и ответ, как мне кажется, можно "расшифровкой" протокола, если конечно данные приняты без ошибок.
При этом методе если запрос принят с ошибкой, то не сможем определить его длину, как следствие не "расшифруем" и ответ.

[dm37]

Можно принимать байты по одному с таймаутом, т.е. таймаут только на приём одного байта. Пока синхронизация приёма пакетов не нарушилась работаем только с crc, если нарушилась, то устанавливаем таймаут равный времени приёма одного байта + небольшой запас (не помню интервал тишины в modbus, вроде три байта). Если передача идёт по стандарту modbus, то таймаут на два-три байта тишины должен помочь

[Alex_2015]

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

Эксперименты с таймаутом особо не помогают. При скорости 115200 время передачи байта составляет 95мкс, а таймауты устанавливаются в миллисекундах.
Основную проблему я вижу в том, что драйвер подбирает у системы данные с некоторым периодом. Программа у драйвера запрашивает данные тоже с каким-то периодом. За это время фактически драйвер может взять у системы несколько байт. Причём может схватить хвост запроса и начало ответа.
Отсюда и лезут проблемы.

[dm37]

т.е. вы подключаетесь к какой либо паре устройств работающих по modbus (запросы отправляете не вы) и задача стоит разобрать протокол (синхронизироваться)?
если да, то можно со сдвигом принятых данных считать crc и где crc верна, там и есть начало пакета. Определить "запрос" или "ответ" можно уже по протоколу.

[DASM]

честно говоря я бы такую задачу решал иначе. А именно - сниффер пишется на МК, и отдает пакеты в комп приплюсовывая к ним time stamp

[_3m]

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

Вы все правильно понимаете.
Вывод из этого простой : стандартные ОС со стандартными компортами (обычно 16550-compatible) ловить таймауты modbus-rtu неспособны. Ставьте конвертор на МК.

[Lagman]

Очень давно, чем то подобным занимался (отлавливал пакет modbus который завешивал устройство), сейчас для измерения времянок воспользовался бы каким нибудь цифровым логическим анализатором (например недорогим китайским), а тогда использовал программу COM Port Toolkit (раньше была бесплатной для русcкоговорящих), в ней даже штамп времени есть (вроде как миллисекунды, но с какой точность не знаю). Т.к. по стандарту modbus рекомендуют на скоростях более 19200 делать T3.5 = 1,750мс то возможно программа поймает начало ответа и отправку нового запроса.

[k155la3]

Если пишете сами, попробуйте использовать таймауты драйвера
см. тут
Писать надо на достаточно низком, в хорошем смысле, уровне. С, CPP PAS, с событиями-потоками.
Win32API, ReadFileEx() etc.
Для модбаса надо отлавливать паузы 3.5 байта.

[megajohn]

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

как вариант, соберите данные любым готовым сниффером и скормите этой программе
mb_dump_parser

если результат устроит и вам нужно в реалтайме, то тогда вердикт "ЭТО ВОЗМОЖНО и без таймаутов, пишите софт"

[Alex_2015]

На тему конвертора мысли были. Но только на самый крайний случай.
Сейчас пока используется модифицированный модбас, в котором есть признаки, позволяющие однозначно определять начало и конец посылок.
Есть потребность перейти к стандартному модбасу и будет нужна прога, которая позволит в реальном времени отслеживать обмен между устройствами в целях отладки.
Сегодня перечитывал старую информацию, которую использовал при освоении программирования ком порта и нашёл то, что пропустил. Есть в структуре DCB символ XOFCHAR, который позволяет определить конец посылки. Осталось непонятным, его записывает драйвер в массив приёма или этот символ должен быть записан передатчиком в конец сообщения.
Интернет по этому поводу подробностей пока не дал. Буду пробовать экспериментально.
Была ещё мысль отслеживать событие DCD data carrier detect, но боюсь оно ожидаемого результата не даст.
Была мысль алгоритмически ловить конец посылки через подсчёт CRC, но вариант не самый красивый. Хотя должен привести к результату.

[jcxz]

честно говоря я бы такую задачу решал иначе. А именно - сниффер пишется на МК, и отдает пакеты в комп приплюсовывая к ним time stamp

Я бы тоже решал по-другому. А именно: с открытия MSDN и прочтения всего, что касается работы с COM-портом. Чего автор как видно не сделал.
Иначе он знал бы о функции SetCommTimeouts() WinAPI и многих других полезных. А не строил пустые предположения.
Далее: установил-бы ReadIntervalTimeout and ReadTotalTimeoutMultiplier to MAXDWORD and sets ReadTotalTimeoutConstant to a value greater than zero and less than MAXDWORD
как советует MSDN, повысил приоритет принимающего потока, а также прочитал в MSDN про семейство функций QueryPerformanceFrequency()/QueryPerformanceCounter() и понял бы, что даже 95мкс - не есть проблема.
Другое дело что всё это лучше делать на железном RS-232 компа, а не USB-COM переходнике, времянки которого сомнительны.

Даже и с железным COM-портом и приоритетом потока ==REALTIME возможно будут проблемы из-за работы других драйверов винды (винта, видео и т.п.). Так что возможно лучше вынести такую работу на уровень драйверов.

Есть в структуре DCB символ XOFCHAR, который позволяет определить конец посылки.

Это вообще из другой оперы. Это для software flowcontrol.

Была мысль алгоритмически ловить конец посылки через подсчёт CRC, но вариант не самый красивый. Хотя должен привести к результату.

Лучше откройте наконец-то MSDN, а не занимайтесь ерундой.

[zltigo]

QueryPerformanceFrequency()/QueryPerformanceCounter() и понял бы, что даже 95мкс - не есть проблема.

К чему опрос счетчиков хоть с тактовой процессора, если их НЕЛЬЗЯ со сколь-нибудь детерминированной точностью привязать к событиям UART.

[Alex_2015]

Читал я MSDN в своё время, когда осваивал программирование ком порта. Но это ни чего не даёт. Когда драйвер захочет вернуть данные пользовательской программе, тогда и вернёт. И совсем не в режиме реального времени.
А с таймоутами я экспериментировал, результат далёк от желаемого.

[jcxz]

К чему опрос счетчиков хоть с тактовой процессора, если их НЕЛЬЗЯ со сколь-нибудь детерминированной точностью привязать к событиям UART.

ТСу нужно не опрашивать счётчики, а вести лог обмена по каналу UART. Причём с таймштампами точностью до десятков мкс. Ну или хотя-бы видеть, что между двумя соседними байтами X1 и X2 была хоть какая-то пауза, обнаруженная драйвером канала или её не было. Аппаратура UART 16550 позволяет определять наличие паузы, значит и драйвер это должен видеть. А функция SetCommTimeouts(), как следует из её описания, должна позволить получить эту инфу юзеру.

Читал я MSDN в своё время, когда осваивал программирование ком порта. Но это ни чего не даёт. Когда драйвер захочет вернуть данные пользовательской программе, тогда и вернёт. И совсем не в режиме реального времени.

Т.е. - Вы утверждаете что MSDN врёт, говоря, что:

Код

If an application sets ReadIntervalTimeout and ReadTotalTimeoutMultiplier to MAXDWORD and sets ReadTotalTimeoutConstant to a value greater than zero and less than MAXDWORD, one of the following occurs when the ReadFile function is called:
If there are any bytes in the input buffer, ReadFile returns immediately with the bytes in the buffer.
If there are no bytes in the input buffer, ReadFile waits until a byte arrives and then returns immediately.

Читаем первую строку с "if" и вторую, видим там слово "immediately", думаем.
Я почти уверен, что если приоритет вызывающего потока будет ==THREAD_PRIORITY_TIME_CRITICAL, а приоритет процесса ==REALTIME_PRIORITY_CLASS, то как только аппаратура UART зафиксирует, что в FIFO есть символы и с момента приёма последнего из них прошло более 3.5 символьных интервала, так сразу и вернёт управление вызывающему потоку.
Возможно даже хватит меньших приоритетов у процесса/потока, главное - превысить приоритеты всех других работающих в системе потоков.
И всё конечно зависит ещё от драйвера. Стандартный виндовый драйвер для UART 16550 на сис. шине должен соответствовать требованиям MSDN. Про сторонние драйвера UART, тем более для USB-UART речи нет - они могут только примерно соответствовать MSDN. Но думаю, если устройство, реализующее CDC-класс USB, при отправке данных, выделяет разные кадры ModBus в отдельные пакеты по USB, то и драйвер CDC-класса под виндой также сможет выполнить требования SetCommTimeouts().

[k155la3]

Если не требуется переносимость-универсальгность, а также работа на физ. RS232 из серии 16550.
Можно попробовать "накрутить" FT2232, например, используя ихнюю (FTDI) библиотеку, позвляющую
работать напрямую, и с расширенным сервисом-API к функциям.
Но надо как следует прокурить даташиты и док на API
ps - оно еще и неплохо увязывается с RS485.

Сообщение отредактировал k155la3 - Sep 8 2016, 06:03

[Alex_2015]

Я не утверждаю, что MSDN врёт. Просто констатирую факты.
Возможно ошибка есть более глубоко в моём коде и я её пока не вижу. Поэтому пытаюсь освежить информацию по работе с портом, возможно пока та самая ошибка не проявлялась за несколько лет работы проги.

[zltigo]

ТСу нужно не опрашивать счётчики, а вести лог обмена по каналу UART. Причём с таймштампами точностью до десятков мкс.

Повторю еще раз - нет никакого смысла в "таймштампами точностью до десятков мкс", если само событие фиксируемое уже "драйвером" совершенно произвольгую задержку и сами события начинают склеиваться в одно уже на уровне FIFO UART.

Аппаратура UART 16550 позволяет определять наличие паузы...

Нет. Только выдает прерывании при заполнении FIFO и при межбайтовой паузе более 4x символов. При этом прием последующих символов продолжается в то же FIFO.

видим там слово "immediately", думаем.

Когда придумаете, где это "immediately" отнормированно в микросекундах и куда денутся байты пришедшие после 3,5 символьного интервала, причем UART будет еще тянуть собственый 4x символьный таймаут до того, как сгенерит прерывание, обязательно сообщите .

ps - оно еще и неплохо увязывается с RS485.

Ослинные уши пакетного а НЕ БАЙТОВОГО интерфейса USB будут торчать по любому.

[DASM]

Я бы тоже решал по-другому. А именно: с открытия MSDN и прочтения всего, что касается работы с COM-портом. Чего автор как видно не сделал.
Иначе он знал бы о функции SetCommTimeouts() WinAPI и многих других полезных. А не строил пустые предположения.
Далее: установил-бы ReadIntervalTimeout and ReadTotalTimeoutMultiplier to MAXDWORD and sets ReadTotalTimeoutConstant to a value greater than zero and less than MAXDWORD
как советует MSDN, повысил приоритет принимающего потока, а также прочитал в MSDN про семейство функций QueryPerformanceFrequency()/QueryPerformanceCounter() и понял бы, что даже 95мкс - не есть проблема.
Другое дело что всё это лучше делать на железном RS-232 компа, а не USB-COM переходнике, времянки которого сомнительны.

Даже и с железным COM-портом и приоритетом потока ==REALTIME возможно будут проблемы из-за работы других драйверов винды (винта, видео и т.п.). Так что возможно лучше вынести такую работу на уровень драйверов.


Это вообще из другой оперы. Это для software flowcontrol.


Лучше откройте наконец-то MSDN, а не занимайтесь ерундой.

MSDN в именно в этой части читал лет 15 назад. Неифга оно так не работает (еще на тех -то компах, когда COM порт не был чудом). zltigo прав абсолютно. Точно вспоминать что именно не работает уже не смогу, помню что нужен был именно Modbus RTU и помню что эта возня с таймаутами в винде достала так, что ушел на SLIP протокол, благо не был ограничен

[jcxz]

Повторю еще раз - нет никакого смысла в "таймштампами точностью до десятков мкс", если само событие фиксируемое уже "драйвером" совершенно произвольгую задержку и сами события начинают склеиваться в одно уже на уровне FIFO UART.

Именно на уровне FIFO эти события никак не склеиваются. От UART есть прерывание заполнения всего FIFO и есть прерывание таймаута. Этих двух прерываний абсолютно достаточно для определения - была дырка между байтами или нет. И для ModBus эти таймштампы не нужны, но нужен факт наличия дырки.
Такой алгоритм работы UART есть во многих контроллерах, например LPC17xx. И он позволяет легко разделять кадры по дыркам между ними. И этот алгоритм - наследство от железного 16550.
Виндовый драйвер после чтения FIFO конечно может склеить, но как-бы описание SetCommTimeouts() говорит об обратном.

Нет. Только выдает прерывании при заполнении FIFO и при межбайтовой паузе более 4x символов. При этом прием последующих символов продолжается в то же FIFO.

А это не одно и то же? Прерывание по таймауту пришло - считали содержимое FIFO, запомнили что после этого содержимого была пауза. Всё.
Или Вы думаете, что вход в ISR может настолько запоздать, что придёт новый символ после 3.5-символьной паузы?

Когда придумаете, где это "immediately" отнормированно в микросекундах и куда денутся байты пришедшие после 3,5 символьного интервала, причем UART будет еще тянуть собственый 4x символьный таймаут до того, как сгенерит прерывание, обязательно сообщите .

Какие 3.5 + 4 интервала?? Принят очередной байт - запускается счётчик таймаута - он отсчитывает 3.5 символьных интервала - генерится прерывание - ISR считывает содержимое UART, пишет в программный FIFO и пишет туда же признак наличия дырки.
А ещё можно в свойствах COM-порта выключить FIFO. Вот тогда будет: пришёл байт, сразу прерывание, ISR кладёт символ в программное FIFO и задача, вызвавшая ReadFile() и ждущая появления данных, тут же переходит из состояния wait в состояние run и получает управление от шедулера и выгребает данные из этого программного FIFO. Вот тогда след. символ точно успеет прийти до входа в ISR. И у драйвера есть все возможности выполнить обязательство "immediately".

MSDN в именно в этой части читал лет 15 назад. Неифга оно так не работает (еще на тех -то компах, когда COM порт не был чудом).

Возможно конечно, что есть ошибки в дровах винды. Но принципиальной невозможности организовать со стороны драйвера обнаружение этих дырок я не вижу. И проверять надо под современной виндой.

[zltigo]

Именно на уровне FIFO эти события никак не склеиваются. От UART есть прерывание заполнения всего FIFO и есть прерывание таймаута. Этих двух прерываний абсолютно достаточно для определения - была дырка между байтами или нет.

Разумеется нет.
1) таймаут отрабатывает на 4 символа паузу и приход следующего MODBUS фрейма приведет с склеиванию фреймов.
2) Если драйвера и система не успеет отработать прерывание до прихода следующего фрейма, то они опять склеятся или FIFO или уже в буферах драйвера.
3) Прерывания по таймауту и по заполнению FIFO не отличаются, так что приход прерывания, как такового не означает конца фрейма.

И для ModBus эти таймштампы не нужны,

О чем я Вам уже и писал.

но нужен факт наличия дырки.

к которому они никакого отношения не имеют, о чем уже тоже писал. Тау что помянуты они всуе.

Такой алгоритм работы UART есть во многих контроллерах, например LPC17xx. И он позволяет легко разделять кадры по дыркам между ними. И этот алгоритм - наследство от железного 16550.

Какой "такой"? В том же помянутом всуе LPC17XX есть еще навороты, типа CTI и самое главное, есть в отличие от WIN, жесткое реальное время и кучка аппаратных таймеров для организации поддержки таймаутов, как собственно UART, так и протоколов типа того же MODBUS-RTU (да гореть его недоучкам авторам в аду). Так что для микроконтролера, даже с минималистичным 55, проблем в реализации кривейшего MODBUS нет.

Виндовый драйвер после чтения FIFO конечно может склеить, но как-бы описание SetCommTimeouts() говорит об обратном.

Поворю, что для начала склеит уже аппаратное FIFO UART ну и "описание" ни о чем не говорит, кроме того, что не будет ДОБАВЛЯТЬ никаких ДОПОЛНИТЕЛЬНЫХ таймаутов к тем, которые так или иначе получатся в системе, которая НИКАК НЕ поддерживает реальное время.

А это не одно и то же? Прерывание по таймауту пришло - считали содержимое FIFO, запомнили что после этого содержимого была пауза. Всё.

Перечитайте неписанное выше.

Или Вы думаете, что вход в ISR может настолько запоздать, что придёт новый символ после 3.5-символьной паузы?

Третий раз - сам таймаут FIFO уже 4 символа. Дальше обслуживание прерывания еще может запоздать и еще как, тем более, что тут НЕ микроконтроллерр и Вы висите НЕ на прерывании. На прерывании висит драйвер, который его обслужит, и запустит планировщик системы, который уж потом в меру своих очередей и приоритетов сообщит ожидающему приложению. Результат всего этого плачевен - никакой повторяемости результатов по времени нет. Совсем нет. Смиритесь.
Так что надежно работающий снифер выделяющий MODBUS-RTU фреймы из 485 под Win нереален. Для низких скоростой и медленнннннооо отвечающих перeферийных устройств, да, частные реализации оаботающие на конкретной машине, возможны.

И проверять надо под современной виндой.

Будет только хуже . Все обещания, которые Вы захотели увидеть в описании драйверов на самом деле тянутся от тех самых Win 3.1/85, котрые еще были как то похожи на "микроконтроллер". В "современных" байтовые интерфесы вообще похоронены де-факто.

[jcxz]

Разумеется нет.
1) таймаут отрабатывает на 4 символа паузу и приход следующего MODBUS фрейма приведет с склеиванию фреймов.
2) Если драйвера и система не успеет отработать прерывание до прихода следующего фрейма, то они опять склеятся или FIFO или уже в буферах драйвера.

Кто-ж спорит что в этом случае склеятся. Только:
1) ТС нужна не рабочая система сбора данных, а система для мониторинга в целях отладки. Значит к этой системе можно предъявить спец. требования (отсутствие посторонних задач, достаточная мощность и др., которые обеспечат достаточную реалтаймовость системы и скорость реакции на прерывания железа).
2) рассмотрим как работает ПО в сети обмена ModBus и начинаем думать какие будут минимальные дырки:
а) предположим мы наблюдаем обмен двух устройств - устройство А передаёт кадр, устройство Б - принимает, обрабатывает и отвечает (режим запрос-ответ), а наше устройство (комп) мониторит этот обмен со стороны:
А передаёт кадр-запрос, заканчивает его передачу (передан последний бит), в приёмнике Б начинается отсчёт таймаута, проходит 4 символьных интервала - устройство Б начинает обработку кадра-запроса, а потом отвечает на него своим кадром-ответом, т.е. - переключает свой драйвер в режим передачи, начинается выдвигание битов первого передаваемого слова ответа.
Когда в FIFO устройства-монитора появится этот первый байт ответа? Правильно, через: 4 символа таймаута + время обработки в Б + 1 символ ответа. Даже если предположить, что устройство Б обрабатывает запросы мгновенно, всё равно имеем в устройстве-мониторе паузу в 5 символов! Т.е. - устройство-монитор сгенерит прерывание таймаута как минимум за один символ до прихода 1го символа ответа.
А теперь ещё немного подумаем и поймём, что после того как устройство Б переключило свой драйвер RS-485 в режим передачи, то после этого и до начала выдвигания бит первого слова ответа, оно должно обеспечить некую паузу для того, чтобы и устройство А принимающее его ответ заведомо успело переключить свой драйвер RS-485 в режим приёма. А ведь и устройство Б может иметь драйвер RS-485 с гальванической развязкой, которому нужно время на переключение RX->TX и у устройства А тоже может быть такой драйвер, требующий доп. задержки. И ПО ModBus-драйвера, написанное прямыми руками, должно учитывать, что у устройств с которыми оно будет работать, могут быть медленные опторазвязки RS-485, а значит давать возможность или конфигурировать минимальное время переключения себя RX->TX или просто хотя-бы выдерживать это время с большим запасом.
Это всё приводит нас к мысли, что паузы запрос-ответ будут заведомо больше чем 5 символьных интервалов.
б) конечно возможен вариант системы работающей в режиме не запрос-ответ, а запрос-запрос-запрос-...-ответ (т.е. - цикл запроса состоит из нескольких ModBus-кадров). Или просто в режиме широковещательной передачи кадров. Но, имхо, это редкий вариант. Да и в этом случае такая система должна обспечить чтобы дырки между кадрами были заведомо больше 4 символов, хотя-бы для того чтобы гарантировать чёткое их обнаружение на приёмной стороне. А не работать на грани фола с дыркой между двумя TX-кадрами ==4 символам.

3) Прерывания по таймауту и по заполнению FIFO не отличаются, так что приход прерывания, как такового не означает конца фрейма.

Да ладно?
Открываем даташит на LPC17xx содержащий UART с, как в нём утверждается: Register locations conform to 16C550 industry standard. Читаем описание регистра IIR и видим две разные причины прерывания: RDA и CTI. И даже если размер принимаемого кадра равен FIFO trigger level, то всё равно можно обнаружить границу кадра: после получения RDA считать (FIFO trigger level - 1) символов и через некоторое время получить ещё и CTI, сигнализирующее о границе кадра.
Даташит на прародитель 16C550 найти конечно сейчас трудно, но вот эта ссылка например http://www.lookrs232.com/rs232/iir.htm говорит, что и в нём дело обстояло так же.

Какой "такой"? В том же помянутом всуе LPC17XX есть еще навороты, типа CTI и самое главное, есть в отличие от WIN, жесткое реальное время и кучка аппаратных таймеров для организации поддержки таймаутов,

Для "поддержки таймаутов" в LPC17xx таймера не нужны, вполне достаточно RDA и CTI. Это на приём. Только на передачу нужен таймер, чтобы отследить момент опустошения сдвигового регистра передатчика и переключения драйвера RS-485 с TX на RX.

Третий раз - сам таймаут FIFO уже 4 символа. Дальше обслуживание прерывания еще может запоздать и еще как, тем более, что тут НЕ микроконтроллерр и Вы висите НЕ на прерывании. На прерывании висит драйвер, который его обслужит, и запустит планировщик системы, который уж потом в меру своих очередей и приоритетов сообщит ожидающему приложению. Результат всего этого плачевен - никакой повторяемости результатов по времени нет. Совсем нет. Смиритесь.

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

к которому они никакого отношения не имеют, о чем уже тоже писал. Тау что помянуты они всуе.

Таймштампы нужны пользовательскому процессу, вызывающему ReadFile(), особенно с выключенным FIFO, чтобы обнаружить дырки:

Код

LARGE_INTEGER t1, t2;
while () ReadFile(); //опустошаем RX-поток UART
for (QueryPerformanceCounter(&t2);; t2 = t1) {
  ReadFile();
  QueryPerformanceCounter(&t1);
  t2.QuadPart = t1.QuadPart - t2.QuadPart;
  //вот здесь t2 будет или примерно равно 1-му символьному интервалу, если чтение идёт внутри кадра; или больше 4-х символьных кадров, если последняя ReadFile() считала 1-й символ ModBus-кадра
  //т.е. - поставив пороговое сравнение скажем на сравнение t2 < 3-х символьных интервалов или t2 >= 3 символьным интервалам можно с запасом обнаружить дырку
  //временем выполнения этого кода на мощном незагруженном процессоре и высокоприоритетном thread-е можно пренебречь
}

[Alex_2015]

Я всё-таки внесу некоторые дополнения.
Использую преобразователь USB-RS485. Провёл несколько экспериментов и выяснил, что данные из порта читаются пачками по 4-16 байт. Причём начало запроса всегда читается с начала, начало ответа читается вместе с хвостом запроса.
Эксперименты с таймаутами мало что меняют. Здесь, я думаю, большую роль играет характер устройства (виртуальный порт).
Так случилось, что преобразователь построен на основе FTDI микросхемы. У неё есть возможность работы через D2XX драйвер, который, если верить описанию, в большей степени позволяет мониторить события железки. Если кто работал с ним, насколько это так.
Сейчас вынужден временно переключиться на другую задачу, поэтому по этой буду только инфу изучать в свободное время.

[zltigo]

Т.е. - устройство-монитор сгенерит прерывание таймаута как минимум за один символ до прихода 1го символа ответа.

Сколько много слов было написано выше, но результат неизменный - прерывание должно быть обработано драйвером, который должен дернуть операционную систему, которая должна запустить ожидающую сигнала задачу, котороая должна вычитать принятую информацию, за время прихода ОДНОГО символа. О скорсти передачи здесь, кажется не говорилось, но при, например, 115200 это очень мало для монстральных операционок типа WIN/LIN.

А теперь ещё немного подумаем и поймём....

Неправильно написано, правильно "еще придумаем" .
Проблема в том, что на любую Вашу фантазию, можно нафантазировать противоположную

, что после того как устройство Б переключило свой драйвер RS-485 в режим передачи, то после этого и до начала выдвигания бит первого слова ответа, оно должно обеспечить некую паузу для того, чтобы и устройство А принимающее его ответ заведомо успело переключить свой драйвер RS-485 в режим приёма.

Для этого у устройства передатчика есть вагон времени:
1) тот самый 3.5 таймаут (да, да я знаю, что так делать не надо, но знаю, что делают)
2) 0.5 символьный таймаут до срабатывания прерывания.

А ведь и устройство Б может иметь драйвер RS-485 с гальванической развязкой, которому нужно время на переключение RX->TX и у устройства

Может, но быстродействие развязки должно быть таким, что бы обеспечивать передачу одиносного БИТА без существенных искажений, так что мимо.

А тоже может быть такой драйвер, требующий доп. задержки. И ПО ModBus-драйвера, написанное прямыми руками, должно учитывать, что у устройств с которыми оно будет работать, могут быть медленные опторазвязки RS-485, а значит давать возможность или конфигурировать минимальное время переключения себя RX->TX или просто хотя-бы выдерживать это время с большим запасом.

Ох уж это "должно" прежде всего оно должно обеспечить собственную работоспостобность, а не возможность подключения неприспособленного для этого железа, типа PC c Windows.

Это всё приводит нас к мысли, что паузы запрос-ответ будут заведомо больше чем 5 символьных интервалов.

Не нас, а Вас . И не будут заведомо, а могут быть . Об желаемых "огромных" 5 символьных интервалах тоже можно поговорить. FIFO в UART появилость в PC не сразу и по одной простой причине - операционые системы тупо не успевали обрабатывать потоки байтов уже на скростях 9600 .

Открываем даташит на LPC17xx содержащий UART с, как в нём утверждается: Register locations conform to 16C550 industry standard. Читаем описание регистра IIR и видим две разные причины прерывания: RDA и CTI. И даже если размер принимаемого кадра равен FIFO trigger level, то всё равно можно обнаружить границу кадра: после получения RDA считать (FIFO trigger level - 1) символов и через некоторое время получить ещё и CTI, сигнализирующее о границе кадра.
Даташит на прародитель 16C550 найти конечно сейчас трудно, но вот эта ссылка например http://www.lookrs232.com/rs232/iir.htm говорит, что и в нём дело обстояло так же.

Открывать 17xx не надо. Это НЕ PC. И найти 550 очень легко. Только искать нужно вообще-то не его, а 450. FIFO начиналось 82450 чипе, где дополнительных идентификаторов нет. А драйвера PC обслуживают и вобще 8250. Так что появившиеся инентификаторы прерывания драйверам PC по барабану - не обрабатывабтся и ПРИЛОЖЕНИЮ НЕ ПЕРЕДАЮТСЯ.

Для "поддержки таймаутов" в LPC17xx таймера не нужны, вполне достаточно RDA и CTI. Это на приём. Только на передачу нужен таймер, чтобы отследить момент опустошения сдвигового регистра передатчика и переключения драйвера RS-485 с TX на RX.

Еще раз - причем тут 17xx к PC? Вообше формально 17xx и помянутый Вами таймер не нужен, но это уже другая тема.

Это всего лишь слова и предположения. Тут может рассудить только эксперимент(-ы).

c 1984 года и поныне занимаюсь "экспериментами" с PC и UART на них.
Результаты не радуют отсутствием гарантированой стабильности. Причина одна - НЕ УСПЕВАЕТ гарантированно отработать операционная система и приложение за время прихода одного байта по UART.

Последние "эксперименты" были по весне - дабы не отсылать кучу железа, вместо железа написал эмулятор для PC некоего протокола у которого в стиле MODBUS признаком конца фрейма пауза длительностью более 64 бит на 115200. Казалось-бы , должно было проскочить. У немцев на их стендовой писишке не заработало, причем абсолютно стабильно не заработало. Пришлось живое железо таки посылать. Хотя, конечно, можно было и DOS приблуду написать .

[Ruslan1]

Мне кажется, изначально вопрос некорректно поставлен: из " данные преобразовать в удобоваримый вид, удобный для отладки работы сети устройств" вовсе не следует что "Надо написать свою".
Берите китайский логический анализатор за 10 баксов, там уже все написано. Для " отладки работы сети устройств" - самое оно. И писать ничего не нужно (если очень хочется, то конечно можно и свое дописать).
И для отладки сети устройств очень важно работать именно на уровне сигналов, а не байтов.так как байтовый уровень не покажет, что кто-то там не то количество стоповых передает, или что кто-то раньше положенной паузы передавать начал. А логический анализатор это покажет (ну и, конечно, псе корректное в байты переведет, чтобы самому не декодировать).

Хотя странно, что там отлаживать. Сначала на бумажке расписываете чего хочется, потом реализовываете и моделируете на этой же бумажке как код работает, ну и проверяете соответствует ли реальность бумажке с помощью логического анализатора. А байтовый лог в случае конфликтов и некорректной реализации никак не поможет разборкам и не покажет правильность работы.

[jcxz]

Может, но быстродействие развязки должно быть таким, что бы обеспечивать передачу одиносного БИТА без существенных искажений, так что мимо.

Вы путаете скорость передачи (от входа до выхода) и время переключения TX/RX. Скорость передачи может быть достаточной для передачах в МГц, а вот время переключения будут сотни мксек или даже миллисекунды.
Чем выше скорость переключения - тем дороже элемент. Во многих устройствах стоят дешёвые опторазвязки, вполне обеспечивающие скорость передачи и с запасом, а вот время переключения может быть и несколько мсек.
Соответственно - любой вменяемый передатчик RS-485 должен это учитывать и позволять увеличить время своего переключения RX на TX.

Ох уж это "должно" прежде всего оно должно обеспечить собственную работоспостобность, а не возможность подключения неприспособленного для этого железа, типа PC c Windows.

Всё это только Ваше личное мнение.
Аргументы я привёл, Ваши доводы против них - считаю малоубедительными. Дальнейший спор - бессмысленным. Имеющий уши - да услышит и сам всё опробует и вполне возможно - добъётся желаемого результата.

Берите китайский логический анализатор за 10 баксов, там уже все написано. Для " отладки работы сети устройств" - самое оно. И писать ничего не нужно (если очень хочется, то конечно можно и свое дописать).

Кстати - тоже хотел это с самого начала предложить. В этих лог.анализаторах как правило стоит CY7C68013A. Можно даже отключить внутреннюю EEPROM и написать свою прошивку для CY7C68013A и ПО на PC, разбирающее пакеты от CY7C68013A - тоже несложно своё написать.

[zltigo]

Вы путаете скорость передачи (от входа до выхода) и время переключения TX/RX. Скорость передачи может быть достаточной для передачах в МГц, а вот время переключения будут сотни мксек или даже миллисекунды.

Я все понял и ничего не путаю. Давайте пример, а не фантазии называемые "убедительными доводами", такого дивного приемопередатчика на бочку!

[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).

ЗАПЕЙСАЛ.

[zltigo]

и если T1.5 почти никто не проверяет

Что очень зря, ибо это есть механизм отсева сбоев и быстрого восстановления фреймовой синхронизации.

то с T3.5 главное не начинать передачу пакета (запрос или ответ) раньше этого момента и можно "терпеть" с передачей вплоть до истечения времени ожидания ответа.

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

[Lagman]

В частном случае, когда конкретные реализаторы протокола "плют", "терпят" и медленно обмениваются пакетами в которых паузы между фреймами определяются не протоколом а неспешым темпом обмена и меееедлееенннооо реагирующими на запросы слейвами, софтовый снифер под WIN как-бы ваделяет фреймы без проблем. Но при полноскоростном обмене шансов под WIN никаких .

Пропускная способность, это да, пострадает, но стандарты протокола никто не нарушает.

[demiurg_spb]

Добрый день коллеги!
Захотелось обсудить вопрос "продувки шины" перед выдачей пакта в линию сразу после включения драйвера RS485 на передачу.

Я обычно формирую требуемую паузу на шине с включенным передатчиком до и после передачи пакта.
Отсюда получается дыра межу фреймами в 2 раза больше, т.к. и мастер и слейв делают это.
Естественно, скорость передачи из-за этих пауз сильно снижается.

У меня есть сомнения, что если этого не делать можно наступить на грабли. Поясню.

1) Мастер хочет передать и не знает был ли шум в линии - следовательно надо "продуть" до, ну а после само-собой разумеется продувать необходимо чтобы слейв словил тишину.

2) Слейв хочет ответить на принятый запрос и тоже не знает про то, был-ли шум на линии с момента приёма пакета до переключения драйвера на передачу. Ведь по окончании паузы сформированной мастером, проходит некоторое время на обработку пакета и в это время линия висит либо в воздухе, либо растянута слабенькими резисторами и помехи могут дать ложный старт-бит. Пока писал это осознал, что если помеха в этот момент случилась, то продувка линии может уже и не спасти ситуацию, т.к. мастер может принять мусор, после которого правильный ответ слейва уже может быть и не валиден. Отсюда напрашивается вывод, что слейв должен мгновенно отвечать мастеру после приёма валидного запроса, либо сразу включать свой передатчик и заниматься подготовкой ответа.
Это несколько затруднительно, т.к. в моей текущей реализации это не реализовано (считать CRC на лету, сранивать первый байт запроса со своим адресом и даже может быть готовить ответ во время паузы, формируемой мастером). Кто-нибудь так уже сделал?

Давайте порассуждаем над этим увлекательным занятием - реализацией идеального MODBUS-RTU MASTER/SLAVE!

[megajohn]

Давайте порассуждаем над этим увлекательным занятием - реализацией идеального MODBUS-RTU MASTER/SLAVE!

RS422

[demiurg_spb]

Нет. Интересует именно RS485!
Наверное мне стоило создать отдельную тему. Прошу извинения у ТС, если это ему помешало.

[juvf]

Мастер хочет передать и не знает был ли шум в линии - следовательно надо "продуть" до, ну а после само-собой разумеется продувать необходимо чтобы слейв словил тишину.

Не нужно ни чего продувать. когда нет драйвера на линии там лог "1". Линяя RS485 должна быть подтянута (А к +V, B k GND). посмотрите осциллографом перевод из приема в передачу и через какое время начинает бит старт бит вылазить. Работает на скоростях от 9600 до 921600. По окончании ни чего мастеру дуть не надо... после передачи последнего байта я снимаю передачу и перехожу на прием. линия остается без драйвера. Подтягивающие резисторы обеспечат слейву лог "1" - это и будет тишина.
Если кто боиться, что в лини без драйвера есть шум... или может возникнуть шум.... нет там шумов. Подтяжка делает сво дело. На длинной линии можно словить наводку, электромагнитную помеху.... НО.... в рс485 длинная линия тянеться витой парой.... наведенный импульс в А+ таже будет и в B-, в итоге разность A и B сохраниться как без помехи.

Забудте про всякие продувки..... слейв как только принял пакет и обработал без всяких пауз и продувок может отвечать.

[demiurg_spb]

Мне бы Вашу непоколебимую уверенность!
Попробуйте поработать с силовой преобразовательной техникой...

[juvf]

ps

помехи могут дать ложный старт-бит.

не всё так печально. в 485 этого вообще не будет. но такое может возникнуть в рс232.... и тем не менее.... процессор получает уже UART.... так вот... как работает UART (по крайней мере в С51 ядре, да и в остальных примерно также)... переход из лог 1 в лог 0 - это ещё не старт бит. любая помеха в UART-е не является стартбитом. Чтоб уарт начал принимать байт, нужно нулевой уровень в линии на протяжении длительности 1-го бита. в 51-ом проце после перехода 1-0 запускается таймер... чререз 1/4 длительности импульса проверяется уровень на линии.... потом ещё через 1/4, и потом ещё раз через 1/4.... если все 3 раза на входе был лог 0 - то это считается стартбит. так что какаянить иголка в линии не запустит уарт на прием.

[demiurg_spb]

Про то, что бит поллится не за один раз - я естественно в теме. Но при высоких скоростях количество поллингов за бит как правило снижается вплоть до 4. Кто сказал, что помеха не в состоянии 4 раза за бит случиться? Я на это никак не могу не рассчитывать...

[juvf]

Мне бы Вашу непоколебимую уверенность!
Попробуйте поработать с силовой преобразовательной техникой...

Работал..... обвязывали 485-ым трансформаторные подстанции, распределительные подстанции, дизельные генераторы... а также на объектах с высоким ВЧ излучением.

ps была проблема однажды.... сильное ВЧ излучение.... и оно лезло везде.... решили проблему полной опторазвязкой RS485 мастера и слейва. Но ни каких продувок не делали.

линия висит либо в воздухе, либо растянута слабенькими резисторами

в воздухе нельзя её вешать.... а резисторы... растяните не слабенькими... 5 кОм... или 2.4 кОм.

Кто сказал, что помеха не в состоянии 4 раза за бит случиться? Я на это никак не могу не рассчитывать...

А реально были такие случаи? если предположить, что брошенная линия постоянно "шумит".... то получается все слейвы на линии постоянно получают мусор по уарту... т.е. постоянно срабатывает прерывание поприему, обработчик байт кудато помещает, запускает таймер на 3.5 символа (а некоторые ещё и црц налету считают).... это же сколько работы процессору - постоянно шум анализировать... а если уартов 4? Не должно быть шумов и всякого мусора в 485. если есть - нужно над линией работать.

[demiurg_spb]

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

Полная опторазвязка - это оптоволокно?

Я никогда не делаю не изолированные RS485 выходы у приборов.
Спасибо!
Ваше мнение я услышал.

[juvf]

Полная опторазвязка - это оптоволокно?

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

[zltigo]

Я обычно формирую требуемую паузу на шине с включенным передатчиком до и после передачи пакта.

Увы, для 485 пауза есть неизбежное зло.
Величина паузы зависит от способа выделения фрейма и при MODBUS самый плохой вариант c точки зрения величины пауз -
1,5 байта в начале и 3,5 байта в конце.
При байтстафинговом фреймере - 1 байт в начале, а в конце не нужно.

У меня есть сомнения, что если этого не делать можно наступить на грабли. Поясню.

Ваши сомения несостоятельны.

Давайте порассуждаем над этим увлекательным занятием - реализацией идеального MODBUS-RTU MASTER/SLAVE!

Из дерьма конфетку не сделаешь, а как максимально соблюсти - написано выше.

[demiurg_spb]

Понятно, что изолированный - это гальванически не связанный и никаких общих земель.
Кстати, про загрузку процессора - если фильтровать по адресу слейва и коду функции то CRC считать для мусора и "не твоих запросов" фактически и не придётся.

[zltigo]

Не нужно ни чего продувать. когда нет драйвера на линии там лог "1". Линяя RS485 должна быть подтянута (А к +V, B k GND).

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

Если кто боиться, что в лини без драйвера есть шум... или может возникнуть шум.... нет там шумов. Подтяжка делает сво дело. На длинной линии можно словить наводку, электромагнитную помеху.... НО.... в рс485 длинная линия тянеться витой парой.... наведенный импульс в А+ таже будет и в B-, в итоге разность A и B сохраниться как без помехи.

Помеха в длинной линии есть уже и без всяких наведенных - просто колебательный процесс при включении и выключении передатчика.
Вот такой сюрприз для любителей растяжек НИКОГДА не работавших с длинными реальными линиями. Это раз. А два, это то, что подавление синфазных далеко не 100% и нормируется только в достаточно узком диапазоне синфазных, а синфазные помехи в десятки и сотни вольт, это тоже реальность длинных линий.
Никакие опторазвязки от помех на 100% не спасают, ибо любая развязка имеет паразитную емкость, через которую прекрасно пролезают импульсы с высокой энергией. Гальваническая развязка это прежде всего защита от выхода из стоя, защита от помех с пологими фронтами, но не защита от любых помех вообще.

[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.

[demiurg_spb]

Увы, для 485 пауза есть неизбежное зло.
Величина паузы зависит от способа выделения фрейма и при MODBUS самый плохой вариант c точки зрения величины пауз -
1,5 байта в начале и 3,5 байта в конце.

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

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

Да именно тишины, а как вы её должны добиться в стандарте ИМХО не сказано. Единственно возможный способ гарантированно этого добиться - включить шину в активное состояние.
А что касается настоящих usb преобразователей в MODBUS-RTU то такие, я думаю есть в природе и в них наверняка стоит контроллер.

Кстати про FAILSAFE - большая их часть нифига не FAILSAFE (т.е. без смещённого порога).
Поскольку последнее время разрабатываем девайсы на отечественной элементной базе могу сказать, что у Миландра правильные RS485 драйверы.

[juvf]

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

не единственный. Я уже писал выше про растяжки.

Кстати, про загрузку процессора - если фильтровать по адресу слейва и коду функции то CRC считать для мусора и "не твоих запросов" фактически и не придётся.

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

1)пришел байт мусора
2)посчитал црц для 1 байта (табличным способом)
3)goto 1
сработал таймер 3,5, если црц == 0, то пакет годный, смотрим адрес.

в таком алгоритме придётся для мусора считать црц.... если не считать црц, а фильтровать по адресу...
1)пришел байт мусора
2)проверили адрес
3)goto 1

где профит? 2-ой шаг - или фильтрация, или подсчет црц всеравно тратить время, все равно вход в прерывание, выход из прерывания....

[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.

[demiurg_spb]

не единственный. Я уже писал выше про растяжки.

Спорить с вами бесполезно.
Вы зациклились на своём решении и не видите его недостатков.
Поверьте что никогда не поздно учиться.
Если не доверяете мне с непрерывным опытом разработки КИПиА и интеграции чуть более 16 лет - я не в обиде.
Но не прислушиваться к корифеям типа zltigo по меньшей мере самонадеянно.

[zltigo]

не единственный. Я уже писал выше про растяжки.

Гарантированный - единственный. Он же, в отличие от растяжек, работающий ВСЕГДА, а не только на короткой линии и при низком уровне помех.

Проверять адрес без принятия всего пакета не совсем правильно....

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

1)пришел байт мусора
2)посчитал црц для 1 байта (табличным способом)
3)goto 1
сработал таймер 3,5, если црц == 0, то пакет годный, смотрим адрес.

Таймер 1,5 как видно из этого супер алгоритма, Вам оказался не по уму

[juvf]

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

К словам цепляетесь... перефразирую вопрос: Как ВЫ делаете активную паузу, если мастер ПК?

Спорить с вами бесполезно.
Вы зациклились на своём решении и не видите его недостатков.
Поверьте что никогда не поздно учиться.

я не пытаюсь вам доказать свою правду.... я хочу учиться... у меня тоже не малый опыт... (с 2000 года, теже 16+, наверно мы ровесники ))) )
Я просто первый раз слышу об активных паузах. всегда линия 485го растягивалась. без растяжек даже на столе могло не работать. я не работал на линиях 1000 метров.... может вы и корифей типа zltigo речь ведёте о 2-3 км.... или десятки км.... тут я пасс.
Но если это до 500м.... тут у меня есть опыт теже, 16 лет.... и растяжки работают на ура. приимущества: 1. не надо заморачиваться с активными паузами, 2 не надо переваривать мусор из-за его отсутствия (а что его нет... на практике проверенно, а не теоретические выводы).

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

ps, да, кстате.... 2demiurg_spb У вас не было задачи с десктопного ПК под виндой или линуксом по MODBUS-у работать? Или промышленная ЭВМ должна быть мастером в MODBUS-е? Как вы добиваетесь в таких случаях активной паузы? (опять же, я не хочу вам навязывать своё решение. я своё мнение высказал, вам решать. я хочу узнать как вы технически решаете подобные задачи? Ну чтоб научиться... ведь ни когда не позно )

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

я считаю пакет с битым црц. поэтому мне не пофиг.

Таймер 1,5 как видно из этого супер алгоритма

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

[zltigo]

К словам цепляетесь... перефразирую вопрос: Как ВЫ делаете активную паузу, если мастер ПК?

Если под ПК Вы очевидно понимаете Windows/Linuх и иже с ними, то ни мастеров ни слейвов MODBUS под такой "ПК" не бывает. Вот такая печальная правда. Под голый ПК, ака DOS - без проблем. Так же без проблем не уродливый MODBUS-RTU, а протоколы, например, на байтстаффинге. В этом случае достаточно 9-10 битовой паузы для захвата байтовой синхронизации и для этого годится посылка 0xFF.
То, что пытаются делать на "ПК" без аппаратной поддержки, это что-то похожее на MODBUS и только в некоторых условиях и с не всяким оборудованием работоспособное. Да, типичный способ ЗАСТАВИТЬ хоть в каких-то условиях работать - прицепить растяжки. Цену такого "решения", если не понимаете, поймете решив задачку в конце поста.
Соответственно при работе с "ПК" я использую свои конверторы протоколов на Ethernet.
Они отрабатывают все паузы и протокольные таймауты, включая таймауты неответа слейвов.

Но если это до 500м.... тут у меня есть опыт теже, 16 лет.... и растяжки работают на ура.

Займемся арифметикой.
Имеем витую пару 100 Ом волнового и соответственно 100 омный терминатор.
Вопрос первый, какое сопротивление должны иметь волшебные растяжки, дабы обеспечить гарантированную паузу, ну, например, при 3.3V питании и стандартных 200mV порогах срабатывания приемника?

[Ruslan1]

когда нет драйвера на линии там лог "1". Линяя RS485 должна быть подтянута (А к +V, B k GND).
...
Забудьте про всякие продувки..... слейв как только принял пакет и обработал без всяких пауз и продувок может отвечать.

Вы не правы. Никто не должен там ничего никому держать.
Пример хорошего протокола для RS485- тот же Модбас: пауза в Модбасе РТУ не просто так сделана в начале пакета, и тайминг там не просто так был придуман.
Случаи- они разные бывают.

[demiurg_spb]

2juvf:
Я стараюсь на комп не заводить MODBUS-RTU - он используется в основном для связи модулей расширения с ПЛК.
Если и завожу по необходимости, то никак не формирую активное состояние в паузе - и говорю клиенту, что так, мол, и так, работать как-то будет...
Если хотите чтобы было совсем хорошо надо раскошелится. Многие не хотят...

А сейчас парсер реализован так (сначала проверка адреса, а уже потом CRC):

CODE

static void modbus_serial_pdu_parser(modbus_handle_t* mb)
{
modbus_buffer_goto_idx(mb, 0);

mb->pdu.current.len = rs485_get_rx_qty(mb->rs);
mb->pdu.current.address = modbus_buffer_get_byte(mb); // address = buffer[0]
mb->pdu.current.function = modbus_buffer_get_byte(mb); // function = buffer[1]

dbg_printf("qlen:%d\taddress:%d\n", (int)mb->pdu.current.len, (int)mb->pdu.current.address);

if ( (mb->pdu.current.address==MB_BROADCAST_ADDRESS)
|| (mb->pdu.current.address==mb->pdu.wanted.address) )
{
if (modbus_buffer_check_crc(mb))
{
if (modbus_serial_is_master(mb))
modbus_serial_stop(mb),
modbus_master_ack_parser(mb);
else
modbus_slave_function_parser(mb);
}
else
{
dbg_printf("bad_crc\n");

#if MB_SLAVE_STATISTICS_ENABLE
mb->stat.comm_errors++;
#endif

modbus_serial_default_state(mb); // idle or stop
}
}
else
modbus_serial_default_state(mb); // idle or stop

#if MB_SLAVE_STATISTICS_ENABLE
mb->stat.total_messages++;
#endif
}

[juvf]

Под голый ПК, ака DOS - без проблем.

Поделитесь опытом.

Цену такого "решения", если не понимаете, поймете решив задачку в конце поста.

И какова? На практике это работает. Об этом пишут в даташитах. Погуглил инет на эту тему - кругом рекомендации про растяжки.

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

какую паузу? растяжки не обеспечат вам гарантированной паузы. растяжки обеспечат вам тишину в линии без дайвера (ну или шум сведут к минимуму).

и говорю клиенту, что так, мол, и так, работать как-то будет...

А мы делаем. И работает, не хоть как-то, а работает.

Пример хорошего протокола для RS485- тот же Модбас: пауза в Модбасе РТУ не просто так сделана в начале пакета

нет там пауз в НАЧАЛЕ пакета. там пакеты разделены 3.5 символьными паузами тишины. Чтоб тишину обеспечить, достаточно всем помолчать. А если в линии шум... так нужно бороться с шумом. У нас в линиях нет шума. Зачем туда что-то дуть активно?


ps Я могу усомниться в своих знаниях (а я и усомнился... и погуглил... да нет... ставят растяжки), я могу не знать как в ДОС врубить активную паузу, я могу встать осцыолом на линию и посмотреть там шумы... и если их сейчас нет, не значит что их вообще нет.... Я могу во что-то поверить, например в ЛММ. Но верить в то, что растяжки не обеспечат тишину - не получается. У меня на каждом устройстве, и на слейве и на мастере стоит счетчик битых пакетов. если пройдет шум.... и хоть какой-то уарт примет хотя бы 1 байт ложный в тишины - счетчик битых пакетов увеличиться. если ложный байт будет перед нормальным пакетом или сразу после него - счетчик битых пакетов увеличиться. По этим счетчикам можно судить о шумах на линии... и вообще о работе всего модбаса на линии. годами в режиме 7/24 работают устройства... и эти счетчики единично инкриминируются. Т.е. эти "сопливые" растяжки не такие уж и сопливые. Тишину в линии они обеспечивают. А что ещё от них нужно? Зато нет гемора с активными паузами.

[zltigo]

Поделитесь опытом.

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

Т.е. эти "сопливые" растяжки не такие уж и сопливые.

Если не сопливые, то тогда это вызывает проблему с дальностью работы в полный рост.

годами в режиме 7/24 работают устройства...

Забыли добавить "у меня". Типичное радиолюбительство описывается одной фразой - "ничего не знаю у меня все работает"

[Ruslan1]

juvf , Вы хотели что-то спросить, или просто еще раз подтвердить самому себе верность своего курса?
Вы очень уверены в том что делаете, в чем тогда вообще смысл дискуссии, что Вы ждете от оппонентов?

Ваш путь ошибочен. Лично Вам он годится, только и всего.

Как говорил один классик "Езжайте! Да, когда свернете налево, ну вы-то направо, там проезд запрещен, обрыв. Но вам туда можно."

[net]

поддержу
особенно про стаффинг

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

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

[dm37]

немного в поддержу juvf
Если вы работаете по протоколу modbus по RS485, будьте добры придерживаться стандартов (использовать подтяжку A и В), в противном случае оборудование сторонних разработчиков ваши изыски по RS485 не поймёт.
Если вы разработчик всей системы (и мастера и слейва), то зачем вы вообще используете modbus. Вы нашли способ, используя драйверы RS485 с True Fail-Safe, повысить надёжность передачи данных на большие расстояния - это замечательно, но не надо навязывать своё решение всем, тем более грубить. Напишите статью на эту тему и поделитесь своими наработками.

Например здесь
http://www.analog.com/media/en/technical-d...otes/AN-960.pdf
на стр. 7 есть описание RS485 с True Fail-Safe, где сказано, что используя новые драйверы отпадает необходимость использовать подтяжку А и В, значит ранее такая необходимость была?
На стр. 6 приводится расчёт резисторов подтяжки.

Сообщение отредактировал dm37 - Sep 25 2016, 18:58

[AHTOXA]

Добавлю сюда пару ссылок на предыдущие обсуждения проблем помехозащищённости RS-485:

• Помехозащищенный RS-485
• как стартует UART?

Краткие выводы:

• Растяжки спасают далеко не всегда;
• Для гарантированного приёма начала пакета нужно либо подержать линию в активном состоянии перед началом пакета, либо передать "прочищающий символ" (это для протоколов с фиксированным символом начала пакета);
• В качестве "прочищающего символа" хорошо подходит 0xFF.

[net]

немного в поддержу juvf
Если вы работаете по протоколу modbus по RS485, будьте добры придерживаться стандартов (использовать подтяжку A и В), в противном случае оборудование сторонних разработчиков ваши изыски по RS485 не поймёт.

это мы сейчас по кругу пойдем - хотя круги уже нарезаны

в чем я с Вами согласен - что манеру zltigo желательно изменить
надо разъяснять проблемы и показывать их решение - а не гордо фыркать - типа это очевидно

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

будьте мягче и добрее и всем будет веселее и лучше

[zltigo]

немного в поддержу juvf
Если вы работаете по протоколу modbus по RS485, будьте добры придерживаться стандартов (использовать подтяжку A и В)

"Стандарт" на MODBUS в котором про подтяжку на бочку

в чем я с Вами согласен - что манеру zltigo желательно изменить
надо разъяснять проблемы и показывать их решение - а не гордо фыркать - типа это очевидно

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

[net]

нет чтобы написать - папа вышли денег
написал ПАПА вЫшли денег


попробуйте сосчитать до 10 - я понимаю что бесит- тогда попробутй до 1000

[juvf]

Понимание начинается с арифметики. Арифметическую задачку простейшую я сформулировал. После решнения ее будет понята и проблема вносимая растяжками.

я уже ответил. растяжки не обеспечивают гарантированную паузу. чо тут решать? очень интересно, чем вам растяжки в MODBUS не нравяться? вам нужна цифра? Для ваших условий согласно APPLICATION NOTE от AD 775 Ом.

[zltigo]

попробуйте сосчитать до 10 - я понимаю что бесит- тогда попробутй до 1000

Меня может бесить, когда я обязан кому-либо что либо втолковывать. Здесь я никому ничего не обязан. Толчек дал. Теперь пусть думает, какие НЕХИЛЫЕ отрицательные последствия от такой низкоомной растяжки, которая в тому-же, как у него зародилсь наконец-то умная мысль "растяжки не обеспечивают гарантированную паузу", то есть паузы по любому придется обеспечивать. Осталось сделать последний шаг, что, если паузы придется по любому обеспечивать управляющему контроллеру, то можно в это время и передатчик активным подержать, что будет будет много эффективнее для подавления помех и обеспечения читстой паузы, нежели растяжеки, и послать растяжки лесом.
Punkts un āmen.

[net]

ктож спорит то?
все дело в том - что зачастую даже когда приводят 2+2=4 нужно не только увидеть - но и прочувствовать
а это не всем дано бывает, и бывает очень долго приходится с этим свыкаться
особенно когда типа ты был молодцом ;-)
а тут вдруг раз и валенком по голове

терпимее надо быть - это я и себе говорю тоже ;-)

[juvf]

у него зародилсь наконец-то умная мысль "растяжки не обеспечивают гарантированную паузу", то есть паузы по любому придется обеспечивать. Осталось сделать последний шаг, что, если паузы придется по любому обеспечивать управляющему контроллеру, то можно в это время и передатчик активным подержать, что будет будет много эффективнее для подавления помех и обеспечения читстой паузы, нежели растяжеки, и послать растяжки лесом.
Punkts un āmen.

пф..... троль!!! ))))) Я вам дал ответ на вашу "задачку" за обещание показать бога надеясь услышать хоть один вразумительный довод. и? ....

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

Нет я так не думаю. Для тех, кто в танке

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

[dm37]

"Стандарт" на MODBUS в котором про подтяжку на бочку

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

Речь шла о том, что большинство поставщиков оборудования с RS485 используют подтяжки. И если вы доработаете схему блока до вашего варианта, не факт, что он вообще работать будет и кому вы тогда будете предъявлять претензии - MOXA, Advantech? А заказчик требует что-бы работало. И ваши доводы, по поводу кривых рук разработчиков из MOXA, ему будут не интересны. Скорее всего он сделает "не правильные" выводы.

P.S. Кстати, разработчики из MOXA ещё те ребята, любят совмещать выходные линии RS485 и RS232. При такой схеме включения частенько вылетает драйвер RS232 и соответственно RS485 перестаёт работать. Приходиться резать дорожки или выбрасывать драйвер RS232.

Сообщение отредактировал dm37 - Sep 26 2016, 13:12

[zltigo]

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

Вооще-то это Вы понесли ахинею. Цитирую:

Если вы работаете по протоколу modbus по RS485, будьте добры придерживаться стандартов (использовать подтяжку A и В)

Так что это я могу поздравляю Вас с "погорячился". Зато теперь Вы узнали, что никаких "стандартов" на подтяжки нет, не было и не будет ни в интерфейсах, ни в протоколах, нигде.

Речь шла о том, что большинство поставщиков оборудования с RS485 используют подтяжки.

Из этого совершенно не следует, что надо пополнять ряды рукожопых.

И если вы доработаете схему блока до вашего варианта, не факт, что он вообще работать будет и кому вы тогда будете предъявлять претензии - MOXA, Advantech? А заказчик требует что-бы работало. И ваши доводы, по поводу кривых рук разработчиков из MOXA, ему будут не интересны. Скорее всего он сделает "не правильные" выводы.

У MOXА растяжки опциональные. Им приходится с рукожопыми работать. Впрочем, как и мне. Так что и у меня, как уже писал, в оборудовании предназначенном для подключения чужих, потенциально рукожопных устройств, опциональные растяжки есть. Для своего оборудования нет, не было и не будет по причине нахренненужности и более того - вредности, ибо мне часто нужны дальности сегментов на уровне километров.
Есть еще один случай, когда таже MOXA вынуждена ставить растяжки, это вырожденный случай, например, конвертора произвольных байтовых потоков в Ethernet. В таком случае, когда правила фреймирования протокола и отсева мусора неизвестны любая помеха это смерть и ее приходится давить любой ценой.

пф..... троль!!! ))))) Я вам дал ответ на вашу "задачку" за обещание показать бога надеясь услышать хоть один вразумительный довод. и? ....

Следующий шаг здесь:
http://electronix.ru/forum/index.php?showt...t&p=1451820
Впрочем, про катострофическую потерю дальности я писал не раз. Посчитайте, что остается от чувствительности затерминированного приемника на дальнем конце линии при такой растяжке. Если сможете, то дальше нарисуйте с любимыми растяжками многоточку штук на 16, например, на километр AVG24 и подумайте как же оно сможет работать-то.


Еще раз, последний - мне эта тема про рукожопство надоела. Больше ответов не будет.

[dm37]

to zltigo для информации

во вложении со страницы 22 и дальше...
отвечать вам не буду - бесполезно. Что хотел сказать, сказал выше. Каждый остаётся при своём мнении. Обсуждения не получается.

И вопрос к модераторам: хамство здесь разрешено?

Прикрепленные файлы

 Modbus_over_serial_line_V1_02.pdf ( 318.76 килобайт ) Кол-во скачиваний: 36

 

[AHTOXA]

во вложении со страницы 22 и дальше...

Там как раз сказано, что растяжки не обязательны. Вернее, что их надо ставить в том и только том случае, если устройства в сети декларируют их необходимость:

Each MODBUS device must be documented to say :
- if the device needs a line polarization,
- if the device implements, or can implement, such a line polarization.
If one or several devices need polarization, one pair of resistors must be connected on the RS-485 balanced pair :
- a Pull-Up Resistor to a 5V Voltage on D1 circuit,
- a Pull-Down Resistor to the common circuit on D0 circuit.
The value of those resistors must be between 450 Ohms and 650 Ohms. 650 Ohms resistors value may allow a higher number of
devices on the serial line bus.

К тому же это уменьшает допустимое число устройств в сети на 4:

The maximum number of devices authorized on such a MODBUS Serial Line is reduced by 4 from a MODBUS without polarization.

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

[juvf]

срезюмирую....

Как человек почти вся жизнь занимающийся всевозможными связными потоколами могу точно сказать, что Modbus RTU есть натуральное дерьмо.

после этого вообще можно было с этим человеком о Modbus-е ни о чем не говорить. Ну и далее гвоздь в дискуссию

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

no comments

juvf , Вы хотели что-то спросить, или просто еще раз подтвердить самому себе верность своего курса?

Во всех рекомендациях, которые я встречал говориться о защитном смещении. Нигде я не встречал про активную продувку. Нет, конечно я про такое слышал.... но не в рамках 485-го и модбаса, а вообще, в теории помехозащищенности линии. Но чтоб в модбасе что-то активно дули!? Может я не правильно готовлю модбас? решил это выяснить. А тут в ответ только вера в что-то святое и хамство. Конкретно, многоуважаемый zltigo заявляет, что под голый ПК, ака DOS - без проблем делает активную паузу. Например это хотел спросить. В ответ получил какую-то задачку…. И ответ “реши и поймёшь как”. Решил. И что? С неба спустилась миссия и открыла мне путь истинный как на десктопном ПК под DOS делать активную паузу?

Цену такого "решения", если не понимаете, поймете решив задачку в конце поста.

И решил…. Каково цена? Только тролить и языком молоть умеет.


Очень умиляют высказывания единомышленников

Пример хорошего протокола для RS485- тот же Модбас

vs

Modbus RTU есть натуральное дерьмо.

)))


Далее…

Ваш путь ошибочен. Лично Вам он годится, только и всего.

Возможно…. Только вот те системы с которыми мы стыкуемся… работают… но это всё равно МОЙ путь…. я понял, тут только болтуны толком ни чего не подскажут…. Только нахамят и потролят, как обычно. Ищем литературу, справочники, статьи на эту тему… кто как делает? кто каким путём ходит? Может кто короткую тропинку мне покажет?
Что находим .... пруф раз, пруф два, три, четыре…, а также five, six, семь, восемь .... Много их… и ненавистные вики, и в даташитах на драйвера и от производителей. вот конкретно

При прекращении передачи данных в сети, состоящих из множества передатчиков, подключенных к одному каналу связи, линейные драйверы переходят в «третье состояние» (т.е. отключенное состояние). В результате линейные приемники, прослушивая сеть, могут регистрировать ложные данные.
Для разрешения указанной проблемы разработчиком в приемопередающих узлах RS-485, должны быть предприняты специальные меры. Приемопередатчики узлов RS-485 должны быть оснащены цепями смещения выхода формирователя. По такому принципу построены приемопередатчики RS-485 всех приборов предприятия МИКРОЛ.

пруф Значит мой путь не ошибочный и он подходит не только мне!
Вот ещё интересный девайс… ICP DAS очевидно тоже ставит и/или предлагает ставить растяжки, по необходимости.
Но наш мистер джедай умеет направлять Силу, что даёт ему некоторые сверхъестественные способности zltigo предлагает всех, кто делает помехозащищенное смещение, кастрировать. Он от всех отличается. Может ему когда-то оторвали гениталии и он не хочет от других отличаться?


Теперь по делу…. Что могу ещё добавить…. Поделившись опытом… а не ради того, чтоб кого-то унизить или холиварить….
2demiurg_spb, я видел подобные парссеры. ..... выскажу мнение: мне не нравиться подобные парссеры. Почему.
1)Есть пакет. целостность пакета обеспечивается контрольной суммой и паузами тишины. я сначала выделяю весь пакет из потока, проверяю его целостность и только потом начинаю обрабатывать данные этого пакета. Ну я как-то изначально…. В любом протоколе сначала проверяю целостность пакета, а потом обрабатываю внутренность пакета. Вы адрес и функцию обрабатываете не проверив целостность пакета. может в поле адрес ошибка, или в поле функция.... конечно в конечном счете црц покажет, что пакет был битый....
но.... вот у вас отправили пакет 2-му устройству, один бит ложный. Слейвы получили адрес 6
и тогда 2-ой девайс НЕ отметит битый пакет, а 6-ой девайс отметит, что пакет был ему адресован, но црц плохой и 6-ой сделает mb->stat.comm_errors++;. хотя на самом деле пакет был адресован 2-му. Если црц не совпал, то ни кто не знает, кому на самом деле пакет был адресован.
2) Вы не сможете оценить зашумлённость линии. Ну если конечно это вам надо. Я всегда это делаю. Даже один ложный байт в тишине увеличит счетчик ошибок во всех слевах.

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

Возможно это нашему маниакальному хирургу кому-то подходит, но это не вписывается в стандарт MODBUS. Ибо в стандарте есть функция 8 -Diagnostics (Serial Line only) . подфункция 12
The response data field returns the quantity of CRC errors encountered by the remote device since its last restart, clear counters operation, or power–up. Т.е. не нужно игнорировать чужой пакет с битым црц.

Что касается растяжек…. Все эти расчеты …. Сложные… они должны учитывать кол-во слейвов, длину кабеля, активное сопротивление/емкость/индуктивность…. Драйвера слейвов (у одних сопротивление 12 кОм, у других 24 кОм…) одни растяжки ставят в начале линии, другие на каждом слейве (например, если растяжки есть внутри драйвера)… терминатор может быть, может не быть, их может быть два….
Согласно апликэшен ноут от аналог девайс на 100 омную линию с 2 терминаторами нужно 775 Ом. Это конечно круто. По другим рекомендованным расчетам получалось около 560 Ом…. На практике мы ставим от 2.4 кОм…. Меньше не ставили. И реально эти растяжки на линии подбирали опытным путём. Также предлагают подберать опытным путём растяжки и терминаторы ICP DAS, причем растяжки только 1 кОм, 10кОм и даже 100кОм

2demiurg_spb я уже говорил, что имею опыт на линиях до 500 м. У вас линии длиннее? Интересно посмотреть на байт 0x55 в линии с растяжками и без. Какие фронты? Как это повлияет на скорость? zltigo не уподобился ответить на вопрос о длине линии…. Но потом проговорился, что ему интересны километры. Однако RS-485 вроде как до 1200 метров. Выше – это уже какой-то овердрайв и использовать там общепринятые решения наверно не целесообразно.

есть такое... но в модбас такое не прокатит... если только в 4 раза скорость понизить, вдунуть 0хфф, потом поднять скорость и слать пакет.

извиняюсь перед ТС за офтоп.

[net]

есть такое... но в модбас такое не прокатит... если только в 4 раза скорость понизить, вдунуть 0хфф, потом поднять скорость и слать пакет.

извиняюсь перед ТС за офтоп.

очень много букв
но вы даже не удосужились прочитать о чем пишет Антоха !!
он же написал о стаффинг протоколах !!! а вы это приписываете, что для модбас не прокатит
естественно потому что это для другого случая он написал !!!
что вобщемто и подтвеждает мысль, что с модбас не все нормально


более того например BSC известен ( применен метод байт стаффинга) с 68 года прошлого века и каким образом вылез модбас со своей временной паузой для синхронизации которые с трудом можно реализовать - не дай бог еще и скорость поднять то вообще труба будет, монотонность потока

и дурацкими растяжками гробящие сигнал и ничего не дающие не очень понятно

[dm37]

to АНТОХА

Там как раз сказано, что растяжки не обязательны. Вернее, что их надо ставить в том и только том случае, если устройства в сети декларируют их необходимость:

дак никто же этого не отрицает

Уверен, что почти каждый будет проверять работу RS485 без растяжек с True Fail-Safe. Правда, если это потребует переделку софта, то не везде это применишь (совместимости не будет).

P.S. Просто, если человек спрашивает, то нужно объяснять (пусть даже 2+2=4), для этого и существует форум. В своё время был очень хороший форум на telesys.ru, правда потом он стал полем разборок "профессионалов". Начинающих просто "забивали". Не хотелось бы здесь увидеть подобную манеру общения.

[demiurg_spb]

2demiurg_spb, я видел подобные парссеры. ..... выскажу мнение: мне не нравиться подобные парссеры. Почему.

Ваше объяснение логично, понятно и более того соответствует описанию счётчиков в документе modbus_over_serial_line.
Но лично мне совершенно не хочется напрягать контроллер расчётами CRC всего сетевого трафика...

Что касается длинны линии, то сталкивался с разными задачами вплоть до километра.
Сейчас под рукой таких линий нет - картинку снять не могу.

А линию продуваю действительно так, как вы предположили. Поясню на примере STM32.
Отключаю функцию UART на ноге ТХ (перевожу в GPIO) и отправляю один байт на заранее рассчитанной скорости чтобы получилась пауза 3,5T (при этом нога TX вообще не дёргается).
Потом в прерывании TXC перевожу ногу обратно в режим UART-TX, меняю на правильный бодрейт и отправляю пакет, потом снова продуваю прежним способом.
Т.е. у меня в драйвере UART есть возможность включить пакетный режим с суффиксом и префиксом активного состояния.
Прерывания от таймера вообще не использую.

[net]

А линию продуваю действительно так, как вы предположили. Поясню на примере STM32.

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

[_Pasha]

Прерывания от таймера вообще не использую.

Кста, хороший метод. Вещь в себе. Спасибо за мысль. Раньше делал по таймеру

[zltigo]

Кста, хороший метод.

1) Абсолютно бесполезный, ибо на приеме таймауты 1,5 и 3,5 по любому придется иметь, так зачем еще плодить лишние сущности.
2) На многих чипах нереализуемый, ибо прерывания окончания передачи просто нет, а есть только освобождение буферного регистра.
3) Ошибочный, поскольку в начале модбасовского фрейма 3,5 пауза избыточна и только снижает темп обмена.

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

В том, что Ваше утверждение "будет принят битый пакет" ошибочное. Это из мусора будет сформирован битый пакет, а передаваемый пакет пойдет очищенным от мусора.

[_Pasha]

1) Абсолютно бесполезный, ибо на приеме таймауты 1,5 и 3,5 по любому придется иметь, так зачем еще плодить лишние сущности.
2) На многих чипах нереализуемый, ибо прерывания окончания передачи просто нет, а есть только освобождение буферного регистра.
3) Ошибочный, поскольку в начале модбасовского фрейма 3,5 пауза избыточна и только снижает темп обмена.

1. Нет. Речь шла о продувке физ. канала. Совершенно закономерно, что мысль дошла до того, чтобы сделать продувку равную Т35 или Т15, но делать ее по максимуму, ессно, необязательно.
2. Нет! "на многих чипах" -это х51?
3. Да )) но не совсем. при Т15 остальной парк девайсов примет все что идет вплоть до Т35. Т.е. после продувки Т15 можно запросто потерять пакет. А после Т35 - нет.
Так что все правильно оказывается.

Сообщение отредактировал _Pasha - Sep 28 2016, 06:58

[net]

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

В том, что Ваше утверждение "будет принят битый пакет" ошибочное. Это из мусора будет сформирован битый пакет, а передаваемый пакет пойдет очищенным от мусора.

2) легко реализуемо путем пердачи лишнего байта - и как только лишний байт уйдет из регистра значит передача нужного байта выполнена

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

а тут важна совокупность того о чем мы говорим - типа синегирия в полном виде ;-)

и уж если придераться к словам - из мусора будет сформирован битый пакет - он что не будет никем принят? хотя тут опять возникает вопрос что значит ПРИНЯТЬ быитый пакет ;-)

[_Pasha]

да модбас RTU, что там оговаривать

[net]

да модбас RTU, что там оговаривать

вот нефига я его не понимаю - поэтому обсуждать его не могу ;-)

[juvf]

Там как раз сказано, что растяжки не обязательны. Вернее, что их надо ставить в том и только том случае, если устройства в сети декларируют их необходимость:

ну тут немного не так....

When there is no data activity on an RS-485 balanced pair, the lines are not driven and, thus susceptible to external noise or
interference. To insure that its receiver stays in a constant state, when no data signal is present, some devices need to bias
the network.
Each MODBUS device must
be documented to say :
-if the device needs a line polarization,
-if the device implements, or can implement, such a line polarization.

смысл такой, что когда линяя без драйвера, то она чувствительна к внешним шумам. Чтобы быть уверенным, что с выхода приемника не сыпет мусор (дословно "приемник в постоянном состоянии") когда нет активного сигнала, некоторым устройствам нужно защитное смещение.
В описании каждого устройства должно быть сказано:
-Нуждается ли в защитном смещении (например, если использовать драйвера True Fail-Safe, то защитное смещение устройству не нужно)
-Если устройстве реализует или может реализовать защитное смещение линии

т.е. протокол подразумевает тишину на приемниках, когда нет передачи.

[AHTOXA]

ну тут немного не так....
...
т.е. протокол подразумевает тишину на приемниках, когда нет передачи.

Нет. Протокол не подразумевает. В стандартах никогда ничего не подразумевается, там всегда всё формулируется чётко. Если написано,

Each MODBUS device must be documented to say :
- if the device needs a line polarization,
- if the device implements, or can implement, such a line polarization.

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

If one or several devices need polarization, one pair of resistors must be connected on the RS-485 balanced pair

То это означает, что если (и только если) одно или несколько устройств нуждается в растяжках (декларирует это в документации), то надо сделать растяжки.
А фраза

When there is no data activity on an RS-485 balanced pair, the lines are not driven and, thus susceptible to external noise or
interference. To insure that its receiver stays in a constant state, when no data signal is present, some devices need to bias
the network.

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

Никакой тишины линии не подразумевается.

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

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

[net]

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

а если банально сменить протокол modbus RTU на протокол использующий byte stuff - то все обсуждаемые проблеммы данного топика
просто исчезнут сами собой - включая начальную тему про сниффер ;-)

[_Pasha]

а если банально сменить протокол modbus RTU на протокол использующий byte stuff - то все обсуждаемые проблеммы данного топика
просто исчезнут сами собой - включая начальную тему про сниффер ;-)

как Вы себе это представляете для случая, когда прибору требуется модбас как стд интерфейс?

[net]

как Вы себе это представляете для случая, когда прибору требуется модбас как стд интерфейс?

я представляю это себе так
1 сначало люди придумали проблему
2 а потом извращаются чтобы ее решить

ТС предложили поставить МК на котором перевести идиотский модбас в нормальный поток RS232 (для примера - а то сейчас опять налетите USB CAN и тд и тп)

либо со штампами времени
либо ... не буду дальше

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

более того он использует переходник USB-RS232 это и есть фактически такое устройство которое ему и прделагали сделать самому
только с его функционалом

[demiurg_spb]

а если банально сменить протокол modbus RTU

Не всё так просто. В АСУТП и КИП на базе интерфейса RS485 протокол Modbus-RTU является стандартом де-факто. И считается, что помимо любых других он должен быть обязательно.
Реже используется Modbus-ASCII и DCON. Остальные протоколы вообще крайне редки. В Росии тот-же ОВЕН долгое время продвигал свой собственный, весьма не плохой протокол, ну а в последнее время сдался и тоже реализовал во всех своих изделия Modbus-RTU.

[net]

Не всё так просто. В АСУТП и КИП на базе интерфейса RS485 протокол Modbus-RTU является стандартом де-факто. И считается, что помимо любых других он должен быть обязательно.
Реже используется Modbus-ASCII и DCON. Остальные протоколы вообще крайне редки. В Росии тот-же ОВЕН долгое время продвигал свой собственный, весьма не плохой протокол, ну а в последнее время сдался и тоже реализовал во всех своих изделия Modbus-RTU.

конечно не просто - мы же всегда любим делать все через одно место
сделать(принять как вы написали дефакто) стандарт который очень неудобный и потом им пользоваться - хотя между BSC(1968 год) и MODBUS-RTU (2006) пропасть времени

сделать растяжки гробящие шину
проДУВАТь канал (хотя хоть какойто смысл есть)
использовать приемо передатчики без сдвига - хотя даже отечественные драйвера все уже правильные - где вы только неправильные достаете ;-)
сначала угробить промышленность - а потом запеть про импорто замещению
когда уже все угроблено- начать делать страховые запасы
зашибись дефакто

правда потом начинаем покупать все иностранное и при этом качать права чтобы все соответсвовало нашим стандартам

типа а какого хрена у вас мерседес с винтиками не по госту?

или почему печатная плата в дюймах? помните проблему псведо дюймов? - которые 2.5 вместо 2.54?
вот этот дефакто из этой же серии

и еще раз ТС дали четкий ответ - хочешь снифер = делай(тем более они делают свои железки как я понял) МК приблуду. под WIN по честному не получится
что еще обсуждать?

[_Pasha]

Реже используется Modbus-ASCII и DCON.

вот мне лично ASCII нравится и я предпочтения ему отдаю, если нужно построить сеть из несложных девайсов.

В Росии тот-же ОВЕН долгое время продвигал свой собственный, весьма не плохой протокол, ну а в последнее время сдался и тоже реализовал во всех своих изделия Modbus-RTU.

А там еще было какое-то решение на базе Modbus-ASCII с заменой множества символов, так что они были прозрачны для остальных девайсов с "фирменным модбасом" с точностью до фрейма. причем, непонятно для чего сие вообще, если мастер один

конечно не просто - мы же всегда любим делать все через одно место
...
что еще обсуждать?

при чем тут... чуждый православию модбас появился эволюционным путем. Всё.

[zltigo]

1. Нет. Речь шла о продувке физ. канала. Совершенно закономерно, что мысль дошла до того, чтобы сделать продувку равную Т35 или Т15, но делать ее по максимуму, ессно, необязательно.

Мягко говоря ничего не понял. Таймера будут по любому и городить "продувку" левой рукой правое ухо просто незачем. Не обойтить без таймера, вот он пусть и отрабатывает все нужные интервалы в зависимости от состояния автомата фреймера.

2. Нет! "на многих чипах" -это х51?

Абсолютно на всех, котрые ведут совместимость от 8250 чипа. Среди микроконтроллеров это, например все NXP включая ARМ. Ну и само собой все IBM-PC.

3. Да )) но не совсем. при Т15 остальной парк девайсов примет все что идет вплоть до Т35. Т.е. после продувки Т15 можно запросто потерять пакет. А после Т35 - нет.

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

2) легко реализуемо путем пердачи лишнего байта - и как только лишний байт уйдет из регистра значит передача нужного байта выполнена

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

[net]

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

реализуемо
и кого волнует мусор на шине?

при чем тут... чуждый православию модбас появился эволюционным путем. Всё.

путем деградации

[AHTOXA]

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

Стартового бита не будет, потому что ножка передатчика отключена. Так что нормуль.

[zltigo]

Стартового бита не будет, потому что ножка передатчика отключена. Так что нормуль.

Если НЕ понимаете о чем речь, не плодите "мусор на шинефоруме". Передатчик НЕ отключен, поскольку передатеся валидный "предпоследний" байт.

реализуемо
и кого волнует мусор на шине?

Меня волнует мусор, которого могло-бы и не быть. Не люблю грязную работу и сам НЕ делаю свою работу грязно.

[net]

Меня волнует мусор, которого могло-бы и не быть. Не люблю грязную работу и сам НЕ делаю свою работу грязно.

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

и в от личии от вашего невозможно - это все решает без проблем

[AHTOXA]

Если НЕ понимаете о чем речь, не плодите "мусор на шинефоруме". Передатчик НЕ отключен, поскольку передатеся валидный "предпоследний" байт.

Нет, это вы влезли посреди обсуждения, и, как выясняется, совершенно НЕ понимаете, о чём речь. Но осуждать это вам не мешает.
На всякий случай, речь шла об вот этом методе:

А линию продуваю действительно так, как вы предположили. Поясню на примере STM32.
Отключаю функцию UART на ноге ТХ (перевожу в GPIO) и отправляю один байт на заранее рассчитанной скорости чтобы получилась пауза 3,5T (при этом нога TX вообще не дёргается).
Потом в прерывании TXC перевожу ногу обратно в режим UART-TX, меняю на правильный бодрейт и отправляю пакет, потом снова продуваю прежним способом.
Т.е. у меня в драйвере UART есть возможность включить пакетный режим с суффиксом и префиксом активного состояния.
Прерывания от таймера вообще не использую.

[zltigo]

Нет, это вы влезли посреди обсуждения, и, как выясняется, совершенно НЕ понимаете, о чём речь. Но осуждать это вам не мешает.
На всякий случай, речь шла об вот этом методе:

Вот именно по этому методу окончание передачи и НЕ работает, если, как уже писал, нет прерывания по окончанию передачи. И прерывание по загрузки регистра хранения в регистр сдвига, как у 8250 совместимых чипов никак не канает.

ну тогда считаем что этого мусора нет

Понял. Насрать соседу под дверь, насрать не считается, ибо дверь чужая и проблемы соседа - пусть чистит.