Как читать последовательные данные с осциллографа

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

Вот две картинки: первая - когда микро посылает «0» на ПК, а вторая - когда «255». Данные передаются с использованием 9600 buad, и я могу получить их на ПК-терминале.

Первая картинка

Вторая картинка

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

Благодарю.

Первое, что заметил Олин: уровни противоположны тому, что обычно выводит микроконтроллер:

Не о чем беспокоиться, мы увидим, что мы тоже можем это прочитать. Мы просто должны помнить, что в области видимости стартовый бит будет a, 1а стоповый бит 0.

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

Не похоже, что данные экрана соответствуют отправленным 0x00. Вы должны увидеть узкий 1бит (стартовый бит) , а затем более низкого уровня (936 с, 8 бит данных ноль + стоп - бит). То же самое для отправления; Вы должны увидеть длинный высокий уровень (снова 936 s, на этот раз стартовый бит + 8 битов данных). Так что это должно быть почти на 1 деление с вашими текущими настройками, но это не то, что я вижу. Похоже, что на первом скриншоте вы отправляете два байта, а на втором - со вторым и третьим значениями. $\mu$
0xFF$\mu$

guesstimates:

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]

Это подтверждает, что моя интерпретация скриншотов верна.

edit 2 (как я интерпретирую данные, по популярному запросу :-))
Предупреждение: это длинная история, потому что это расшифровка того, что происходит в моей голове, когда я пытаюсь декодировать что-то подобное. Прочитайте его, только если вы хотите узнать один из способов справиться с этим.

Пример: второй байт на 1-м скриншоте, начиная с 2 узких импульсов. Я намеренно начинаю со второго байта, потому что в нем больше ребер, чем в первом байте, поэтому будет проще сделать его правильно. Каждый из узких импульсов составляет около 1/10 деления, так что каждый может иметь высоту 1 бит, а младший бит между ними. Я также не вижу ничего более узкого, чем это, поэтому я думаю, что это немного. Это наша ссылка.
Затем, после 101более длительного периода на низком уровне. Выглядит примерно в два раза шире, чем предыдущие, так что это может быть 00. Высокий следующий, который снова в два раза шире, так что будет 1111. Теперь у нас есть 9 бит: стартовый бит ( 1) плюс 8 бит данных. Таким образом, следующий бит будет стоп-бит, но потому что это0это не сразу видно Итак, все это вместе 1010011110, включая старт и остановку. Если бы стоповый бит не был равен нулю, я бы где-то сделал неверное предположение!
Помните, что UART сначала отправляет младший бит (младший значащий бит), поэтому нам придется обратить вспять 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-курсоры для помощи в декодировании. Поместите первый курсор на передний край данных и переместите второй курсор через поток битов. Дельта между курсорами может быть использована для определения того, какой «бит» вы в данный момент зависаете с помощью простой арифметики. Игнорировать биты пуска / остановки / четности, очевидно.