Эмуляция EEPROM на ESP32: Preferences

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

Тупик разрешился чтением, а не паяльником. EEPROM.h в ядре ESP32 существует, но это эмуляция: библиотека держит буфер в оперативной памяти и сносит его во флеш только по явной команде commit(). Мой скетч буфер обновлял, а команду сохранения не давал никогда — отсюда вечная единица после каждого включения питания.

Разберём, чем ESP32 хранит настройки на самом деле: раздел NVS во флеше и библиотека Preferences поверх него — хранилище ключ-значение с namespace. Перенесём счётчик и настройки термостата из прошлого урока, найдём ловушки миграции и посмотрим, что происходит физически, когда вы пишете ключ.

Preferences в симуляторе не эмулируется — модель хранилища это массив store в скетче, а журнал и commit изображают счётчик записей и печать в Serial. Логика ключей, дефолтов и read-only показывается честно: переключите read-only и посмотрите, как записи проходят мимо хранилища.

Физика здесь другая целиком. У ATmega есть отдельная EEPROM-область на кристалле — 1024 ячейки с адресами от 0 до 1023. У ESP32 вместо неё один кусок флеш-памяти, где лежат и прошивка, и данные: под данные отведён раздел NVS — non-volatile storage. В стандартной таблице разделов ему отведено порядка двадцати килобайт — в двадцать раз больше, чем весь EEPROM у Uno, — и устроен он как журнал: каждая запись дописывается, устаревшие помечаются, страницы периодически уплотняются. Wear leveling встроен в сам механизм — флеш не протирается в одной точке, как это случилось бы при наивной записи по фиксированному адресу.

Preferences — официальная обёртка над NVS в ардуино-ядре ESP32. Хранилище не байтовое, а ключ-значение: вы открываете namespace — группу настроек с именем до пятнадцати символов — и кладёте в неё ключи с типизированными значениями: putUChar, putShort, putFloat, putString. Чтение зеркальное, и главная удобность в том, что get принимает дефолт прямо в аргументе: ключа нет — вернётся ваша заводская цифра, без проверок вокруг. Тот самый magic-байт из урока про первые настройки здесь встроен в API: отсутствующий ключ и есть признак первого запуска.

Ограничения стоит знать до кода. Имя namespace и имена ключей — до пятнадцати символов, более длинные молча не работают. Значения — от байта до структур через putBytes. И флеш остаётся флешем: сектора выдерживают порядка ста тысяч циклов стирания, поэтому принцип редкой записи из урока про update и износ переезжает на ESP32 без единой поправки. Одно отличие в пользу ESP32: журнал уплотняется, поэтому износ делится по всему разделу — а не по одной несчастной ячейке, которую вы забыл ротировать.

Две строки в этом скетче решают судьбу данных: begin и end. begin открывает namespace в режиме записи — второй аргумент false; end закрывает и выполняет commit, фактический перенос буфера в NVS. Если put был, а end не случился, данные живут в оперативной памяти до отключения: скетч выглядит рабочим ровно до первого выдёргивания вилки — самый коварный вид поломки. Форумы полны тем в духе «Preferences не сохраняет»: в девяти случаях из десяти человек забыл end() или открыл namespace только для чтения и удивляется, что put проходит мимо. Держите запись сконцентрированной: открыл — написал всё — закрыл. Второй аргумент begin умеет и наоборот: передадите true — получите namespace только для чтения, удобно для конфигурации, которую пишется один раз при прошивке.

Частоту commit держите на уровне редких событий, а не потока: настройки пишутся при нажатии кнопок и смене режима — это единицы записей в день, и раздел переживёт любой разумный срок службы. А вот лог каждые десять секунд в NVS отправлять не стоит: журнал каждый commit помечает и дописывает, и даже с встроенным wear leveling вы сами решаете, как быстро исчерпать ресурс секторов.

Чтение с дефолтом меняет стиль кода. На Uno я сначала читал ячейку, проверял на 255 и мусор, потом подставлял заводское — три шага. Здесь getUChar делает это в одном вызове: первый запуск даёт ноль, дальше — накопленное, и счётчик переехал одной строкой с сохранением всей логики инкремента.

Структуры настроек из урока про put и get структур переезжают через putBytes: передаёте указатель на структуру и её размер, читаете getBytes. Имена ключей у меня короткие: porog, rezhim, zapuski. Экономия букв тут не для красоты: длинный ключ молча не сохранится, и вы будете искать пропажу в совершенно другом месте. Один нюанс: структура — это сырые байты, поэтому при изменении состава полей меняйте и подпись внутри неё, иначе старая версия структуры прочитается в новую как чемодан без замка.

Миграция в части памяти — это словарь замен. EEPROM.read(5) становится prefs.getUChar с потерей адреса и обретением имени: вместо магических цифр адресов — ключи. EEPROM.write становится putUChar, а EEPROM.update не нужен вовсе: журнал NVS и так дописывает записи и вычищает их при уплотнении. Зато правило писать редко остаётся железным: каждый commit — это стирание и запись секторов флеша, и commit на каждое нажатие кнопки изнашивает раздел быстрее, чем наивный код на Uno изнашивал ячейку. Заодно уходит класс грызни с картой адресов: у меня в проектах был листочек, где какой байт лежит, — теперь его заменяют имена ключей прямо в коде.

Отдельная тема — сон. Узел теплицы спит между измерениями, и счётчик циклов сна логично держать в том же NVS: проснулся — begin, чтение, инкремент, запись, end. Запись раз в цикл сна — это единицы commit в сутки, и раздел с такими темпами живёт дольше самого узла. Бюджеты сна и срок узла на батарейке мы считали в уроке про глубокий сон: память настроек вписывается туда без дополнительных схем. Если вы только выбираете плату под такой узел, я начинал бы с первого скетча на ESP32: периферии там больше, но привычной EEPROM-модели больше нет.

Три последних урока закрыли горизонт от простой ячейки до журнальной флешки: настройки с дефолтами, ресурс и update, структуры через put и get, заводской сброс по удержанию, термостат, пережидающий сбой, и переезд на Preferences. Если упёрлись в объём — у внешних микросхем 24Cxx на шине I2C ёмкости начинаются там, где заканчивается раздел NVS; дверь туда открыта в уроке про два провода I2C. Держите настройки маленькими, записи редкими, а сброс — долгим: этим трём правилам я доверяю больше любой библиотеки, и они одинаково честно работают и на Uno, и на ESP32.