Не очень понял как это касается темы спора
встроенные vs собственные средства работы с EEPROM ?
Если вы о том что нужно таки аппаратными средствами обеспечить запись в eeprom,
то придумывать ничего нового не будем, уже все придумано.
Транзакция считается законченой когда записано обе копии данных в EEPROM.

Если бы Вы внимательно читали мои посты, например пост №54 то Вы бы заметили что
мой автомат апдейтит две копии данных и по ходу для каждой из них
сохраняет/проверяет CRC.

- я писал?
а это -

Озаботились кроме Вас ещё много людей и я Вам написал о том, что проблема не нова. И независимо от Вашего некоего "автомата" давно успешно решаема. Если Вы не знакомы с известными решениями, то это не повод рассказывать о том, что кроме Вашего решения (крохи которого Вы попытались громко показать) ничего иного нет))


Простите, но не заставляйте ассоциировать себя с героем старого анекдота "чукча не читатель - чукча писатель". Лучше всё-таки расскажите, чем отличается Ваше решение от общеизвестных, кроме как авторством кода и неприятием готовых решений от авторов компиляторов и сопутствующих библиотек.

Я и не пытаюсь себе присваивать пальму первенства, более того, я уверен что те
решения о которых я говорю применяются очень широко. Тока почему то на электрониксе
очень многим они не нравятся

Если Вас не убедило 33 такта против 81 на записи одного байта (да еще и в ситуации когда
цейтнот и питания осталось совсем мало), то я не смогу Вам объяснить чем мое решение лучше...

А если Вы действительно хотите разобраться со всеми нюансами сохранения правильной
конфигурации в EEPROM, то давайте это обсуждать, тока без вариантов типа в IAR это сделано
круто и ничего другого я знать не хочу,
и я думаю что тоже узнаю для себя что-то новое.

Да какая разница сколько тактов уйдет на sheduling записи одного байта. Операция записи длится 3-5ms, ответьте - сколько раз при этом будет осуществлен вызов вашего автомата и "отвал" по факту занятости eeprom, сколько тактов это сожрет? Не кажется ли вам, что разница 81-33 = 48 тактов просто мизерная и стремится к нулю на фоне постоянных накладных расходов автомата.
Кстати откуда 81 такт?
(eeprom char *)xxx = YY - это 14 инструкций с отключенной оптимизацией


что тут обсуждать. три основных момента - залог успеха:
1. пакетная организация,
2. CRC обязательно.
3. Дублировать записи.

Вы то хоть поняли что в IAR сделано? И как то, что сделано в IAR кореллирует с тем, что выставляете вы? Уровни же разные совершенно, вы хотите сопоставить пакетный уровень, байт уровню? Типа - да начерта нам эти сигналы всякие, биты, байты, вот IE с http прекрасно работает..

Если у меня правильная конфигурация (состояния автоматов) меняется примерно раз в минуту, то дырку я протру за 100К/60/24 = 70 дней. Если я растиражирую эту запись 10 раз - то за 700 дней. Правда, епром у меня используется впритык, и максимум, что я могу - это 3 копии. Т.е. 70*3 = 210 дней. Все равно мало. Поэтому приходится иметь парковку...

Кст, насчет спора собственные функции \ встроенные средства. Сам для епрома использую собственные - с автоматическим тиражированием, CRC и работающие в фоне. А вот для доступа к флэшу использую модификатор __flash. По моему, вполне удобно.

8.5 МИЛЛИСЕКУНД продолжается запись. Какие такты кого спасут? IMNHO, Вы путаете время записи адреса и данных для АППАРАТНОЙ записи с продолжительностью самой записи. И, кроме того, извините, но глядя на кусочек кода (вероятно это код Вашего автомата), не только у меня возникли сомнения в его корректности. Вопрос же о хранении и валидности данных касается более алгоритмов хранения, а не реализации их в конкретном драйвере, о котором кроме дифирамбов никакой инфы, кроме неиспользования штатных средств, толком и не было.

Ну я в IDA размотал этот кусок, где он генерирует комманду записи в RAMPx, ее можно там заменить, пропатчив экзешник конечно, штатными средствами не получится. Только что-то меня остановило, уже не помню что.

Уже не помню, но кроме адресации по смещению какие-то нюансы с регистрами передачи параметров в функции были.