Кракозябры в мониторе: скорости, биты и рассинхрон

Скетч из чужой статьи был скопирован символ в символ: код, схема, даже порядок проводов. Плата отрабатывала как в статье, а в мониторе вместо строки статуса шла каша — вопросики, стрелочки, обрывки цифр. Скорость в списке монитора я тогда не трогал вовсе, потому что не знал, что она там есть: список стоял на 115200, скетч просил 9600, и оба устройства были технически исправны — передатчик честно клал биты на провод, приёмник честно брал их мимо. Первая помощь описана в уроке про первый разговор с портом: сверьте два числа. Здесь разберёмся глубже — почему несовпадение даже на два-три процента роняет байты, где предел у скорости и длины провода и на каком кварце вас ждёт каша при любой скорости из списка.

Механика короткая, и её полезно держать в голове целиком. Байт на проводе — не восемь бит, а десять: стартовый ноль, восемь бит данных, стоповая единица. При 9600 бод бит длится 104 микросекунды, кадр — около 1,04 мс, значит канал отдаёт 960 байт в секунду. Приёмник засекает фронт стартового бита и берёт каждый следующий бит в середине его длительности. Погрешность такта накапливается от бита к биту, и к десятому она обязана остаться меньше половины бита — иначе приёмник возьмёт стоповый бит мимо и склеит мусор из двух соседних кадров.

Отсюда главный бюджет линии: на пару передатчик-приёмник остаётся примерно ±2-3 % расхождения тактов, по полтора процента на сторону. Важное следствие, которое часто пропускают: сдвиг фазы UART прощает, а неверную скорость — нет. Каждый кадр выравнивается по стартовому фронту, поэтому один случайный сбой лечится сам собой на следующем байте; а скорость, отличающаяся в полтора-два раза, портит все биты подряд — из такой каши не вырвать ни одного символа. Диагностику живой линии с осциллографом и без мы делали в уроке про диагностику UART, здесь — та же физика со стороны чисел.

Запись Serial.begin(9600) прячет за собой договор из трёх пунктов: 8 бит данных, без бита чётности, один стоповый бит — режим 8N1, третий аргумент с умолчанием SERIAL_8N1. Девять из десяти устройств говорят именно так, поэтому ручку трогать не приходится. Но она есть: серийные приборы вроде промышленных метеостанций частенько просят 7E1 — семь бит с чётностью, — и тогда пишут Serial.begin(9600, SERIAL_7E1). Если скорость совпала, а в строке всё равно битые символы, проверьте чётность: это вторая по частоте причина после самой скорости.

Служебные биты кадра — это налог, который платят всегда: из десяти бит байта два не несут данных, то есть двадцать процентов провода уходит на разметку. Чётность, если она включена, добавляет девятый бит: передатчик досчитывает единицы в байте и ставит чётность так, чтобы их стало чётное число, приёмник пересчитывает и сверяет. Один бит ловит одиночный сбой, но не двойной, и приборы с чётностью на коротком USB-проводе мне не встречались ни разу — там хватает 8N1. Стоповая единица заодно работает разделителем: линия между кадрами висит в единице, и приёмник по этой паузе понимает, где кончился один байт и ещё не начался другой.

Вызывать begin нужно один раз в setup: повторный вызов глушит порт на время переконфигурации и роняет то, что ещё не уехало из буфера. Сменить скорость на ходу можно парой Serial.end() и begin с новым числом, но в обычном скетче это не нужно — скорость выбирается под задачу один раз и живёт до перепрошивки. Мой критерий выбора простой: свой отладочный вывод по USB — 115200, чужие модули — их заводская скорость, обычно 9600. Гнаться за максимумом ради максимума смысла нет: на 9600 строка лога в тридцать символов занимает 31 мс провода, и для глаза это мгновенно.

Отдельная ловушка — плата с чужим кварцем. Pro Mini и клоны продаются в версиях на 16 и на 8 МГц, внешне неразличимых, и восьмимегагерцовая, запущенная со скетчем под 16, уронит скорость вдвое: генератор baud rate считает от тактовой частоты, и каждый бит растянется в два раза против расчётного. Монитор сшивает из растянутых бит по два одинаковых — на экране повторяющаяся каша, которую отличить от обычной можно по регулярности. Симптом-маяк такой: мусор при любой скорости из списка, не только при неверной.

Проверка занимает минуту: скетч просит 115200 — поставьте в списке 57600. Если текст ожил, тактовая частота вдвое ниже расчётной, и лечится это не списком, а правильной платой в меню Tools. Есть и маячок попроще, без монитора вообще: мигалка с delay(1000), собранная под 16 МГц, на восьмимегагерцовой плате мигает раз в две секунды — delay откалиброван той же константой F_CPU, что и генератор скорости. После того как частота сходится, мусор при совпавшей скорости ищите уже не в линии, а в кодировке: кириллица в UTF-8 против CP1251 даёт ровно такие же закорючки, и мы разобрали это в уроке про кириллицу и кодировки.

У скорости и длины провода общий бюджет. TTL-линия на 5 вольт с обычными проводами держит 115200 на тридцати сантиметрах без вопросов; на метре-двух я опускаюсь до 9600 — ёмкость кабеля размывает фронты, и чем короче бит, тем легче ему превратиться в соседний. Классический RS-232 с уровнями ±12 В по старому стандарту тянет 15 метров на тех же 9600; длинную дистанцию в TTL-мире несёт не скорость, а конвертер — USB-адаптер или пара чипов MAX485. Отдельная цифра из чужого мира: MIDI живёт на 31250 бод, скорость зашита в стандарт, — про неё был отдельный урок.

Виртуальные порты выкидывают всю эту арифметику: у Leonardo и ESP32 главный Serial — это USB-CDC, скорость в списке монитора игнорируется, и кракозябры от несовпадения там невозможны в принципе; устройство такого порта мы разбирали в уроке про Leonardo и ESP32. Обратная сторона той же медали: порта нет, пока скетч не стартовал, и первые строки после перезагрузки теряются. Bluetooth-модули вроде HC-05 живут на своей заводской скорости, но сидят на макетке рядом с платой — правила TTL-линии для проводов к ним снова в силе, просто провод короткий.

Последнее правило пары: числа совпадают на обоих концах. В связке из двух плат по уроку про связь двух Arduino каша лечится тем же списком — скетч первой платы и скетч второй просят одно и то же число, и терминал тут третий участник, если вы смотрите на обмен со стороны. Терминалы вроде PuTTY держат собственный список скоростей, отдельный от скетча: я дважды терял вечер на то, что PuTTY стоял на 9600, а скетч — на 115200, при идеально совпавших платах. Уровни тоже вносят вклад: линия между 5-вольтовой платой и 3,3-вольтовым модулем работает, но на границе бюджета, и длинный провод добавляет ту каплю, которой не хватало для каши.

Если перевести физику кадра в числа настоящей линии: при 115200 бит длится 8,68 микросекунды, и приёмник должен попасть в его середину с точностью до пары микросекунд — отсюда и жёсткий бюджет такта. При 9600 окно вдвое мягче: бит 104 микросекунды, ошибки кварца в десятые доли процента не успевают испортить даже последний бит кадра. Именно поэтому девять из десяти моих сборок с чужими модулями живут на 9600: запас такта десятикратный, провода прощаются, и скорость вспоминается только тогда, когда лога становится по-настоящему много.

Служебные двадцать процентов — ещё один аргумент не гнаться за бодами там, где данных мало: на 9600 по проводу проезжает 960 байт в секунду, а «чистыми» из них — 768, остальное разметка кадра. Для лога в строку в секунду разница между 9600 и 115200 невидима; для плоттера, заливающего сто точек в секунду, — уже судьба, и там 115200 оправдана полностью. Спорить о «правильной» скорости — всё равно что спорить о передачах на велосипеде: важен рельеф, то есть сколько байт в секунду реально производит ваш скетч.