Про правильно ничего не понял - автор периодически в произвольный момент вычитывает байт УЖЕ ИЗ софтового буфера, неведая сколько байт-килобайт в этом буфере лежат и при этом считывает флаг признака ошибки, который мог быть взведен (в том числе и многократно) при заполнении этого буфера и сбрасывает его.

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

Бред. UART оперирует исключительно байтами и совершенно спокойно выделяет следующий БАЙТОВЫЙ ФРЕЙМ. По фрейму медленно и печально перечитайте пост #14

Изложите, тогда, "свой бред". Сравним.
...

Вот это действительно бред. После сбоя ничего уже не гарантируется... Медленно и печально перечитайте пост №3.

Гарантируется с того момента, как будет принят байт 0xFF (при отсутствии контроля чётности или с той чётностью когда 0xFF передаётся в виде только стартового бита). Поэтому жел-но в протоколе периодически вставлять в передачу по два FF-а - второй из этих FF-ов обязательно примется правильно. Например, каждый пакет с них начинать. Это гарантирует восстановление синхронизации даже в непрерывном потоке данных. А потом можно перепередать только разрушенные пакеты, а не всё...
Но вот из-за того, что ошибки в win хранятся не на каждый принятый байт (хотя железо 16550 это позволяет), там использовать такую фичу невозможно. Тем более с переходником USB-COM (там и железо не позволяет). А в передачах между МК можно и нужно использовать...

А вот BREAK (достаточно долгий) можно использовать и под win.

Вот именно эти Ваши "гипотезы" о том, что в течении времени образуется разрыв, куда пропадают биты я и называю бредом.


Для восстановления БАЙТОВОЙ синхронизации глубоко безразлично по какому байту восстанавливаться.


1. Позволяет с оговорками.
2. Вы читаете НЕ из железа, а из многокилобайтовых буферов операционной системы - тогда и их пришлось-бы расширять.
3. Пишите свои драйвера - никто не запрещает.

Что в вашем понимании значит БАЙТОВАЯ синхронизация? Я так считаю, что БАЙТОВАЯ синхронизация имеется, когда стартовый бит принимается именно как стартовый, а не как бит данных. Вот это гарантированно произойдёт после появления в линии 2-х последовательных байтов FF (после сбоя синхронизации правильно примется только 2-й). А вот передача байтов 0xAA - самый худший вариант для восстановления байтовой синхронизации.

2. Многокилобайтовые буфера стали бы в 2 раза больше, если бы в них было по 2 байта на каждый принятый байт. По современным меркам это мизер.
3. Драйвера писать не буду. На мой взгляд использование USART в компе, при наличии там USB хоста, это анахронизм. Сейчас, при появлении 3-х долларовых МК с USB девайсом на борту использование RS-232 для подключения к компу лишено всякого смысла.
Протоколы на базе USART стоит использовать только для связи между МК, при только при соединении точка-точка. А в остальных случаях там CAN лучше, хотя он и пока (!) несколько дороже.

Ксати да, тоже ожидал, что обязательно появится некто, кому череп жмёт, с полезными советами использовать CRC вместо чётности, CAN или USB вместо RS232/RS485, молоток вместо отвёртки, и другими глубокими мыслями. Напомню: про всё, что хотелось бы выяснить - спрашивалось в первом посте. Про црц, кан, усб и забивание шурупов - в другой раз.

Ну а если подумать о том, какое количество софта, с каким количеством ошибок и какой зависимостью от окружения требуется для облуживания USB? Нужен, например, отладочный интерфейс - при вылете системы через USB стек Вы почти наверняка вообще ничего не увидите. UART, как минималистичная штучка будет востребован еще очень и очень долго.

Практически уже нет и использование UART для организации сетей в стиле 70х годов прошлого века уже не оправдано.



Вынужден заметить, что "глубокую мысль" использовать Бит-UART-молоток и, полагаю, PIC/AVR до кучи, вместо "отвертки" высказали именно Вы.

Замечательно. А я называю бредом Вашу уверенность в том, что после ошибочного приема байта, стартовый бит следующего байта непременно останется неповрежденным, и синхронизация не будет нарушена. Я думаю, мы определились с позициями.

Жаль, что вы не способны понять, как работает реальный контроллер UART и пытаетесь подменить его своими чрезмерно вульгарными представлениями.
Категорическое непонимание того, что, как минимум, в пределах одного байтового фрейма контроллеры работают в СИНХРОННОМ режиме порождают у Вас совершенно искаженную картину реальности . Контроллер UART совершенно спокойно выделяет одиночные ошибки и восстанавливается при одиночных ошибках в байтовых фреймах. Для работы в непрерывном потоке ошибок оно просто не предназначен и это принципиально.

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

Вот именно, только в одном этом конкретном случае - из всего множества ситуаций, которые реально могут случиться на линии. Это лишь частный случай, "закладываться" на который в реальных условиях - просто наивно.

Никто и не претендует. Речь идет о правильной (надежной) обработке ошибок. В частности, не допускающей недостоверную передачу, если вдруг на линии появился их "непрерывный поток".

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

... главное, что я не получу недостоверную информацию. И даже не буду пытаться работать в этом "слошном потоке дерьма". Мне этого вполне достаточно.

С чего-бы это вдруг? Ваша волшебная байт-пауза превратилась в какие-то непонятные биты. В такие-же непонятные биты превратилcя в тех-же условиях, например, жутких помех, обычный байт. В чем разница? Только в том, что из-за своей ненормированной паузы Вы еще совсем потеряли битовую синхронизацию.