Фрейминг для очень коротких последовательных пакетов

Обычный способ сделать то, что вы просите, - это "поиск кадра" при запуске и требование N последовательных хороших пакетов перед тем, как принять какие-либо пакеты. Это может быть реализовано с помощью конечного автомата с 3 состояниями: HUNT, LOF (потеря кадра), SYNC.

Это могло быть что-то вроде:

#define GOOD_PACKETS_REQUIRED_BEFORE_SYNC 8
int state = HUNT;
int good_count = 0;

Packet GetPacket(void)
{
    unsigned char fb = 0;
    unsigned char sb = 0;

    while (1)
    {
        if (state == HUNT)
        {
            fb = sb;
            sb = GetNextByteFromUART();

            if (IsValidCRC(fb, sb))
            {
                state = LOF;
                good_count = 1;
            }
        }
        else if (state == LOF)
        {
            fb = GetNextByteFromUART();
            sb = GetNextByteFromUART();

            if (IsValidCRC(fb, sb))
            {
                good_count++;
                if (good_count >= GOOD_PACKETS_REQUIRED_BEFORE_SYNC)
                {
                    state = SYNC;
                }
            }
            else
            {
                state = HUNT;
                good_count = 0;
            }
        }
        else if (state == SYNC)
        {
            fb = GetNextByteFromUART();
            sb = GetNextByteFromUART();

            if (IsValidCRC(fb, sb))
            {
                return packet(fb, sb);;
            }

            // SYNC lost! Start a new hunt for correct framing
            state = HUNT;
            good_count = 0;
        }
    } 
}

Вы можете найти несколько стандартных протоколов связи, которые используют этот (или аналогичный) метод, например Банкомат и E1 (https://en.wikipedia.org/wiki/E-carrier ). Есть разные варианты принципа. Например, вы можете захотеть перейти от SYNC к LOF при получении первого плохого пакета (с уменьшением good_count), а затем перейти от LOF к HUNT во втором последовательном плохом пакете. Это сократит время, необходимое для изменения кадра. Выше показан очень простой вариант.

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

Нужен ли вам CRC или можно использовать фиксированное слово кадра (например, 0xB), зависит от вашего носителя.

Есть одна загвоздка: рекомендуемая длина сообщения для CRC4 составляет 11 бит, а здесь она вычисляется для 12 бит.

Нет, здесь он рассчитан на 16 бит.

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

Рекомендации по CRC, вероятно, относятся к тому, есть ли у вас 100% шанс найти однобитную ошибку или нет. Все CRC борются с многобитовыми ошибками и не обязательно их обнаруживают.

При расчетах надежности CRC UART вы также должны учитывать стартовый и стоповый биты. Здесь также могут возникнуть битовые ошибки, и в этом случае оборудование может помочь или не помочь в обнаружении ошибки.

второй байт из одного сообщения и первый байт из следующего сообщения иногда образуют правильное сообщение

Конечно. У вас нет механизма синхронизации, чего вы ожидаете? Это не имеет ничего общего с CRC.

У меня вопрос - есть ли способ исправить кадрирование без добавления байтов?

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

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

Может быть, есть какой-нибудь другой метод обнаружения ошибок, который будет работать лучше, чем CRC4?

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

Альтернативы - это суммы, xor, четность, количество единиц и т.д., все они довольно плохи с точки зрения вероятности.

Если нам нужно добавить больше байтов, как лучше всего это сделать?

Никто не может ответить на этот вопрос, не зная природы данных.

Если CRC предназначен в основном для паранойи (из комментариев), вы можете отказаться от некоторой надежности проверки ошибок и времени процессора для кадрирования.

Поскольку в коде операции есть свободный бит, всегда устанавливайте самый старший бит первого байта равным нулю. Затем перед передачей, но после вычисления CRC, установите самый старший бит второго байта в единицу.

Таким образом, кадр представляет собой два последовательных байта, где первый старший бит равен нулю, а второй - единице. Если два байта не прошли проверку CRC, установите самый старший бит второго байта в ноль и пересчитайте, чтобы увидеть, был ли бит пакета перевернут перед передачей.

Обратной стороной является то, что CRC будет вычисляться дважды примерно в половине случаев. Кроме того, установка бита для кадрирования может привести к тому, что недопустимые данные будут соответствовать CRC.