Обработка ошибок UART


8

Я не концентрируюсь на конкретном MCU, поскольку UART большинства контроллеров имеет схожую архитектуру. У них есть FIFO для Tx и Rx.

Наиболее распространенными ошибками, генерируемыми UART, являются: - 1. Ошибка кадрирования 2. Ошибка четности 3. Ошибка переполнения (переполнение FIFO Tx / Rx) 4. Ошибка прерывания приема (некоторая ошибка со стоп-битами)

Как следует обращаться с этими ошибочными условиями, чтобы поддерживать связь должным образом?

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

Ответы:


6

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

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

Стивен дал вам несколько хороших идей, что с этим делать на более высоком уровне. Когда вы думаете, что существует реальная вероятность ошибок и важна целостность данных, вы обычно инкапсулируете порции данных в пакеты с контрольными суммами. Получатель отправляет ACK для каждой правильно полученной контрольной суммы.

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


9

Эти ошибки не могут быть исправлены, поэтому требуется повторная передача. Для этого нужен протокол на более высоком уровне, чем UART; вы обычно хотите подтвердить правильность приема пакета данных. Этот пакет может составлять 1 байт, но также могут использоваться более длинные пакеты, если в связи есть небольшие ошибки. Подтвердите каждый пакет, отправив ACK на передатчик, NACK, если произошла ошибка. В последнем случае отбросьте пакет и дождитесь повторной передачи.
Если вы используете передачу пакетов, вы можете рассмотреть проверку ошибок CRC вместо четности, которая не очень эффективна (добавляет 1 бит на байт) и перехватывает только однобитовые ошибки.


3

Когда в принятых данных UART возникает ошибка кадрирования, велика вероятность того, что все последующие байты станут мусором до тех пор, пока, в зависимости от UART, между последовательными падающими фронтами в канале данных не будет десять или более битов, девятнадцать битов между последовательным интервалом или девятью битами последовательной маркировки (последний из них будет работать на всех UART). Если получен байт с правильным кадром со значением 0x00 или 0x80 (0x100 в 9-битном режиме) и либо передатчик не отправляет длинные перерывы, либо приемник перестанет пытаться анализировать байты из любых длинных перерывов, отправленных передатчиком, можно будьте уверены, что это правильно, и последующие байты также будут правильными. Если кто-то получает значение, в котором есть 0-6 последовательных «нулей» в младших битах, и все остальные биты установлены,

S = START P = данные предыдущего байта s = останов D = текущий байт - = холостой ход
0111111101000000011111 - Сигнал на линии
Ps ------ SDDDDDDDDs ---: по назначению передатчика (0x02)
SPPPPPPPPsSDDDDDDDDs-: как получено (0xC0)

Если каждый пакет начинается с 0x00 и сопровождается 0xFF, ошибка кадрирования в одном пакете не повлияет на следующий. Когда получатель замечает ошибку кадрирования, он может начать отбрасывать данные до тех пор, пока не увидит правильно сформированный 0x00, после чего он узнает, что у него есть законное начало пакета.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.