EEPROM: управление сопоставлением адресов между версиями прошивки
Есть ли общий способ обработки изменений в сопоставлении адресов eeprom и переменных между версиями прошивки? Дело не в том, что память eeprom сохранится после обновления, а в том, чтобы быть совместимым с будущими скетчами с, возможно, другим набором переменных.
Чтобы было понятнее, рассмотрим следующий вымышленный сценарий:
Кофемашина запрограммирована на измерение температуры_воды
, и предполагается, что прошивка прекращает нагрев в пределах temperature_hysteresis
.
ниже set_temperature
. set_temperature
— это постоянный параметр, который оптимизируется индивидуально для пользователя и поэтому должен сохраняться при любом обновлении прошивки. В качестве параметра конфигурации также хранится temperature_hysteresis
в eeprom.
Теперь производитель решает дополнить свою машину ПИД-регулятором, сделав параметр temperature_hysteresis
устаревшим и введя несколько новых параметров для коэффициентов усиления регулятора (pid_gains
). Как он может добиться того, чтобы прошивка сохраняла значения, которые не были затронуты обновлением (например, set_temperature
), пока добавляется дополнительный параметр pid_gains
.
Я предполагаю, что устаревшие параметры следует удалить, так как в будущем может появиться больше обновлений с новыми параметрами. Вот почему простое увеличение адреса eeprom и игнорирование устаревших адресов, вероятно, не сработает.
С другой стороны, при повторном использовании старых адресов мне интересно, как можно избежать фрагментации eeprom. Мне пришла в голову идея поместить все данные конфигурации в json в eeprom и решить проблему уровнем выше, проанализировав json для данных конфигурации. Но в любом случае это кажется таким неправильным и может оказаться слишком сложным.
Кто-нибудь сталкивался с подобными проблемами и знает, как обычно реализуется эта процедура?
@Sim Son, 👍1
1 ответ
Лучший ответ:
С этим можно справиться множеством способов.
Две мысли сразу пришли мне в голову:
- Имейте идентификатор "Версия" в EEPROM.
Тогда микропрограмме необходимо знать структуру EEPROM всех версий, вплоть до текущей. Затем он может прочитать EEPROM из старой версии и записать обратно в новом формате для текущей версии.
- Каждая запись в EEPROM должна быть помечена "значением".
Это не слишком отличается от вашей идеи JSON (вы правы, это ужасно), но вместо множества слов вы просто используете простое число, чтобы определить значение значения, с которым оно связано. Предполагая, что каждое сохраненное значение представляет собой 8-битный байт (хотя это и не обязательно), вы можете выделить «1» как «set_temperature», «2» как «temperature_hysteresis», «3» как «pid_gains», и т. д. Тогда EEPROM может содержать байты 1,96,2,5
, и прошивка будет знать, что второй байт — это set_temperature
, потому что он имеет 1 в первом байт.
Вы можете думать об этом как о паре "ключ/значение", но и ключ, и значение – это просто числа.
Чтобы найти temperature_hysteresis
, вы просто просматриваете все четные записи EEPROM, пока не найдете 2
, а затем читаете следующую запись. Если вы не найдете 2
, используйте значение по умолчанию.
Ваша прошивка может либо обновить существующую ячейку с тегом нужного типа (сканировать тип, обновить следующую ячейку), либо стереть все значения и заменить их только теми, которые ей интересны. выбор за вами.
Любые значения, которые больше не нужны вашей прошивке, будут игнорироваться и, возможно, удалены.
- ESP32: лучший способ встраивания сертификатов
- Резервное копирование и восстановление прошивки
- Как установить начальное значение eeprom при перепрошивке ESP32
- заставить EEPROM.h использовать пользовательский раздел eeprom
- Arduino IDE EEPROM put(), затем read() возвращает разные данные на ESP32
- Что не так с тем, как я записываю и/или считываю адреса EEPROM?
- Esp32: загрузить файл eeprom
- Как записать прошивку на ESP32 Devkit V1 с помощью MacBook Pro с адаптером USB Type C?
Спасибо за ваш немедленный ответ! Я не знаю, полностью ли я понял ваше первое решение, но похоже, что у меня все еще может не хватить памяти после ограниченного количества обновлений. Но идея состоит в том, чтобы сделать все предыдущие изменения в отображении eeprom одно за другим до последней версии (на случай, если кто-то пропустил какие-то обновления за это время), не так ли?, @Sim Son
ваше второе решение в целом довольно ясно, но мне интересно, как обрабатывать типы данных разного размера. Должен ли я хранить размер каждого значения после его «ключевого» байта или как бы вы это сделали?, @Sim Son
Вы можете вывести тип данных из ключа., @Majenko
Да, обернуть вокруг него рутину, чтобы добиться этого, — это отдельная история, но, по крайней мере, для меня это не является загадкой. Спасибо, @Sim Son
У меня также есть такие вещи, как справочные таблицы (не совсем предсказуемый размер/структура), которые необходимо хранить. Каковы недостатки использования моего подхода json в spiffs? Я имею в виду, что это во флэш-памяти в любом случае..., @Sim Son
Мне это кажется прямолинейным: наличие
config.json
иconfig_updated.json
(который обновляется через ota), и при самой первой загрузке прошивка объединяет эти файлы., @Sim SonМне кажется почти неизбежным, что новая прошивка потребует хотя бы _некоторого_ понимания того, что старые версии хранят в EEPROM. В такой ситуации решение 1 кажется наиболее простым., @Edgar Bonet