Банальный ModBus RTU

[SSerge 0]

3 часа назад, C2000 сказал:

А Вы уверены что все прочитали и правильно поняли? IDLE вроде бы определяется не через 1.5t а через 1t.

Раньше я это точно видел в RM.

Сегодня неожиданно оказалось что ни в свежем RM ни в даташите явно не указана длительность паузы для IDLE.

PS. Попробую завтра измерить на F103, F407 и F030.

 

[Сергей Борщ 0]

2 минуты назад, SSerge сказал:

Сегодня неожиданно оказалось что ни в свежем RM ни в даташите явно не указана длительность паузы для IDLE.

Странно. В моих есть:

Цитата

An Idle character is interpreted as an entire frame of “1”s (the number of “1”s includes the number of stop bits).

 

[C2000 0]

On 10/28/2020 at 12:02 AM, Arlleex said:

...
Я никогда не использовал в STM32 возможность отслеживания символьной тишины на периферии UART. Но можно придумать с таймером.
Заводим сигнал RX одновременно на вход RX UART-периферии и на внешний вход (например, ETR) таймера (пусть TIM1).
Таймер настраиваем так, чтобы передний фронт ETR сбрасывал счетчик. Период таймера настраиваем на 3.5 символа для выбранной скорости UART.
Также настраиваем один из каналов сравнения этого же таймера на таймаут 1.5 символа для выбранной скорости UART. Разрешаем прерывания.
...

В этом случае тайм-ауты будут не четкие. Будут плавать +-1t.

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

On 10/28/2020 at 12:31 AM, AlexRayne said:

Там проще немного делали: по таймауту1.5 заканчивали прием. И обрабатывали пакет

По таймауту3.5 - запускали ответ в шину, если есть.

Много чего можно придумать, если нет задачи/желания чётко соответствовать стандарту.

Если же следовать стандарту, то там всё чётко описано, что да как должно происходить.

[Arlleex 0]

5 часов назад, C2000 сказал:

В этом случае тайм-ауты будут не четкие. Будут плавать +-1t.

Почему?

5 часов назад, C2000 сказал:

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

А чем отличается фронт на ноге от окончания приема в данном случае? Ничем. STOP-бит это установка линии в 1. То есть передний фронт.
Так что когда сработает таймаут по 1.5t, это будет значить, что он сработал от STOP последнего байта. Прерывание RX формируется где-то очень близко к STOP.

[C2000 0]

26 minutes ago, Arlleex said:

Так что когда сработает таймаут по 1.5t, это будет значить, что он сработал от STOP последнего байта...

Нет не от STOP, а от последнего фронта. Если последний передаваемый байт будет 0xFF, то таймаут сработает раньше.

[Arlleex 0]

5 минут назад, C2000 сказал:

Нет не от STOP, а от последнего фронта. Если последний передаваемый байт будет 0xFF, то таймаут сработает раньше.

Ну, будет 0xFF и что? У этого 0xFF будет свой START-бит, и расстояние между ним и STOP-ом предыдущего байта сбросит таймер.

[AlexRayne 0]

10 часов назад, C2000 сказал:

Много чего можно придумать, если нет задачи/желания чётко соответствовать стандарту.

Если же следовать стандарту, то там всё чётко описано, что да как должно происходить.

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

 

Edited November 1, 2020 by AlexRayne

[C2000 0]

6 hours ago, Arlleex said:

Ну, будет 0xFF и что? У этого 0xFF будет свой START-бит, и расстояние между ним и STOP-ом предыдущего байта сбросит таймер.

А если будет 0x00? То таймер сброситься на 8 бит позже чем при 0xFF. А говорите нет разницы))

2 hours ago, AlexRayne said:

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

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

[vguard 0]

По мне так хороший прибор соблюдает сам стандарт, но подстраивается под некритичное отклонение от стандарта своих собеседников. Пользователю прибора не нужно строгое соблюдение стандарта в ущерб надежности связи с различными коммуникационными устройствами. Ему не важна химия, ему важно чтобы спички горели.
Пример. Некоторые преобразователи Ethernet<->RS485 (например moxa) разбивают длинные modbus пакеты на несколько более коротких. В результате, по шине RS485 пакет приходит частями с паузой превышающей требование стандарта. Ваш принципиальный прибор не сможет работать с такими преобразователями, и очень вероятно будет заменен на продукцию конкурента.

Есть смысл таймауты при приеме пакета сделать конфигурируемыми.

[AlexRayne 0]

1 час назад, C2000 сказал:

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

и какой таймаут не соблюден?

[Arlleex 0]

1 час назад, C2000 сказал:

А если будет 0x00? То таймер сброситься на 8 бит позже чем при 0xFF...

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

[C2000 0]

16 hours ago, Arlleex said:

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

Я то давно разобрался. Есть там таймаут настраиваемый в битах, он вполне подходит. А вот таймер по внешнему пину и IDLE флаги пролетают))

17 hours ago, vguard said:

..
Пример. Некоторые преобразователи Ethernet<->RS485 (например moxa) разбивают длинные modbus пакеты на несколько более коротких. В результате, по шине RS485 пакет приходит частями с паузой превышающей требование стандарта. Ваш принципиальный прибор не сможет работать с такими преобразователями, и очень вероятно будет заменен на продукцию конкурента.

Есть смысл таймауты при приеме пакета сделать конфигурируемыми.

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

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