EEPROM.put и get: структуры одним вызовом

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

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

Ящик называется struct, а переносят его в память две функции: EEPROM.put и EEPROM.get. Один вызов пишет всю структуру целиком, один вызов читает её обратно, раскладку по байтам делает компилятор. В этом уроке соберём блок настроек с контрольным и версионным байтами внутри, посчитаем его размер и научимся менять раскладку, не теряя данные пользователей.

Честная оговорка про симулятор: put, get и sizeof структур движок не поддерживает — он умеет read, write, update и length. Поэтому в сим-блоке мы соберём ручную модель блока настроек на отдельных ячейках с обменом парами «адрес — значение» через Serial: на ней видна вся механика, которая под капотом put и get.

Структура — это тип, склеенный из полей любых других типов: байты, целые, дробные, массивы фиксированной длины. С точки зрения EEPROM она просто кусок памяти известной длины: сколько байт занимает структура, подсказывает sizeof, и на платах AVR это почти всегда сумма размеров полей. Схема работы: в setup() читаем ящик get-ом, в момент изменения настроек пишем его put-ом целиком. Никаких /256, никаких пар адресов — имена полей вместо адресов.

Самое приятное — внутри. EEPROM.put разбирает структуру на байты и пишет их через update-семантику: неизменившиеся байты пропускаются, ресурс ячеек не тратится. То есть перезаписать весь ящик из восьми байт ради одного изменившегося поля — нормальная практика: реально перезапишутся один-два байта. Это снимает страх износа, о котором мы считали в уроке про ресурс.

Внутрь структуры сразу кладём два служебных поля: magic-байт и версию раскладки. Magic отличает первый запуск от данных: свежая EEPROM читается нулями-единичками, и если magic не совпал — ящик пуст, ставим дефолты. Версия пригодится, когда раскладка поменяется: именно об этом моя история с поливалкой.

Пара слов о происхождении, чтобы вы не удивлялись чужому коду. Раньше библиотека умела только read и write, и в каждом втором проекте жила скопированная функция EEPROM_writeAnything — шаблон, который резал структуру на байты указателем. С версии IDE 1.6.0 put и get вошли в библиотеку и сделали приём стандартным: те же байты, тот же порядок, но без ручных указателей и без копипасты из форума десятилетней давности. Старые скетчи при этом пишут те же байты, что и put, — раскладка полей не менялась, так что настройки, записанные старой функцией, прочитаются новым get-ом.

Разбор одной строки, самой важной: EEPROM.get(addrBox, box). Функция смотрит на тип box, вычисляет его размер — sizeof(Settings) на Uno даст восемь байт: один на magic, один на version, два на int, четыре на float — и читает ровно столько ячеек подряд, раскладывая по полям. AVR кладёт поля структуры вплотную, без выравнивающих дырок, поэтому ручная арифметика из урока про побайтовую запись здесь не нужна. Но заметим: дамп структуры с одной платы нельзя вслепую читать на плате с другой архитектурой — там внутри структуры возможны выравнивающие байты, и раскладка поплывёт.

Проверка box.magic != 170 заменяет все проверки «а пустая ли память»: get на свежей плате вернёт в magic что-то другое — чаще всего 255 — и код сам поставит дефолты и тут же запишет их put-ом. Первый запуск самообслуживается, все следующие читают то, что пользователь настроил. Ровно та же идея magic-байта из первого урока, только теперь он едет внутри ящика и не занимает отдельный адрес вне раскладки.

Где это пригождается кроме настроек: профиль пользователя, расписание полива, таблица калибровок, последний экран меню. Везде, где данных больше одного байта и они меняются вместе. Для пересылки таких же структур между платами взгляните на урок про передачу структур по UART — там те же struct и sizeof, но вместо EEPROM — сериал.

И про безопасность раскладки на будущее. Байт version в структуре — страховка от моего балконного конфуза. Правило такое: любое изменение состава или смысла полей — новый номер версии. При старте читаем ящик и смотрим обе контрольки: magic говорит «здесь вообще были настройки», version говорит «они в той раскладке, которую ждёт этот скетч». Не сошлось — не читаем поля наугад, а конвертируем или сбрасываем. Именно сброс честнее всего, если старые данные нельзя однозначно распознать: пользователь потратит минуту на настройку, а не неделю на поиск причины странных порогов.

И да, put перезаписывает весь ящик — все восемь байт при изменении одного поля. Но вспоминаем update-семантику: реально перезапишутся только отличившиеся байты. При записи раз в час такой блок переживёт и вас, и ваших внуков.

Присмотритесь к ответам симулятора: ok=1 addr=10 val=220 — это ровно то, что делает put, только в микромасштабе. Один байт по одному адресу за один вызов. Настоящий put делает то же самое восемь раз подряд — по числу байт структуры, — но адреса и границы вычисляет компилятор из sizeof, а не ваша голова. Если протокол «адрес — значение» показался удобным, в уроке про командный парсер на его основе собирается полноценное текстовое меню: имена команд вместо чисел, валидация, ответы.

И границы метода. EEPROM идеален для ящика на десятки байт, который меняется от раза в минуту до раза в месяц. Когда настроек становится сотни или их нужно отдавать наружу — выгружать на компьютер, редактировать в файле, — то же самое содержимое удобнее держать в CSV на карте памяти, как в уроке про конфиги на SD. EEPROM — для маленького и горячего, SD — для большого и переносимого. Между ними целый класс гибридов: настройки в struct на EEPROM, журнал измерений — в файл, и скетч при старте первым делом проверяет оба источника.

И не забудьте про соседей: ящик настроек занимает адреса с нулевого и дальше на sizeof байт. Всё, что живёт в EEPROM помимо структуры — счётчики, калибровки, ротационные блоки, — располагайте после addrBox плюс sizeof(Settings), а не по привычным адресам с прошлого скетча. Один sizeof в константе — и добавление нового поля в структуру не сломает соседей по памяти. Карту памяти руками мы вели в прежних уроках — здесь её ведёт компилятор, пользуйтесь этим.

Раздел сложился в полный конструктор: в первом уроке — байтовые настройки и гистерезис, во втором уроке — счётчики и двухбайтовая арифметика, здесь — ресурс памяти и ящик-структура одним вызовом. Дальше по курсу эти знания работают в связке: логгер, который хранит калибровки в EEPROM и пишет поток на SD-карту, переживает и отключения питания, и десятки тысяч записей — потому что каждый тип данных живёт там, где ему по ресурсу комфортно. Соберите свой блок настроек на struct — и мои балконные грабли останутся только в истории.