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

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

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

Ответы (4)

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

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

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

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

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

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

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

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

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

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

1/4 разделить на 8 1/2 = 2,94%.

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

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

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