[Arlleex 189]

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

Итак, допустим есть UART (скорость не важна, но для примера пусть будет 921600) 8-N-2. Поток байтов, который отправляет передатчик, по времени не детерминирован (по сути, активность на линии может случаться произвольно). Приемник же (на другой стороне) технически допускает возможность "горячего подключения". Т.е. по разным причинам его приемный UART может включиться в любое время (например, из-за перезагрузки устройства по WDT или еще почему). Существует вероятность неправильной синхронизации приемника с байтовым потоком, и принятия "мусора" за полезные символы. Хорошо, если поток данных не сплошной (рано или поздно приемный UART обнаружит ошибку фрейминга и внутренние алгоритмы работы ПО могут сбросить этот мусор). А если сплошной? Может, есть какая-то секретная таблетка для таких случаев?

[aaarrr 69]

14 minutes ago, Arlleex said:

Может, есть какая-то секретная таблетка для таких случаев?

Byte stuffing.

[haker_fox 61]

4 minutes ago, aaarrr said:

Byte stuffing.

+1. Я бы сказал у этого способа просто поразительные возможности к синхронизации приёмника с передатчиком.

18 minutes ago, Arlleex said:

Может, есть какая-то секретная таблетка для таких случаев?

В принципе мне хватает слегка "генномодифицированного" под свои цели Wake от Ридико Леонида Ивановича. Но модификация совершенно не связана с механизмом byte stuffing.

[ViKo 1]

Старт, четность, стоп - эти биты тоже помогают определить неправильную интерпретацию данных. 

[Arlleex 189]

Стаффинг - это уже протокольная штука. Кстати, не уверен, что на сплошном потоке может помочь в 100% случаев.

5 минут назад, ViKo сказал:

Старт, четность, стоп - эти биты тоже помогают определить неправильную интерпретацию данных. 

Ну как сказать... Сейчас воткнул Rx FT232 к МК, который непрерывно отправляет 0xEF. Теперь, если в процессе работы отрывать и соединять снова проводок данных, данные в терминале либо 0xEF (что верно), либо 0xDF (причем постоянный прием). Т.е. тут ни стопы (их итак уже 2), ни четность (на таких данных она одинаковая) не помогут.

[MegaVolt 29]

18 минут назад, haker_fox сказал:

В принципе мне хватает слегка "генномодифицированного" под свои цели Wake от Ридико Леонида Ивановича. Но модификация совершенно не связана с механизмом byte stuffing.

Так протокол уже содержит byte stuffing о чём явно сказано в описании протокола.

[ViKo 1]

5 минут назад, Arlleex сказал:

Ну как сказать... Сейчас воткнул Rx FT232 к МК, который непрерывно отправляет 0xEF. Теперь, если в процессе работы отрывать и соединять снова проводок данных, данные в терминале либо 0xEF (что верно), либо 0xDF (причем постоянный прием). Т.е. тут ни стопы (их итак уже 2), ни четность (на таких данных она одинаковая) не помогут.

Я диаграммы нарисовал. При двух стопах они разные.

[jcxz 242]

50 минут назад, Arlleex сказал:

Существует вероятность неправильной синхронизации приемника с байтовым потоком, и принятия "мусора" за полезные символы. Хорошо, если поток данных не сплошной (рано или поздно приемный UART обнаружит ошибку фрейминга и внутренние алгоритмы работы ПО могут сбросить этот мусор). А если сплошной? Может, есть какая-то секретная таблетка для таких случаев?

Существует конечно и давно известная: Кодонезависимая передача данных  http://adminbook.ru/index.php?men1=2/81

Кодонезависимые протоколы обмена: SLIP, COBS, ASCII-Hex и т.д. Вобщем-то даже AT-командные протоколы GSM-модемов или там того же ESP8266 - кодонезависимы (если корректно реализованы).

Кодонезависимость достигается экранированием управляющих символов из потока символов данных. Методы экранирования разные: может быть и байт-стаффинг и другие методы.

33 минуты назад, haker_fox сказал:

+1. Я бы сказал у этого способа просто поразительные возможности к синхронизации приёмника с передатчиком.

COBS значительно лучше имхо. Так как не имеет главного недостатка байт-стаффинга: большого оверхеда выходного потока кодировщика при определённых кодовых комбинациях во входном потоке.

У COBS оверхед = const. Это огромный +

[Arlleex 189]

Кстати, пример.

Передатчик сплошным потоком отправляет байт-стаффинговый кадр "C0 EF EF EF EF C0".
В одну из "неудачных" активизаций приема у FT232 ловлю данные следующего содержания

Цитата

002111 11:58:24.850  EF EF C0 C0 EF EF EF EF C0 C0 0F BC DF DF ïïÀÀïïïïÀÀ.¼ßß
002112 11:58:24.947  DF 1F 78 F0 EF EF EF FF D8 C0 EF EF FF EF ß.xðïïïÿØÀïïÿï

Ну да, спасут контрольные суммы протокола верхнего уровня, это все понятно.
Но можно ли обеспечить непопадание такого мусора в приемный FIFO парсера того же стаффинга?

Вангую, нет.

[jcxz 242]

26 минут назад, Arlleex сказал:

Стаффинг - это уже протокольная штука. Кстати, не уверен, что на сплошном потоке может помочь в 100% случаев.

Если реализован без ошибок - поможет 100%. Это как 2*2.

8 минут назад, Arlleex сказал:

Но можно ли обеспечить непопадание такого мусора в приемный FIFO парсера того же стаффинга?

Не очень понятно - при чём тут байт-стаффинг? Мусор этот у вас кто генерит? Кто-то на линии? Вот с ним и разбирайтесь. Если не удаётся - остаётся надеяться на CRC и увеличивать её стойкость (вплоть до хешей).

А байт-стаффинг тут вообще не при чёи. Он для другого вообще-то: для выделения границ кадров из потока байт. А не для борьбы с мусором. Мухи - отдельно, котлеты - отдельно.

[Arlleex 189]

16 минут назад, ViKo сказал:

Я диаграммы нарисовал. При двух стопах они разные.

Стопы не учитываются при расчете паритета.

[ViKo 1]

2 минуты назад, Arlleex сказал:

Стопы не учитываются при расчете паритета.

Диаграммы разные, не совпадают.

[Arlleex 189]

47 минут назад, ViKo сказал:

Я диаграммы нарисовал. При двух стопах они разные.

И я нарисовал, при передаче слошных 0xEF и сбое синхронизации будет приниматься 0xBF. 2 стоп-бита и включенная четность. Проверил в железе - так и есть.

[ViKo 1]

Да, для EF и BF будет совпадать. Выше вы писали про DF.

[Arlleex 189]

4 минуты назад, ViKo сказал:

Да, для EF и BF будет совпадать. Выше вы писали про DF.

Посмотрите внимательно, DF это неправильная интерпретация EF при выключенном паритете.
 

42 минуты назад, jcxz сказал:

Если реализован без ошибок - поможет 100%. Это как 2*2.

Только при условии, что приемник UART правильно синхронизировался с передатчиком (старт-бит передатчика взялся в расчет приемным UART-ом именно как старт-бит нового байта). А при горячем подключении это может оказаться далеко не так. Старт-битом для приемника может оказаться и любой нулевой бит в середине байта, если приемник активизировался именно в этот момент.