[forever failure 0]

Всем доброго.

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

Приём и проверка выполняется вот таким кодом:

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 1]

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

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

[Гость @Ark]

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

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

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

[forever failure 0]

Тогда можно было-бы переформулировать вопрос:

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

[zltigo 1]

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

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

[_Pasha 0]

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

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

[zltigo 1]

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

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

[forever failure 0]

Ну я тоже так же и предполагал.

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

[_Pasha 0]

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

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

[galjoen 0]

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

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

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

[zltigo 1]

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

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

[galjoen 0]

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

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

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

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

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

 

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

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

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

[Гость @Ark]

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

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

[zltigo 1]

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

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

 

 

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

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

 

 

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

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

[Гость @Ark]

Цитата(zltigo)

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

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

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

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

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