У меня не чисто бытовые цели, поэтому мой выбор - DS3231. Проверено временем, его точность меня полностью устраивает. Но дополнительной памяти у него, увы, нет.
Замените его на что-то из линейки FM31T372/374/376/378. И будет вам и RTC с погрешностью не более 2.5 минут за год (встроенный уже на заводе температурно-компенсированный кварц) и + несколько Кб FRAM. И всё это счастье в одном флаконе корпусе. И никакой мороки с кольцевыми буферами - можно писать в одни и те же адреса хоть до посинения!
Хорошая вещь, вот только достать ее у нас не так просто. Это DS-ки на каждом углу продаются.
https://github.com/chayanforyou/WearLev ... arLeveling - либа для Ардуино. Надо только ручками под свои нужды (размеры подправить). Я у себя пишу структуру. 1 поле uint32_t - порядковый номер записи, далее пошли данные (фиксированный размер), далее в конце CRC16 на всякий случай. Ну и пишу по кругу и читаю после перезагрузки. По номеру записи определяю какая последняя. Если реально только пару байт надо сохранять - можно значительно упростить и сократить "служебные данные".
По номеру записи определяю какая последняя. Если реально только пару байт надо сохранять - можно значительно упростить и сократить "служебные данные".
А зачем там "номер записи"? Кольцевой буфер на флеши строится просто: Кольцо из N секторов стирания. В котором как минимум один сектор должен быть стёрт. Вот от этого стёртого и нужно искать в сторону головы записи. Представьте себе червяка, который ползёт по кольцу из секторов стирания. Как только он собирается заползти на новый сектор (сектор S1), то он сначала стирает сектор идущий за ним (сектор S2), а потом - начинает заползать на S1. Чтобы найти голову червяка, сначала ищем полностью стёртый сектор, а потом двигаемся от его границы (по байтам содержащим чистое значение (0xFF например)) в сторону головы червяка. Пока не наткнёмся на неё. Длина червяка - это его размер в байтах. Каждая новая запись - одно тело червяка вперед по 0xFF-кам + 1 байт интервал (между записями). Индексы никакие не нужны. Писать такое кольцо можно сразу - даже поверх заполненной мусором флеши (только обеспечивать чтобы всегда как минимум один полный стёртый сектор был в кольце). Предварительное стирание флеши не нужно. Чтобы тело червяка отличать от чистой флеши (0xFF), нужно предварительно закодировать данные тела так, чтобы они не содержали стёртого значения (экранировать стёртое значение из данных).
jcxz, ну можно и так. У меня там свои нюансы были, мне стирать на сектор вперед неудобно было бы (накладных расходов больше). Плюсы и минусы у обоих способов есть.
Один недостаток - каждый сектор по два раза записываем и стираем. Износ EEPROM в два раза больше... Но всё таки лучше чем писать всё в одно место))
Интересно... а кто реально проводил эксперименты по износу AVR ? Действительно ли там ограничение на 100.000 циклов ? Просто я так много ещё не писал))
Интересно... а кто реально проводил эксперименты по износу AVR ? Действительно ли там ограничение на 100.000 циклов ?
Где-то видел тесты. Реально по факту в разы больше. Всё-таки поискал и вот, нашел: https://chipenable.ru/index.php/program ... iment.html По факту что-то больше 3 млн циклов при 25*С. Просто 100К - это гарантированный производителем ресурс во всем температурном диапазоне МК. Это не значит, что после 100К записей внезапно всё начнет ломаться.
А много чего вы можете записать, не стирая? Думаете есть принципиальная разница сразу записать в ячейку один ноль, а позже еще один. Или сразу два нуля записать?
А много чего вы можете записать, не стирая? Думаете есть принципиальная разница сразу записать в ячейку один ноль, а позже еще один. Или сразу два нуля записать?
Разница - огромная! Например у меня чип памяти с секторами стирания ==256КБ. А записывать нужно структуру размером например ==8 байт. Естественно я буду записывать в один сектор флешь кольцевого буфера 256*1024/8=32768 раз. И сотру его только 1 раз на каждые 32768 записи (когда сектор полностью заполнится). Или Вы будете писать, а затем стирать сектор каждый раз при записи следующих 8 байт данных? Чтобы ресурс флеши поскорее убить? В 32768 раза быстрее чем нужно?
PS: Правда для флешь памяти программ многих МК дело обстоит несколько сложнее: Там часто используют алгоритмы контроля (на аппаратном уровне) содержимого FLASH. И поэтому дописывать в произвольные смещения флешь - нельзя. А записывать можно элементами фиксированного размера (обычно == 16 байт). Но всё равно - это намного лучше чем стирать каждый раз перед записью заново весь сектор. Для EEPROM-памяти таких ограничений нет.
jcxz, я вообще-то не вам писал, а Самсусамыч. Соглашаясь с вашим утверждением, что "Ресурс считается по количеству стираний. Записывать можно сколько угодно.". Но только зачем вы сейчас о страничном флэше пишете? Мы про EEPROM с по-байтовым доступом говорили. Где можно записать-стереть 1 байт отдельно.
Но только зачем вы сейчас о страничном флэше пишете? Мы про EEPROM с по-байтовым доступом говорили. Где можно записать-стереть 1 байт отдельно.
Ну - здесь уже о разных говорили. Даже о FRAM. А EEPROM предложили как я помню - по той причине, что у неё ресурс стираний больше. Но другой путь увеличения ресурса кольцевого буфера - это просто взять чип ФЛЕШЬ большого объёма (пускай с большими секторами стирания). И таким образом увеличить количество циклов записи на одно стирание.
Вы с чтением не перепутали? Это читать можно сколько угодно, а стирать и записывать – только определённое количество раз.
Не перепутал. Почитайте что такое "флешь-память" и о принципах её работы.
Я прекрасно знаю, что это такое и «с чем это едят».
Как Вы прокомментируете данный параметр?
Вложение:
3.png
А данное утверждение?
Вложение:
4.png
Будете продолжать настаивать, что «Записывать можно сколько угодно.»? Ну-ну…
Цитата:
Ресурс записи Изменение заряда сопряжено с накоплением необратимых изменений в структуре и потому количество записей для ячейки флеш-памяти ограничено. Типичные количества циклов стирания-записи составляют от десятков и сотен тысяч до тысячи или менее, в зависимости от типа памяти и технологического процесса. Гарантированный ресурс значительно более низок при хранении нескольких бит в ячейке (MLC и TLC) и при использовании техпроцессов класса «30 нм» и более современных.
Одна из причин деградации — невозможность индивидуально контролировать заряд плавающего затвора в каждой ячейке. Дело в том, что запись и стирание производятся над множеством ячеек одновременно — это неотъемлемое свойство технологии флеш-памяти. Автомат записи контролирует достаточность инжекции заряда по референсной ячейке или по средней величине. Постепенно заряд отдельных ячеек рассогласовывается и в некоторый момент выходит за допустимые границы, которые может скомпенсировать инжекцией автомат записи и воспринять устройство чтения. Понятно, что на ресурс влияет степень идентичности ячеек. Одно из следствий этого — с уменьшением топологических норм полупроводниковой технологии создавать идентичные элементы все труднее, поэтому вопрос ресурса записи становится все острее.
Другая причина — взаимная диффузия атомов изолирующих и проводящих областей полупроводниковой структуры, ускоренная градиентом электрического поля в области кармана и периодическими электрическими пробоями изолятора при записи и стирании. Это приводит к размыванию границ и ухудшению качества изолятора, уменьшению времени хранения заряда.
Последний раз редактировалось Самсусамыч Чт сен 03, 2020 14:54:23, всего редактировалось 1 раз.
Будете продолжать настаивать, что «Записывать можно сколько угодно.»? Ну-ну…
И что? В чём именно противоречие с тем что я сказал? Почитайте внимательнее что я писал. Вы похоже ничего не поняли.
А те цитаты, которые Вы дёргаете, толком не понимая о чём там говорится, говорят о количестве циклов записи/стирания для одной ячейки флешь. Один такой цикл - это один переход одной ячейки (для SLC - бита) из нестёртого состояния, в стёртое. Можно конечно считать не переходы 0->1, а переходы 1->0 - это будет то же самое количество. И если скажем для сектора флеши размером 256КБ сделать 256*1024*8 = ~2М отдельных операций записи, в каждой операции модифицируя всего 1 бит, а потом стереть весь сектор, то счётчик циклов для всех ячеек сектора увеличится всего на 1. Вот об этом я и писал.
Почитайте внимательнее что я писал. Вы похоже ничего не поняли.
Вы утверждаете в своём высказывании: https://radiokot.ru/forum/viewtopic.php ... 3#p3887233 Что записывать можно неограниченное количество раз («Записывать можно сколько угодно»). Я Вам привожу факты, что это не так, так как ресурс записи имеет ограниченное количество раз. О котором указывает и производитель. Так что Ваше утверждение не соответствует действительности.
2. Записываем адрес в "шапку", 00FFFFFF а данные в нулевой сектор : 000000 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
3. Записываем новый адрес в "шапку", 01FFFFFF а данные в первый сектор : 0000001111111 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
4. Записываем новый адрес в "шапку", 02FFFFFF а данные в второй сектор : 00000011111112222222 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
А зачем тогда? Просто писать последовательно в сектор и всё. И все его байты будут изнашиваться равномерно. Но можно и вашим методом, только номер сектора указывать номером самого старшего 0-го бита. Т.е. шаги: 1. шапка == FFFFFFFF 2. шапка == FFFFFFFE 3. шапка == FFFFFFFC 4. шапка == FFFFFFF8 5. шапка == FFFFFFF0 ...
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Ну-ну…
