SoftwareSerial: второй UART на любых пинах

Метеостанция на подоконнике прожила у меня две недели в режиме «снимаю показания кабелем»: датчик CO2 MH-Z19 требует собственный UART, а на Uno он один. Пины D0 и D1 — это и есть Serial, тот самый, через который плата разговаривает с компьютером, и я воткнул TX датчика прямо в D0. Некоторое время я даже любовался цифрами в мониторе. Потом пришло время обновить скетч — и заливка упала. Не один раз, а пять попыток подряд: загрузчик рапортовал про таймауты, светодиод L нервно мигал. Датчик, сидящий на пинах прошивки, слушал загрузчик и лез в разговор со своими байтами.

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

Ответ старше Arduino на десятилетия: второй порт, который не мешает прошивке. Аппаратный у Uno один, зато программный можно вырастить почти на любом пине: библиотека SoftwareSerial.h из комплекта IDE поднимает полноценный Serial на двух цифровых пинах по вашему выбору. Скорость — скромнее, дисциплина в скетче — строже, но для датчика, GPS-приёмника или Bluetooth-модуля этого хватает с запасом. В этом уроке ставим второй порт, учимся не путать RX и TX и честно считаем, сколько байт он успевает принять, пока loop делает свои дела.

Аппаратный UART Uno — это пины D0 (RX) и D1 (TX). Через них же работают USB-чип и загрузчик: при каждой заливке по линии летит около 115200 бод прошивки, и любой собеседник на этих пинах получает её фрагменты вместо ожидаемых данных, а загрузчик — чужие байты вместо своих. Отсюда правило, которое я вывел за тот вечер с таймаутами: периферию на D0/D1 не вешаем вообще. Ни датчик, ни GPS, ни дисплей с UART-интерфейсом. Два провода, выдёргиваемые перед прошивкой, — это не решение, а залог новых забытых проводов.

SoftwareSerial идёт другим путём: у него нет аппаратного передатчика, обычный цифровой пин переключается программно, с точностью до долей микросекунды. Приём ведётся по прерыванию от смены уровня на пине — механизм из той же семьи, что и прерывания attachInterrupt, только спрятан он внутри библиотеки. Вы пишете знакомые bt.available(), bt.read() и bt.println(), а библиотека щёлкает пинами сама. Ставится она одним include; если вы ещё не трогали сторонние библиотеки, порядок действий разложен в уроке про библиотеки в IDE, но SoftwareSerial к ним не относится — она уже в комплекте.

Объявление — одна строка: SoftwareSerial bt(10, 11). Порядок аргументов — RX, TX: сначала пин, на котором порт слушает, потом пин, на котором говорит. bt.begin(9600) — и дальше API совпадает с Serial один в один: print, println, read, available, readStringUntil — всё то же, что мы прошли в уроке про чтение данных из порта. Значит, командный словарь из урока про парсер пересаживается на второй порт почти без правок: поменять имя объекта, и всё.

Соединение — крест-накрест: TX одного конца идёт в RX другого. Мой личный тупик длился один вечер: я подключил RX модуля к пину 11 — «ну это же тоже передача, что-то общее» — и слушал тишину, пока не взял карандаш и не нарисовал два бокса со стрелками. Стрелки пересекаются. Всегда. TX модуля — в пин 10 (RX скетча), RX модуля — в пин 11 (TX скетча), земля — общая, без неё порт читает кашу. Пины выбираем любые цифровые от 2 до 12: 0 и 1 заняты аппаратным портом. Аналоговые входы A0–A5 тоже годятся — digitalWrite на них работает, хотя выкидывать аналоговые каналы ради порта расточительно; я держал второй порт на 10 и 11 годами и ни разу не пожалел об этой паре.

Со скоростями честнее сразу: чем выше бод, тем точнее должен щёлкать пин, а точность программного порта конечна. На передачу SoftwareSerial дотягивает до 115200, но приём выше 38400 уже сыплет битыми байтами — цифры в таблице проверены на Uno с Bluetooth-модулем и GPS-приёмником. Для HC-05 из следующего урока берите 9600: заводская скорость этого модуля в режиме данных именно такая.

Первая грабля проявляется, когда портов становится три. SoftwareSerial умеет несколько экземпляров, но слушать в каждый момент может только один — тот, что вызвал listen(). Данные неслушающего порта теряются молча: без ошибок, без уведомлений. Я собрал GPS и Bluetooth на одной плате и полдня не понимал, почему GPS молчит, а телефон работает: оба порта были подключены, но слушал только тот, кто начал последним. listen() — это переключатель канала, а не разветвитель.

Вторая грабля — время. Буфер приёма у SoftwareSerial — 64 байта, те же, что мы считали в уроке про буфер UART. При 9600 бод буфер наполняется за 64 символа, то есть примерно за 67 мс. Мой delay(100) между опросами датчика гарантированно терял хвост строки: пока loop спал, порт принимал, а потом очередь переворачивалась. Лечение одно: миллисекундный таймер вместо delay и bt.read() в каждом обороте loop.

Третья грабля — на отправке. TX у SoftwareSerial не буферизуется: println из тридцати символов при 9600 бод занимает около 31 мс, и всё это время библиотека держит прерывания, чтобы не смазать фронты битов. millis() за эти тридцать одну миллисекунду отстаёт ровно на столько же. Для строки раз в секунду это незаметно; для печати в горячем цикле — уже тормоз. Отсюда моё правило: во второй порт пишем редко и осмысленно, в монитор — сколько влезет.

У симулятора этого самоучителя есть честное ограничение: SoftwareSerial в движке не поддержан, второй порт он не изображает. Поэтому тренажёр проверяет не пины, а то, ради чего SoftwareSerial вообще заводят: протокол «команда — ответ» с другим собеседником. Скетч ниже эмулирует модуль на втором порту: вы печатаете команду в монитор — как будто переслали её через мост из скетча выше, — а «модуль» отвечает строкой с парой имя=значение, латентностью ms= и счётчиком принятых байтов bajt=. На реальной плате между этими строчками и встаёт SoftwareSerial bt(10, 11).

Команды три: ping — проверка живости, temp — показание датчика, ver — версия прошивки модуля. Незнакомая строка получает err neizvestno — так же, как отвечал настоящий парсер. И посмотрите на ms=: на 9600 бод команда temp из четырёх символов едет до модуля около четырёх миллисекунд, ответ — столько же обратно; симулятор показывает меньше, потому что эфир в нём не эмулируется, зато пары имя=значение строятся в плоттере рядами без единой правки.