Свой класс Button: антидребезг как объект

Пульт на три кнопки я собрал за час, а ловил потом три вечера: первая кнопка изредка срабатывала так, будто её нажали на третьей. Виновника нашёл на бумаге, а не в железе: у меня были пары глобальных lastReading1, lastChange1, lastReading2, lastChange2, lastReading3, lastChange3 — и в одной ветке я читал состояние второй кнопки, когда думал про третью. Компилятор молчал честно: оба имени существуют, типы сходятся. Антидребезг при этом был написан по всем правилам — окно 50 мс на millis(), как в уроке про кнопку и digitalRead. Сломалась не логика, а раскладка: шесть переменных на кнопку, размазанные по файлу.

Класс — это способ сложить пин, сырую reading, стабильное состояние и метку времени в один пучок и больше их не рассыпать. Здесь мы соберём класс Button с методами begin(), changed() и isLow(), заведём массив из трёх кнопок и посчитаем честную цену — сколько байт RAM съедает каждый объект на Uno. Автомат на состояниях без классов я уже разбирал в уроке про кнопку-автомат — там та же механика жила в отдельных переменных; теперь она переезжает внутрь типа, а список глобальных ужимается до одной строки.

Оговорка про масштаб сразу: класс — не про «взрослый код ради взрослого кода». Две кнопки спокойно живут и на плоских переменных, и я не буду уверять, что ради них нужен тип. Рубеж, где пучок начинает окупаться, я для себя вывел на трёх: с трёх кнопок пары переменных перестают читаться с одного взгляда, и опечатка в индексе случается у каждого. Если у вас одна кнопка — урок про кнопку и digitalRead останется достаточным ещё долго.

Объявление класса выглядит как struct из урока про структуры, только после полей идут методы — функции, которые работают с полями своего объекта. У Button пять полей: пин, последний сырой уровень с пина, стабильное состояние, метка millis() последней смены и окно антидребезга. Конструктор с двумя аргументами заполняет их при создании — кнопка рождается уже настроенной, а не обрастает флагами по ходу скетча. begin() переносит в себя pinMode(INPUT_PULLUP) — ту подтяжку, что держит линию HIGH, пока кнопка не замкнёт её на землю.

Рабочая лошадь — changed(): читает пин, следит за дребезгом через окно debounceMs, отсчитанное от последней смены уровня, и возвращает true ровно один раз — на смене стабильного состояния. Все остальные проходы loop() получают false и не засоряются проверками. Методы, написанные прямо внутри тела класса, компилятор разворачивает на месте вызова — inline по умолчанию, и вызов knopki[i].changed() стоит столько же тактов, сколько ручной if с теми же переменными. Я сверял листинг для пары методов: тот же машинный код, что у плоской версии, отличается только раскладка исходника.

Три кнопки — это массив объектов: каждая создаётся конструктором со своим пином, а setup() сжимается в цикл for из трёх строк. Хотите четвёртую кнопку — дописываете элемент в массив и меняете потолок цикла; в глобалах не возникает ни одной новой переменной. Обработка событий живёт там же, в цикле: changed() вернул true — смотрим isLow() и решаем, что делать. Это ровно та раскладка, которой не хватало пульту из первого абзаца: состояние кнопки одно, у него одно имя и один владелец.

Метка lastChange хранится в unsigned long — и это не прихоть: millis() переполняется на 49,7 сутки, и сравнение в лоб с int сломалось бы через двое суток непрерывной работы; механика переполнения разобрана в отдельном уроке, а разность millis() - lastChange корректна в любом моменте цикла. Окно 50 мс — ходовое для тактильных кнопок: дребезг дешёвой тактовой укладывается в 5-20 мс, и запас двойной. Мокрым кнопкам в подвале ставьте 100 мс: контакт окисляется, и паразитные фронты прилетают пачками.

Отдельно про подтяжку, потому что класс прячёт её в begin() — и прятать опасно без понимания. Пин без подтяжки висит в воздухе: пока кнопка не нажата, вход читает то HIGH, то LOW от наводок, и changed() стреляет сама. INPUT_PULLUP в begin() решает это для всех кнопок сразу — и ровно поэтому у changed() в коде нет ни одной настройки режима вне класса. Если пойдёте на внешние резисторы 10 кОм и обычный INPUT, правка тоже живёт в одном месте — в begin().

Теперь цена. sizeof(Button) печатает девять: byte pin — 1, byte lastReading — 1, byte stable — 1, unsigned long lastChange — 4, unsigned int debounceMs — 2. Выравнивания на AVR нет, поля лежат вплотную, поэтому честно девять, а не двенадцать. Три кнопки — 27 байт из 2048 RAM Uno, полтора процента памяти. За эти байты вы получаете один список полей вместо девяти разрозненных глобальных, опечатки в именах, которые ловятся при сборке, и begin() с changed(), которые не рассыпаются по файлу. Плата с десятью кнопками съест девяносто байт — всё ещё меньше пяти процентов, и масштаб сохраняется линейно.

Класс растёт естественно. Понадобился подсчёт нажатий — добавили поле count и метод reset(); понадобился длинный фронт — метод pressedFor(), который отдаёт millis() - lastChange, пока кнопка в нажатом состоянии. Поля и методы прирастают к тому же пучку, и соседний код при этом не меняется вовсе: loop() по-прежнему спрашивает changed(). На пульте из первого абзаца я заодно получил свободно третье поведение: двойное нажатие отличил по времени между двумя срабатываниями changed() — таймер уже был внутри объекта, писать его заново не пришлось.

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

Виртуальных методов у класса нет — а значит нет и vtable, скрытой таблицы указателей, которая добавляет два байта к каждому объекту и лишний прыжок в вызове. Добавите virtual — расклад изменится; для кнопок он не нужен ни при каком сценарии. Вторая граница — динамическая память: new на 8-битных AVR ненадёжен, у чипа нет защиты от фрагментации кучи, и сообщества embedded-C++ это признают прямым текстом. Все объекты здесь статические: объявлены на верхнем уровне, живут от включения до выключения питания, heap не трогают.

Передавайте объект в функцию по ссылке из урока про указатели и ссылки: nastroit(Button& k) работает с оригиналом, а не с копией из девяти байт на каждый вызов. Если функция только читает поля — пишите const Button&: попытку испортить объект компилятор поймает при сборке. И держите методы короткими: changed() на десяток строк — норма; метод на полтора экрана — сигнал, что внутри просится отдельный класс или обычная функция.