SAM7s256 есть ли возможность использования програмной памяти как EEPROM?, Или придется вешать внешнюю? Опции

[Димон Безпарольн...]

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

[aaarrr]

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

[prottoss]

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

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

[Сергей Борщ]

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

[Димон Безпарольн...]

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

Сообщение отредактировал Димон Безпарольный - Mar 9 2017, 20:46

[jcxz]

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

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

[Димон Безпарольн...]

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

[aaarrr]

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

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

[Димон Безпарольн...]

Да, EEPROM лучше.

[scifi]

Да, EEPROM лучше.

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

[Obam]

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

Сообщение отредактировал Obam - Mar 10 2017, 07:59

[mantech]

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

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

[Димон Безпарольн...]

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

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

[aaarrr]

Да и криво получится - писать по 32 слова.

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

[Димон Безпарольн...]

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

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

[jcxz]

Да, EEPROM лучше.

А FRAM ещё лучше

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

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

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

[aaarrr]

Я так понял - этот МК имеет ECC-защиту программной флешь с размером страницы == 32 бита?

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

[scifi]

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

[Obam]

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

[aaarrr]

Опять же, неясно, будет ли страдать ресурс флеша, если программировать по одному биту за раз.

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

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

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

[scifi]

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

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

[Obam]

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

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

[jcxz]

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

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

[Obam]

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


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

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

[scifi]

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

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

[Obam]

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

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

Сообщение отредактировал Obam - Mar 10 2017, 12:58

[Velund]

А FRAM ещё лучше

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

[jcxz]

A Serial EERAM (EEPROM-backed SRAM), который при пропадании питания на кондере пишет SRAM в EEPROM а при появлении питания автоматом восстанавливает с еепрома в SRAM - еще лучше для данного применения.

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

[Velund]

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

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

[Alechek]

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

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

[Baser]

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

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

[jcxz]

Налетел на это, когда эмуляцию eeprom писал, хотя в мануале это описано

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

[Baser]

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

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

The Flash memory interface preliminarily reads the value at the addressed main Flash memory location and checks that it has been erased. If not, the program operation is skipped and a warning is issued by the PGERR bit in FLASH_SR register. The only exception to this is when 0x0000 is programmed. In this case, the location is correctly programmed to 0x0000 and the PGERR bit is not set.

[jcxz]

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

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