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

я б тоже не советовал никому использовать то что вы тут намутили, кошмар и только.
Ни объем передать, ни короткими пакетами поработать. Да и за пределами стандартов, все это у вас протокольное.
Про временную синхру, сбои ... никак, и много еще чего, что в реальных условиях нужно.
Подвис у вас один узел-транслятор, которого не обойти, пошли теряться пакеты, сеть из 200 подвисла, как восстановить?
Никак, только перезагрузка всех и пере-синхронизацией заново. Кому это нужно?
От наведеной помехи повиснет треть оконечников в сети ... и проблема вашего протокола очевидна. Итд ...

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

-Здесь я описал только ту часть протокола, которая касается байтстаффинга(по просьбам зрителей))). Конечно кроме байтстаффинга в протоколе есть и длина кадра и CRC16 и адресация... Кто удосужился пройти по ссылке вначале, очень надеюсь, всё это увидели А вот преамбулы и синхронизации там нет. Если кто-то читал статейку, то увидели, что главная первоначальная задача была связать 2 микроконтроллера по УАРТу. Синхронизацией вам для этого заниматься не надо. Протокол лишь дает удобство общения между микроконтроллерами по УАРТу(с проверкой CRC и другими приятными мелочами(см. видео по ссылке). И вот к такому микроконтроллеру, опять же ПО УАРТу, вы можете подключить стандартный радиомодуль, который имеет свой протокол, и вам до него дела нет. У него есть и преамбула и все остальное для эфирной передачи, но, повторяю, вам до этого дела нет, вы на этом не заморачиваетесь: подключили к УАРТу и кидаете данные. Или, например, если речь идет о применении моего протокола в переходнике УАРТ-ЮСБ: мой протокол НЕ ЗАМЕНЯЕТ протокола ЮСБ, так же как НЕ ЗАМЕНЯЕТ эфирный протокол радиомодулей. Вы просто кидаете данные по УАРТу в переходник и не заботитесь о том как ЮСБ передает все это в компьютер. А то некоторые, не разобравшись, понавесят на мой протокол функций, которых я не заявлял, а потом говорят "фу". Ну разве вы требуете, например, от МОДБАСа, чтобы он имел преамбулу для захвата эфира? Вот и от моего не стоит требовать. А почему я написал про радиосеть? Да просто потому, что я подключил к нескольким микроконтроллерам радиомодули, это все отлично заработало и я понял, что более удобной системы я не встречал: три строчки кода- и готов полноценный обмен данными. С помощью МОДБАСа, например, так просто не получится.(Но я не уничижаю МОДБАС:он имеет свои достоинства, до которых мне далеко) Кроме того мой протокол дает возможность ретрансляции(то есть нечто типичное именно для радиосвязи). Причем никаких специальных ретрансляторов городить не надо. Неужели после этого я не мог в название этой темы добавить слово"радиосеть"?-Никакого сжатия, просто модифицированный байтстаффинг.-Скачайте библиотеку(по ссылке вначале):даже AVR8 на частоте всего 1 МГц справляется с максимальными пакетами(247байт) и бОльшую часть времени отдыхает.

Уж простите, но я прошел по ссылке и увидел там только портянку
Касательно подключил и забыл - модули как минимум придется конфигурировать, а если брать CC430 и аналоги то и вовсе для них прошивку нужно ваять

Мы говорили о кадрах размером >255 байт.
Берём в руки обычный калькулятор, считаем сколько времени потребуется для поиска 2-байтовой последовательности, отсутствующей в кадре.
Допустим размер кадра == 1000байт. Допустим поиск 2-байтовой последовательности идёт просто прямым сравнением подряд от начала кадра.
Допустим искомые последовательности генерим начиная от 0 и далее (если найдена) инкремент.
Получаем:
1.Для проверки вхождения одной 2-байтовой последовательности в кадр потребуется от 1 до 999 сравнений. Среднее кол-во == ~500.
2.В худшем случае придётся выполнить 501 генерацию новых последовательностей (с их последующей проверкой).
Это в случае если кадр состоит из слов: 0000, 0001, 0002, ... .
Итого получаем: 500*500 = 250000 сравнений. И это без учёта ещё сравнений с последовательностями границы кадра.
Сколько Ваш AVR8 будет кодировать такой кадр? Особенно учитывая что он 8-битный и на одно сравнение тратит кучу команд. Думаю - несколько секунд. При полной загрузке CPU.
Жесть короче.

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

А байт-стаффинг тем и хорош, что он малозатратен ресурсам - памяти и времени выполнения (мой метод - тож).
Кодирование/декодирование кадра можно проводить хоть прямо на лету в ISR не расходуя на это драгоценное ОЗУ - записывать в выходной буфер уже декодированный кадр,
а на в буфере передачи хранить исходный кадр и кодировать его на лету при записи собственно в порт в ISR.