Снова о ресурсе EEPROM

[Petrovi4]

ASR Такое ощущение, что большая часть сообщений ТСом принципиально игнорится. Еще в самом начале темы писали, что алгоритмы снижения количества записей EEPROM, как и алгоритмы выравнивания ее износа будут сильно зависимы от от самих данных. Причем в это же входит и специфика применения данных в программе устройства, и то на что будет влиять их сбой.
Приведенный выше алгоритм с задержкой записи обычно применяют для варианта ручного регулирования параметра, например регулятор громкости. Крутится не часто, но не сразу не нужное значение, потому такой алгоритм там работает хорошо. Для других мест - как повезет.

[Вячеслав М.]

Да нет, не игнорится - задержка записи, это очень похоже на то что и я предложил, просто пока может не все поняли как эту очередь на запись создать, если ещё несколько запросов из разных мест с разными таймингами.

[jcxz]

[uquote="Вячеслав М.",url="/forum/viewtopic.php?p=4689910#p4689910"]Eстественно мониторить питание нужно на 8V, а не на 5V, когда уже поздно что то делать.[/uquote]Расскажите - как именно "мониторить 8V" если устройство питается например от +5V USB? Или от USB питаться нельзя?
И как обеспечить эти самые "полсекунды"? Впендюривать конденсатор, размером больше чем всё остальное устройство?

Добавлено after 2 minutes 9 seconds:
[uquote="Вячеслав М.",url="/forum/viewtopic.php?p=4689916#p4689916"]Ну например появляется возможность сбрасывать в EEPROM только при пропадании питания, это очень сильно продлевает ресурс, тем более что мы уже выяснили что после пропадания питания есть уйма времени, это если чисто об EEPROM говорить и о софте, если придерживаться темы.[/uquote]Откуда эта самая "уйма времени" и почему во время этой "уймы" не может прилететь помеха, которая вызовет сброс МК?

Добавлено after 1 minute 48 seconds:
[uquote="Вячеслав М.",url="/forum/viewtopic.php?p=4689921#p4689921"]Да нет, не игнорится - задержка записи, это очень похоже на то что и я предложил[/uquote]Все давно всё знают про этот способ. И все знают что он крайне ненадёжен на практике. Из-за влияния помех.

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

И реализовывать мы его пробовали в коммерческих устройствах. В результате отказались от него после всесторонних испытаний устройств на ЭМС.

[Вячеслав М.]

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

А про питание по USB, так у меня сразу возникла мысль как это сделать, и без "Больших конденсаторов", но вам похоже это не интересно, так что наверно всё таки вам по другому адресу, где с помехами борются.

[ARV]

[uquote="Petrovi4",url="/forum/viewtopic.php?p=4689917#p4689917"]ASR ощущение, что большая часть сообщений ТСом принципиально игнорится[/uquote]я внимательно читаю все даваемые мне советы, и не менее тщательно их обдумываю, но "реагирую" в теме только в двух случаях: если я вообще не понял или категорически не согласен, или если мне советуют невозможные вещи, как например, переделку схемы.

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

[Petrovi4]

[uquote="ARV",url="/forum/viewtopic.php?p=4689970#p4689970"]я в поиске наиболее универсального решения, поскольку никаких конкретных сведений ни о данных, ни о частоте их изменения, у меня нет, только предположения.[/uquote]
Ну... подобный изврат в поставленной системе уравнений решение имеет только в области мнимых чисел также, как и решение известного соотношения дешево-быстро-качественно.

[ARV]

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

[Petrovi4]

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

[jcxz]

[uquote="Petrovi4",url="/forum/viewtopic.php?p=4689986#p4689986"]Есть. Но смотря в чем и с какой стороны посмотреть.
В ваших условиях остается только изобретать кольцевую запись "страницами" с метками порядка записи и контролем целостности этих "страниц". по возможности группируя данные по частоте их обновления, дабы подгонять размер кольца записи для выравнивания износа.[/uquote]Не обязательно "кольцевую". В принципе возможны разные алгоритмы выравнивания износа. Журнал или кольцо - это только одни из. Самые простые, имхо.
Наверняка можно придумать и получше алгоритм.
Например: Разбитие на отдельные одинаковые ячейки с индивидуальным счётчиком перезаписей в каждой и периодическим перераспределением редко-меняющихся данных из ячеек с малым износом в более изношенные. Подобно тому, что делают SSD, но более мелкими порциями. В каждой ячейке хранить одну переменную с её идентификатором и счётчиком перезаписей. Но это более сложный алгоритм. Журнал - проще.

PS: Журнал проще не кольцевой, а линейный. С отдельным массивом хранения начальных значений переменных и обновлениями их при каждом заполнении линейного журнала. Описывал в теме в ARM-разделе: https://radiokot.ru/forum/viewtopic.php ... 8#p4689798