Виявлення стартового біта в програмному забезпеченні UART

Я експериментую з написанням програмного забезпечення UART на своєму мікроконтролері за допомогою штифтів GPIO. Це тимчасово додати канал UART до проекту, поки ми не отримаємо новий дизайн, який використовує UC з більшою кількістю портів UART.

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

Це неминуча проблема із каналом UART? Або є якась хитра хитрість, яку виробники UC використовують у своїх апаратних UART?

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

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

Майте на увазі, що кількість бітів даних має бути передбачуваним, як і розмір кадру, тому навіть якщо ви використовуєте 100% ємності шини і ваш стоп-біт становить один біт, ви все одно зможете знайти Почніть біт, якщо ви наберете достатню кількість кадрів. Кожен кадр гарантовано має перехід у ньому. Біт стоп - це той, який завжди високий. Стартовий біт - той, який завжди низький. Якщо припустити, що ваші дані є випадковими (або досить випадковими), ви можете зробити щось настільки просто, як створити буфер розміром з ваш кадр, встановити кожен біт у ньому, а потім продовжувати збирати кадри та ANDing їх у цей буфер, поки у буфера не буде лише 1 біт встановлений. Цей шматочок - ваш стоп-біт. Один після нього - ваш початковий біт. Вуаля! Ви його знайшли.

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

У апаратних UART є однакові проблеми. Але це, як правило, той, хто вирішує себе у короткому порядку. В кінці кожного кадру перевірте стоп-біт, а якщо він не високий, відмовтеся від кадру та дочекайтеся наступного переходу від високого до низького. Якщо припустити, що дані з джерела не є абсолютно патологічними (наприклад, довгі рядки "UUUU" або ASCII 0x55), UART з часом "перейде" до справжнього початкового біта.

Припускаючи передачу 8N1.

Потрібно дочекатися рядка з 9 високих або низьких біт підряд.

Якщо високий, він буде означати або розрив у режимі очікування даних або символ 0xFF та біт STOP,
або
низький розмір START біт та символ NULL 0x00.

Будь-яка з цих умов дозволить ресинхронізувати.

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

Подібні проблеми у вас будуть, коли ви використовуєте вбудовану периферійну систему UART і не зможете здійснювати побітну оцінку, а також потрібно пам’ятати про скидання всіх бітів помилок на обрамлення і таких, коли вони виникають (особливо при включенні живлення).