Планировщик задач на millis(): три таймера в одном loop

Теплица на моём подоконнике прожила на Uno два месяца спокойно, а сломалась в тот вечер, когда я решил добавить ей кнопку «полей сейчас». Схема была простая: аналоговый датчик влажности на A0, индикаторный светодиод, мигавший раз в полсекунды, чтобы было видно, что плата жива, и новая кнопка на пине 2. Мигалку я тогда писал честно, как умел: digitalWrite, delay(500), инверсия. Кнопку опрашивал в начале loop — один раз за оборот. Итог: из трёх нажатий срабатывало примерно одно. Палец держит кнопку 150–200 мс, а между опросами лежала пауза почти в 600 мс — кнопка жила в глухом окне, пока loop спал в delay.

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

Выход, к которому я пришёл, помещается в одну строку на задачу. В уроке про millis() вместо delay() мы держали одну пару «отметка lastRun + период» для одной мигалки. Планировщик — это несколько таких пар рядом: массив периодов PERIODY, массив отметок lastRun и один loop, который раздаёт ход задачам по расписанию. Ниже — как это выглядит целиком, сколько стоит каждая задача в микросекундах и правило, по которому заранее видно, что четвёртая и пятая задача ничего не сломают.

Механика — будильники на одном столе. millis() не знает про задачи: она просто возвращает миллисекунды с подачи питания. Таймером её делает пара переменных: отметка, когда задача последний раз запускалась, и период, через который её пора запускать снова. Условие millis() - lastRun >= PERIOD читается как «переросло — пора». Мигалка из урока про millis — один такой будильник; планировщик — три, пять, десять, но у каждой задачи своя пара, и они не знают друг о друге.

Почему «переросло», а не «равно». loop на Uno без delay крутится со скоростью порядка сотни тысяч оборотов в секунду, а период у датчика — 250 мс. Момент строгого равенства millis() - lastRun == PERIOD почти никогда не наступает: millis() тикает миллисекундами, а между двумя тиками loop успевает провернуть десятки оборотов. Условие со знаком «больше или равно» не требует поймать мгновение: как только разница доросла до периода — запускай.

Теперь про вычитание, которое выглядит опасно. millis() переполняется через 49,7 суток — об этом уже был разговор в уроке про millis. В беззнаковой арифметике unsigned long разность millis() - lastRun даёт правильный интервал и через момент переполнения: счётчик как будто склеивается, а расстояние между «было» и «сейчас» остаётся верным. Ломается здесь только прямое сравнение millis() > lastRun — его в планировщике нет и быть не должно.

И где здесь массивы. Задач три — пар «период + отметка» тоже три, и это буквально два массива по три ячейки: PERIODY и lastRun. Индекс — номер задачи. Цикл for перебирает номера, условие решает, пора ли, и вызов передаёт работу нужной функции. Каркас я взял из урока про массивы: там массив был партитурой маяка, здесь — расписанием.

Добавление четвёртой задачи — это ровно три действия: ячейка в PERIODY, ячейка в lastRun и ветка в zapuskZadachi. Сам loop не меняется никогда, и это главный признак того, что каркас собран правильно. Порядок обхода имеет смысл: задачи с коротким периодом ставьте в начало массива — они получают ход раньше и с меньшим сдвигом.

Про сдвиг честно. Отчёт в 25 символов на 9600 бод держит loop около 25 мс, и всё это время соседние задачи стоят в очереди: замер датчика, совпавший с печатью, доедет на 25 мс позже. Для периода 250 мс это десятая часть — на плоттере Serial Plotter такое видно как редкие зазубрины на ряде v=, но на поведение не влияет. Рабочее правило я вывел такое: суммарная работа всех задач за период должна быть в разы меньше самого короткого периода. У моей теплицы за секунду набирается около шести миллисекунд — два с небольшим процента от короткого периода в 250 мс, запас огромный.

И обратная сторона той же честности: девяносто девять процентов времени Uno крутится вхолостую — опрос кнопки по 5 мкс, повторённый сотни тысяч раз за секунду, съедает больше времени, чем все три задачи вместе. Это нормально и чинить это не надо: показатель здоровья цикла — не проценты загрузки, а самая длинная непрерывная работа. Пока она короче 100 мс, нажатие в 150–200 мс не потеряется никогда. Вырастет работа длиннее — а если появятся события, которые нельзя ждать вовсе, кнопку выносят на прерывание, как в уроке про attachInterrupt.

Последняя развилка — чем обновлять отметку. Вариант lastRun[i] = millis() простой: задача проснулась, отметилась, следующий период отсчитывается от «сейчас». Вариант lastRun[i] += PERIODY[i] держит средний период ровнее, но после любого зависания начинает догонять серией мгновенных прогонов подряд. Я всюду ставлю первый: задачи могут чуть опаздывать, но не мстят. А когда задачам понадобится собственная память состояний — сетка светофора, очередность фаз — следующий шаг по лестнице делает конечный автомат из урока про светофор, планировщик при этом остаётся прежним. Ниже — живая лаборатория: две одинаковые платы-мигалки, левая на delay, правая на millis, — пощёлкайте кнопки и посчитайте, кто из них теряет нажатия.