Блог

Jan 22, 2024

Что может пойти не так: асинхронное последовательное издание

Это самая простая вещь в мире — простые и понятные последовательные данные. Это резервный протокол связи почти для каждой встроенной системы, поэтому вам действительно нужно его использовать.

Это самая простая вещь в мире — простые и понятные последовательные данные. Это резервный протокол связи почти для каждой встроенной системы, поэтому вам действительно хочется работать с ним, когда чипы не работают. И все еще! Когда вам это понадобится больше всего, вы можете обнаружить, что даже асинхронный последовательный порт может стоить вам нескольких часов времени на отладку и добавить несколько седых волос на вашу голову.

В этой статье я собираюсь рассказать о большинстве (всех?) проблем, которые могут пойти не так с асинхронными последовательными протоколами, а также о том, как диагностировать и отлаживать этот наиболее полезный из методов передачи данных. Цель состоит в том, чтобы вы достаточно знали о том, что может пойти не так, чтобы, когда это произойдет, вы могли систематически устранять неполадки в течение нескольких минут, а не тратить несколько часов.

Представьте, что у вас есть восемь бит данных, которые вы хотите отправить мне в электронном виде. Если между нами восемь проводов (плюс земля), вы можете просто щелкнуть восемью переключателями и подать на каждый провод высокое или низкое напряжение. Если я на другом конце с несколькими светодиодами, я просто прочитаю, какие из них загорятся, и все готово. Но восемь проводов — это очень много меди. Поэтому вместо этого вы решаете отправлять по одному биту за раз, используя только один провод (плюс землю). В этом суть последовательной связи — биты передаются последовательно за счет точного изменения напряжения на проводе с течением времени.

Звучит просто, но теперь у нас есть выбор. Как быстро вы отправляете каждый бит? Горящий светодиод означает 1 или 0? Как я узнаю, когда начнется или закончится ваше сообщение? И, наконец, если мы оба собираемся отправлять данные друг другу, нам понадобится два провода. Откуда нам знать, какой из них я отправляю, а какой вы? Каждый из этих вариантов — это место, где можно ошибиться и закрасться ошибками.

Последний пункт (какие провода и в каком направлении передают данные) на удивление является частым источником путаницы, поэтому это хорошее место для начала отладки.

«RX» и «TX» означают «прием» и «передача» соответственно. Большинство систем последовательной связи имеют по одному из каждого типа. Часто настройка происходит примерно так: вы подключаете «GND» на одном устройстве к «GND» на другом. Возможно, они также будут использовать общую шину питания, поэтому вы подключите «VCC» одного к «VCC» другого. А затем, по ходу, вы подключите «RX» на одном устройстве к «RX» на другом.

И это ошибка номер один. Оба устройства ожидают получения данных по своей линии «RX», поэтому они оба просто сидят и ждут, пока две линии «TX» в конечном итоге начнут общаться друг с другом. Нет, «правильный» способ сделать это — соединить порт «RX» одного устройства с портом «TX» другого и наоборот. Это просто логично, правда? Чтобы напомнить вам об этом, иногда «TX» обозначается как «TXD», где «D» означает «устройство», и это должно напоминать вам, что вы смотрите на вещи с точки зрения этого устройства.

Как бы вы это ни называли, подключение порта под названием «TX» к порту под названием «RX» вызывает проблемы в современных программах САПР, где вы называете сеть, а не отдельные порты. Как вы называете провод, соединяющий контакты «GND» обоих устройств? «GND» — хорошее имя. Как вы называете провод, соединяющий «TX» с «RX»? А как насчет того, который соединяет «RX» с «TX»? Царит смятение.

(Обратите внимание, что SPI, у которого есть свои проблемы, о которых мы поговорим в следующий раз, называет эти строки «главный вход, подчиненный выход» и «главный выход, подчиненный вход». Имена строк одинаковы, и если вы знаете, какое устройство на что вы смотрите, вы сразу узнаете, в каком направлении движутся данные. Это намного лучше.)

Итак, первый вопрос, который следует задать себе при отладке, — правильно ли вы пересекли сигнальные линии. И даже если да, все равно попробуйте поменять их местами, потому что даже если вы не запутались, вы не можете быть уверены, что инженер выше вас не запутался. (Мы видели, как это произошло.)

У нас есть прямая проводка, а как насчет скорости отправки (и получения) данных? Это важно, потому что если вы какое-то время видите высокое напряжение на своем проводе, вам нужно знать, сколько бит должно было представлять это «пока». Если я отправлю вам четыре нуля, вы увидите постоянное напряжение в два раза дольше, чем если бы я отправил вам два, но нам нужно согласовать временную развертку, чтобы вы могли быть уверены, что я не просто отправил два нуля или восемь. .