SAM7s256 не имеет EEPROM внутри. Есть ли возможность использования програмной памяти как EEPROM?

Возможность есть. Но если речь идет об экономии $0.1, то лучше не стоит.

Есть в нем такая возможность. Из кода, выполняющегося из FLASH не пробовал, но из кода, выполняющегося в SRAM, программировал.
Читайте раздел Embedded Flash Controller (EFC) в мануале.

Как часто вы собираетесь менять данные? Это я к тому, что количество перезаписей у встроенного флеша на порядки меньше, чем у ЭСППЗУ. Стирается флеш тоже только странично в отличие от побайтового стирания у ЭСППЗУ. Если эти факторы не пугают - то можно. Но закладывать в изделие AT91SAM7 сегодня я бы в любом случае не стал.

Да ничего особенного туда не планировалось писать - дни наработки. Ну видимо без геморроя не обойдется.

Осталось выяснить размер минимального записываемого элемента во FLASH этого МК.

Кажется 16 слов - минимум. Невыгодно это.

32 бита. Но лучше, конечно, EEPROM

Да, EEPROM лучше.

А вот такая штука ещё более лучше.

"unlimited endurance" они, конечно, лукавят, но умеют EEPROM с 1млн. циклов. По сему, не станем цепляться… (;
И цены у микрочипа приятные…

Если используете RTC с батарейкой, пишите туда, на 10ю или 100ю запись скидывайте во флешку, при этом ресурс вырастает в разы. И если даже что-то произойдет с батарейкой или сотрутся данные в RTC, то потеряете только последнее обновление, если опять же, испортится счетчик во флеше, можно восстановить его из RTC.

Да так и сделал. На борту есть DS1307. Только флэш хотел использовать внутри SAM7s256. Но видно не судьба. В Сети ничего подходящего не нашел, а ковырять самому пока некогда. Да и криво получится - писать по 32 слова.

По одному слову, 32 бита.

Это уже интересней.

А FRAM ещё лучше


Ещё интересней если немного подумать и поэкспериментировать.
Исходя из исходных данных задачи - во флешь нужно хранить инкрементирующийся счётчик.
Я так понял - этот МК имеет ECC-защиту программной флешь с размером страницы == 32 бита?
Пустая (стёртая) ячейка вероятно имеет значение == 0xFFFFFFFF. Примем это значение за значение счётчика ==0.
Тогда очевидно, что в пустую ячейку можно записать любое значение. Например 0xFFFFFFFE. Примем это значение за значение счётчика ==1.
Поверх него можно попробовать записать 0xFFFFFFFC, но, так как есть ECC, то скорей всего получим не 0xFFFFFFFC, а нечто другое. Ну да ладно - то что получим примем за значение счётчика ==2.
Далее - опять попробуем записать в эту же ячейку нечто другое. Если получим значение отличное от предыдущего, то примем это значение за следующее значение счётчика.
И так можно модифицировать эту ячейку до тех пор, пока значение ячейки не перестанет меняться.
Очевидно, что последовательность этих значений ячейки будет одинакова для всех ячеек флешь (если флешь ещё не изношена!!!). Отсюда следует, что можно определить значение счётчика, записанного в ячейку. А значит - увеличить максимальное кол-во записей во флешь на количество полученных значений счётчика. Таким образом - увеличив ресурс флешь.

Экспериментальным путём (или иным путём) можно определить последовательность записываемых значений в одну и ту же ячейку флешь, при которой значения ячейки будут меняться дольше всего (до конечного фиксированного значения).

Нет, не имеет.

Вот тут пишут, что можно даже отдельные биты переключать из 1 в 0.
В связи с этим перспективы открываются радужные. Правда, для надёжности нужно делать хитрую схему с двумя или более страницами. Опять же, неясно, будет ли страдать ресурс флеша, если программировать по одному биту за раз.

"Writing 8-bit and 16-bit data is not allowed and may lead to unpredictable data corruption."

С ресурсом не ясно, "потекут" ли соседние биты - тоже не ясно. Ненужный геморрой все это.


Записать вместо 0xFFFFFFFF 0xFFFFFFFE, а затем 0xFFFFFFFC это никоим образом не мешает.

Между тем, вот здесь применяют именно побитовую запись во флешь. Может быть, они что-то знают. Или это просто слабоумие и отвага. Не знаю

Проц атмеловский!!!

Если не имеет, то модифицировать можно побитно, а не по 32 бита.

Типа счётчик Джонсона, но "заполняющий ноль" это вариант

Флеш - он и в Африке флеш. Но гарантий никто не даст, очевидно. Я склоняюсь к тому, что это волюнтаризм автора апноты.

Ну да, ну да… (;

A Serial EERAM (EEPROM-backed SRAM), который при пропадании питания на кондере пишет SRAM в EEPROM а при появлении питания автоматом восстанавливает с еепрома в SRAM - еще лучше для данного применения. Какой нибудь Microchip 47L04... 1 миллион выключений питания - а там хоть миллисекунды наработки считай.

Чем лучше-то??? Тем что кондёр хороший ставить ещё нужно??

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

Или просто для ленивых.
Потому как 8мс@3мA для CY14*101Q немногим менее чем 6(3)мс@5.5мА для SAM7S256 (1 страница)

Флеш то он всегда флеш, да вот контроллер флеша может быть разный. В STM32F0 после очистки страницы в слово можно записать только два раза. Один раз поменять единицы на любое значение, и еще раз можно записать в слово ноль.
Записывать по одному нулю в бит контроллер не разрешает, запись блокируется.
Налетел на это, когда эмуляцию eeprom писал, хотя в мануале это описано

А если не в то же слово, а в соседнее? Или в слово в соседних 16/32/.. байтах но внутри той же страницы?

Без проблем, можно.
Но пишется по 16 бит. И эти 16 бит можно менять только: стирание -> значение -> ноль -> стирание.
Ну, или без записи нуля.
Это Cortex-M0:

Ну это вполне обычное дело, как и в других МК. Даже неплохо, потому что в LPC, например, можно менять только 16-байтовыми сегментами. Но даже с такими ограничениями я организовывал хранение данных с перезаписью без стирания страницы