CANNY forum — Подсчет контрольной суммы. Как эффективнее всего?

Re: Подсчет контрольной суммы. Как эффективнее всего?

null@example.com (Константин, CANNY) — Tue, 27 Nov 2018 12:54:29 +0000

Речь о i-bus шине, контрольная сумма для которой - последний байт посылки, как результат всех предыдущих через XOR

Ясно. Появись эта информация в исходном сообщении, тема была бы намного короче.

Re: Подсчет контрольной суммы. Как эффективнее всего?

null@example.com (alex_engine) — Tue, 27 Nov 2018 12:26:37 +0000

Пока у меня два пути, по которым все получается:
1. подсчет вручную виндосовским калькулятором через XOR всех байтов посылки
2. отправкой через I-Bus analyser посылки без чек суммы, программа добавляет ее автоматом, и я могу на выходе "подсмотреть" результат.
Но это годится только для статичных сообщений.

Речь о i-bus шине, контрольная сумма для которой - последний байт посылки, как результат всех предыдущих через XOR

Буду пробовать реализовать через блоки диаграммы.

Благодарю

Re: Подсчет контрольной суммы. Как эффективнее всего?

null@example.com (Константин, CANNY) — Tue, 27 Nov 2018 09:37:05 +0000

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

Re: Подсчет контрольной суммы. Как эффективнее всего?

null@example.com (alex_engine) — Tue, 27 Nov 2018 09:30:27 +0000

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

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

Насколько я успел заметить - во втором случае изменяются две последние позиции посылки. А в "оригинале" чексумма - одна последняя позиция (27)

Re: Подсчет контрольной суммы. Как эффективнее всего?

null@example.com (Константин, CANNY) — Mon, 26 Nov 2018 20:18:40 +0000

рабочая посылка

нерабочая посылка

Что это значит?

Re: Подсчет контрольной суммы. Как эффективнее всего?

null@example.com (alex_engine) — Mon, 26 Nov 2018 20:14:57 +0000

Спасибо, попробовал.

У меня получается так:
30 19 80 1A 35 00 20 20 20 20 20 20 20 2D 24 42 4D 57 24 2D 20 20 20 20 20 20 FE - без RTU, рабочая посылка. FE - чек сумма. Строка на экране отображается.

30 19 80 1A 35 00 20 20 20 20 20 20 20 2D 24 42 4D 57 24 2D 20 20 20 20 20 9E 62 - с RTU, нерабочая посылка.

Длинна сообщения UART - 27 в обоих случаях.

Увеличил длину до 28, в шину шлет такое:
30 19 80 1A 35 00 20 20 20 20 20 20 20 2D 24 42 4D 57 24 2D 20 20 20 20 20 20 E2 70 - rtu (28), все равно не получается.

В описании RTU указано, что чек сумма это два байта. В моей посылке - один. Я так понимаю, проблема в этом. Это как-то можно победить?
Благодарю

Re: Подсчет контрольной суммы. Как эффективнее всего?

null@example.com (Константин, CANNY) — Mon, 26 Nov 2018 15:08:47 +0000

Но, кроме этого, посылка должна содержать чек сумму.

Если алгоритм расчета контрольной суммой не фиксированный, то я бы использовал протокол Modbus RTU: http://wiki.canny.ru/index.php?title=CA … Modbus_RTU

в этом случае, драйвер UART рассчитает с добавит контрольную сумму сам.

Начиная с версии CannyLab 1.35 поддержка Modbus RTU добавлена в драйвер UART контроллера Canny 5 nano.

Re: Подсчет контрольной суммы. Как эффективнее всего?

null@example.com (Константин, CANNY) — Mon, 26 Nov 2018 12:14:16 +0000

Посылка состоит из HEX кодов символов ASCII, которые принимаемое устройство само в символы преобразует.

Блок "Число в строку" по основанию 10, преобразует именно в ASCII коды символов. То, в какой системе счисления вы видите ASCII коды, зависит только от средства просмотра. Полагаю, что никаких дополнительных преобразований вам не потребуется.

Подсчет контрольной суммы. Как эффективнее всего?

null@example.com (alex_engine) — Sun, 25 Nov 2018 16:00:25 +0000

Здравствуйте
Подскажите, плиз, в такой ситуации оптимальный путь:

Имеется надобность посылать через UART посылку, в которой из диаграммы будет передаваться число (десятичное), которое принимаемым устройством должно быть отображено на экране цифрами. Посылка состоит из HEX кодов символов ASCII, которые принимаемое устройство само в символы преобразует.

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

Но мне нужно десятичное число в шестнадцатиричное преобразовать для пересылки. И таким образом этого не добиться.
Сначала число в строку по основанию 10, потом строку в число по основанию 16? Это сработает?

Но, кроме этого, посылка должна содержать чек сумму. А значение меняется по результатам работы диаграммы.
Есть какой-то более оптимальный способ для вычисления чексуммы чем банальное XOR всех бит посылки? (их почти три десятка )
Спасибо