Прогресс долгой операции: проценты без мигания

Калибровка датчика давления занимает три минуты: 240 шагов с паузами по полсекунды. Первая версия показывала прогресс честно — lcd.clear() и полный кадр с процентами на каждом шаге. Экран мигал в такт шагам так, что коллеги из соседней комнаты спросили, не с демо-стенда ли я транслирую. Диагноз давно известен по уроку про мерцание: причины и лечение: clear стирает весь DDRAM и держит экран пустым дольше миллисекунды. Здесь частный случай, который встречается чаще всего: одна строка статуса на 16 знаков, из которых живые — четыре-пять. Так устроены прошивки, калибровки, заливка массивов в EEPROM, сушка датчика — всё, где loop делает одно и то же сотни раз.

Строка делится на две части. Слева статичный заголовок вроде ZAPIS EEPROM, который пишется один раз в setup и больше не трогается. Справа — окно перерисовки: четыре-шесть ячеек с процентами и счётчиком шагов. Обновляется только окно и только когда его содержимое изменилось; общий каркас с кэшем прошлого кадра разобран в уроке про точечную перерисовку — здесь уровень ниже: не панель целиком, а строчка из пяти знаков.

Числа ради масштаба: setCursor стоит 37 микросекунд, запись байта — ещё 37-43 по даташиту HD44780, разобранному в уроке про устройство контроллера. Окно из пяти знаков — это 200-400 микросекунд раз в секунду. Даже по I2C с накладными расходами — единицы миллисекунд против десятков на полный кадр. При периоде обновления в секунду мигать нечему: экран занят на три десятых процента времени. Для сравнения: полный кадр с clear на каждом шаге занимал у меня 28-35 мс по I2C — почти треть бюджета секунды.

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

Проценты из шагов считаются в целых: p = 100 * i / n. При 240 шагах часть значений пропускается — окно перескакивает с 37 на 38 и с 38 на 41; это нормально, если условие перерисовки — изменение числа, а не каждый проход loop. Поле держится фиксированной ширины в четыре знака: пробелы перед числом, число, процент — тогда переход 99 на 100 не оставляет хвостов. Про begin, setCursor и печать с выравниванием — в уроке про базовые команды.

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

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

Потенциометр в симуляторе меняет длительность шага от 5 до 60 мс — следите, как редко при медленном темпе трогается экран: на весь процент уходит пара записей ячеек. Кнопка запускает операцию, повторное нажатие сбрасывает, светодиод держится, пока запись идёт. Всё то же самое на плате — с реальной записью в EEPROM или на SD: окну всё равно, что считается шагами. Разброс темпа заметен и по Serial: при быстром шаге проценты бегут, при медленном счётчик записей падает до единицы — это лучший тест окна, чем любые слова.

Когда операция блокирующая — библиотека внутри держит loop сотни миллисекунд, — окно не спасёт: перерисовка просто станет редкой. Лечение одно: дробить операцию на шаги и разносить их по loop через millis, как любой планировщик без delay. Для записи в EEPROM и SD это работает напрямую; библиотечные функции с внутренними задержками придётся переписывать или принимать их темп.

Окно полезно не только процентам. Счётчик шагов STR 231/240 занимает девять знаков и честнее процентов, когда шаги неровные: зритель видит остаток, а не дёрганую шкалу. Я оставляю проценты для отчёта заказчику, а шаги — для себя в Serial; при отладке это две разные правды, и путать их не стоит. Тот же счётчик спасает при диагностике: если STR замер, а Serial молчит, вы застряли внутри шага, а не в печати — сразу видно, куда смотреть.

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

Наконец, граница применимости приёма. Если операция состоит из фаз разной длины — нагрев десять минут, выдержка две, спуск полминуты, — один процент на всю операцию врёт по построению. Тогда окно показывает фазу и её локальный прогресс: PHAZA 2/3 45%. Ячейки те же, заголовок меняется раз за фазу, и миганий по-прежнему нет. Фазу удобно держать в одной переменной со счётчиком: старший байт — номер фазы, младший — шаг внутри неё, и EEPROM получает одну запись вместо двух.

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

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

И последнее: окно любит ровные поля. Заранее прикиньте на бумажке в клетку, какие колонки строки живые, а какие статичные, и запишите колонку окна в константу — правка раскладки потом займёт минуту, а не пересчёт setCursor-ов по всему скетчу. Мой стендовый скетч держит окно в колонках 12-15, бар в 0-9, и эта раскладка пережила три переделки интерфейса без единой правки печати.