Монитор порта глубже: line ending и молчание parseInt

Скетч с Serial.parseInt() вы вчерашним вечером проверяли сорок минут: в мониторе печатаете 42, сервопривод должен качнуться на 42 градуса, а плата отмалчивается или отвечает нулём. Код правильный — я его тоже сначала переписал дважды. Виноват дропдаун у правого края монитора порта: настройка «Нет конца строки» после вашего числа не досылает ни одного байта, а parseInt останавливается только на нецифровом символе. Без него разбор тянется до таймаута — по умолчанию до тысячи миллисекунд — и возвращает ноль. Молча, без единого намёка в мониторе. Флешка-приём «переписать код» я тогда перепробовал весь, а поиски вёл не в том месте: в меню, а не в дропдауне на два сантиметра ниже.

Разбираю здесь три вещи, которые этот дропдаун трогает: какие байты монитор досылает за вас в четырёх режимах line ending, как устроен таймаут разбора и почему несовпадение скоростей вываливает кракозябры. Базовые кнопки монитора я показывал в уроке про первый выход на связь, а панель настроек IDE 2 и её отличия от старой версии — в уроке про монитор порта в IDE 2; здесь же — уровень байтов, на котором видно, почему команды молчат.

Вариантов в дропдауне четыре, и разница между ними — два байта максимум. «Нет конца строки» шлёт ровно то, что вы набрали: ни байта после. «Перевод строки» (NL, байт 10) добавляет десятый байт. «Возврат каретки» (CR, байт 13) — тринадцатый. «Оба NL и CR» — сначала 13, потом 10, два байта на каждую отправку. Плата получает эти байты честно, в приёмный буфер на 64 байта, а дальше всё зависит от скетча: собирать строку до перевода строки, вылавливать байт 13 или считать всё нецифровое признаком конца числа. В старых версиях IDE дефолтом стояло «Нет конца строки», сейчас свежие сборки обычно ставят NL — но проверьте свой дропдаун глазами, он помнит последний выбор.

Механику parseInt стоит проговорить вслух один раз, и все молчания перестанут быть мистикой. Функция пропускает нецифровые байты, собирает цифры в число и останавливается на первом нецифровом. Если буфер кончился, а конца числа всё нет, она ждёт: потолок ожидания в ядре Arduino — тысяча миллисекунд, меняется через Serial.setTimeout(). Отсюда два характерных симптома. Первый: число без хвоста разбирается с секундной паузой и нулём на выходе — таймаут выработался. Второй: между отправками проскакивает ровно секунда тишины, потому что каждая посылка доживает до потолка ожидания.

Тот же таймаут стоит за readStringUntil(10): не дождались байта 10 — через секунду функция отдаёт накопленное. Из-за этого команда on без конца строки срабатывает не в момент отправки, а когда вы пришлёте следующую строку: хвост догоняет голову, и «мёртвая» кнопка оживала сама. У меня она оживала ровно на второй команде, до того как я открыл дропдаун. Отдельная история — переполнение приёмного буфера: на Uno под приём стоит 64 байта, и посылки быстрее, чем скетч читает, обрезаются бесшумно. При 9600 бод канал наливает примерно 960 байт в секунду, значит скетч, который наведывается в приём раз в триста миллисекунд, успевает всё; плотный цикл без чтения переполняет буфер за сотую долю секунды. Диагностика простая: начало команды доходит, а конец нет — считайте байты между чтениями. Если шлёте числа пачкой, подряд и без разделителей, parseInt склеит их в одно — вставляйте между ними запятую или пробел: нецифровой байт закроет число раньше потолка ожидания. Глубже в приём по байтам копаю в уроке про available и read.

Вторая половина странных молчаний — кракозябры: вместо букв высыпает пепел из символов. UART не угадывает скорость: скетч говорит Serial.begin(9600), монитор крутит 115200 — кадры рассыпаются, потому что каждый байт едет кадром из десяти бит со старта и стопом, и слушатель отмеряет биты не там. Лечится сверкой двух цифр: что в begin, то и в дропдауне скорости. Классика жанра — скетч с чужого блога на 115200 при вашем мониторе на 9600: плата мигает, монитор печатает мусор, а вы греете подозрениями чип USB-UART, который ни при чём. Тот же мусор получается и на полуотжившем мосте USB-UART, но по полевой статистике девять случаев из десяти — скорость; начинайте с неё.

Поправка с границей применимости: платы с нативным USB — Leonardo, Micro, ESP32-S3 — скорость в мониторе игнорируют, там Serial едет по USB-кабелю как по шине, и 9600 против 115200 ничего не ломает. Для Uno, Nano и Mega с мостом USB-UART на борту скорость — договор двух сторон, и gibberish почти всегда её рассинхрон, а не сгоревшая микросхема. Какую плату и порт выбрал IDE, я вспоминал в уроке про выбор платы и порта.

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

Как я теперь держу приём. Дропдаун — NL всегда, независимо от проекта: единый выбор значит единый набор граблей. Строку беру readStringUntil(10) и сразу переприсваиваю trim: команда целиком, хвосты срезаны. Числа достаю toInt() из готовой строки — у него нет таймаутных сюрпризов, и мусор честно превращается в ноль на глазах. parseInt оставляю для потоков, где числа идут одно за другим от машины, а не от человека: там он быстрее ручной сборки, а его молчаливый ноль предсказуем, если разделитель гарантирован.

И второй пункт: лог-формат, машинно-читаемый. Пары имя=значение через пробел потом распарсятся в блокноте или скетче-логгере, а фраза «сейчас жду датчик» парсится только глазами. Сырую длину посылки печатаю рядом со счётчиком строк: прилипший CR виден как лишний байт, и спор «кто приклеил хвост» решается одним взглядом на stat. Настроенный один раз приём перестаёт быть источником вечеров — остаётся следить, чтобы обе стороны кабеля договаривались об одних и тех же байтах.