Жизнь - есть! Согласен. Но USB в ней места нет . USB живет там где кошечки, брелочки, MP плееры и т п.

Ни в каком проекте никто не не использует USB. Вы что? У отдельных заказчиков вообще требование ни за что не использовать Форточки ни в каком виде.

В моих условиях не только JTAG, но и USART идут лесом ибо не только человек (высокое напряжение), но и комп (с UART) там просто не поместится. Пользуюсь флешкой с SPI - сильно помогает. Поэтому про JTAG написал чисто теоретически, если не прав, то пусть будет так.

Если вы знаете способ лучше, как восстановить байтовую синхронизацию в непрерывном потоке данных (8N1) то так и напишите, а в бубен постучим параллельно.

По пунктам 1,4,5 - после потери байтовой синхронизации (стартовый бит принимается как бит данных) работать не будет.
П. 2 - таймаут может помехой быть изменён на 0xFF, 0xEF и т.д.
П. 6 не спорный, а вынужденный под win - тоже делал.
Но по теме, с учётом ограничений родного драйвера в win, остаются только 2, 6 (вынужденный) и отчасти 3 (модбас), но там время паузы может стать слишком большим. Да и вообще, модбасу давно на пенсию пора...
Собственно, только 2 то под win и остаётся...

А USB я успешно использую в условиях 6..10кВ * 1..2кА. Работает под lin. Там к хабу без без проблем обратится можно. И если потеряется EOP и хаб отключит мой девайс (в этом ведь проблема USB), то тут-же переподключаюсь и всё - 5 мСек max. Но если нет 5 мСек ограничения, то можно и по win работать - даже со стороны девайса всё решается. Только уже порядка 50 мСек будет.

Дык как же не будет? Это бит данных может быть воспринят как стартовый - я это понимаю.
По этой причине вопросы могут быть к п.1 и 5.
Про п.1 - ничего не скажу, там где использую 9 бит, посылка идет с паузой между байтами.
А п.5 - на символ начала можно наложить ограничения, забив старшие биты единицами.

Действительно кругозор узковат у вас. В наших контроллерах, предназначенных для учета энергоресурсов, которые в т.ч. и в котельных работают , используется USB для снятия журнала. USB заменил FDD, который использовался в предыдущем поколении приборов для той же цели - снятие журналов с удаленных объектов, не имеющих связи. Естественно, что для организации сетевой связи в приборе имеются и RS232 и RS485, посредством которых также можно считывать и журнал и текущие рабочие значения/параметры. То бишь, USB это еще один интерфейс в приборе.

Про кругозор советую помолчать. Выношу вам замечание.
Ну и в моих приборах есть USB дырка. Это кстати не общение , а перенос архива (еще можно конфигурить - но это экзотическая особенность). Ни нафиг она никому не нужна. (Хотя вопрос о FDD в свое врем тоже обсуждался ) Те заказчики, кто архив через USB сливает - их единицы (буквально, хотя есть тоже). По крайней мере все что я видел по объектам - это желание видеть в Москве аж температуру каждого подшипника ( и делаю ведь). И уж тем более предлагать общение с промышленным прибором через USB - глупость какая то. Основные заказчики строят скады . Большие или маленькие, но скады.
Тема топика - что делать при приеме с паритетом. Когда в такую тему влезают с советами использовать USB , нужно тут же банить за глупость.
Вопрос темы непростой - при DOSe все решалось, при винде - стало плохо. Советов по теме было только на первой странице - остальное - междусобойчик. Кстати про запоминание в буфере для каждого байта паритетов для 550 серии я не знал (не надо было и внимания не обращал), надо посмотреть, может и в самом деле запоминает в буфере. В 450, по моему не было. Вот это была полезная часть обсуждения.

По п. 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).

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

Согласен