Насколько критичны частоты UART?

17

Я собираюсь использовать кристалл 8 МГц для запуска моего микроконтроллера со скоростью 16 MIPS (PLL 4x, 2 цикла инструкции). Однако, 8 МГц не делятся на частоты UART AFAIK ... так насколько критичны эти частоты? Я планирую использовать 115 200 бод.

Может ли UART работать в пределах ± 1%? Если это не работает, какую частоту я должен использовать? (Я хотел бы получить максимально 16 MIPS для максимальной скорости обработки.) Если это имеет значение, я использую PIC24FJ64GA004.

Томас О
источник

Ответы:

13

Если вы находитесь в пределах 1%, вы должны быть в порядке.

Предположим, что ваш UART использует 16-кратную частоту передискретизации, например, вы можете установить его на 1843,200 Гц до 16-кратного передискретизации 115,200 бит / с. (передискретизация, как это довольно распространено). Это позволяет UART отсчитывать 8 разгонов от падающего фронта начального бита, поэтому он может найти центр битовых ячеек с точностью до +/- одного периода времени после который он отсчитывает 16 периодов времени, чтобы определить, когда для выборки данных.

Если вы предполагаете, что он может попасть в центр начального бита, то для того, чтобы сохранить выборку последовательных данных в правильных битовых ячейках по 8 битам данных, тактовая частота должна оставаться между (8-0,5) / 8 и (8 + 0,5). ) / 8 или +/- 6,25% от предполагаемой скорости передачи. Более высокий разгон приближается к идеальному состоянию удара по центру стартового бита, но 8х или 16х обычно достаточно близко, чтобы можно было предположить, что сработает 5% несоответствие.

Тем не менее, вы не можете рассчитывать на то, что другая сторона будет идеально на частоте Если вы подключите устройство с 4% высокой скоростью к устройству с 4% низкой скоростью, у вас возникнут проблемы. Я столкнулся, по крайней мере, с одним случаем, когда ПК работал немного медленно, а устройство - немного быстро, и эти два устройства могли общаться только незначительно, хотя одно и то же устройство было в порядке с другими ПК, а ПК - с другими устройства. (O-scoped они со скоростью около 112 кбит / с и 119 кбит / с) По этой причине хорошо бы попытаться достичь номинальной частоты как можно ближе. Я никогда не видел ничего в пределах 2% от номинальной проблемы.

Обычно нужно использовать основную тактовую частоту, которая обеспечивает целое число, кратное предполагаемой частоте передискретизации UART, умноженной на скорость передачи в бодах. Например, если вы хотите, чтобы процессор работал с частотой около 8 МГц, вы можете использовать генератор с частотой 7,3728 МГц, который можно разделить на 4, чтобы получить 1,8432 МГц, что в точности равно 16 раз 115200.

JustJeff
источник
8 МГц можно разделить на 69, чтобы получить 115 942, что находится в пределах ± 1%. Мне интересно, поддерживает ли PIC этот тип деления для своего генератора скорости передачи. Я надеюсь на это, но не думаю, что так и будет.
Томас О
PIC имеет генератор скорости передачи. Он будет работать хорошо, но только для более низкой скорости передачи данных, например 9600, он не будет работать для высокой скорости передачи данных, например, 115,200, он становится слишком неточным.
Томас О
Как вы думаете, я мог бы использовать кристалл 7,3728 МГц? (Я не собираюсь использовать внутренний генератор 7,37 МГц, потому что мне нужна точность.) Он позволяет мне делиться на 64, чтобы получить частоту UART 115 200. Это самое быстрое, что я могу пройти с высокой терпимостью.
Томас О
1
если ваш UART поддерживает его, предпочтительно дать ему разгон (например, 16x), чтобы он мог пересчитать стартовый бит и найти центр битовой ячейки, но получить 16x для 115K с точностью до 1% может быть проблемой, если только Вы используете многократный кристалл в бодах.
JustJeff
4

Упоминание 1% @JustJeff не обязательно. Большинство UART допускают половинную ошибку в последнем бите. Большую часть времени кадр состоит из 1 начального бита, 8 бит данных и 1 стопового бита, что в сумме составляет 10 бит. Полубит на 10 битах составляет 5% (6,25% в JustJeff не учитывают начальный и конечный биты).

stevenvh
источник
1
не вводите меня в заблуждение; Что касается «1%», то я утверждал, что этого может быть трудно достичь. «6,25%» предполагало, что вы попали в центр начального бита, и было бы максимально допустимой разницей в тактовых частотах приемник-передатчик при таких условиях.
JustJeff
1

Джаст Джефф забыл о бите старта, но Стивен добавил бит бита. Предполагая, что общий протокол состоит из 8 битов данных, 1 начального бита и без бита четности (количество стоповых битов не имеет значения), имеется 8 1/2 битных раз от переднего фронта начального бита к центру последний бит данных. Как правило, вы хотите, чтобы приемник выбрал этот последний бит в течение 1/4 битного времени. Обратите внимание, что 1/2 бит является гарантированным порогом отказа. Все, что рядом, становится нереальным, так как всегда есть электрический шум и дрожание.

1/4 делится на 8 1/2 = 2,94%.

Как упомянул JustJeff, большинство реализаций UART фактически отбирают входящие данные с асинхронным 16-кратным тактовым сигналом. Это добавляет еще одну 1/16-битную временную неопределенность, поскольку это ошибка, с которой может быть измерен передний фронт начального бита. 1/16 битного времени из 8 1/2 битов - это еще 0,74%. Это вытекает из ошибки бюджета, рассчитанной ранее. Вы получите 2,2% допустимого рассогласования тактовой частоты, чтобы приемник выбрал последний бит в пределах 1/4 битного времени от его центра.

Как уже говорили другие, использование кристалла 7,3728 МГц является обычной практикой, когда требуется точная скорость передачи. Обычно вы можете организовать работу процессора вблизи его максимальной скорости, одновременно увеличивая скорость передачи UART при кристальной ошибке.

Олин Латроп
источник
Я не согласен, что стоп-биты не имеют значения. В этом вопросе связь не удалась, поскольку стоповый бит был ошибочно установлен на низкий уровень.
Stevenvh
Стоповый бит должен присутствовать для общего взаимодействия, но он не входит в расчет бюджета ошибок для большинства UART. Для UART потребуется некоторое минимальное время после последнего бита данных до следующего переднего фронта следующего начального бита. Вот для чего нужно время остановки. Когда это время не соблюдено, вы получаете «ошибку кадрирования». Возможно, это сэмплируется как бит данных, но я знаю случаи, когда он обрабатывался по-другому. Старым телетайпам требовалось 2 стоп-бита, чтобы дать механическому механизму время, чтобы быть готовым захватить следующий символ.
Олин Латроп
Я упоминал стартовый бит три раза, не так ли?
JustJeff
@OlinLathrop: стоповый бит требуется , чтобы гарантировать , что при отправке байта , чей старший бит равен нулю , будет иметь спадающий фронт для следующего стартового бита. Разные устройства ведут себя по-разному в тех случаях, когда линия данных опускается раньше, чем предполагалось, но если бы не было стоп-бита, передаваемая последовательность нулевых байтов не содержала бы полезной информации о синхронизации. Такое требование может быть выполнено с помощью других средств с фиксированными накладными расходами кадров менее 25%, но я не знаю, кто это делает.
суперкат
1

Еще один момент, о котором еще не говорилось, заключается в том, что некоторые устройства ожидают передачи байта данных для каждого байта данных, которые они получают. Если такое устройство непрерывно передает данные, его скорость передачи даже на 0,1% ниже, чем у передающего устройства, и у него нет возможности посылать слегка сжатые стоп-биты, его выход будет отставать на один байт на каждые 1000 последовательных входящие байты. Если устройство ограничено 16 байтами буферизации, оно пропустит один байт данных после прохождения примерно 16 000 и после этого уменьшит примерно один байт на тысячу. Стоит отметить, что так называемые «1200 бод» модемы на самом деле работают со скоростью чуть выше 1200 бит / с (я думаю, что это около 1202) именно по этой причине (так что даже если передатчик работает на 0,15% быстрее, чем должен) быть,

Supercat
источник