Первый запуск: свежая EEPROM из 0xFF и версия конфига

Плата с склада, свежая прошивка, первое включение — и на экране порог 255, калибровка -1, а термостат уже бьётся о несуществующие границы. Классика первого запуска: EEPROM после заводского стирания читается как 0xFF во всех 1024 ячейках, и любой код, который верит прочитанному без проверки, получает мусор с уверенным видом. У меня однажды такой мусор перекалибровал датчик так, что показания уехали на десяток градусов: сутки я искал причину в датчике и проводах, а лежала она в четырёх байтах, которые никто никогда не записывал.

Инструменты проверок у нас уже есть: magic-байт и дефолты из урока про magic-номер, put и get структуры из урока про конфиг-структуру. Здесь собираю из них полный сценарий первого запуска: сырые байты свежей памяти, версия конфига как главный вопрос о том, что вообще лежит, миграция между версиями и осознанный сброс к дефолтам. Ниже — одна структура на четыре ветки чтения; она же — главная функция любого моего проекта с настройками, от ночника до термостата.

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

Свежая ячейка EEPROM хранит 0xFF: стирание ставит все восемь бит в единицы, а запись умеет лишь превращать единицы в нули. Поэтому 0xFF — признак нетронутой памяти, а 0x00 — признак записанного нуля, и это разные состояния. Читая 0xFF разными типами, получаем разный мусор: uint8_t даст 255, int16_t — -1, четыре байта 0xFFFFFFFF как float — NaN. Порог 255 всегда больше любой температуры, смещение -1 тихо кривит калибровку, NaN отравляет арифметику — каждое из значений без проверки ломает логику по-своему. Проверить свой мусор легко: прочитайте сырой байт и напечатайте в HEX — FF после заводского стирания ни с чем не спутается.

EEPROM.get копирует в структуру sizeof байт подряд, и на свежей памяти все поля окажутся 0xFF — библиотека честно отражает память, а не ломается. Вопрос не в том, как читать, а в том, как отличить «конфига нет» от «конфиг есть и валиден». С типами и их байтовыми лицами мы разбирались в уроке про int и float по байтам; здесь за ответ отвечает версия конфига. Практическое следствие: любые вычисления с прочитанными полями — только после проверки версии, иначе NaN отравит и среднее, и порог, и всё, что от них зависит.

Первым полем структуры кладу uint8_t ver. Свежая память даёт 255: такого номера не существует по определению, значит — дефолты и первое сохранение. Совпадает с TEK_VER — конфиг записан скетчем той же сборки, грузим как есть. Ниже — конфиг от старого скетча: перетаскиваем существующие поля, новым назначаем дефолты, версию поднимаем и сохраняем. Выше — конфиг от более нового скетча, чем этот: молча грузить нельзя, поля могли сместиться; безопаснее дефолты и громкое сообщение в Serial. Номер версии — обычный uint8_t: место копеечное, а смысл ветки чтения определяется одним сравнением.

Версия снимает и вопрос обновлений: добавили поле — подняли версию, и платы в поле при первом запуске нового скетча мигрируют сами, без визита с кнопкой. Сброс к дефолтам при этом не провал, а сценарий: кнопка заводского сброса из урока про заводской сброс вызывает ровно ту же ветку, что и ver = 255, — один код на оба случая. Если версий уже накопилось две-три, миграция делается цепочкой: пока ver меньше текущего, применяете шаги следующей версии и поднимаете номер — цикл while с переключателем шагов короче, чем лесенка if для каждой версии отдельно.

Главная грабля миграции — порядок полей. Структура хранится байтами подряд, и перестановка существующих полей читает старый конфиг по новым адресам: порог возьмёт чужое смещение, смещение — мусор из-под порога. Правило жёсткое: новые поля добавляются в конец, версия растёт на единицу, порядок и типы старых полей не меняются никогда. На AVR поля структур лежат подряд без выравнивания, но sizeof(Konfig) напечатайте в Serial один раз — эта цифра понадобится при разводке адресов соседей по памяти. Третья грабля тише остальных: структуру меняют, а адреса соседей по памяти не пересчитывают. Если конфиг лежит с адреса 0 и вырос с четырёх байтов до восьми, он съест соседние ячейки — счётчик перезаписей из первого урока начнёт жить внутри порога. Разводите адреса с запасом и после каждого роста структуры сверяйте карту памяти.

Вторая грабля — ver выше TEK_VER. Сценарий живой: шили новый скетч, потом откатились старым. Молчаливый сброс безопасен, но нечестен к пользователю — печатайте в Serial, что вернули дефолты и почему. Совсем аккуратно поверх версии ложится контрольная сумма: она ловит и недописанные слоты wear leveling из прошлого урока — связка версии с CRC разобрана в уроке про целостность настроек. Проверка на столе: поменяйте местами два поля и запустите скетч на памяти с валидным конфигом — печать сырых байтов покажет тот же сдвиг, который увидит плата.

Отладка первого запуска начинается с сырых байтов: печатайте первые sizeof(Konfig) адресов в HEX до всякого get. Свежая память покажет столбик FF, после первого сохранения — версию и поля, после кнопки стирания — снова FF. Одна печать различает «память стёрли» и «конфиг потерялся по дороге», а заодно проверяет sizeof. Задавать конфиг по-человечески удобно с терминала — приём из урока про конфигуратор по Serial.

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