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

[_Pasha]

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

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

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

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

[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 мСек будет.