Ну так поставьте себя на место UARTa. Вот в линии нулевой уровень. Долго. Так долго, что даже длиннее байта на скорости 100 бод. И вдруг перепад. Это начался старт-бит. Дальше остаётся только мерить время между перепадами и соображать, где бит, где байт, где пауза (если есть!) - после неё будет старт-бит.
Заметьте, что задачка распадается на две: когда на борту есть кварц и вы можете прикинуть длительность принятых бит к стандартному ряду скоростей, или когда есть RC генератор и вы не знаете, сколько, образно говоря, тиков таймера пойдёт на бит при скорости 9600.
Ну и, конечно, "произвольные данные" должны быть ограничены требованиями протокола. Не представляю себе полностью неопределённый поток - разве что когда подслушиваешь кого-нибудь
Кстати, очень интересно было нарваться на поток данных без пауз, по RS485. Отлично принималось, начиная с произвольного нулевого бита в байте, и при изменении полярности - тоже, всего лишь с инверсией!

в принципе, для абсолютно неизвестного потока данных можно долго слушать линию, замеряя длительность всех сигналов и выбирая наименьший - это и будет длителность одного бита - по ней скорость и восстанавливать... хотя все равно возникает другая сложность - определение длины кадра - 8 бит данных или 9...

В моём посте абсолютно подробно, по пунктам расписано. Я не привязываюсь к конкретному байту. Я восстанавливаю любой.
При этом надо понимать, что есть байты которые (за 1 байт) не могут быть восстановлены. Надеюсь это понимает каждый?

Для Maik-vs, в линии изначально 1 и старт-бит приходит 0. Далее если вы распишете например байт 0xf0(на 115200), то вы поймёте, что он может быть 0xf0 на 115200, или 0xfc на 57600 или 0xfe на 28800 или 00 на 230400.

Для начала надо понять что для произвольного входного потока понадобятся от
1 до ~9-11 байт входного потока для первоначальной синхронизации,
если вас устроит синхронизация по такой последовательности, тогда можно обсуждать дальше...

Уточнение, для совсем произвольного входого потока(это когда промежутки между байтами
неопределенные), скорее всего нужно как минимум ~ 20байт для первоначальной синхронизации,
а дальше только один вопрос, а оно надо... ???

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

Если рассматривать, что принимается посылка, то есть сначала линия неактивна и вот пошёл первый байт, то тогда я описал ситуацию, правда я там немного ошибся - ну да ладно. Это не принципиально. Главное что существуют символы где будет один импульс. В этом случае нельзя достоверно по одному байту определить скорость. Но таких символов очень мало. Примерно 99% будут восстановлены грамотно. Если же стоит задача полностью определить 100% символов, то выход - полностью программный анализ входного протокола. Я уверен, что на скорости >=8МГц при том, что однокристалка будет занята этой задачей, я бы восстановил любую многобайтовую посылку от 300 бод до 115200.

Для непрерывного потока как раз все просто, Вы забываете в своем анализе что
всегда стартовый бит это переход 1->0 а стоповый наоборот.
ну и нужно конечно успет накопить статистику(может за 1 байт а может и за 20)

Только есть шанс необнаружить этот стоп бит а засинхронизароваться посреди байта и благополучно принимать послудующую инфу неправильно. Здесь как раз тема была. Парень передавал 55 а получал что угодно в зависимости от удачности врезания.

Я тоже считаю,что для определения скорости на лету с полным восстановлением данных и без байта синхронизации - задача под rs232 практически нерешаема.

Так,для самоуспокоения,хотел посоветоваться,может кто-то знает путь решения задачи.
Всё-равно,спасибо всем за идеи.

Я это понимаю, про f0 - fc - fe. Насмотрелся . А про 0 и 1 приучен не говрить, лучше уж говорить в терминах уровней "высокий-низкий". Потому что когда работал с ТТЛ и ЭСЛ, д аещё и интерфейсы - тады ой.

Я имел в виду что скорость потока за ~20 байт мы можем выяснить гарантированно.
Для синхронизации конечно нужны паузы в потоке или достаточно длительное накопление
статистики и сдвиги на 1 бит до получения потока с правильными
стоп битами(наименьший % ошибок кадра).

Формат передачи 8-N-1, неприрывная серия байт:
0x55 @ speed 1x ничем не отличается от 0x0F @ speed 5x
0xF8 @ speed 1x -//- от 0xCE @ speed 2x
0x08 @ speed 1x -//- от 0x80 @ speed 2x
Т.е. нельзя выяснить скорость произвольного потока ни за 20 байт, а вообще нельзя, если в нём встречаются только две длительности нулей и единиц - 1/1, 2/3, 1/5, как в приведённых выше примерах.

Я согласен что есть несколько вырожденных случаев при которых передается
один неизменный байт, наверное слово "гарантированно" было не совсем правильным.
Если же байты изменяются то определить скорость практически всегда возможно...

Делал автобауд для USART и для CAN (AT90CAN128). Подобно тому, как писал SasaVitebsk.
Отличие в том, что у меня процессор был занят, и пришлось использовать входы захвата таймеров. Один захватывал фронт, другой спад (прерывание от обоих). Получалась длительность нуля или единицы. Далее, по заранее рассчитанной таблице, прибавлял баллы накопителям (одному или нескольким), соответствующим скоростям от 1200 до 115200 бод. Причём, если длина соответствовала скорости неточно - баллов добавлял меньше (SasaVitebsk, а как вы дейсвовали в таком случае?). Скорость считалась определённой, когда один из накопителей переполнялся. Какой первым переполнился - такая и скорость. Конечно я согласен, что можно найти такие данные на которых данный алгоритм проколется, но в реальности я с этим не сталкивался.
Кстати в случае CAN такой алгоритм (ну несколько модифицированный) всегда безошибочно срабатывает с 1й посылки.

Скачайте с gaisler.com библиотеку grlib-gpl
Там как как раз в DSU UART есть автоопределение