Это потому что вы думать не хотите. Потому у вас и "нет алгоритмов".

Опять не хотите думать. Указатель можно вычислить на старте. Нет никаких проблем это сделать.

А завтра "выяснится", что если в момент записи 32-битного значения 0x12345678 поверх старого 0x87654321 и выключении питания в этот момент, в ячейке оказывается совершенно неожиданное и недопустимое 0x87655678. Кто-ж мог предположить-то??!

Ок, замечание справедливое. Но какие варианты можете вы предложить? Или ограничитесь сарказмом?

Я реалист, и исхожу из принципа вероятности. Нулевых вероятностей, пожалуй, во вселенной не бывает, так что и стремиться к нулевой нет смысла. Как я оцениваю вероятность того, что при начавшейся записи 4 байт, каждая из которых длится 4мс, между записью байтов исчезнет питание? Как крайне малую, ничтожную, ибо если оператор нажал кнопку ввода нового значения, а потом стремглав бросился к автомату питания на задней стенке стойки, это потребует от него никак не 16мс... А если вдруг случайно гавкнется подстанция, то такой сбой ни у кого не вызовет вопросов, это форсмажор классический.

Да, это не сверхнадежно и не сверхпрофессионально, но других вариантов я не вижу...

сам плохо понимаю.. но поверил китайцам на слово))

нужно разбираться.. Бегло глянул. Не утверждаю, но пишут что в stm32-х тоже эмуляция

опять же.. там обновление страниц идёт, пишет в другую страницу типа.. там читать нужно

Писать не байты и слова, а целиком структуру данных. С маркерами валидности. Например. Но как можно чего-то предложить если мы не знаем вашей задачи??

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

Маркер валидности это те же байты или слова, проблема не в этом. Целостность данных не решает проблему ресурса. Пока я веду речь о ресурсе.

Добавлено after 3 minutes 29 seconds:
Попробую подробнее.
Вот у меня есть переменная, изменяемая по модбасу. В коде эта переменная увязана, как константный коэффициент, т.е. не перезаписывается, только используется. Поскольку в модбасе любая модификация легко отслеживается, я всегда знаю момент изменения этой переменной, и "зеркалирую" её в EEPROM. Тут все просто.
Сложно обеспечить, чтобы EEPROM не стерся слишком быстро...

Добавлено after 4 minutes 41 second:
И о валидности данных. Если я данные загоню в структуру, и буду для неё считать CRC, это решит проблему целостности. Но это принесет проблему ресурсу, т.к. ячейки CRC этой структуры будут изнашиваться сильнее любого из ее полей! И что в этом случае делать?!

Зачем? Я же писал. В кольцевом буфере пишется признак последней записи, При инициализации по этому признаку устанавливается указатель на запись, который находится в ОЗУ.

Ну, можно и маркировать блок... Но во всех этих вещах наиболее актуален вопрос, когда этот блок "двигать"?

Для нескольких микроконтроллеров (AVR, PIC, STM8/32), для внешней EEPROM по I2c (напр. 24C02) давно добавил функции, похожие на update: перед запись: чтение и сравнением с новым состоянием. Запись только при нового значения. Для нескольких конструкций: при входе 32-битную переменную: 32 бита -> при разборке на 4 x 8 бит: сравнение каждого полученного байта и анализ того, был ли он уже записан в ячейки EEPROM. Запись только при необходимости: новое значение отличается от старого значения?, через 5–20 секунд после установления. EEPROM с 1М стал практически вечным - напр. написал как коментарии: 24C02 (EEPROM не был новым, а был взят из какого-то оборудования: "старт 24C02 - 6 септември 2017 г."). Устройство по-прежнему работает и не выдает ошибок при записи/чтении.
---
Есть F-RAM. Есть Serial EERAM. Оба варианта не такие уж и дорогие.

Я например на контроль питания канал ADC выделил, причём по 24V, так что когда пропадёт питание то остаётся уйма времени всё скоротечное начатое завершить и сохранить необходимое в EEPROM, пол секунды или даже больше есть времени, естественно с отключением в экстренном порядке всех нагрузок, принято мониторить все каналы ADC раз в миллисекунду. Так что мне не понятен тот кризис который возникает у кого то от выключения питания - защищайтесь от этого.

Еще раз: аппаратная часть есть, и это константа. "Защищайтесь" неприменимо - это для будущих проектов, и это не обсуждается.
Обсуждается исключительно программный способ

Прилетела помеха и ваше устройство перегрузилось от неё. И не успела программа снова запуститься, как питание вырубилось. Как будете защищаться?
А если пачка помех прилетит? (а они как раз обычно так и летают - пачками, например в тестах на ЭМС)
Попробуйте как-нить пройти тестирование на ЭМ-устойчивость. Будете неприятно удивлены работой вашего девайса.

Ну и как "правильные" разработчики побеждают летающие пачки помех с непредвиденным пропаданием питания во время этих пролётов?

Вы это у Вячеслав М спрашивайте. Это ведь он их победил. Раз не боится их.

Я их тоже не боюсь. Как микробов: я ж их не вижу... Но руки мою и с пачками тоже хотелось бы какую-нибудь профилактику делать

От непредвиденного пропадания питания, конкретно в Вашем устройстве, - никак. ПО этому, предшествовали ему какие-либо сбросы, или нет - фиолетово.
А вот от случайного сброса (для некоторых - без выключения питания !) защитить оперативные данные - элементарно. Оперируя этими данными и фактом сброса, можно предпринимать определённые шаги.

А вообще, не понятно, с чем мы тут боремся. С некорректной записью во время сброса/выключения, или с проблемой ресурса ? Смешались в кучу кони, люди ....

Тут мы за ресурс боремся. А со сбоями можем в теме про АРМ для начинающих побороться, чтобы отделить коней от котлет.

Так алгоритм экономии ресурса я вам в той теме привёл.

Может тогда модераторы сочтут за лучшее - переместить этот массив сообщений (по экономии ресурса) сюда?

Я имел ввиду что не бывает непредвиденных катастрофичных пропаданий питания, всегда есть пол секунды чтобы корректно завершить и ни чего не забыть, дело в схемотехнике! Мониторы питания которые в процах констатируют катастрофу а не предупреждают её, да и внешние то же самое. Предлагаю пример: Вот у вас AC/DC 220V/5V, вот переделайте его на 8V, а далее LOWDROP 5V, вот и решение проблемы времени после пропадания питания, появляется уйма времени чтобы решить проблему "программным" способом. Eстественно мониторить питание нужно на 8V, а не на 5V, когда уже поздно что то делать.

Я, как автор темы, поясню, почему я упоминал пропадание питания, как проблему. Дело в том, что некоторые алгоритмы продления ресурса EEPROM подразумевают запись данных не в момент их обновления, а позже, в расчете на то, что они снова могут измениться через некоторое время. А вот если, скажем, 2 секунды они неизменны - тогда и сбрасывать кэш в EEPROM, как "окончательный" результат. И вот при применении этого алгоритма с моментом выключения могут быть проблемы (повторяю: речь о варианте схемы без контроля питания, речь о чисто софтовых извратах)

Ну например появляется возможность сбрасывать в EEPROM только при пропадании питания, это очень сильно продлевает ресурс, тем более что мы уже выяснили что после пропадания питания есть уйма времени, это если чисто об EEPROM говорить и о софте, если придерживаться темы.