Як читати серійні дані з осцилографа

У мене є мікроконтролер (PICAXE 20X2) і метр для горщика. Я запрограмував мікро, щоб він надсилав будь-які зміни лічильника горщика до послідовного порту ПК. Очевидно, що це 8-бітний АЦП. Тепер для мене найцікавішою є можливість декодування цих серійних даних на осцилограмі.

Ось дві картинки, перше - це коли мікрокореспондент надсилає "0" на ПК, а наступне - "255". Дані передаються за допомогою 9600 buad, і я можу їх отримати в терміналі ПК.

Перший малюнок

Другий рис

Отже, моє запитання полягає в тому, чи я зафіксував потрібні дані щодо своєї сфери, і по-друге, як можна прочитати та розшифрувати цей імпульс у шістнадцятковий або формат ascii. Я маю на увазі, як читати цей зростаючий і спадаючий імпульси (0/1).

Спасибі.

Спочатку щось помітив і Олін: рівні - це зворотне значення того, що мікроконтролер зазвичай видає:

Не хвилюйтесь, ми побачимо, що ми можемо читати і цей шлях. Ми просто повинні пам’ятати, що в області запуску біт буде 1бітом стоп і стоп 0.

Далі ви маєте неправильну базу часу, щоб правильно прочитати це. 9600 біт на секунду (більш відповідні одиниці, ніж Бод, хоча останні не є помилковими за кожний сеанс) - це 104 за біт, що становить 1/10 частини ділення у вашому поточному налаштуванні. Збільшити масштаб і встановити вертикальний курсор на перший край. Це початок вашого стартового біта. Перемістіть другий курсор до кожного наступного краю. Різниця між курсорами повинна бути кратною 104 . Кожні 104 s - це один біт, спочатку біт запуску ( ), потім 8 бітів даних, загальний час 832 s та стоп-біт ( ). $\mu$$\mu$$\mu$1$\mu$0

Це не схоже на те, що дані на екрані відповідають відправленим 0x00. Ви повинні побачити вузький 1біт (початковий біт) з подальшим більш низьким рівнем (936 мс, 8 нульових біт даних + стоп-біт). Те саме, що ви надсилаєте; ви повинні побачити довгий високий рівень (знову 936 , на цей раз стартовий біт + 8 бітів даних). Отже, це має бути майже 1 поділ з вашим поточним налаштуванням, але це не те, що я бачу. Це більше схоже на першому скріншоті, який ви надсилаєте два байти, а в другому чотирьох - з 2-м і 3-м тим самим значенням. $\mu$
0xFF$\mu$

здогадки:

0b11001111 = 0xCF
0b11110010 = 0xF2

0b11001101 = 0xCD
0b11001010 = 0xCA
0b11001010 = 0xCA
0b11110010 = 0xF2

редагувати
Олін абсолютно прав, це щось на зразок ASCII. По суті, це доповнення 1 ASCII.

0xCF ~ 0x30 = '0'
0xCE ~ 0x31 = '1'
0xCD ~ 0x32 = '2'
0xCC ~ 0x33 = '3'
0xCB ~ 0x34 = '4'
0xCA ~ 0x35 = '5'

0xF2 ~ 0x0D = [CR]

Це підтверджує, що моє тлумачення скріншотів правильне.

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

Приклад: другий байт на 1-му екрані, починаючи з 2 вузьких імпульсів. Початково я починаю з другого байту, тому що там більше ребер, ніж у першому байті, тому буде легше це правильно виправити. Кожен з вузьких імпульсів становить приблизно 1/10 частини поділу, так що може бути 1 біт високий кожен, з низьким бітом між ними. Я також не бачу нічого вужчого, ніж це, тому, мабуть, це єдиний шматочок. Ось наш довідник.
Потім після 101більш тривалого періоду на низькому рівні. Виглядає приблизно вдвічі ширше попередніх, так що могло бути 00. Високий наступний, що знову вдвічі ширший, так що буде 1111. Зараз у нас є 9 біт: початковий біт ( 1) плюс 8 бітів даних. Тож наступним шматочком буде стоп-біт, а тому що це0це не відразу видно. Таким чином, склавши все це у нас є 1010011110, включаючи біт старту та зупинки. Якби стоп-біт не дорівнював би нулю, я б десь зробив погане припущення!
Пам'ятайте, що UART спочатку надсилає LSB (найменш значущий біт), тому нам доведеться повернути 8 бітів даних: 11110010= 0xF2.

Тепер ми знаємо ширину одного біта, подвійного біта та 4-бітової послідовності, і ми подивимось на перший байт. Перший високий період (широкий імпульс) трохи ширший, ніж 1111у другому байті, так що шириною буде 5 біт. Низький і високий період, що слідує за ним, такі ж широкі, як і подвійний біт в іншому байті, тому ми отримуємо 111110011. Знову 9 біт, тому наступним повинен бути низький біт, стоп-біт. Це нормально, тож якщо наша здогадка правильна, ми можемо знову змінити біти даних: 11001111= 0xCF.

Тоді ми отримали підказку від Оліна. Перша комунікація завдовжки 2 байти, 2 байти коротша за другу. І "0" також на 2 байти коротше, ніж "255". Тож це, мабуть, щось на кшталт ASCII, хоча і не зовсім. Також зазначу, що другий та третій байти "255" є однаковими. Чудово, що це буде подвійне "5". У нас все добре! (Доводиться час від часу заохочувати себе.) Після розшифровки "0", "2" і "5" я помічаю, що між кодами для перших двох є різниця в 2, а різниця - 3 між останніми два. І, нарешті, я помічаю, що 0xC_це доповнення 0x3_, яке є схемою для цифр в ASCII.

Щось не додається. Ваші сигнали мають пік 3,3 В до піку, що означає, що вони прямо з мікроелементів. Однак рівні UART мікроконтролерів (майже) завжди простоюють високо, а активні - низькі. Ваші сигнали від цього перевернуті, що не має сенсу.

Щоб в кінцевому підсумку отримати ці дані в ПК, їх потрібно перетворити на рівні RS-232. Це те, що очікується побачити з COM-порту для ПК. RS-232 в режимі холостого ходу низький і активний, але низький - нижче -5 В, а високий - вище + 5 В. На щастя, є мікросхеми, які полегшують перетворення між типовими сигналами UART на логічному рівні мікроконтролера та RS-232. Ці мікросхеми містять зарядні насоси для отримання напруги RS-232 від джерела живлення 3,3 В. Іноді ці чіпи загалом називають "MAX232", оскільки це був номер деталі для раннього і популярного чіпа цього типу. Вам потрібен інший варіант, оскільки ви, мабуть, використовуєте потужність 3,3 В, а не 5 В. Ми робимо продукт, який в основному є однією з цих мікросхем на платі з роз'ємами. Перейдіть на сторінку http://www.embedinc.com/products/rslink2і подивіться на схему, щоб побачити один приклад того, як підключити таку фішку.

Інша річ, яка не додається, - це те, що обидві послідовності здаються більш ніж одним байтом, навіть якщо ви говорите, що ви надсилаєте лише 0 і 255. Цей тип послідовних даних надсилається з початковим бітом, то 8 бітів даних, потім стоп-біт. Стартовий біт завжди знаходиться на протилежній полярності від рівня простою лінії. У більшості описів рівень простою лінії вважається "пробілом", а протилежний - як "позначка". Тож стартовий біт завжди на меті. Мета початкового біта - забезпечити синхронізацію часу для решти бітів. Оскільки обидві сторони знають, як триває трохи часу, питання лише в тому, коли починається байт. Біт запуску надає цю інформацію. Одержувач, по суті, запускає годинник на передньому краю стартового біта і використовує це, щоб знати, коли будуть надходити біти даних.

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

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

Це допоможе, якщо ви розширите часовий масштаб слідів. Таким чином ви могли виміряти, що насправді трохи часу. Це дозволить вам переконатися, що ви дійсно маєте 9600 бод (104 мкс / біт), і дозволить вам декодувати окремі біти захоплення. Як і зараз, недостатньо роздільної здатності, щоб побачити, де знаходяться біти, і тому насправді розшифрувати те, що надсилається.

Додано:

Мені просто прийшло в голову, що ваша система може надсилати дані в ASCII замість двійкових. Це не так, як це робиться, оскільки перетворення в ASCII в маленькій системі займає більше обмежених ресурсів, погано використовує пропускну здатність, і легко зробити перетворення на ПК, якщо ви хочете відобразити дані користувачеві. Однак якщо у ваших передачах є символи ASCII, які пояснювали б, чому послідовності більше одного байта, чому другий довший ("255" більше символів, ніж "0"), і чому обидва, здається, закінчуються в одному байті. Останній байт - це, мабуть, якийсь символ кінця рядка, який, як правило, буде поверненням каретки або каналом рядка.

У будь-якому разі розгорніть шкалу часу, і ми можемо розшифрувати саме те, що надсилається.

Вам потрібно знати всі деталі: швидкість, якщо є стартовий біт, кількість бітів даних, якщо є стоп-біт і якщо є біт парності. Це має бути функцією того, як налаштовано UART в мікроконтролері.

Якщо в області Rigol немає опції послідовного декодування (багато DSO), ви можете використовувати X-курсори для допомоги в декодуванні. Помістіть перший курсор у передній край даних та перемістіть другий курсор через бітовий потік. Дельта між курсорами може бути використана для визначення того, який "біт" ви в даний момент наводите за допомогою простої арифметики. Очевидно, ігноруйте біти старту / стопу / парності.