Протокол modbus. Вопросы по интерфейсу Опции

[rezident]

Не совсем, у Вас в описании просматривается часть характеристки канального уровня - проверка правильности принятых данных (по крайней мере четность).

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

<физ уровень> --> сводится к драйверу железа или эмулятору железа (программый UART/ программный SPI)
<канальный уровень> ---> разбиение пакетов на голые байты и передача их драйверу железа, прием голых данных от железа и укладка в пакеты
<сеть> --> поиск и проверка маршрутов
<транспорт> --> укладка и выделение пользовательских данных в/из пакетов.

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

[aaarrr]

Ну, а как быть с реальным временем?

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

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

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

[Guest_@Ark_*]

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

Я опять не понял. Вы не могли бы излагать яснее. То есть Вы предлагаете передавать данные блоками, снабжая их метками реального времени, и с возможной неопределенной задержкой при передаче. Какая же это работа в реальном времени?

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

Почему же? Если уже обработаны и выполнены команды за ветвлением, тогда если ветвление не состоялось, эти результаты используются. А если "вдруг" состоялось, то что еще делать с результатами этих команд - только выбросить.

[aaarrr]

Я опять не понял. Вы не могли бы излагать яснее. То есть Вы предлагаете передавать данные блоками, снабжая их метками реального времени, и с возможной неопределенной задержкой при передаче. Какая же это работа в реальном времени?

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

Почему же? Если уже обработаны и выполнены команды за ветвлением, тогда если ветвление не состоялось, эти результаты используются. А если "вдруг" состоялось, то что еще делать с результатами этих команд - только выбросить.

OMG! Да не выполняет их никто, естественно, в конвейер только грузят.

[Guest_@Ark_*]

... что данные будут получены с некоторой апертурной задержкой.

С какой? Это критичный параметр. В реальном времени задержка должна быть минимальна, насколько это позволяет канал и используемый протокол. В чем, в данном случае, преимущество блочной передачи, при прочих равных? Я ее не вижу.

... Да не выполняет их никто, естественно, в конвейер только грузят.

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

[aaarrr]

С какой? Это критичный параметр. В реальном времени задержка должна быть минимальна, насколько это позволяет канал и используемый протокол. В чем, в данном случае, преимущество блочной передачи, при прочих равных? Я ее не вижу.

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

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

Да, а потом специальный "выпиливатель" удаляет результаты выполнения ненужных операций из регистров/памяти.

[Guest_@Ark_*]

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

Здесь мы с Вами расходимся принципиально. Предпочтительнее минимальная возможная задержка от момента измерения до получения данных. И естественно, точно известное, фиксированное, значение этой задержки. А не поступление значений блоками с известными задержками. Хотя, здесь уже все зависит от задачи...

Да, а потом специальный "выпиливатель" удаляет результаты выполнения ненужных операций из регистров/памяти.

Примерно так.

[aaarrr]

Здесь мы с Вами расходимся принципиально.

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

Примерно так.

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

[defunct]

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

Можно полюбопытствовать - почему? - Какие объективные причины подтолкнули к такому решению? (требования к латентности прерываний, особенность ОС, особенности аппаратуры)?

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

Есть две разные задачи.
1. обеспечить Real-time - см. real-time protocol который с помощью меток времени и блочной передачи, вне зависимости от задержек канала и межпакетного джиттера, гарантирует real-time воспроизведение медиа потока.
2. обеспечить максимально возможный КПД использования канала.

То о чем говорите Вы решает 1), то о чем говорит @Ark решает 2).

[Guest_@Ark_*]

Цитата(aaarrr @ Nov 9 2009, 00:17)
Да, я все же не могу понять, зачем делать задержку меньше минимально достаточной.

Цитата(defunct @ Nov 9 2009, 00:51)
Есть две разные задачи...

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

Цитата(aaarrr @ Nov 9 2009, 00:17)
... выполнить и безболезненно удалить результат выполнения можно только в очень ограниченном ряду случаев. На практике, как я понимаю, используется только для некоторых команд типа загрузки регистров, так что до полноценных вычислений и уж тем более записи результатов дело все равно не доходит.

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

[rezident]

Можно полюбопытствовать - почему? - Какие объективные причины подтолкнули к такому решению? (требования к латентности прерываний, особенность ОС, особенности аппаратуры)?

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

[koyodza]

Стандарты порой устаревают. А сильно распространненные нарушения часто становятся частью страндарта.
Грубых нарушений стандарта в упор не вижу, если CRC сошлась ложно, то пакет отбракуется по длине и прием продолжится.

Данное нарушение пока не стало частью стандарта. И пока это является именно грубым нарушением.
Вы никогда не получали совпадение CRC внутри пакета? Значит Вы не использовали ModBus в реальных проектах. Или Вам просто пока крупно везло.
Или Вы предлагаете после получения совпадения CRC продолжать принимать пакет, параллельно пересчитывая CRC и убеждаясь (по другим признакам) что пакет битый, после чего ждать нового совпадения CRC?

С другой стороны, на кой в холостую ждать 3.5 символьных интервала (это ж вагон и еще маленькая тележка времени особенно на 9600 и ниже), когда их можно потратить с пользой, например на вычитку архива из медленного eeprom'а по текущему запросу мастера.

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

Полностью поддерживаю идеи, изложенные коллегой rezident: не нужно смешивать разные уровни обмена в одну кучу. Прерывание по приему/передаче байта должно быть максимально коротким (взять или положить в буфер и всё). Как в принципе и любое другое прерывание.

Может для "Копилки Вечности" у вас найдется способ отмерить таймаут в 1.75ms под Windows?

Windows вообще никакого отношения к ModBus не имеет. Ну а если в качестве мастера у Вас выступает РС - никто не запрещает сделать интервал больше, чем 1,75 мсек. Приемлемые таймауты в единицы мсек отрабатываются нормально.

Есть две разные задачи.
1. обеспечить Real-time - см. real-time protocol который с помощью меток времени и блочной передачи, вне зависимости от задержек канала и межпакетного джиттера, гарантирует real-time воспроизведение медиа потока.
2. обеспечить максимально возможный КПД использования канала.

То о чем говорите Вы решает 1), то о чем говорит @Ark решает 2).

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

[defunct]

Или Вы предлагаете после получения совпадения CRC продолжать принимать пакет, параллельно пересчитывая CRC и убеждаясь (по другим признакам) что пакет битый, после чего ждать нового совпадения CRC?

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

Данное нарушение пока не стало частью стандарта. И пока это является именно грубым нарушением.

Нет никакого нарушения стандарта, тем более грубого:

Код

1. При совпадении CRC текущего пакета background task создает копию принимаемого пакета,
    и записывает перекресную ссылку (друг на друга) в текщий пакет и его копию,
    а также взводит callback c таймаутом на отправку копии пакета.
2. background task приступает к формированию ответа на запрос незамедлительно,
    ответ на запрос формируется в этой же копии пакета.
3. Взависимости от того что наступит раньше - вызов callback'а по таймауту
    или прием символа по уарту:

     a. вызов callback'а наступает раньше.
          - удаляется перекресная ссылка из пакета и копии пакета (т.е. копия отвязывается от приемника)
          - приемник (оригинал пакета) обнуляется - переход к приему нового пакета
          - проверяется полностью ли сформирован ответ на запрос:
            если ответ сформирован, тогда
            он нативно отправляется ровно через указанный в стандарте минимальный межпакетный интервал
            (в 99% случаев имеет место именно этот случай).
          - если ответ еще не сформирован - повторно взводится callback с таймаутом в одно-символьный интервал.
     b. eсли раньше примется символ, прошло не более 1.5 символьного интервала от последнего принятого символа,
         копия помечается как бракованая (при вызове callback'a удалится автоматически), а символ добаляется к текущему
         пакету и подсчет CRC продолжается.
     с. если раньше примется символ, но 1.5 символьный таймаут уже пройден -
         копия пакета помечается как бракованая и оригинальный пакет обнуляется.

Собсно вот так у меня реализовано, алгоритм ниоткуда не слизанный, просто устройств в сети много, и опрашиваются непрерывно. Эти 1-2% КПД канала это +1..2 устройства в сети без ухудшения характеристик всей системы.

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

Расскажите это мастеру который хочет прочитать данные со слейва которые лежат в i2c eeprom'е. Если быть точнее - расскажете мастеру почему ответ на его запрос появляется не через 3.5 символьных интервала, а через 7 (4-5ms - среднее время i2c транзакции).

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

Я считаю, гоняться за наносекундами в обработчиках прерываний - нет смысла. Что 32 регистра в стек будет сохраняться что 1, какая разница? это вопрос микросекунды. А если что-то совсем совсем критичное ко времени реакции - проще поставить плиску или какой-нибудь мелкий МК в помощь, чем лишать себя свободы в обработчиках прерываний. Тобиш минимальное время реакции это удел мелких проектов. В крупных проектах бывает удобно уменьшать число прерываний как таковых за счет пакетной обработки нескольких прерываний от нескольких периферийных модулей за один заход. Реакция возрастает, но накладные расходы на вход-выход в обработчик снижаются пропорционально количеству обработанных за один заход прерываний.

А вот там где счет идет на миллисекунды, предпочитаю их не терять.
Максимальный КПД канала он к любому протоколу применим, в т.ч. и к Модбас, т.к. в нем минимальное время между пакетами оговоренно стандартом, вот к нему надо стремиться.
Да и на 485-м можно иметь вполне причную скорость ~2Mbps.

[defunct]

Полностью поддерживаю идеи, изложенные коллегой rezident: не нужно смешивать разные уровни обмена в одну кучу. Прерывание по приему/передаче байта должно быть максимально коротким (взять или положить в буфер и всё). Как в принципе и любое другое прерывание.

Разные уровни обмена не нужно смешивать разумеется. Только вот идеи на которые Вы ссылаетесь примерно такого плана: а давайте чтобы сократить время реакции прерывания разобъем канальный уровень на два подуровня, первый подуровень канального уровня будем обслуживать в прерывании, а второй - постобработкой. Ничего что для этого придется обзавестись большим буфером памяти, зато реакция на прерывание будет быстрой. И ради чего? Разница ведь в нано-, микро- секундах исчисляется. Снижаем реакцию на прерывание просто ради получения минимальной реакции?! Дык с тем же успехом можете просто разрешить другие прерывания в обработчике текущего, реакция будет еще быстрее.


Ethernet MAC - пример канального уровня, выдает пакеты, а не байты которые надо собирать в пакеты. И выдает прерывания "пакет" принят а не байт принят. Так вот объясните мне доходчиво если можно, почему модель программиста канального уровня Ethernet должна отличаться от модели канального уровня PPP или того же Modbus? И зачем делать двойную работу? Зачем накапливать в памяти что-то непотребное, - escaped chars, пакеты нам не адресованые, метки времени на каждый принятый символ для определения таймаутов, и прочее г. которое можно отсеяться сразу в прерывании.

[Verifi]

Зачем накапливать в памяти что-то непотребное, - escaped chars, пакеты нам не адресованые, метки времени на каждый принятый символ для определения таймаутов, и прочее г. которое можно отсеяться сразу в прерывании.

Совершенно согласен по началу принятия пакета проверяете адрес ежли это не ваше ,то просто проверяете CRC в буфере приёма,и только если CRC не правильная или ставите флаг и обрабатываете в обработчике ошибки, либо сразу выходите из прерывания с подменой стека со смещением стека на обработчик соответствующий ошибке и соответственно надолго в прерывании не задерживаетесь.
Данным образом реализовал мастер модбус на 51 ядре с буфером приёма-передачи в 128байт интервалы пакетов контролируются в прерываниях по таймеру и по UART.