По п. 4 передача первым символа 0x55 это хорошее решение, но не для приёма компом. МК может 0x55 вообще с помощью входа захвата принять и настроится, а комп - нет. Для компа лучше уж 0xFF передавать. Как, собственно, и по п. 5. Но два 0xFF подряд будет ещё лучше.

Ничего не делать - отказаться от паритета как от устаревшего и неэффективного решения. Паритет, этот CRC1 - совершенно неэффективен. Если принимается от 10 байт, то CRC8 на все эти байты займёт времени меньше, чем паритет. А уж эффект несравнимо выше будет. А CRC16 и CRC32 с CRC1 даже и сравнивать смешно...

Для ограниченного набора символов - никогда он не устареет. Еще вспоминается темка из одной хорошей книжки по помехоустойчивому кодированию. Рассматривается блок данных, пусть это будут биты

p[i] - это биты полученные путем xor по строкам и столбцам. Такой блочок данных позволяет восстановить все одиночные и часть двойных ошибок. Если совсем не фантазировать, то

такой блочок (р5 - паритет) позволяет исправить все двойные ошибки
Извините за оффтоп.

Это называется поблочный контроль чётности. Он низкоэффективен и бессилен против ошибок возникающих в чётном кол-ве строк. А использовать для восстановления 4-х бит данных 5 дополнительных бит - это уже слишком. Есть методы получше.
Насчёт поблочного контроля в частности, и насчёт обнаружения и исправления ошибок вообще, очень хорошо и понятно написано тут: Р.Л.Хаммел Последовательная передача данных.

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

Потом паритет всплыл когда пришел modbus. Тут ограничились обнаружением ошибки в принимаемой посылке (собственно после ReadFile читаем ошибку и смотрим есть ли она). Но задачу приема с получением информации о паритете в каждом байте так и не решили (и нафиг не нужно было). Хотя возможно она и решаема для всего диапазона скоростей.

С кадрированием (тут тащат не нравящийся мне термин "синхронизация")вот как раз столкнулись когда валится непрерывный поток данных без всяких перерывов. Да только перерыв более чем несколько интервалов передачи байта спасет, а никакие 55 или ff. Пока автомат в UART не отработает цикл - бесполезно что-то делать (значит нужно хотя бы 2 интервала передачи байта подождать), а в компе как правило еще буферизация включена.

Кстати говоря, заглянул в описание (exar)16с550, так там ничего про хранение в FIFO ошибок (паритета) нет. Так что, скорее всего, есть разные 550 и, вообще говоря, что на самом деле сделано в большой микросхеме в компе (когда пишут 550 совместимый UART)- совершенно не ясно. Скорее надо ориентироваться - что сделано, как делалось вначале - в FIFO пишется только данные , а флаг ошибки выставляется скопом для всего FIFO.

Стоп. Автомат в уарт отбрыкнется после ложного старта максимум через 0,5 битового интервала. Инфа об испорченном байте появляется апостериорно. Что еще надо для жизни?

А если старт не ложный? Вот и начинается мешанина и конца и краю ей бывает не видно. Есть шанс, что ошибка кадрирования опознается, если стопа не окажется там, где он должен быть. Но это зависит от содержимого байта. И то. Мы в винде получим ошибку кадрирования, но мешанина продолжиться дальше.

Про паритет. Кто - нибудь чего придумал ?

Мешанина закончится сразу после того, как в линии появится неповреждённый байт 0xFF (говорим про формат 8N1 и непрерывный поток данных). Сам этот 0xFF будет принят неправильно, точнее его вообще не будет, но в какой бы момент не был принят ложный стартовый бит (он может быть только раньше стартового бита 0xFF) , 9-ти единиц подряд (8 бит данных и 1 стоповый бит) хватит, чтобы следующий стартовый бит воспринялся именно как стартовый, и с этого момента всё пойдёт нормально до следующего сбоя байтовой синхронизации.

Кстати, к сбою байтовой синхронизации в непрерывном потоке 8N1 может привести только 2 случая:
1. Стоповый бит =0 (соединится со следующим стартовым) , но тогда будет ошибка кадра.
2. Стартовый бит =1. Тогда никаких ошибок не будет (пока на место стопового не попадёт 0).

Все, я устал. Извините за компанию.

Согласен