Arduino и энергонезависимая память

[slyubez]

jcxz писал(а):

slyubez писал(а):

У меня не чисто бытовые цели, поэтому мой выбор - DS3231. Проверено временем, его точность меня полностью устраивает. Но дополнительной памяти у него, увы, нет.

Замените его на что-то из линейки FM31T372/374/376/378. И будет вам и RTC с погрешностью не более 2.5 минут за год (встроенный уже на заводе температурно-компенсированный кварц) и + несколько Кб FRAM. И всё это счастье в одном флаконе корпусе. И никакой мороки с кольцевыми буферами - можно писать в одни и те же адреса хоть до посинения!

Хорошая вещь, вот только достать ее у нас не так просто. Это DS-ки на каждом углу продаются.

[NStorm]

slyubez писал(а):

Кольцевой буфер в ЕЕПРОМ всего делов то.

Склоняюсь пока к этому варианту.

https://github.com/chayanforyou/WearLev ... arLeveling - либа для Ардуино. Надо только ручками под свои нужды (размеры подправить).
Я у себя пишу структуру. 1 поле uint32_t - порядковый номер записи, далее пошли данные (фиксированный размер), далее в конце CRC16 на всякий случай. Ну и пишу по кругу и читаю после перезагрузки. По номеру записи определяю какая последняя.
Если реально только пару байт надо сохранять - можно значительно упростить и сократить "служебные данные".

[jcxz]

NStorm писал(а):

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

А зачем там "номер записи"?
Кольцевой буфер на флеши строится просто: Кольцо из N секторов стирания. В котором как минимум один сектор должен быть стёрт. Вот от этого стёртого и нужно искать в сторону головы записи.
Представьте себе червяка, который ползёт по кольцу из секторов стирания. Как только он собирается заползти на новый сектор (сектор S1), то он сначала стирает сектор идущий за ним (сектор S2), а потом - начинает заползать на S1. Чтобы найти голову червяка, сначала ищем полностью стёртый сектор, а потом двигаемся от его границы (по байтам содержащим чистое значение (0xFF например)) в сторону головы червяка. Пока не наткнёмся на неё.
Длина червяка - это его размер в байтах. Каждая новая запись - одно тело червяка вперед по 0xFF-кам + 1 байт интервал (между записями).
Индексы никакие не нужны. Писать такое кольцо можно сразу - даже поверх заполненной мусором флеши (только обеспечивать чтобы всегда как минимум один полный стёртый сектор был в кольце). Предварительное стирание флеши не нужно.
Чтобы тело червяка отличать от чистой флеши (0xFF), нужно предварительно закодировать данные тела так, чтобы они не содержали стёртого значения (экранировать стёртое значение из данных).

[NStorm]

jcxz, ну можно и так. У меня там свои нюансы были, мне стирать на сектор вперед неудобно было бы (накладных расходов больше). Плюсы и минусы у обоих способов есть.

[roman.com]

Тема любопытная... тоже думаю как лучше сделать...

Наверно самое простое так:

1. Разбиваем EEPROM на сетора:

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

2. Записываем данные в первый сектор:

1111111 FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

3. Записываем новые данные в новый сектор, а старый сектор стираем:

FFFFFFFF 1111111 FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

4. Записываем новые данные в новый сектор, а старый сектор стираем:

FFFFFFFF FFFFFFFF 1111111 FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

5. И т.д. ))

Получили кольцевой буфер.

Один недостаток - каждый сектор по два раза записываем и стираем. Износ EEPROM в два раза больше...
Но всё таки лучше чем писать всё в одно место))

Интересно... а кто реально проводил эксперименты по износу AVR ?
Действительно ли там ограничение на 100.000 циклов ?
Просто я так много ещё не писал))

roman.com писал(а):

Записываем новые данные в новый сектор, а старый сектор стираем

Такой вариант ресурс ячеек сокращает в двое.

[jcxz]

Самсусамыч писал(а):

Такой вариант ресурс ячеек сокращает в двое.

Ресурс считается по количеству стираний. Записывать можно сколько угодно.

[NStorm]

Интересно... а кто реально проводил эксперименты по износу AVR ?
Действительно ли там ограничение на 100.000 циклов ?

Где-то видел тесты. Реально по факту в разы больше.
Всё-таки поискал и вот, нашел: https://chipenable.ru/index.php/program ... iment.html
По факту что-то больше 3 млн циклов при 25*С. Просто 100К - это гарантированный производителем ресурс во всем температурном диапазоне МК. Это не значит, что после 100К записей внезапно всё начнет ломаться.

jcxz писал(а):

Записывать можно сколько угодно.

Вы с чтением не перепутали? Это читать можно сколько угодно, а стирать и записывать – только определённое количество раз.

1.png

[NStorm]

А много чего вы можете записать, не стирая? Думаете есть принципиальная разница сразу записать в ячейку один ноль, а позже еще один. Или сразу два нуля записать?

[OKF]

Самсусамыч писал(а):

jcxz писал(а):

Записывать можно сколько угодно.

Вы с чтением не перепутали?

Всё верно. Запись и стирание - это разные операции.

[jcxz]

Самсусамыч писал(а):

Вы с чтением не перепутали? Это читать можно сколько угодно, а стирать и записывать – только определённое количество раз.

Не перепутал. Почитайте что такое "флешь-память" и о принципах её работы.

Добавлено after 5 minutes 53 seconds:

NStorm писал(а):

А много чего вы можете записать, не стирая? Думаете есть принципиальная разница сразу записать в ячейку один ноль, а позже еще один. Или сразу два нуля записать?

Разница - огромная!
Например у меня чип памяти с секторами стирания ==256КБ. А записывать нужно структуру размером например ==8 байт. Естественно я буду записывать в один сектор флешь кольцевого буфера 256*1024/8=32768 раз. И сотру его только 1 раз на каждые 32768 записи (когда сектор полностью заполнится).
Или Вы будете писать, а затем стирать сектор каждый раз при записи следующих 8 байт данных? Чтобы ресурс флеши поскорее убить? В 32768 раза быстрее чем нужно?

PS: Правда для флешь памяти программ многих МК дело обстоит несколько сложнее: Там часто используют алгоритмы контроля (на аппаратном уровне) содержимого FLASH. И поэтому дописывать в произвольные смещения флешь - нельзя. А записывать можно элементами фиксированного размера (обычно == 16 байт). Но всё равно - это намного лучше чем стирать каждый раз перед записью заново весь сектор.
Для EEPROM-памяти таких ограничений нет.

[NStorm]

jcxz, я вообще-то не вам писал, а Самсусамыч. Соглашаясь с вашим утверждением, что "Ресурс считается по количеству стираний. Записывать можно сколько угодно.".
Но только зачем вы сейчас о страничном флэше пишете? Мы про EEPROM с по-байтовым доступом говорили. Где можно записать-стереть 1 байт отдельно.

[jcxz]

NStorm писал(а):

Но только зачем вы сейчас о страничном флэше пишете? Мы про EEPROM с по-байтовым доступом говорили. Где можно записать-стереть 1 байт отдельно.

Ну - здесь уже о разных говорили. Даже о FRAM.
А EEPROM предложили как я помню - по той причине, что у неё ресурс стираний больше.
Но другой путь увеличения ресурса кольцевого буфера - это просто взять чип ФЛЕШЬ большого объёма (пускай с большими секторами стирания). И таким образом увеличить количество циклов записи на одно стирание.

jcxz писал(а):

Самсусамыч писал(а):

Вы с чтением не перепутали? Это читать можно сколько угодно, а стирать и записывать – только определённое количество раз.

Не перепутал. Почитайте что такое "флешь-память" и о принципах её работы.

Я прекрасно знаю, что это такое и «с чем это едят».

Как Вы прокомментируете данный параметр?

3.png

А данное утверждение?

4.png

Будете продолжать настаивать, что «Записывать можно сколько угодно.»? Ну-ну…

Ресурс записи
Изменение заряда сопряжено с накоплением необратимых изменений в структуре и потому количество записей для ячейки флеш-памяти ограничено. Типичные количества циклов стирания-записи составляют от десятков и сотен тысяч до тысячи или менее, в зависимости от типа памяти и технологического процесса. Гарантированный ресурс значительно более низок при хранении нескольких бит в ячейке (MLC и TLC) и при использовании техпроцессов класса «30 нм» и более современных.

Одна из причин деградации — невозможность индивидуально контролировать заряд плавающего затвора в каждой ячейке. Дело в том, что запись и стирание производятся над множеством ячеек одновременно — это неотъемлемое свойство технологии флеш-памяти. Автомат записи контролирует достаточность инжекции заряда по референсной ячейке или по средней величине. Постепенно заряд отдельных ячеек рассогласовывается и в некоторый момент выходит за допустимые границы, которые может скомпенсировать инжекцией автомат записи и воспринять устройство чтения. Понятно, что на ресурс влияет степень идентичности ячеек. Одно из следствий этого — с уменьшением топологических норм полупроводниковой технологии создавать идентичные элементы все труднее, поэтому вопрос ресурса записи становится все острее.

Другая причина — взаимная диффузия атомов изолирующих и проводящих областей полупроводниковой структуры, ускоренная градиентом электрического поля в области кармана и периодическими электрическими пробоями изолятора при записи и стирании. Это приводит к размыванию границ и ухудшению качества изолятора, уменьшению времени хранения заряда.

Последний раз редактировалось Самсусамыч Чт сен 03, 2020 14:54:23, всего редактировалось 1 раз.

[jcxz]

Самсусамыч писал(а):

Будете продолжать настаивать, что «Записывать можно сколько угодно.»? Ну-ну…

И что? В чём именно противоречие с тем что я сказал?
Почитайте внимательнее что я писал. Вы похоже ничего не поняли.

А те цитаты, которые Вы дёргаете, толком не понимая о чём там говорится, говорят о количестве циклов записи/стирания для одной ячейки флешь. Один такой цикл - это один переход одной ячейки (для SLC - бита) из нестёртого состояния, в стёртое. Можно конечно считать не переходы 0->1, а переходы 1->0 - это будет то же самое количество.
И если скажем для сектора флеши размером 256КБ сделать 256*1024*8 = ~2М отдельных операций записи, в каждой операции модифицируя всего 1 бит, а потом стереть весь сектор, то счётчик циклов для всех ячеек сектора увеличится всего на 1. Вот об этом я и писал.

jcxz писал(а):

Почитайте внимательнее что я писал. Вы похоже ничего не поняли.

Вы утверждаете в своём высказывании: https://radiokot.ru/forum/viewtopic.php ... 3#p3887233
Что записывать можно неограниченное количество раз («Записывать можно сколько угодно»). Я Вам привожу факты, что это не так, так как ресурс записи имеет ограниченное количество раз. О котором указывает и производитель. Так что Ваше утверждение не соответствует действительности.

[jcxz]

Самсусамыч писал(а):

Вы утверждаете в своём высказывании: https://radiokot.ru/forum/viewtopic.php ... 3#p3887233
Что записывать можно неограниченное количество раз («Записывать можно сколько угодно»).

Да уж.... медицина тут бессильна....

[roman.com]

По факту что-то больше 3 млн циклов при 25*С.

Хм... интересно. 3 млн циклов - это не плохо))

Можно придумать другой способ записи... Например как SD карте... Там есть "шапка" с адресом ячеек и сектора с данными.

1. "шапка" с адресом ячеек:
FFFFFFFF
Разбиваем EEPROM на сектора:
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

2. Записываем адрес в "шапку",
00FFFFFF
а данные в нулевой сектор :
000000 FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

3. Записываем новый адрес в "шапку",
01FFFFFF
а данные в первый сектор :
000000 1111111 FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

4. Записываем новый адрес в "шапку",
02FFFFFF
а данные в второй сектор :
000000 1111111 2222222 FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

5. И т.д. ))

Только теперь "шапка" быстро износится...))

[jcxz]

roman.com писал(а):

Только теперь "шапка" быстро износится...))

А зачем тогда? Просто писать последовательно в сектор и всё. И все его байты будут изнашиваться равномерно.
Но можно и вашим методом, только номер сектора указывать номером самого старшего 0-го бита. Т.е. шаги:
1. шапка == FFFFFFFF
2. шапка == FFFFFFFE
3. шапка == FFFFFFFC
4. шапка == FFFFFFF8
5. шапка == FFFFFFF0
...