UART и Serial в Arduino: RX, TX и связь двух плат

Связь двух плат: три провода

Это самая частая практическая задача и самая частая ошибка в ней. Провода перекрещиваются: тот, кто говорит, соединяется с тем, кто слушает.

Почему TX к TX не работает. Это два передатчика, соединённые вместе: оба выдают напряжение, слушать некому. В мониторе будет тишина, а при одновременной передаче с обеих сторон выходы будут ещё и бороться друг с другом — один тянет линию вверх, другой вниз.

Почему земля обязательна. Сигнал — это не «напряжение само по себе», а разница между сигнальным проводом и нулём. Пока у плат нет общего нуля, приёмник просто не знает, относительно чего мерить: связь будет то работать, то нет, чаще всего именно на длинных проводах и при отдельном питании плат. Питание между платами, наоборот, соединять не нужно — у каждой своё.

Аппаратный порт или программный

У Uno одна пара выводов, а модулей может быть несколько. Выход — библиотека SoftwareSerial: она делает «порт» из любой пары обычных выводов, отсчитывая промежутки программно. Её не нужно нигде скачивать, она приходит вместе с поддержкой платы:

#include <SoftwareSerial.h>

SoftwareSerial link(2, 3);  // 2 - приём (RX), 3 - передача (TX)

void setup() {
  link.begin(9600);
}

void loop() {
}

Плата за это выглядит так (все числа — наши сборки одного и того же скетча-эха под Arduino Uno):

Неожиданный результат в строке про ОЗУ: программный порт занимает памяти меньше аппаратного — 117 байт против 175. Причина в том, что у него нет очереди на передачу: он не складывает байты, а отправляет их сразу, занимая процессор. Зато кода ему нужно почти вдвое больше.

Четыре ограничения, о которых узнают поздно

• Слушать можно только один программный порт. Внутри библиотеки один указатель на «активный» объект на весь класс. Команда begin() сама делает порт активным, поэтому после двух вызовов подряд слушать будет только второй, а первый молча перестанет принимать. Переключение командой listen() вдобавок стирает всё, что успело накопиться.
• На время передачи байта выключаются все прерывания. На 9 600 бод это 0,94 мс полной глухоты на каждый байт: в это время не принимаются данные на других портах, а часы millis() замирают и потом догоняют. На приёме обработчик занимает процессор дольше целого байта — там миллисекунды теряются по-настоящему.
• Приём работает не на всех выводах. На Uno и Nano — на любых, а на Mega только на выводах 10–13, 50–53 и A8–A15, то есть на 16 из 70. Хуже всего то, что begin() об этом не сообщает: порт просто останется передающим, а приём будет молчать.
• Есть потолок скорости. В самой библиотеке написано: приём рассчитан до 115 200 на 16 МГц и до 57 600 на 8 МГц. Причина арифметическая — на 115 200 один бит длится около 139 тактов, а вход в обработчик прерывания съедает больше половины этого времени.

Отсюда простое правило: аппаратный порт — всегда, когда он свободен. Если модулей больше одного, стоит смотреть в сторону платы с несколькими портами: Mega, где их четыре, или ESP32, где выводы портов ещё и переназначаются.

Как передавать числа, а не буквы

Пока речь о «привет» из монитора, всё просто. Как только две платы начинают обмениваться показаниями, всплывает неприятное свойство UART: это поток байтов без границ. Приёмник не знает, где кончилась одна посылка и началась следующая, а любая помеха на проводе — это лишний или потерянный байт, после которого всё едет.

Поэтому в передаче должны быть две вещи: метка начала и контрольная сумма. На схеме выше связь показана на аппаратном порту — выводах 0 и 1. В скетчах ниже она поднята на программном порту, выводы 3 и 2: так провода не мешают заливать скетч, а монитор остаётся свободным для отладки. Соединяются они по тому же правилу: вывод 3 передатчика идёт на вывод 2 приёмника, земли соединены. Вот передатчик — он шлёт номер датчика и значение:

// Передатчик. Отправляет по проводам номер датчика и его значение.
// Провода: вывод 3 передатчика -> вывод 2 приёмника, и обязательно GND -> GND.
// К выводу A0 подключите потенциометр или датчик.

#include <SoftwareSerial.h>

SoftwareSerial link(2, 3);  // 2 - приём (RX), 3 - передача (TX)

const byte START = 0xAA;    // метка начала пакета
const byte ESC   = 0xAB;    // служебный байт: следующий за ним - это данные

void setup() {
  link.begin(9600);
}

void put(byte b) {          // метку и сам ESC внутри данных экранируем
  if (b == START || b == ESC) {
    link.write(ESC);
    link.write((byte)(b ^ 0x20));
  } else {
    link.write(b);
  }
}

void send(byte id, int value) {
  byte lo = value & 0xFF;
  byte hi = (value >> 8) & 0xFF;
  byte sum = id ^ lo ^ hi;  // контрольная сумма: сложение по модулю два
  link.write(START);        // метка идёт без экранирования - она одна такая
  put(id);
  put(lo);
  put(hi);
  put(sum);
}

void loop() {
  send(1, analogRead(A0));
  delay(200);
}

А вот приёмник. Он не читает «по одному байту в цикле», а собирает пакет и проверяет сумму; если она не сошлась, пакет выбрасывается, и приём начинается заново с ближайшей метки:

// Приёмник. Собирает пакет из потока байтов и проверяет контрольную сумму.
// Провода: вывод 3 передатчика -> вывод 2 приёмника, и обязательно GND -> GND.

#include <SoftwareSerial.h>

SoftwareSerial link(2, 3);  // 2 - приём (RX), 3 - передача (TX)

const byte START = 0xAA;
const byte ESC   = 0xAB;

byte packet[4];
byte filled = 0;
bool started = false;
bool escaped = false;

void setup() {
  Serial.begin(9600);
  link.begin(9600);
}

void loop() {
  while (link.available()) {
    byte b = link.read();

    if (b == START) {         // метка всегда начинает пакет заново
      started = true;
      filled = 0;
      escaped = false;
      continue;
    }
    if (!started) continue;   // мусор до первой метки пропускаем

    if (b == ESC) {           // следующий байт - экранированные данные
      escaped = true;
      continue;
    }
    if (escaped) {
      b ^= 0x20;
      escaped = false;
    }

    packet[filled++] = b;
    if (filled < 4) continue; // пакет ещё не полон

    started = false;
    byte id = packet[0];
    int value = (int)((uint16_t)packet[1] | ((uint16_t)packet[2] << 8));
    byte sum = packet[0] ^ packet[1] ^ packet[2];

    if (sum != packet[3]) {   // сумма не сошлась - пакет битый
      Serial.println(F("Помеха: пакет отброшен"));
      continue;
    }

    Serial.print(F("Датчик "));
    Serial.print(id);
    Serial.print(F(": "));
    Serial.println(value);
  }
}

Честная оговорка: одной метки и суммы мало. Байт метки может попасться внутри данных, и если хоть один байт потерялся, приёмник встанет на ложную нарезку — сумма при этом иногда сходится, и на экран пойдут числа из воздуха. Мы это проверили моделированием: при неподвижном показании приёмник может печатать одно и то же неверное число до самой перезагрузки. Поэтому метку экранируют: если байт данных совпал с меткой, передатчик ставит перед ним служебный байт. Тогда метка означает начало кадра и ничего больше, а любая помеха стоит ровно одного пакета. Для более требовательных задач добавляют ещё длину пакета и настоящую контрольную сумму CRC.

Очередь на приём: 64 байта и ни байтом больше

Принятые байты складываются в очередь, и если программа не успевает их забирать, новые выбрасываются молча — ни ошибки, ни признака. Размер очереди — 64 байта (полезных 63), и вот за какое время она заполняется:

Смотрите на правый столбец и сравнивайте со своим циклом. Обычный delay(100) в loop() при скорости 9 600 уже теряет данные, а на 115 200 данные начнёт терять даже delay(10): очередь заполняется за 5,6 мс. Лечится это не увеличением буфера, а отказом от задержек — счётом времени по millis(), как в уроке про кнопку без задержек.

Есть и обратная ловушка: команды вроде Serial.readStringUntil() или parseInt() ждут данные целую секунду, если их нет — таково значение по умолчанию. Секунда простоя в цикле часто выглядит как «плата стала тормозить».

Команды текстом: без класса String дешевле

Второй способ обмена — обычный текст с переводом строки в конце. Он удобен тем, что команды можно набирать руками в мониторе. Разбирать такую строку лучше в обычном массиве символов:

// Разбор команды из монитора порта без класса String:
// строка собирается в обычный массив символов, память не дробится.

char buffer[16];
byte length = 0;

void setup() {
  Serial.begin(9600);
  pinMode(13, OUTPUT);
}

void loop() {
  while (Serial.available()) {
    char c = Serial.read();

    if (c == '\r') continue;               // мониторы Windows шлют \r перед \n
    if (c == '\n') {                       // команда закончилась
      buffer[length] = 0;
      if (strcmp(buffer, "on") == 0) digitalWrite(13, HIGH);
      if (strcmp(buffer, "off") == 0) digitalWrite(13, LOW);
      length = 0;
    } else if (length < sizeof(buffer) - 1) {
      buffer[length++] = c;                 // копим символы
    }
  }
}

Одна тонкость: монитор порта добавляет к строке не только перевод строки, но может добавлять и возврат каретки — в Trema IDE это выпадающий список «Конец строки». Строка if (c == 0x0D) continue; в скетче делает разбор нечувствительным к выбору: без неё команда «on» превратится в «on» с невидимым символом на конце и не совпадёт ни с чем.

Тот же разбор через класс String — то же самое поведение, только вместо массива символов строка — занимает на 1 620 байт больше флеш-памяти: 3 474 байта против 1 854. Это 5 % всей памяти Uno за одну строчку удобства. И это ещё не всё: String занимает память по ходу работы, и в долго живущем устройстве она со временем дробится на куски. Для разбора коротких команд массив символов надёжнее.

Что купить для связи

Цены, артикулы и наличие — на 23.08.2026, магазин iarduino.ru. Первые три позиции нашего собственного производства.