Всем доброго.
Ув. эксперты, поскажите, есть ли в виндовых осях возможность обнаруживать ошибки контроля чётности и другие (CE_FRAME, CE_OVERRUN) при получении данных побайтно по последовательному порту ? Пробую тестовую программу - внешним устройством (контроллером) посылается поток байт - часть с ошибкой чётности (точнее, просто с перевёрнутой чётностью), часть - без ошибок. Принимающая часть (программа под виндой) распознаёт только ошибку в самом первом испорченном байте, остальные почему-то молча пропускает - это при приёме через встроенный железный COM порт. При прохождении через виртуальный COM порт (переходник USB<->COM FT232) ещё хуже - не только пропускаются ошибочные байты, но и метятся ошибочными безошибочные данные.
Приём и проверка выполняется вот таким кодом:


Есть код аналогичного назначения под Linux - там всё чётко работает - обнаруживаются все заваленные байты, а правильно отправленные (безошибочные) байты не маркируются как ошибочные, при работе и через реальный и через виртуальный последовательный порт. Можно было бы достичь того же результата в винде ?

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

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

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

Именно так дело и обстоит если не приказали блокировать порт при возникновении ошибки.

Только в том случае, если блоки разделяются паузой (соответственно, тайм-аутом при приеме).

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

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

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

Почему? Там ведь вроде как 2 FIFO. Одно на данные, а другое на их ошибки.
Другое дело, что в большинстве случаев то, к какому конкретно байту относится ошибка не имеет значения - всё равно перепередавать весь блок. Да и вообще, из ошибок актуальна только строка нулей, а вместо остальных CRC лучше работает.

А может 3 FIFO? Или 4 FIFO? Там действительно 2 FIFO - одно для приема и второе для передачи. Давайте, Вы посмотрите документацию, и тогда не придется фантазировать.

Посмотреть документацию, а не заниматься фантазиями - это действительно хороший совет, но это не только ко мне относится...
Вот, что я вычитал в самом начале документа:

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

А так же в FIFO-режиме там в регистре LSR в 7-м бите имеется ошибка RFE, про которую написано:

Вот этот бит не позволят локализовать ошибки...

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

Таки да - в классическом нейшиналовском 16550D такое поминается!



Гарантированные "Паузы" есть - это стоп-старт биты. При ошибках внутренняя логика UART рестартует и осуществляет поиск нового фрейма. Таким образом достоверность байта следующего за сбойным по анализу трех бит (start-parity-stop) гарантируется железом.



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

Именно по этой причине:

То есть все сделано правильно - так, чтобы гарантировать достоверность приема. Зачем автору темы потребовалось обходить это - мне не совсем понятно.

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

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

Бред. 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я в тех-же условиях, например, жутких помех, обычный байт. В чем разница? Только в том, что из-за своей ненормированной паузы Вы еще совсем потеряли битовую синхронизацию.

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

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

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

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

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

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

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

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

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

Взаимно.

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

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

Последний раз. Ложный старт возможен только если в предыдущем байте был сбит стартовый бит. Только, раз Вы так любите рассуждать вероятности, то даже одиночный сбойный бит собьет байтовую синхронизацию в паузе со 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.

Жизнь - есть! Согласен. Но USB в ней места нет . USB живет там где кошечки, брелочки, MP плееры и т п.

Ни в каком проекте никто не не использует USB. Вы что? У отдельных заказчиков вообще требование ни за что не использовать Форточки ни в каком виде.

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

Если вы знаете способ лучше, как восстановить байтовую синхронизацию в непрерывном потоке данных (8N1) то так и напишите, а в бубен постучим параллельно.

По пунктам 1,4,5 - после потери байтовой синхронизации (стартовый бит принимается как бит данных) работать не будет.
П. 2 - таймаут может помехой быть изменён на 0xFF, 0xEF и т.д.
П. 6 не спорный, а вынужденный под win - тоже делал.
Но по теме, с учётом ограничений родного драйвера в win, остаются только 2, 6 (вынужденный) и отчасти 3 (модбас), но там время паузы может стать слишком большим. Да и вообще, модбасу давно на пенсию пора...
Собственно, только 2 то под win и остаётся...

А USB я успешно использую в условиях 6..10кВ * 1..2кА. Работает под lin. Там к хабу без без проблем обратится можно. И если потеряется EOP и хаб отключит мой девайс (в этом ведь проблема USB), то тут-же переподключаюсь и всё - 5 мСек max. Но если нет 5 мСек ограничения, то можно и по win работать - даже со стороны девайса всё решается. Только уже порядка 50 мСек будет.

Дык как же не будет? Это бит данных может быть воспринят как стартовый - я это понимаю.
По этой причине вопросы могут быть к п.1 и 5.
Про п.1 - ничего не скажу, там где использую 9 бит, посылка идет с паузой между байтами.
А п.5 - на символ начала можно наложить ограничения, забив старшие биты единицами.

Действительно кругозор узковат у вас. В наших контроллерах, предназначенных для учета энергоресурсов, которые в т.ч. и в котельных работают , используется USB для снятия журнала. USB заменил FDD, который использовался в предыдущем поколении приборов для той же цели - снятие журналов с удаленных объектов, не имеющих связи. Естественно, что для организации сетевой связи в приборе имеются и RS232 и RS485, посредством которых также можно считывать и журнал и текущие рабочие значения/параметры. То бишь, USB это еще один интерфейс в приборе.

Про кругозор советую помолчать. Выношу вам замечание.
Ну и в моих приборах есть USB дырка. Это кстати не общение , а перенос архива (еще можно конфигурить - но это экзотическая особенность). Ни нафиг она никому не нужна. (Хотя вопрос о FDD в свое врем тоже обсуждался ) Те заказчики, кто архив через USB сливает - их единицы (буквально, хотя есть тоже). По крайней мере все что я видел по объектам - это желание видеть в Москве аж температуру каждого подшипника ( и делаю ведь). И уж тем более предлагать общение с промышленным прибором через USB - глупость какая то. Основные заказчики строят скады . Большие или маленькие, но скады.
Тема топика - что делать при приеме с паритетом. Когда в такую тему влезают с советами использовать USB , нужно тут же банить за глупость.
Вопрос темы непростой - при DOSe все решалось, при винде - стало плохо. Советов по теме было только на первой странице - остальное - междусобойчик. Кстати про запоминание в буфере для каждого байта паритетов для 550 серии я не знал (не надо было и внимания не обращал), надо посмотреть, может и в самом деле запоминает в буфере. В 450, по моему не было. Вот это была полезная часть обсуждения.