Как лучше использовать плохой алгоритм «контрольной суммы»

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

Команды представляют собой gcode с номером строки и контрольной суммой:

N3 T0*57
N4 G92 E0*67
N5 G28*22
N6 G1 F1500.0*82
N7 G1 X2.0 Y2.0 F3000.0*85
N8 G1 X3.0 Y3.0*33

Номер строки должен быть последовательный (но может быть сброшен с помощью M110 ). Если контрольная сумма не t соответствует или номер строки не соответствует порядку, микропрограмма ответит Повторно отправит: nnn , где nnn - последний успешный N плюс 1. «Контрольная сумма» чрезвычайно примитивен:

        // Calc checksum.
        byte checksum = 0;
        byte count = 0;
        while(instruction[count] != '*')
                checksum = checksum^instruction[count++];

Основная проблема заключается в том, что основной механизм ошибки - это потерянных байтов из-за удержания прерываний, приводящих к переполнениям в 1-байтовом буфере FIFO MCU. Фактическая последовательная шина находится на расстоянии нескольких см между последовательным мостом USB FTDI (или аналогичным) и MCU, поэтому битовые ошибки маловероятны. Я никогда не наблюдал битовой ошибки в ответе от прошивки.

Как видите, приведенный выше алгоритм обнаружит один потерянный байт, но если вы сбросите два одинаковых байта (где угодно!), Результат все равно будет совпадать . Таким образом, F3000.0 (скорость подачи 3000 мм / мин) можно преобразовать в F30.0 и все равно соответствовать. и если вы отправите F3000 , когда это предполагается в будущем, чтобы его можно было отправлять или нет)

Если я считаю, что прошивка сбрасывает байты группами, тогда наиболее важным может быть предотвращение возврата -to-back дубликаты, такие как 00 , которые (если бы упали вместе) были бы невидимы.