UART работает, когда я открываю minicom перед запуском UART

Я пытаюсь отправить большие объемы данных на 115200 через UART. Столкнулся с довольно странной проблемой. Я отправляю данные в цикле while MCU. MCU больше ничего не делает. Я подключаю UART через контакт ввода-вывода. Я заметил, что если я открываю minicom, а затем запускаю UART, данные отображаются правильно. Однако, если я запущу UART, а затем открою minicom, я не получу правильных данных. Я подозреваю, что это как-то связано с обнаружением битов остановки и запуска. Поскольку, когда я случайно открываю minicom, он принимает стоповый бит и стартовый бит за один из битов данных, а данные неверны. Это потому, что данные отправляются все время. Это звучит как разумное объяснение? Или есть что-то еще?

Следы: http://wikisend.com/download/389684/notworking.csv http://wikisend.com/download/977160/working.csv

Не работает

Этот рабочийРаботающий

В стартовых и стоповых битах UART нет ничего волшебного, они такие же, как биты данных. Принимающий UART не может узнать, принимает ли он стартовый/стоповый бит или бит данных. Некоторые распространенные способы справиться с этим - вставить задержки или использовать символ «разрыва» для кадрирования блоков данных (как это делает DMX).
@brhans - DMX использует разрыв для обозначения начала кадра , который придает значение отдельным словам по отношению друг к другу. Но это не нужно для правильной расшифровки самих слов.
@ChrisStratton, есть идеи, как справиться с этой ситуацией? один из них - вставить delay , но это уменьшит общий объем данных, которые можно вывести. Есть ли другой путь?
@brhans Я так и думал. Итак, задержка - лучший способ справиться с этим?
Сравните вывод вашего программного UART на осциллографе с фактическим аппаратным UART (например, с тем, что вы получаете). Вам не нужно добавлять задержки , выявлять и исправлять то, что не так с вашей реализацией
@ChrisStratton, позвольте мне прикрепить след Лос-Анджелеса.
@ChrisStratton, обновлено, пожалуйста, взгляните
Ваше битовое время выглядит не так. Обратите внимание на «ошибки кадрирования» и точки не центрированы в битах. Как у вас обстоят дела с синхронизацией в вашем программном UART?
На обоих снимках экрана запущена одна и та же программа. Нет разницы. Это как раз когда я запускаю анализатор. Вы можете видеть, что диаграммы в 1 и 2 на самом деле одинаковы.
@redcar, вы пробовали использовать 2 стоповых бита? посмотрите, исправится ли он после нескольких байтов.
Вы снова и снова меняете отправляемые данные или один и тот же символ? возможно, что UART хост-компьютера всегда будет отключен, если данные недостаточно различаются, чтобы работать с ошибками кадрирования, а затем синхронизироваться.
вы можете попробовать один или два символа времени простоя за каждые отправленные N-ые байты. не между каждым байтом, а выберите что-то через каждый 100-й байт или что-то в этом роде. если uart на хосте не синхронизируется, тогда уменьшайте количество байтов, пока не получите что-то, что подходит для области, но не синхронизируется на хосте, а затем вручную декодируйте сигнал (не доверяйте области, если у нее есть это программное обеспечение, сделать своими руками).
@dwelch Один и тот же персонаж снова и снова
попробуйте перепутать его, нет причин ожидать, что rx uart будет думать, что он не синхронизирован, если это один и тот же символ снова и снова (если только это не все нули или все единицы).
@ChrisStratton - да, поэтому я предложил использовать его для «кадрирования блоков данных». Это даст принимающему UART что-то, что он может повторно синхронизировать. Хотя эту ситуацию легко распознать (из-за регулярных ошибок кадрирования), ее практически невозможно исправить без создания какого-либо события, которое позволяет ресинхронизировать rx UART, независимо от того, реализован ли UART аппаратно или программно (как вы можете это сделать? скажите своему UART «игнорировать следующие 3 бита»…?). Задержка передачи длиной в байт или символ прерывания будут работать идеально.

Ответы (1)

Конечно, возможно, что у вас есть ошибка в вашей реализации UART с битовым ударом. Как вы определяете время, тратите ли вы цикл, тратя определенное количество времени, или вы выполняете цикл до тех пор, пока не наступит определенный момент времени (единственный реальный способ - помимо изосинхронного кодирования - сделать это - использовать автономный таймер ). Вы можете очень внимательно посмотреть на свой вывод с тестовым символом 0x00 и посмотреть, насколько время (от начала стартового бита до начала стопового бита) отличается от идеального. Мне было бы комфортно с 1% или меньше, вы могли бы обойтись немного больше.

Тем не менее, я согласен с brhans. Бывают ситуации, когда связь между абсолютно правильными отправителем и получателем UART начинается в «неправильный» момент и продолжает рассинхронизироваться навсегда. Это свойство протокола UART и не имеет ничего общего с качеством (или его отсутствием) любой из сторон. Единственный выход - пауза в передаче (перерыв не нужен) длиной более символа.

В качестве иллюстрации ситуации рассинхронизации рассмотрим непрерывную передачу шаблона 0011111101 (формат 8N1).

Когда первый 0 интерпретируется как стартовый бит, биты данных равны 01111110, за которыми следует стоповый бит (1) и следующий стартовый бит (0). Это полностью допустимый поток байтов 0x7E.

Но когда последний 0 интерпретируется как стартовый бит, за ним следуют 1 и 0011111101, что интерпретируется как 10011111 и стоповый бит 1, за которым следует следующий 0 стартовый бит. Это одинаково допустимый поток байтов 0x9F.

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

Кажется, работает увеличение задержки после стопового бита. Но есть ли другой способ?
Как следует из моей аргументации, нет другого надежного способа выйти из ситуации множественной интерпретации. Но если вы можете допустить, что ситуация длится несколько символов, достаточно вставить задержку после этого количества символов.