Здесь уже давно рассмотрели все возможные реализации асинхроного обмена. О каком внешнетактируемом приемнике идет речь.

Стандартная ситуация. Нужно обработать в конце стопового перед новым стартовым.

ага найди тут информацию 01010101011101010101011101010101010101010101? - это уже после мажоритирования

тут есть старт стоп и 8 бит данных без чётностей

На этом физическом уровне он примет правильно - всё что после первого распознаного нуля - посылка. Стандарт выполнен. А целостность данный должна проверятся уже на уровень выше. Есть модель OSI.

я не случайно говорил про удлиннённые стоповые биты
в данный момент я специально написал такую последовательность из которой нельзя выделить байты - на самом деле приписав к тому что несёт информацию пустые поля из 0101..

01010101 0_11101010_1 0_10111010_1 0_10101010_1 010101
биты чётности специально не показаны

так вот вопрос и стоит так, что модули уартов (я об этом могу судить по довольно длительному использованию 8051) такую последовательность разгребёт так как он формирует её с паузами - удлиннённым стопом про которые знает. Ради интереса коротили кратковременно телеметрию и имели только пропуски отдельных байтов.

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

А почему не удлиненный старт? А если анализировать удлиненный стоп, значит осознано игнорировать первый байт данных. И почему пустые поля 0101 а не 1111.
Если речь идет о UART, то можно дополнить обмен управляющими сигналами для "рукопожатия".
Если используется тольколиния данных, то в линию данных как минимум должны подавться в данном случает 10 единичных битов перед массивом данных для установки приемника в начальное состояние
(ожидание перепада из 1 в 0).

К слову, не обязательно - можно и не игнорировать, если принимать решение после приема удлиненного стопа (если байт целый)


Если подытожить, то в конце все равно будет вывод, который в общем формулирается так:
У любого стандарта/протокола есть своя область применения.

А по умному: Решение задачи оптимизации верно при заданных условиях

вот я и пришёл к такому выводу, что сделал свой протокол где на байты не делится и подрят передаётся 128 бит

Это ерунда. Часто и густо сваливал с одного УАРТа в другой потоки с одним стопом. Всё прекрасно разгребалось.
По одной простой причине: принимался первый байт и поток самосинхронизировался. Два стоп-бита, в случае чего, не помогут никак, бо это просто 2 единицы в потоке. И при приёме могут быть сплошные ошибки фрейма, а синхронизироваться не получится. Бо первый-же спад будет опознан как старт и приёмник честно зацепится за середину передаваемого байта. Т.е. в случае рассинхронизации, восстановление - процесс вероятностный. Спасёт только зазор между пакетами на величину, большую байтовой посылки.

2 не спасут а полтора могут - если при передаче не наискажать скважность конечно - то можно найти этот удлинненный стоп

маловероятно. Старт будет от любого перепада, только принимать будет не только с ФЕ по "0" в стопе, но и "честную" ересь по пресловутым "3 мажоритарным выборкам".
Закладываться на такое, что "само рассосётся когда-нить" - себе дороже.

To NIOS:
1. Спору нет, вроде схема рабочая но для дома и оффиса . Для температур (и резких перепадов температур) -60...+120 когда частота генераторов приемника и передатчика начинает гулять, более надежна классическая реализация, с определением середины битового интервала. А это значит лучше сразу делать надежно, чем потом в законченном устройстве при эксплуатации появятся непонятные редкие сбои...

2. Есче один классический вопрос о надежности. Триггера имеют так называемые времена Tsetup / Thold (помоему так называют), те минимально возможное время м/у установкой данных и прохождением тактового и м/у прохождением тактового и временем удержания данных при котором гарантируется его переключение в одно из определенных рабочих состояний. Если времена не выдерживаются, то возможно сваливание выхода триггера в неопределенное состояние (между 0 и 1). Теоретически триггер может долго находится в этом состоянии. Это то, что называют метастабильностью. Для снижения MTBF используют последовательно 2 триггера, на которых прощелкивают все входные сигналы. Если не изменяет память, то у TI в логических сериях есть подобные законченные устройства (те 2 последовательно соединенных триггера).Известный мне специалист высокого уровня, после расчета MTBF ставит 3 последовательно соединенных триггера на каждый вход от различных тактовых доменов. Это я к тому, что ваш МЖ фильтр работает напрямую с сигналом rxd...

1.Для фиксированного количества битов можно заранее вычислить критический набег фазы генератора.
И его уже сравнить с температурным уходом в генераторе. Те в хорошей моделе генератора это все можно просчитать и учесть.

2. Я уже упоминал, что там есть два можаритарных фильтра работающих на разный частотах.
На входе сигнала rxd сразу стоит можаритарный фильтр на тактовой частоте проекта. Он и представляет собой те три последовательных триггера о которых вы упоминали + можаритарность (она фильтрует короткие пички не больше 2-ух периодов тактовой частоты). Можно сказать улучшенная версия с "цифровым фильтром".