Обнаружение ошибок чётности и др. при приёме ч/з 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 мСек будет.

[_Pasha]

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

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

[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 дополнительных бит - это уже слишком. Есть методы получше.
Насчёт поблочного контроля в частности, и насчёт обнаружения и исправления ошибок вообще, очень хорошо и понятно написано тут: Р.Л.Хаммел Последовательная передача данных.