Обнаружение ошибок чётности и др. при приёме ч/з COM порт, В винде Опции

[forever failure]

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

CODE

static int read_byte (HANDLE handle, uint8_t * byte)
{
uint8_t b;
DWORD ret;

if (!ReadFile (handle, &b, 1, &ret, 0))
return -1;

if (0 == ret)
return 0;

DWORD err;
ClearCommError (handle, &err, 0);

if (err)
{
fprintf (stderr, "\nComm Error: ");
fprintf (stderr, CE_FRAME & err ? "F" : "-");
fprintf (stderr, CE_RXPARITY & err ? "P" : "-");
fprintf (stderr, CE_IOE & err ? "I" : "-");
fprintf (stderr, CE_OVERRUN & err ? "O" : "-");
fprintf (stderr, CE_RXOVER & err ? "B" : "-");
fprintf (stderr, " = %02X ", b);
return -2;
}

*byte = b;
return 1;
}

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

[zltigo]

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

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

[Guest_@Ark_*]

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

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

[forever failure]

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

[zltigo]

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

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

[_Pasha]

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

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

[zltigo]

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

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

[forever failure]

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

[_Pasha]

С чего-бы это вдруг.

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

[galjoen]

железо 550 совместимого порта принципиально не способно в потоке, при включенном FIFO локализовать ошибку в конкретном байте.

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

[zltigo]

Почему? Там ведь вроде как 2 FIFO. Одно на данные, а другое на их ошибки.

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

[galjoen]

Давайте, Вы посмотрите документацию, и тогда не придется фантазировать.

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

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

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

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

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

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

[Guest_@Ark_*]

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

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

[zltigo]

Вот, что я вычитал в самом начале документа:

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

вплоть до появления паузы при приеме.

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

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

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

[Guest_@Ark_*]

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

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

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

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

[zltigo]

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

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

[Guest_@Ark_*]

Про правильно ничего не понял...

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

[zltigo]

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

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

[Guest_@Ark_*]

Бред.

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

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

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

[galjoen]

После сбоя ничего уже не гарантируется...

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

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

[zltigo]

Медленно и печально перечитайте пост №3.

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

Гарантируется с того момента, как будет принят байт 0xFF

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

Но вот из-за того, что ошибки в win хранятся не на каждый принятый байт (хотя железо 16550 это позволяет)

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

[galjoen]

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

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

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

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

[forever failure]

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

[zltigo]

Сейчас, при появлении 3-х долларовых МК с USB девайсом на борту использование RS-232 для подключения к компу лишено всякого смысла.

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

Протоколы на базе USART стоит использовать только для связи между МК, при только при соединении точка-точка. А в остальных случаях там CAN лучше, хотя он и пока (!) несколько дороже.

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

молоток вместо отвёртки, и другими глубокими мыслями.

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

[Guest_@Ark_*]

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

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

[zltigo]

А я называю бредом...

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

[Guest_@Ark_*]

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

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

Контроллер UART совершенно спокойно выделяет одиночные ошибки и восстанавливается при одиночных ошибках в байтовых фреймах.

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

Для работы в непрерывном потоке ошибок он просто не предназначен и это принципиально.

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

[zltigo]

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

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

[Guest_@Ark_*]

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

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

[zltigo]

... главное, что я не получу недостоверную информацию.

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

[Guest_@Ark_*]

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

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

[zltigo]

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

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

Длительная пауза есть некоторая гарантия того, что временные помехи на линии прекратились, и можно начинать работать.

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

[Guest_@Ark_*]

А сделать паузу в "твержении" и НАКОНЕЦ подумать?

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

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

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

[zltigo]

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

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

Есть высокая вероятность, что помехи прекратились

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

И разница в том, что "битая" пауза - это уже не пауза.

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

[Guest_@Ark_*]

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

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

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

Взаимно.

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

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

.. Написано много, и имеющий разум, да поймет...

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

[zltigo]

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

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

[Guest_@Ark_*]

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

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

Это действительно было последнее разъяснение.

Аналогично.

[_Pasha]

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

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

[firstvald]

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


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

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

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

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

[galjoen]

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

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

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

[firstvald]

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

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

[zltigo]

А во время отладки, но не в изделии, конечно можно использовать UART, но житаг то получше будет.

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

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

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

А синхронизацию в UART лучше всего....

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

[firstvald]

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

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

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

[_Pasha]

А синхронизацию в UART лучше всего

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

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

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

[zltigo]

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

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

Вот обязательно (иногда на первой же странице иногда к третьей) всплывает кто то с USB. И начинается пурга полная.

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

Настоятельно рекомендую сходить в любую котельную

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

[firstvald]

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

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

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

[galjoen]

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

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

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

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

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

По пунктам 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 мСек будет.

[_Pasha]

По пунктам 1,4,5 - после потери байтовой синхронизации (стартовый бит принимается как бит данных) работать не будет.

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

[rezident]

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

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

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

[firstvald]

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

[galjoen]

А п.5 - на символ начала можно наложить ограничения, забив старшие биты единицами.

По п. 4 передача первым символа 0x55 это хорошее решение, но не для приёма компом. МК может 0x55 вообще с помощью входа захвата принять и настроится, а комп - нет. Для компа лучше уж 0xFF передавать. Как, собственно, и по п. 5. Но два 0xFF подряд будет ещё лучше.

Тема топика - что делать при приеме с паритетом.

Ничего не делать - отказаться от паритета как от устаревшего и неэффективного решения. Паритет, этот CRC1 - совершенно неэффективен. Если принимается от 10 байт, то CRC8 на все эти байты займёт времени меньше, чем паритет. А уж эффект несравнимо выше будет. А CRC16 и CRC32 с CRC1 даже и сравнивать смешно...

[_Pasha]

отказаться от паритета как от устаревшего и неэффективного решения.

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

Код

b0  b1  b2  p1
b3  b4  b5  p2
b6  b7  b8  p3
p4  p5  p6  p7

p[i] - это биты полученные путем xor по строкам и столбцам. Такой блочок данных позволяет восстановить все одиночные и часть двойных ошибок. Если совсем не фантазировать, то

Код

b0 b1 p1
b2 b3 p2
p3 p4 p5

такой блочок (р5 - паритет) позволяет исправить все двойные ошибки
Извините за оффтоп.

[galjoen]

p[i] - это биты полученные путем xor по строкам и столбцам.

Это называется поблочный контроль чётности. Он низкоэффективен и бессилен против ошибок возникающих в чётном кол-ве строк. А использовать для восстановления 4-х бит данных 5 дополнительных бит - это уже слишком. Есть методы получше.
Насчёт поблочного контроля в частности, и насчёт обнаружения и исправления ошибок вообще, очень хорошо и понятно написано тут: Р.Л.Хаммел Последовательная передача данных.

[firstvald]

Первый раз с проблемой паритета столкнулись, когда появилась 95 форточка, а надо было делать новое поколение медицинского прибора, в котором до этого дня непрерывно валились данные в сыром виде , а начало кадра обозначалось выставленным паритетом. Решили не заниматься фигней и перепаковали передаваемые данные в байты (вот там как раз и можно было сделать групповой бит проверки), а паритет ессно использовать никак.

Потом паритет всплыл когда пришел modbus. Тут ограничились обнаружением ошибки в принимаемой посылке (собственно после ReadFile читаем ошибку и смотрим есть ли она). Но задачу приема с получением информации о паритете в каждом байте так и не решили (и нафиг не нужно было). Хотя возможно она и решаема для всего диапазона скоростей.

С кадрированием (тут тащат не нравящийся мне термин "синхронизация")вот как раз столкнулись когда валится непрерывный поток данных без всяких перерывов. Да только перерыв более чем несколько интервалов передачи байта спасет, а никакие 55 или ff. Пока автомат в UART не отработает цикл - бесполезно что-то делать (значит нужно хотя бы 2 интервала передачи байта подождать), а в компе как правило еще буферизация включена.

Кстати говоря, заглянул в описание (exar)16с550, так там ничего про хранение в FIFO ошибок (паритета) нет. Так что, скорее всего, есть разные 550 и, вообще говоря, что на самом деле сделано в большой микросхеме в компе (когда пишут 550 совместимый UART)- совершенно не ясно. Скорее надо ориентироваться - что сделано, как делалось вначале - в FIFO пишется только данные , а флаг ошибки выставляется скопом для всего FIFO.

[_Pasha]

Пока автомат в UART не отработает цикл - бесполезно что-то делать (значит нужно хотя бы 2 интервала передачи байта подождать)

Стоп. Автомат в уарт отбрыкнется после ложного старта максимум через 0,5 битового интервала. Инфа об испорченном байте появляется апостериорно. Что еще надо для жизни?

[firstvald]

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

Про паритет. Кто - нибудь чего придумал ?

[galjoen]

А если старт не ложный? Вот и начинается мешанина и конца и краю ей бывает не видно.

Мешанина закончится сразу после того, как в линии появится неповреждённый байт 0xFF (говорим про формат 8N1 и непрерывный поток данных). Сам этот 0xFF будет принят неправильно, точнее его вообще не будет, но в какой бы момент не был принят ложный стартовый бит (он может быть только раньше стартового бита 0xFF) , 9-ти единиц подряд (8 бит данных и 1 стоповый бит) хватит, чтобы следующий стартовый бит воспринялся именно как стартовый, и с этого момента всё пойдёт нормально до следующего сбоя байтовой синхронизации.

Кстати, к сбою байтовой синхронизации в непрерывном потоке 8N1 может привести только 2 случая:
1. Стоповый бит =0 (соединится со следующим стартовым) , но тогда будет ошибка кадра.
2. Стартовый бит =1. Тогда никаких ошибок не будет (пока на место стопового не попадёт 0).

[_Pasha]

А если старт не ложный?

Все, я устал. Извините за компанию.

[firstvald]

Согласен