Обнаружение ошибок чётности и др. при приёме ч/з 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 - там всё чётко работает - обнаруживаются все заваленные байты, а правильно отправленные (безошибочные) байты не маркируются как ошибочные, при работе и через реальный и через виртуальный последовательный порт. Можно было бы достичь того же результата в винде ?

[Guest_@Ark_*]

Бред.

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

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

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

[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 лучше, хотя он и пока (!) несколько дороже.

[zltigo]

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

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

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

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

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

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

[galjoen]

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

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

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