Выбор эффекта по Serial: команда меняет режим

Гирлянда на шкафу давно была готова к празднику, но жила по страшному распорядку: чтобы сменить эффект, нужно снять ленту, дотащить её до стола, шить десять секунд и вешать обратно. Пять минут телодвижений ради двадцати секунд результата — и я делал так до тех пор, пока не поймал себя на том, что не переключаю эффекты вовсе: лента годами крутит один и тот же дождь. Лечится USB-кабелем и протоколом из четырёх слов: печатаете «kometa» в монитор порта — лента переезжает на другой эффект. Всё для этого уже есть: строки из порта мы научились ловить в уроке про readStringUntil, а кадры эффектов собираем каркасом из урока про эффекты.

За три сезона я перепробовал для той самой гирлянды три интерфейса: ИК-пульт (терялся), энкодер (отвалился вместе с кронштейном) и Serial — он жив до сих пор, потому что ноутбук и кабель есть всегда. Для стола и отладки альтернативы Serial я не вижу: ноль новой электроники, протокол в три строки и каждое слово команды видно в журнале. А протокол прирос сам собой: сначала был только выбор эффекта, потом понадобились «погаси», «а какой щас включён?», «сделай побыстрее». Хороший Serial-протокол растёт как дом — комнату за комнатой, без перестройки фундамента, поэтому с первого дня в нём живёт ветка «не понял»: будущие расширения лягут в неё строкой кода, а не переписыванием.

Плейлист живёт в одной переменной mode: 0 — радуга, 1 — комета, 2 — искры, 3 — погасить. Каждый кадр loop() рисует ровно один режим в функции drawFrame() — та же дисциплина «одно место на одно действие», из-за которой кнопочный пульт в следующем уроке соберётся за десять минут: там поменяется только способ записи в mode, а рисование останется как есть. Команды — слова, потому что их набирает человек: raduga, kometa, iskry, stop. На любое незнакомое слово скетч не молчит, а отвечает подсказкой со списком — молчание в протоколе превращает опечатку в полчаса чтения кода.

Слово «режим» здесь не украшение. Худший вариант, который я видел (и сам писал): четыре эффекта прямо в loop() с собственными таймерами и флагами. Переключение ломает кадр посередине: старый эффект не «отпущен», новый не «взят» с чистого листа, и лента на полсекунды показывает кашу из двух. В переменной mode вся перезагрузка — одна строчка: следующий кадр начнётся с чистого буфера, потому что каждая ветка drawFrame() сама приводит ленту к своему виду — fill_solid для стопа, fadeToBlackBy для искр.

Отсюда мой тест на качество плейлиста: добавьте пятый эффект одной веткой в drawFrame() и одной строкой в if-цепочку. Если пришлось лезть в таймеры — каркас протёк; у нас всё дописывается в два места, и оба на виду.

Чтение устроено по трём правилам, каждое из которых — шрам. Первое: читать только когда Serial.available() > 0 — в уроке про available и read это байт-копилка, а здесь страховка от таймаута, о нём ниже. Второе: readStringUntil вызывается ровно один раз на команду и складывается в переменную — второй вызов в том же проходе увидит пустой буфер. Третье: сразу cmd.trim() — монитор порта подкидывает невидимые пробелы и возврат каретки, из-за которых «kometa» с хвостиком не равна «kometa», и команда тихо не срабатывает.

Радуга и искры здесь собраны из того же набора, что в уроке про fill_rainbow и искры на затухании — на живой плате в искры добавится random8() вместо random(), а в симуляторе и без него видно всё, что важно: смену режимов и честные ответы в Serial. Обратите внимание на дисциплину веток: каждая из них начинает с затирания или затухания, поэтому после «stop» радуга не вспыхнет поверх старого кадра, а выстроится с чистого буфера. Если добавить режим, который рисует поверх прежнего — например, вторую комету поверх радуги, — тогда затухание придётся делать условным, и это будет осознанное решение, а не случайный каше-кадр.

Теперь тот же протокол в симуляторе — и здесь он работает интерактивно: печатайте команду в строку монитора порта и жмите Enter, лента отвечает сразу. Попробуйте три сценария подряд: сменить эффект на ходу, послать незнакомое слово, спросить «?» — и заметьте, что анимация не замирает ни на мгновение: чтение порта сидит в том же неблокирующем loop() и не трогает таймер кадров. Заодно поглядите на ответы: у корректного обмена на каждую строку от вас есть строка от платы, и пустота в журнале — тоже диагноз.

Таймаутная ловушка стоит отдельным абзацем. На живой плате readStringUntil ждёт терминатор до 1000 мс по умолчанию: читать без проверки available() — значит платить секундой за каждый проход loop(), а монитор в режиме «Без знака окончания» не присылает терминатор вовсе, и каждая команда срабатывает с задержкой в секунду. Лечение бесплатное: available() перед чтением и режим «Новая строка» в мониторе. Таймаут настраивается и напрямую: Serial.setTimeout(50) режет цену промаха с тысячи миллисекунд до пятидесяти — я ставлю его в setup() во всех скетчах с readStringUntil и за полгода ни разу не пожалел. Если эффекты идут по тридцать кадров в секунду, секунда зависания выглядит как полный обморок анимации — и ищут его обычно в ленте, а не в порту. В симуляторе ниже поведение то же самое: движок честно выдерживает секунду ожидания, когда терминатора нет, так что привычку available()-перед-чтением можно наработать прямо здесь, на живом скетче.

Дальше протокол можно ужать или расширить. Числовые команды из урока про parseInt удобны, когда режимов много: «11» — «12» — «13» без всяких словарей. Для шести-семи эффектов мне хватает слов: они читаются в журнале сами, без легенды. А если каждый байт на счету — берите односимвольные команды «r», «k», «i», «s» и switch по cmd.charAt(0): одна команда на 9600 бод стоит миллисекунду против шести за «kometa», и при кадре в 30 мс это уже заметно. На 115200 бод разница исчезает, поэтому мой выбор по умолчанию — слова. И знак вопроса в таблице не случайно: справка — тоже команда, и её удобно проверять первой после каждой прошивки — она сразу показывает, что живой именно новый скетч.

Когда протокол переживёт первую неделю, придёт запрос «а сделай ярче». Удобная конвенция — команда-глагол и число-параметр в одной строке: «speed 3», «brt 120». Читается в два шага: до первого пробела — команда, остаток через parseInt — число, и вот погода скорости и яркости управляется тем же портом. Второй гость любого приличного протокола — команда status: она печатает mode= и параметры, и вечный вопрос «а какой эффект щас включён» снимается без вспомогательных светодиодов.

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