SerialEvent: асинхронная обработка входящих данных

Год я честно начинал каждый loop со строки if (Serial.available() > 0) — приём из первого урока про чтение команд. Потом в примерах самой Arduino IDE встретил serialEvent() — функцию, которую скетч не зовёт ни разу, а данные она почему-то принимает. Решив, что открыл настоящее прерывание, я порадовался: наконец-то приём не будет зависеть от того, чем занят основной цикл.

Тупик вскрылся на проекте с бегущей строкой: loop рисовал её кусочками по четыреста миллисекунд, и команды срабатывали с запозданием почти до секунды. Я полез в исходники ядра и нашёл правду: serialEvent — не прерывание. Это обычная функция, которую main() вызывает после каждого прохода loop(), и спящий loop тормозит её ровно как любую свою часть. Будь там настоящее прерывание из урока про attachInterrupt — задержки бы не было вовсе.

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

Схема на Uno двухэтажная. Нижний этаж — аппаратное прерывание UART: каждый принятый байт оно кладёт в 64-байтовый кольцевой буфер, тот самый из урока про буфер UART, и на этом его работа кончается. Верхний этаж — main(): выполнил loop(), спросил, есть ли байты в буфере, и если есть — позвал вашу serialEvent(). Один вызов на один проход цикла, не чаще и не реже.

Из схемы следуют три вещи. Первая: пока loop живёт — delay там или честный millis-планировщик, без разницы, — serialEvent не вызовется ни разу. Вторая: байты при этом не пропадают, нижний этаж работает всегда, но буфер ограничен: на 9600 бод байт стоит около миллисекунды, и 64 байта набегают за 64 мс молчания скетча. Третья: внутри serialEvent действуют те же запреты, что и в loop, — заняли его на секунду разбором, и весь скетч встал на секунду.

Где это живёт: ядро AVR — Uno, Nano, Mega — зовёт serialEvent всегда, если вы её описали. Ядро ESP32 такой функции не знает: скетч с serialEvent соберётся без единого предупреждения, но вызываться она не будет никогда. Моё мнение после одного молчащего переезда: приём пишу прямо в loop, а serialEvent считаю удобной локальной привычкой AVR-проектов — переносимый код не должен зависеть от вежливости ядра. У Mega, кстати, таких функций три: serialEvent, serialEvent1 и serialEvent2 — по одной на каждый UART, и зовутся они в том же проходе, одна за другой.

Приём команд — это вычерпывание буфера, сборка строки, парсер и исполнение — добрый десяток строк, как в уроке про командный парсер. Без serialEvent вся эта простыня открывает loop, и main-логика уезжает вниз экрана. serialEvent разделяет профессии: слушает — одна функция, работает — другая. В маленьких скетчах разница косметическая, в скетче на пятьсот строк — уже удобство. Заодно приём получает своё место в журнале: строки из одной функции легко искать глазами среди чужих и фильтровать при разборе.

Правило гигиены, которое я вывел из собственных грабель: в serialEvent только вычерпать буфер, накопить строку и поставить флаг; разбор и исполнение — в loop. Один раз я исполнял команду прямо в serialEvent — с пересчётом шкалы и печатью в пять строк, — и получил двойной вывод и зависший проход: serialEvent с длинным телом — это второй loop, только с сюрпризной точкой входа. Флаг решает: поймал строку, записал, вернулся.

Когда serialEvent бесполезен: если loop честный — без delay, всё на millis, как учил урок про планировщик, — то он ровно эквивалентен первой строке loop. Разница не в скорости, а в словах. Я выбираю по признаку «сколько чужих людей будут читать скетч»: для себя — if в начале loop, для урока или коллеги, привыкших к примерам IDE, — serialEvent, помеченный комментарием о переносимости.

Теперь заглянем в буфер во время тяжёлой работы. Пока loop занят, RX-прерывание продолжает складывать байты; как только 64 байта набрались, буфер перестаёт принимать: свежий байт отбрасывается на входе, старые лежат где лежали. Пропадает всегда хвост потока — самое новое. Поэтому спать надолго безопасно только при редком вводе: команда в десять-двадцать символов доживёт, поток телеметрии на 9600 бод порежется уже с первой сотни миллисекунд.

Второе следствие: длинный сон рвёт строки посреди слова. Пришло шестьдесят байт, буфер полон, а хвост команды ещё в дороге — добор отбросится, и вы соберёте обрубок. Лечится проверкой на внятность: обрубок не проходит словарь и получает ERR с эхом вместо исполнения. Задержку приёма помогает увидеть счётчик проходов: строка PRIEM n= показывает, между какими проходами приехала команда, — разница с моментом отправки и есть цена занятого цикла.

Движок симулятора serialEvent не вызывает сам — и мы не будем притворяться. В скетче ниже вызов вписан вручную последней строкой loop(), ровно в то место, где на реальной плате его ставит AVR-ядро: выполнили работу — спросили буфер — обработали. В журнале идут номера проходов loop n=: по ним видно, между какими проходами приехала команда, и что приём случился не мгновенно, а в конце текущей итерации. Разница между номером в loop n= и номером в PRIEM — это число проходов, которые loop прожил, пока ваша строка ждала.

Команда spat 3 укладывает loop в delay(3000) — изображает тяжёлую работу без планировщика. Отправьте svet 0 прямо во время сна: ответ придёт после пробуждения, потому что всё время сна serialEvent не звался, а строка ждала в буфере. Десять символов в 64 байтах доживают спокойно; поток телеметрии за три секунды сна не доживёт: 64 байта на 9600 бод полны за 64 мс, и всё, что сверх, отбрасывается на входе — старые байты лежат, свежие пропадают. Сон loop — это всегда торговля: сколько байт вы готовы потерять и чем это кончится для хвоста потока.