Точечная перерисовка: обновляем только изменённые ячейки

Панель контроля зарядки: сверху бар из клеток и проценты, снизу статус и счётчик циклов. Первая версия переписывала всё целиком на каждом проходе loop: lcd.clear(), потом тридцать две ячейки заново. Экран стробил так, что коллега спросил, не бракованный ли дисплей. Браком оказался алгоритм: тридцать две записи ради двух изменившихся цифр, каждый кадр, без пауз.

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

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

Свои цифры снять несложно. Запишите millis() до кадра и после, разницу печатайте в Serial раз в секунду — это и есть ваш бюджет шины в миллисекундах. На моём стенде с Uno и клоном PCF8574 полный кадр с clear занимал порядка тридцати-сорока миллисекунд, точечный апдейт спокойной панели — две-четыре. Сравните кадр с периодом обновления: если кадр съедает треть периода, вы уже на полпути к стробу и зависшим транзакциям соседей по шине.

Начнём с даташита. Команда clear исполняется 1,52 миллисекунды — это голое время контроллера HD44780, ещё до всякой шины. Дальше шина: печать одного символа через PCF8574 — это несколько байтовых транзакций на полубайты со стробами, при 100 кГц на ячейку уходит порядка одной-двух миллисекунд в зависимости от библиотеки. Полный кадр 16×2 с clear перед ним — на практике десятки миллисекунд шины; точечный апдейт из четырёх-пяти ячеек — единицы.

Разница становится весом, когда на той же шине заводится жилец: датчик, часы, второй экран. При десяти обновлениях в секунду полная перерисовка держит шину занятой заметную часть времени и влезает в чужие транзакции; точечный апдейт — единицы процентов. Условие честности: цифры — для типичного клона на 100 кГц; на 400 кГц, куда некоторые гонят шину, всё делится на четыре, но клоны PCF8574 на повышенной частоте начинают чудить — я не поднимаюсь выше 100 кГц на шинах с двумя устройствами. Метеостанция из итогового проекта раздела как раз держала LCD и датчики на одном I2C, и часть странностей чтения ушла не со схемой, а вместе с лишними перерисовками.

Адресация при этом дешёвая: setCursor исполняется 37 микросекунд — как почти любая команда контроллера, кроме clear и home. Двигать курсор хоть на каждую ячейку — не трата; трата — переписывать неизменное. Поэтому в скетче ниже курсор дёргается часто, а за записями следит счётчик.

Как это выглядит у пользователя: полная перерисовка на общих проводах с датчиком даёт редкие, но регулярные подвисания чужих чтений, которые обычно списывают на плохой контакт. Точечный апдейт делает поток шины разреженным — в логическом анализаторе это видно сразу, а без анализатора его показывает тот самый счётчик записей за кадр.

Стратегий обновления три, и я держу их в голове как лестницу — от грубой к точной:

Паттерн — на три переменные: prevPercent, prevStatus, prevSpin. Перед записью сравниваем новое значение с кэшем: совпало — пропускаем, изменилось — пишем и запоминаем. Для бара добавляется арифметика клеток: переписываем только диапазон между старым и новым заполнением, клетка за клеткой. На спокойной панели девяносто процентов кадров заканчиваются нулём записей — шина молчит вместе с экраном, и это не оптимизация ради оптимизации, а запас на случай, когда шина понадобится чему-то ещё.

На моём зарядном приборе за минуту в спокойном режиме счётчик показывал три-пять записей на кадр и добрую сотню кадров с нулём: проценты в паузе не меняются, спиннер погашен, статус прежний. Такие нулевые кадры — цель дисциплины: экран живой для глаза, когда есть что показать, и невидимый для шины, когда показывать нечего. Раньше я мерил качество интерфейса картинкой; теперь мерю числом записей за кадр — картинка у всех одинаковая, а шине от неё дышится по-разному.

Таймеры кадра — на millis, без delay: в продвинутом разделе этому посвящён целый урок, а delay здесь съел бы и реакцию кнопки, и спиннер. Процесс растёт на свой тик, спиннер крутится на свой, кнопка опрашивается каждый проход loop — три независимых ритма на одной петле.

Вторая половина дисциплины — поля фиксированной ширины. Проценты живут в трёх знаках: 5 печатается как пробел-пробел-5, 100 — как есть. Без поля двузначное число после трёхзначного оставит прилипший хвост — та же механика, что с ведущими нулями в уроке про числа на LCD. Ширина поля известна заранее, хвосты затираются пробелами в момент записи, а не отдельным проходом по экрану.

Со статусом забота обратная: слово укорачивается. RABOTA — шесть знаков, PAUZA — пять, и без затирания от старого слова остаётся буква. Поэтому статусное поле пишется одной строкой фиксированной длины: PAUZA с запасным пробелом в конце. А спиннер в углу живёт по своему таймеру и меняет одну ячейку раз в 250 миллисекунд — единственная анимация, которая панели действительно нужна: палочка крутится, значит loop не завис.

Честности ради: точечный дифф нужен не всегда. Один виджет с обновлением раз в секунду — как термометр из урока про показания без мерцания — обходится печатью поверх без всяких prev-переменных: десяток ячеек раз в секунду не заметит ни глаз, ни шина. Дифф окупается, когда виджетов несколько, кадры частые, а шина общая.

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

Панель живёт в трёх ритмах на одной петле: процесс тикает каждые 150 мс, спиннер — каждые 250, кнопка опрашивается каждый проход. delay() разрушил бы все три сразу, поэтому вся петля стоит на millis. Спиннер у меня гаснет в паузе сознательно: пауза — тихий экран, и палочка, которая крутится просто по таймеру, а не по делу, лжёт ровно как фейковый процент.

Кэш после clear() — тонкое место. После полной перерисовки prev-переменные уже не совпадают с экраном, и дифф оставит дыры там, где решил, что ячейка не менялась. Поэтому при перезапуске я не просто обнуляю значения, а ставлю prevPercent и prevStatus в -1: любое реальное значение не совпадёт с минус единицей, и панель перерисуется вся — один раз, честно, без строба.

Кнопка в этой дисциплине ведёт себя прилично: статус печатается через тот же кэш, шесть ячеек один раз при смене. Если после нажатия в Serial прилетело KADR 32 IZ 32 — вы где-то потеряли prev-переменную. Счётчик работает детектором дыр в дисциплине, и за это его терпят в рабочих логах. Заодно ритмы задают и отладку: паузу видно по Serial, спиннер — по экрану, кнопку — по счётчику, и ни один из трёх признаков не мешает двум другим.