caxapa.ru :: не годится: если запрос с правильным адресом, но с неподдерживаемым кодом функции, то правильно будет убедиться, что пакет не битый. И если CRC сошлась, ответить на него "неподдерживаемая функция"

koyodza (01.04.2012 11:09, просмотров: 741) ответил zlogic на А для чего вы считаете CRC сообщения, которое явно не для вашего устройства?

не годится: если запрос с правильным адресом, но с неподдерживаемым кодом функции, то правильно будет убедиться, что пакет не битый. И если CRC сошлась, ответить на него "неподдерживаемая функция" Просто пропускать и не отвечать можно только пакеты с неправильным адресом (тут можно и CRC не считать), и пакеты, у которых не сошлась CRC

Ответить

- Если пакет имеет правильный адрес, но левый код функции, то это пакет или битый, или ошибочный (из-за ошибки верхнего ПО). В любом случае нет разницы, проигнорируем его, или ответим, что функция не поддерживается. Разве что для отладки может Леонид Иванович(13 знак., 01.04.2012 11:37)
  - ничего подобного, разница есть. Положено на пакеты с правильным адресом отвечать "функция не поддерживается". Иначе из-за таймаутов при неответах тормозится работа всей системы koyodza(201 знак., 01.04.2012 11:40)
    - Ешё раз... Если функция не поддерживается, то посылается мастеру exception, который не содержит CRC... то есть не надо CRC считать... - zlogic(01.04.2012 14:16)
      - чего-чего? Каие ещё посылки без CRC ? Что, 1 апреля давит? - koyodza(01.04.2012 15:13)
      - Еще раз... Если CRC не посчитана, нельзя с уверенностью сказать, это неподдерживаемая функция или битый пакет. - Леонид Иванович(01.04.2012 14:25)
        
        Верно... Но я с чего начинал разговор? если пакет больше ожидаемой длины, то это не ваш пакет... и на него вообще отвечать не стоит... просто разговор немного ушёл в сторону... - zlogic(01.04.2012 14:33)
        
        нельзя. Если адрес наш - нужно отвечать. Даже если функция не поддерживается. Иначе мастером это будет расценено как сбой связи, а не как недопустимость для слейва такого запроса - koyodza(01.04.2012 15:19)
        
        Ну и? мастер не идиёт... сформирует правильный запрос... адрес, количество байт в сообщении и т.п. хню... если мастер такой тупой, то и не получит в ответ ничего, что ожидал... программист на стороне мастера подумает и сформирует сообщение zlogic(14 знак., 01.04.2012 15:33)
        
        ничего он не "подумает". Обычная реакция мастера на отсутствие ответа - это повторение запроса. Дальше подумайте сами, что будет - koyodza(01.04.2012 15:41)
        
        совсем не отвечать (при совпадении адреса) можно только на пакеты длиной больше 256 байт - koyodza(01.04.2012 15:32)
        
        Формально любой пакет с нашим адресом - наш пакет. И если он с правильной CRC, то положено на него отвечать. Хотя я тоже в своей реализации это игнорирую, Леонид Иванович(69 знак., 01.04.2012 14:41)
        
        С одной стороны так, но с другой... анализ пакета происходит после паузы от мастера в 3.5 символа... если в процессе приёма пакета количество байт превышает ожидаемое, то это не ваш пакет... в топку его и CRC туда же... то есть я в самом начале zlogic(177 знак., 01.04.2012 14:53)
        
        Я именно так и делаю, но уважаемый koyodza привел аргументированные возражения. - Леонид Иванович(01.04.2012 15:01)
        
        Давайте вернёмся к его аргументам... Ссылку, плиз... Хотя, мы сейчас ведём разговор о пакете с количеством байт больше ожидаемого... а уважаемый koyodza на эту тему вроде бы ничего не говорил... - zlogic(01.04.2012 15:04 - 15:09)
        
        Аргументы просты - устройство формально не будет Modbus-совместимым. Насчет пакетов, не умещающихся в буфер, тоже было сказано. На них нужно отвечать ILLEGAL_DATA_VALUE. А вот ожидаемое количество байт - это другое, мы узнаем его только при Леонид Иванович(34 знак., 01.04.2012 16:29)
    - Нечего посылать неподдерживаемые функции. Тогда и буфер нужен 256 байт, а это в большинстве случаев непозволительная роскошь, в мелких контроллерах ОЗУ кот наплакал. - Леонид Иванович(01.04.2012 11:46)
      - буфер не обязательно 256 байт, CRC в экстремальных случаях считается "на лету". Тем более что считать CRC нужно только для своих пакетов. Для пакетов, которые подлежат обработке, но длиннее буфера, есть ошибка ILLEGAL_DATA_VALUE koyodza(186 знак., 01.04.2012 11:53 - 12:04)
        
        Я разве не об этом писал? "Тем более что считать CRC нужно только для своих пакетов." Пакет длиной более 8 байт есть не пакет для Юра... Ответ с exception вообще не содержит CRC... - zlogic(01.04.2012 13:49)
        
        с какой это радости "Ответ с exception вообще не содержит CRC"? Любой небитый пакет в ModBus RTU должен содержать CRC - koyodza(01.04.2012 16:36)
        
        Для Юра чисто прикладно легче единообразно считать CRC от начала до конца пакета, первые 8 складывать в буфер остальные нет. А уж потом анализировать и адрес количество пришедших и совпадение CRC, благо оно уже посчитано. Хотя конечно, можно, не Юра(101 знак., 01.04.2012 13:56, )
        
        если ресурсов мало, то удобнее именно дропать не складывая и не считая CRC все пакеты, которые адресованы не нам и не широковещательные. Всё равно на них отвечать не положено, и действий никаких производить тоже - koyodza(01.04.2012 15:15)
        
        Сам сейчас делаю устройство, в котором МК C8051F301 (всегда его использую в модулях, типа ADAM и ICPCON (протокол DCON), а тут заказчик захотел MODBUS)... В этом МК всего-то ОЗУ 256 байт, буфер разместить на 256 байт фрейма MODBUS нет никакой zlogic(114 знак., 01.04.2012 14:07 - 14:29)
        
        Вы можете хоть на голове стоять в своём девайсе, только он не будет от этого более полно соответствовать стандарту - koyodza(01.04.2012 15:17 - 15:20)
        
        Вы сами-то читаете то, что пишете? - zlogic(01.04.2012 15:37, ссылка)
        
        перечитал. Именно так - можно дропать все пакеты, адрес в которых не наш. Дропать наши пакеты только потому, что функция не поддерживается, или потому, что пакет не помещается в буфере (но при этом не превышает максимальной разрешенной стандартом koyodza(14 знак., 01.04.2012 15:49)

Микроконтроллеры