Как UART узнает разницу между битами данных и стартовыми/стоповыми битами? [дубликат]

Это звучит как вопрос, исходящий от кого-то, кто пытается эмулировать приемник UART в программном обеспечении или FPGA. Для RS-232 используются термины метка и пробел . Но после оцифровки они обычно соответствуют «1» и «0» соответственно.

Приемник UART часто делит каждое битовое время (должно быть известно априори) как минимум на 4, но часто на 16 или более подпериодов. Он запускается (при включении питания/сбросе) в состоянии, в котором ожидается, что линия последовательного приемника находится в состоянии метки . Если линия в этот момент НЕ находится в метке , то она знает , что находится в середине кадра передачи, и должна ждать, пока не сможет синхронизироваться. Если линия находится в состоянии метки , то она может или не можетбыть в середине чего-то и придется подождать и посмотреть. Это проблема с RS-232, если просто подключиться к другому устройству во время последовательной связи или если часть касания для мониторинга асинхронной последовательной связи между двумя другими плеерами и только что была сброшена. Чтобы быть абсолютно уверенным, в любом случае при выходе из сброса UART должен будет наблюдать как минимум N битовых времен (где N - количество битов в слове, а часто 7 или 8, и здесь не предполагается параметр четности), достойный отметки за которым следует один бит пространства для повторной синхронизации (или N+1 бит пространства.) Многие не переносят столько состояний, поэтому они могут неправильно синхронизироваться, если запущены в середине потока. Вы часто будете получать ошибки кадрирования и случайные байты данных, пока не случится случайная повторная синхронизация снова правильно. Это также часто была приемлемой ценой. Обычно кабели подключаются, а устройства включаются в определенном порядке, поэтому проблемы возникают редко.

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

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

Он определяет стартовый бит. Именно в этом его цель. Строка бездействия будет выглядеть так:

...1111111111111111111111111111111...

Как только приемник видит 0после длительного времени единиц (или после стопового бита, как мы скоро увидим), он знает, что передача началась и начинает считать биты. Он знает, что 8биты (или как определено конфигурацией) после стартового бита являются данными. Девятый является стоповым битом и должен быть 1. Если это не так - возникает ошибка кадрирования и требуется повторная синхронизация.

После получения стопового бита он снова начинает ждать стартового бита. И так далее.

Теоретически могут быть проблемы с синхронизацией, если строка выглядит так:

..1010101010101010101.... 

или подобное, так что в этом случае получатель не увидит, где начать, но в этом случае это не будет иметь большого значения, так как начальная позиция не будет иметь никакого значения. Но во избежание таких проблем некоторые протоколы определяют длину стопового бита в 1,5 (полтора) бита, чтобы сделать его уникальным. Или, на практике, между двумя пакетами данных всегда есть некоторая временная задержка, поэтому линия простаивает достаточно долго, чтобы приемник мог синхронизироваться.

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

Он может определить разницу, потому что знает, где они должны быть в битовом потоке (потому что вы сказали ему).

Просто помните, что любой символ не имеет смысла, пока не существует согласованного значения.

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

Квитирование необходимо для сообщения об обнаружении заполнения буфера, переполнения, ошибки четности или ошибки стопового бита.

Нечетная четность полезна здесь для обнаружения ошибки данных и/или ошибки кадра, чтобы возобновить правильную синхронизацию начального бита и безошибочную связь.