Синхронизация, после сбоя и так будет потеряна с большой вероятностью. Я вам об этом уже устал твердить. И основной вопрос как ее достоверно восстановить. Если это делать по паузе - то получается более или менее надежно. И чем больше запрашиваемая пауза, тем лучше с этой точки зрения. Длительная пауза есть некоторая гарантия того, что временные помехи на линии прекратились, и можно начинать работать.

А сделать паузу в "твержении" и НАКОНЕЦ подумать? Чем отличается искаженный бит в середине байта от всплеска в середине или конце Вашей байтовой паузы? Я бы сказал, что Вы получите ложный старт и худший вариант , нежели битый бит. Ну а в случае искажения стартового бита, что в лоб, что по лбу хоть для байта, хоть для Вашей волшебной паузы.

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

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

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

Ля-ля-ля... продолжаете себя обманывать? Ну и как борьбе с ошибками ДАЖЕ ОДИНОЧНЫМИ помогает волшебная пауза? Никак? Ну а массовыми сбоями - еще хреновее.

Утомили, ей богу своими фантазиями.

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

Повторять сначала?

Взаимно.

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

... и сделает правильные выводы.

Последний раз. Ложный старт возможен только если в предыдущем байте был сбит стартовый бит. Только, раз Вы так любите рассуждать вероятности, то даже одиночный сбойный бит собьет байтовую синхронизацию в паузе со 100% вероятностью, а при посылке байта, только если попадет на ПЕРВЫЙ из 11-12 битов посылки. Вот такие дела, смеющийся без причины Вы наш. Это действительно было последнее разъяснение.

Можно и в последний. Вероятность ложного старта даже при одиночной ошибке, грубо - порядка 10%. А поскольку одиночные ошибки - лишь один из возможных видов ошибок - вероятность ложного старта будет еще выше. Можете сюда добавить еще вероятность появления сбоев в паузах между байтами, так как при асинхронной передаче байты не всегда, и не обязательно, следуют друг за другом без пауз... Если Вы взялись рассуждать о вероятностях...
Возникновение же ложного старта в межфреймовой паузе, просто сделает эту паузу не действительной, и принятый ложный байт будет отброшен...

Аналогично.

А на кой их, пардон, рассматривать? Если не используются коды с исправлением ошибок, то рассмотрение "количественного" содержания ошибок в пакете данных бессмысленно - пакет либо валидный, либо нет. И если не приняты маркеры начала или конца - пакет недействительный, и если к моменту чтения и подсчета CRC взведен флаг ошибки - пакет недействительный. И всем пофигу, сколько там помех проскочило и с какими статистическими характеристиками: неверный пакет - повторить передачу. Хоть до второго пришествия.

Всего хорошо в меру. Под каждую задачу - свой метод. Если мы принимаем очередную фотку с Вояджера, то переспросы бессмыслены и там надо избыточной кодирование с исправлением ошибок. Если мы обмениваемся с устройством на столе или даже в пределах цеха , то там обмен идет четко разграниченными лигическими блоками (запрос ответ). И по любому подозрению на ошибку просто бракуем или запрос или ответ . С этим справляется обычная контрольная сумма в конце. Дополнительно вводить паритеты при этом - полная чушь. Причем вводить их требую протоколы. Пока мы являемся хозяевами положения и пишем свою прогу в контроллере на С - мы все определим, как только встает какая ОС - приплыли - еле еле удается выковырять эту информацию от операционки.


На практике ошибки все же ходят парами. И то что мы на стендах видим и то что глазками - как то этежем ниже велись сварочные работы - обмену - конец. Грозоотметчик Попова в действии.

Реально нам бед больше принесло использование коллегами вставки в RS232 сегмента из локальной сети. Вот круче диверсии никто еще не делал.

А по теме топика - ну только в отдельном потоке ReadFile крутить ожидая приема 1 байта и каждый раз смотреть ошибку (это чтобы конкретно поймать где ошибка паритета). Подозреваю что до 2400 , ну 4800 будет работать, а дальше вопрос.

Ну и "не могу молчать" про предложения обмениваться через USB - чушь полнейшая. Но, это уже коллеги , собственно, отметили.

С USB всё не так страшно. Клавиатуры (HID) и флешки (MassStorage) без проблем работают с любым железом и любой ОС. Вот их то (HID+MassStorage) я и использую для связи с компом.
А во время отладки, но не в изделии, конечно можно использовать UART, но житаг то получше будет. Хотя, ИМХО и без того и другого вполне успешно можно обходится.

А синхронизацию в UART лучше всего не по паузе восстанавливать, а именно по передаче 2-х FF-ов в непрерывном потоке данных. Т.к. в этом случае безошибочный приём FF-а (второго) с весьма высокой вероятностью свидетельствует о восстановлении синхронизации - если помеха 0-й создаст сразу видно. Немного протокол подправить, чтобы пакет с синхронизирующего FF-а начинался и всё. Тогда если этот FF и следующие за ним байты приняты без ошибок, то можно считать, что новый пакет не испорчен. Но на компе при работе через родной драйвер так не сделаешь - ошибки в кучу сливаются.

Не-а. В modbus rtu никаких своих чудес вставлять нельзя в протокол (вставить можно но толку от этого никакого , наоборот еще больше ждать надо будет). Можно только в символьный. Так что, именно пауза, так скажем в 10 интервалов передачи байта на данной скорости, прочищает мозги принимающему UARTU. А лучше еще побольше - это уже чтобы протокольная прога поняла, что больше ей ничего не придет.

В промышленности нигде и никогда USB не использовался и не будет использоваться (ну только иногда в контексте - сунул - скачал - ушел). Со всеми приборами обмен идет по последовательным каналам с реализацией или умощненного RS232 или RS485.

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

Это просто значит, что Ваш кругозор крайне ограничен. Утверждать о не применимости USB, CAN ...., а только знакомого Вам "485 со товарищами" есть просто недалекость.


А еще пофантазировать? А в бубен, постучать? Шаманы рекомендуют.....

Ну ка ну ка. Расскажите: где там в промышленности USB используется, а то может мы не знаем и паримся зря? А CAN я бы с USB вообще не стал в одну кучу валить.

Вот обязательно (иногда на первой же странице иногда к третьей) всплывает кто то с USB. И начинается пурга полная. Причем ясно что человек делал какую то настольную поделку и начинается выдача этого за наше всё. Настоятельно рекомендую сходить в любую котельную хотя бы и посмотреть (если он там вообще есть) как делается обмен с приборами. Или зайти на сайт хотя бы прософта или КотрАвт или Теплоприбора или Метрана или Элемера и посмотреть как делается обмен с приборами.

Равноправные варианты пакетной синхронизации:
1. При 9-битах (не к этой теме, по все же) - прием байта адреса (бит9=1)
2. Посылка BREAK, прочищающего мозги всем и откидывающего на дефолтные настройки
3. По модбасовски - тайм-аут между посылками
4. Преамбула 0х55 (одновременно и автонастройка скорости, кто может)
5. Любой символ, считающийся признаком начала пакета с разруливанием двойного толкования этого символа (эскейп-последовательности).
6. Самосинхронизация за счет длины пакета и контрольной сигнатуры - например, длина пакета не более 10байт, сигнатура, как в далласах(onewire) - пожалста, приняли байт, отсчитали от него назад контрольную сумму в окне, не более длины пакета, если совпало с принятым байтом - пакет принят.
Все это так или иначе делал. Сказать, что какой-нить из методов (особенно спорный №6) - полный ацтой - не скажу. Номер шесть тоже вполне ничего.


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

Ну утешили хотя-бы CAN, как я понял, "использовать в промышленности" Вы разрешили. А USB это совершенно обыденный интерфейс
к PC, в том числе массово используемый для тех-же CAN адаптеров. Не говоря уже о десктопных измерительных приборах.

Да я вижу, какую пургу Вы дежурно понесли

У меня встречное предложение - вылезайте Вы из этой котельной, оглянитесь - за ее пределами тоже есть жизнь и промышленность! И место для USB.