Обнаружение начального бита в программном обеспечении UART


9

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

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

Это неизбежная проблема с каналом UART? Или есть какая-то хитрая уловка, которую производители ОК используют в своих аппаратных UART?


Хороший вопрос. Ваше внешнее устройство непрерывно отправляет символы? Если нет, следует проверить, совпадают ли начальный и конечный биты. А если данные между ними совпадают с вашей проверкой (сумма / бит)?
Пол

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

1
Если последовательный поток не содержит достаточно большой период простоя - ваш юрт вряд ли оправится от этого. Частичное решение может прийти, если вы не получаете бит «стоп» там, где ожидаете. Тогда вы сможете сбросить состояние и повторить попытку.
Евгений Ш.

1
Вам не нужна специальная преамбула ... просто время от времени отдыхать дольше, чем один символ (включая старт, стоп-биты). Или 10+ стоп-битов подряд, что одно и то же.
Брайан Драммонд

2
@Fuaze, внешнее устройство непрерывно отправляет длинный поток символов, но иногда оно простаивает. В худшем случае, я могу просто игнорировать ввод, пока он в первый раз не будет работать.
Дэн Лакс

Ответы:


5

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

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

Имейте в виду, что число битов данных должно быть предсказуемым, как и размер кадра, поэтому даже если вы используете 100% пропускной способности шины, а ваш стоп-бит занимает один бит, вы все равно сможете найти начать бит, если вы соберете достаточно кадров. Каждый кадр гарантированно имеет переход hi-lo в нем. Стоп-бит всегда высокий. Стартовый бит всегда низкий. Предполагая, что ваши данные случайные (или достаточно случайные), вы можете сделать что-то простое, например создать буфер размером вашего кадра, установить каждый бит в нем, а затем продолжать собирать кадры и вставлять их в этот буфер, пока в буфере не будет только 1 бит установлен. Этот бит ваш стоп-бит. Следующий за ним - ваш стартовый бит. Вуаля! Вы нашли это.

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


Идея аккуратно объединять кадры до тех пор, пока не выживут только биты начала и конца. Это будет слишком много для моего конкретного приложения, но, тем не менее, умно.
Дэн Лакс

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

Этот комментарий не был сделан в то время, когда я начал писать этот ответ. Тем не менее, остальные три опции, которые я перечислил, по-прежнему применяются в случае, когда длина стопового бита фиксирована
Доктор Функ

3

Аппаратные UART имеют ту же проблему. Но обычно это тот, который решает себя в короткие сроки в любом случае. В конце каждого кадра проверьте стоп-бит, и, если он не высокий, сбросьте кадр и дождитесь следующего перехода с высокого уровня на низкий. Предполагая, что данные из источника не являются полностью патологическими (например, длинные строки «UUUU» или ASCII 0x55), UART в конечном итоге «переходит» к реальному начальному биту.


1

Предполагая передачу 8N1.

Вы должны ждать строку из 9 старших или младших битов подряд.

Если он высокий, это будет означать либо разрыв в данных, либо символ 0xFF и бит STOP,
либо
низкий бит START и NULL 0x00.

Любое из этих условий разрешит повторную синхронизацию.

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

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

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