Организация настроек для записи во внешную ЕЕПРОМ(AT24C32)

Для хранения настроек использовал внутреную flash процессора, но потом заметил что во время записи некоторые периферия работает не совсем адекватно, и могут быть пропущены внешние сигналы, решил перейти на внешнюю память, выбор пал на серию AT24**так как есть место куда её можно запаять. Почитал как с ней работают, в принципе понятно и на запись N количество байт проблем не должно быть. Вопрос встал как хранить настройки, что бы потом их можно было легко записать. Раньше когда использовал falsh все днастройки хранил в структуре,после модификации структуры, просто стирал всю страницу flash (все настройки) и записывал, новые настройки.
Такой подход к еепром считаю не правильным, надо записывать чисто изменения, если изменилось 4 байта в структре то их и надо записать, как это можно сделать по феншую?

Флеш во время записи блокируется, если хочешь в это время реагировать на события, то нужно переносить те же обработчики прерываний в RAM.

pokk, вообще-то,в даташит at24c32 указано, что внутренняя организация памяти у нее страничная. 128 страниц по 32 байта.
Поэтому, если объем сохраняемых данных существенно меньше, чем 4 килобайта, а записываются они относительно часто, то лучше писать их по кругу, выравнивая по адресу кратному 32 и записывая страницами по 32 байта. Каждую запись конфигурации следует предварять одним дополнительным байтом инкрементируемом при каждой записи. Тогда при старте программы находим последнюю версию конфигурации, с учётом возможного перехода счётчика через ноль, и используем ее адрес и значение счётчика конфигураций для последующих записей.

Добавлено after 3 minutes 28 seconds:
Re: Организация настроек для записи во внешную ЕЕПРОМ(AT24C32)
pokk, неплохо так же дублировать значение счётчика и в конце конфигурации. Тогда будет дополнительный контроль, на случай если запись конфигурации была прервана до ее окончания.

Что-то вы всё усложняете. pokk, вы ресурс eeprom экономить собрались? Пишите просто структуру с контрольной суммой да и всё. Если уж данные такие ценные, запишите в двух местах.

Самое поикольное, что если не выходить за пределы страницы, то запись блока данных даже быстрее его чтения. Переход на следующую страницу при записи стоит 5мс.

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

Мы же про настройки говорим судя по сообщению ТС. Настройка это такая штука, которая считывается при старте, чтобы установить состояние устройства. Вот при старте мы их считываем, проверяем целостность по контрольной сумме (счётчик нам тут мало поможет) и применяем. Если контрольная сумма не сошлась, то устанавливаем дефолтное состояние. В особо запущенных случаях можно хранить несколько копий данных. Я не запрещаю вести счётчик, только пользы от него никакой. Данные либо целые, либо нет и это контрольной суммой проверяется.

VladislavS, как раз шансы на то, что совпадет контрольная сумма, есть всегда (что, впрочем, не отменяет полезность контрольной суммы). А одинаковое значение счетчика, записываемое перед данными и после них - однозначный признак того, что все данные записались. Плюс данного подхода еще в том, что если последняя конфигурация не валидна (значения счетчика в начале и в конце не совпадают), то можно использовать предыдущую конфигурацию. То есть, мы теряем только последнее изменение конфигурации устройства, а вовсе не всю целиком. Очень Вас порадует, когда устройство с конфигурацей по-умолчанию займет статический IP адрес 192.168.0.1, который в сети уже занят? )))

Я также всегда использую в таких случаях маркер начала и конца записи. Так чтобы они были равны другу другу и не равны стёртому состоянию флешь и не равны полностью записанному состоянию флешь.
Т.е. - если стёртое состояние флешь (все биты) = 0xFF, а записанное = 0x00, то допустимое значение маркера в пределах 0x01...0xFE. Если страница имела начальное (стёртое) состояние == 0xFF, то наличие валидных и одинаковых маркеров со значением 0x01...0xFE в начале и конце записи означает что запись была выполнена полностью успешно.
CRC в записи у меня тоже есть, но это уже - для дополнительной защиты. По уму построенный алгоритм должен и без CRC корректно работать.

ПростоНуб писал(а):

Очень Вас порадует, когда устройство с конфигурацей по-умолчанию займет статический IP адрес 192.168.0.1, который в сети уже занят? )))

Ещё меньше меня порадует адрес 192.ххх.0.1 после "успешных" записи и чтении, но сбойном одном байте.

VladislavS, читать умеете?

ПростоНуб писал(а):что, впрочем, не отменяет полезность контрольной суммы

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

Надеюсь, термины чисто "инженерные" термины "очень редки" и "частое явления" подтверждены конкретными цифрами а не высосаны из пальца?

VladislavS, читать умеете? Где я употребил слово "частое"? Я могу только утверждать, что с повреждениями информации в EEPROM я не только не сталкивался ни разу, но даже не слышал о таком. А вот о зависании МК при записи во внешний чип, который при этом еще и потребляет в 3-4 раза больше энергии, чем в холостом режиме, не только слышал, но и сталкивался с этим сам.

Меня вот при записи во внешнюю флешь всегда тревожила мысль: "А что будет если питание флешь-чипа отключится во время записи?" Будет там исходное значение, или целевое? И насколько оно будет стабильным? Возможны ли случаи, когда сбой питания во время записи какого-то байта, может привести к тому, что потом этот байт будет читаться неустойчиво: иногда одно значение, иногда - другое? В мануалах на flash не видел упоминаний такой ситуации.
Или в его составе есть ёмкость, гарантирующая завершение записи в любом случае? Или за счёт внешней ёмкости?...
То же самое касается и операции стирания. Но здесь ещё сложнее, так как это - длительная процедура. Может ли быть такое что если после старта стирания страницы сбойнуло питание, и после этого в странице уже и не начальное содержимое и не стёртое?

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

Что то я не пойму , при чем здесь тема АРМ. Вроде как Периферия.