Тактова частота приймача UART

Я намагався зрозуміти основи UART. Це зрозуміло

• Це асинхронний протокол зв'язку, отже, годинники TX і RX не залежать один від одного
• Прийом даних гарантується використанням пускового біта та одного або декількох стоп-бітів. Додатково одержувач повинен знати про швидкість передачі даних, щоб генерувати підходящий годинник для керування реєстром SIPO, який використовується для прийому.

Питання тут є

Згадується, що зазвичай для відновлення даних використовується годинник 16X бітової швидкості. То як можливе перетворення bps в тактову частоту ? Надайте, будь ласка, кілька посилань на вивчення механізму синхронізації, що використовується у приймачі UART.

Годинники передавача та приймача не залежать один від одного таким чином, що вони генеруються незалежно, але вони повинні добре узгоджуватися для забезпечення належної передачі.

$T_0$$T_0$$T_0$$\times$$T_0$є падаючою кромкою стартового долота. Хоча вибірка початкового біта насправді не потрібна (ви знаєте, що він низький), корисно з’ясувати, що початковий край не був шипом.

$\times$

Якщо я правильно пригадую, 68HC11 взяв кілька зразків на початку, в середині та в кінці трохи, перший і останній, мабуть, повторно синхронізувались у разі зміни рівня (що не гарантується).

Годинник вибірки не походить від швидкості передачі бітів, це навпаки. Для 9600 біт / с вам доведеться встановити тактовий дискретизатор до 153 600 Гц, який ви отримаєте за допомогою докашляра з тактової частоти мікроконтролера. Тоді бітовий годинник виводиться з цього іншим поділом на 16.

неперевершені годинники
Це те, що станеться, якщо годинник приймача не синхронізується з передавачем:

Годинник приймача повільний на 6,25%, і ви можете бачити, що вибірки для кожного наступного біта будуть пізнішими та пізнішими. Типова передача UART складається з 10 біт: 1 стартовий біт, корисна навантаження 8 біт даних та 1 стоп-біт. Тоді, якщо ви зробите вибірку в середині шматочка, ви можете дозволити собі відпочити в останній біт, стоп-біт. Половина на десять біт - це 5%, тому з нашим відхиленням 6,25% ми зіткнемся з проблемами. Це добре видно на малюнку: вже на третьому біті даних ми відбираємо вибірку біля краю.

Давайте трохи відступимо та поговоримо про протокол сигналізації низького рівня, який використовують UART. TX і RX - це рядки даних, а не тактові. Годинники є лише всередині кожного UART, саме тому доводиться домовлятися про те, що таке швидкість передачі.

При непередаванні лінія залишається в режимі очікування. Щоб передати байт (наприклад, можливі інші ширини даних), передавач спочатку надсилає початковий біт . Одержувач використовує час переднього краю стартового біта і відому швидкість передачі даних, щоб потім декодувати решту символів. Скажімо для простоти, що використовується 100 кБауд. Це означає, що кожен біт триває 10 мкс. Сюди входить початковий біт, біти даних та стопи (біти) зупинки. Отже, середина першого біта даних буде знаходитись через 15 мкс після переднього краю стартового біта, другого - на 25 мкс і т.д.

Поки годинник приймача та передавача однакові, це може тривати назавжди. Однак вони ніколи не будуть абсолютно однаковими, тому це не може тривати вічно. Щоб дозволити повторну синхронізацію годинника приймача з тактовою частотою передавача, символ даних закінчується, рядок на деякий час залишається в режимі очікування, після чого процес повторюється. Помилки синхронізації накопичуються починаючи з переднього краю стартового біта, тому максимальний дрейф знаходиться в останньому біті. Після завершення цього символу приймач скидає очікування наступного біта запуску і процес повторюється.

З 8 бітів даних, найгірший випадок для синхронізації - вибірка останнього біта. Це в 8,5 біт разів від посилання часу, що є передовим краєм стартового біта. Якщо приймач вимкнений на 1/2 біта або більше, він відбиратиме останній біт під час іншого біта. Зрозуміло, що це погано. Це відбувається при невідповідності тактової частоти 1/2 біт у 8 1/2 біт, або 5,9%. Це гарантовано невідповідність. Для надійності зазвичай потрібно переконатися, що приймач відповідає половині передавача, або 2,9%. Це являє собою 1/4-бітну помилку часу в останньому біті.

Однак це не зовсім так просто. У вищеописаному сценарії приймач, по суті, запускає секундомір на передньому краї стартового біта. Теоретично це можна зробити в аналоговій електроніці, але це було б складно і дорого і не легко інтегрується в цифрові мікросхеми. Натомість у більшості цифрових UART-реалізацій є внутрішній тактовий годинник, який працює на 16x очікуваної швидкості передачі бітів. Потім "секундомір" підраховує ці 16x циклів. Це означає, що існує додаткова можлива помилка 1/16 біта, додана до всіх разів вибірки бітів, що є подібним до іншого .7% невідповідності тактових частот в останній біт.

Сподіваємось, це дає зрозуміти, що таке стоп-біт, як працює синхронізація бітів та що таке 16-годинний годинник. Я здебільшого пропускав стоп-біти, але, можливо, зараз ви можете переконатися, чому потрібен хоча б один стоп-біт. В основному стоп-біти - це мінімальний примусовий час простою рядка між символами. Це час, протягом якого приймач закінчив приймати символ і готовий до наступного переднього краю стартового біта. Якби не було стоп-біту, то останній біт даних міг би бути такої ж полярності, як і початковий біт, і у приймача не було б краю для запуску секундоміра.

Давно цей протокол був розшифрований кулачками, важелями та прядилами. Два стоп-біта часто використовувались для того, щоб дозволити скидання механізму. В даний час все робиться в цифровій логіці, і 1 стоп-біт використовується в значній мірі універсально. Ви часто бачите протокол низького рівня, записаний стенограмою, як 8-N-1, тобто 8 бітів даних, відсутні біти парності (забудьте про них, вони сьогодні рідко використовуються) та 1 стоп-біт. Початковий біт мається на увазі, оскільки тут немає жодної опції.

Використовуючи 8-N-1, 8-бітний байт даних фактично займає 10 біт разів для надсилання. Це одна з причин, що існує різниця між "швидкістю передачі бітів" і "швидкістю передачі даних". Швидкість передачі передач позначає окремі час сигналу бітів, включаючи біти початку та зупинки. При 100 кбаудах кожен переданий біт займає 10 мкс, включаючи біти запуску та зупинки. Тому весь персонаж займає 100 мкс, але передаються лише 8 біт реальних даних. Швидкість передачі даних становить 100 к, але швидкість передачі даних з точки зору вищих рівнів становить лише 80 кбіт / с.

Швидкість передачі для передачі даних - це тактова частота, поділене на (як ви кажете, як правило, 16.). У вас також є декілька бітів без даних для бітів обрамлення (початок, парність, зупинка). Так, за тактовою частотою 16000 Гц ви отримуєте 1000 біт на секунду, але після мінімальних бітів кадрування вставляється лише 800 біт даних або 100 байт в секунду.

Для прийому приймач рахує від середини стартового біта 16 тактових частот і відбирає лінію, яка викликає те, що вона бачить, "перший біт даних". він повторює цю кількість і вибірку достатньо разів, щоб прочитати весь символ, потім підтверджує наявність стоп-біта і починає чекати наступного стартового біта.

Поки тактова частота приймача наближається до швидкості тактової частоти передавача, вибірки будуть вражати правильні частини переданого сигналу.