[VoltageCurrent 0]

Как известно, в UART могут быть один, полтора или два стоп-бита.

 

Если оговорена передача с одним стоп-битом, то всё относительно просто. При длине символа N (5...8 бит) устройство считывает N+1 бит по середине каждого бита и далее возможно два варианта:
1. Если до этого в символе передавались в том числе единицы, то это - ошибка передачи.
2. Если до этого в символе были только нули это - break frame.

 

С двумя стоп-битами уже не совсем ясно. Считывается N+2 бита по середине каждого из них, а далее варианты:
1. Если оба стоп-бита единицы, то успех.
2. Если оба стоп-бита нули - это, вероятно, break frame.
3. Если первый стоп-бит - единица, а второй ноль, является ли это ошибкой передачи (если все биты в символе равны нулю)?
4. Если первый стоп-бит - ноль, а второй единица, является ли это ошибкой передачи (если все биты в символе равны нулю)?

 

И, наконец, полтора стоп-бита. Если биты будут считываться в середине интервала, то считав N+1 бит устройство не отличит передачу с полутора стоп-битами от передачи с одним стоп-битом. Если производить считывание не только в середине битов, но и, так скажем, на их стыках, то это тоже не будет особо информативным: то есть устройство увидит середину первого стоп-бита, его "стык" с половинкой стоп-бита и конец этой половинки. Предположим, устройство считало "...xxx110", значит ли это, что полтора стоп-бита произошли и всё отлично? Получается, для надёжной обработки ошибок конца символа следует производить чтение 4 раза за бит, но такой подход кажется перетяжелённым.

 

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

[jcxz 384]

В 12.08.2022 в 16:28, VoltageCurrent сказал:

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

Если Вы немного получше почитаете про механизм работы UART, то узнаете, что он производит сэмплирование входного сигнала как правило 16 раз за бит. И только некоторые реализации опционально позволяют снижать величину оверсэмплинга до 8.

[V_G 49]

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

[sazh 12]

В 12.08.2022 в 16:28, VoltageCurrent сказал:

Как известно, в UART могут быть один, полтора или два стоп-бита.

Если оговорена передача с одним стоп-битом, то всё относительно просто. При длине символа N (5...8 бит) устройство считывает N+1 бит по середине каждого бита и далее возможно два варианта:
1. Если до этого в символе передавались в том числе единицы, то это - ошибка передачи.
2. Если до этого в символе были только нули это - break frame.

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

Обычно UART - это точка - точка. И наверно важно, на какой платформе он реализуется.

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

Боле того UART обычно используют в старт стопном режиме исходя из того, что пауза в линии это эквивалент стоп бита (логическая 1). Поэтому сколько стоп бит, 1 или 1.5 - 1000, не имеет значения, все укладываются в 1 стоп бит, а наличие логического нуля на месте стоп бита - это ошибка кадрирования и посылка считается не корректной. И автомат состояний переводят в состояние ожидание приема первой логической 1, далее в  IDLE, ожидание старта (логический 0).  При этом конечно можно подсчитать количество логический нулей.

break frame - как я понял - это намеренное использование в системе уровня логического нуля длительностью больше длительности стартового бита.

Это другая логика работы. Это наверно к микроконтрольщикам.

 

[flammmable 4]

On 8/12/2022 at 8:50 PM, sazh said:

Обычно UART - это точка - точка. И наверно важно, на какой платформе он реализуется.

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

Боле того UART обычно используют в старт стопном режиме исходя из того, что пауза в линии это эквивалент стоп бита (логическая 1). Поэтому сколько стоп бит, 1 или 1.5 - 1000, не имеет значения, все укладываются в 1 стоп бит, а наличие логического нуля на месте стоп бита - это ошибка кадрирования и посылка считается не корректной. И автомат состояний переводят в состояние ожидание приема первой логической 1, далее в  IDLE, ожидание старта (логический 0).  При этом конечно можно подсчитать количество логический нулей.

break frame - как я понял - это намеренное использование в системе уровня логического нуля длительностью больше длительности стартового бита.

Это другая логика работы. Это наверно к микроконтрольщикам.

 

Технически, (наивную) логику приёма данных по UART можно сделать следующей:

1) Ждём нисходящий фронт

2) Отсчитываем 0,5+1 длительности бита

3) Производим замер, ждём 1 длительность бита, повторяем N-1 раз

4) Символ успешно принят, снова ждём нисходящий фронт

В подобном подходе нет проверки "а точно ли нисходящий фронт - это фронт от старт-бита?" И нет проверки "а точно ли это символ, отправленный по всем правилам, со стоп-битом в нужном месте?" Конечно, эти две проверки можно добавить. Но тогда возникает вопрос, а почему эти проверки стоит добавить, а проверку на второй стоп-бит - не стоит? А если добавить и её, то стоит ли добавить проверку на 1,5 стоп-бита? Если ответы "нет и нет, эти проверки не нужны", то тогда так ли уж нужны первые две проверки?

[tonyk_av 86]

17 hours ago, flammmable said:

"а точно ли это символ, отправленный по всем правилам, со стоп-битом в нужном месте?"

[vladec 30]

В 12.08.2022 в 21:50, sazh сказал:

break frame - как я понял - это намеренное использование в системе уровня логического нуля длительностью больше длительности стартового бита.

Обычно длительностью больше одного слота и служит меткой начала фрейма. Это, например, протокол DMX-512: https://ru.wikipedia.org/wiki/DMX-512

 

[sazh 12]

В 15.08.2022 в 11:12, vladec сказал:

Обычно длительностью больше одного слота и служит меткой начала фрейма. Это, например, протокол DMX-512: https://ru.wikipedia.org/wiki/DMX-512

 

Спасибо. UART для меня - это rs-232

[sazh 12]

В 13.08.2022 в 15:40, flammmable сказал:

Технически, (наивную) логику приёма данных по UART можно сделать следующей:

1) Ждём нисходящий фронт

2) Отсчитываем 0,5+1 длительности бита

3) Производим замер, ждём 1 длительность бита, повторяем N-1 раз

4) Символ успешно принят, снова ждём нисходящий фронт

В подобном подходе нет проверки "а точно ли нисходящий фронт - это фронт от старт-бита?" И нет проверки "а точно ли это символ, отправленный по всем правилам, со стоп-битом в нужном месте?" Конечно, эти две проверки можно добавить. Но тогда возникает вопрос, а почему эти проверки стоит добавить, а проверку на второй стоп-бит - не стоит? А если добавить и её, то стоит ли добавить проверку на 1,5 стоп-бита? Если ответы "нет и нет, эти проверки не нужны", то тогда так ли уж нужны первые две проверки?

логику приёма данных по UART можно сделать следующей:

1) Ждём уровень логического нуля длительностью в половину стартового бита

2) Если интервал - половина бита, принимаем решение, что это стартовый бит.

3)нарезаем данные по середине бита

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

5) переходим в состояние ожидания стартового бита.

Обычно в rs232 передача пакета:

Подача уровня лог.1 длительностью например в 11 бит {старт, байт, стоп, 1'b1}. Нормально сконструированный приемник встанет в состояние ожидания стартового бита. В конце пакета - например crc -16. И анализ каждого символа на рассогласование по частоте передачи (ошибка кадра).

как то так.

rxd_232.zip

[BSACPLD 17]

Я делал у себя так:

1. На входной сигнал ставил мажоритар 2 из 3.

2. Делал N семплов на бит.

3. Стартовый бит ловил по отрицательному фронту.

4. Семплировал в середине каждого бита.

5. В конце проверял значение стоп-бита.

Если 1, то все хорошо, если 0, то ошибка фрейма.

6. Потом снова начинал ждать отрицательный фронт.

 

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

При расчете скорости UART если не получается точно установить скорость, на приемной стороне лучше ставить скорость в большую сторону, тогда получается некий аналог удлиннения стоп-бита.

 

P.S.

Я в свое время выкладывал на форуме полностью рабочий код для UART - можете посмотреть как там у меня реализовано: