Форум РадиоКот

А ещё есть RAM c I2C/SPI интерфейсом. На одном конденсаторе неделями живут.
А ещё есть источники питания с небольшими АКБ.

Вариантов много, желания изучать каталоги мало.

[uquote="jcxz",url="/forum/viewtopic.php?p=4153774#p4153774"]А ещё существует FRAM/MRAM память.[/uquote]
Раз уж подели тему 10-летней давности... Конечно, FRAM - хорошее решение. Но всё же - внешний элемент, не дешёвый к тому же. Но для ответственных применений - лишнего 1$ не жалко.

[uquote="phalanx",url="/forum/viewtopic.php?p=4153803#p4153803"]А еще копеечные SPI Serial EERAM и I2C Serial EERAM, которым вообще кроме одного внешнего конденсатора ничего не нужно.[/uquote]Это которые внутри имеют ОЗУ и EEPROM и запись из 1-й во 2-ю по сигналу аварии питания?
Когда то давно заменили FRAM в одном из серийных изделий на такой чип (от Cypress). В результате получили периодические разрушения содержимого памяти.
ПО не менялось, и по идее - что FRAM что такой чип ОЗУ+EEPROM должны вроде работать одинаково. Но что то было не так. Происходило изредка, невоспроизводимо (если бы это было не серийное изделие, может и не заметили бы). Причину так и не нашли (были подозрения на сбои системы аварийного сохранения из-за каких-то помех в момент аварии питания, но подтвердить не удалось). Просто откатили обратно на FRAM - экономия копеечная по сравнению с FRAM, а гемору на порядок больше.

С тех пор не доверяю им. Но это только моё личное впечатление.

Добавлено after 2 minutes 14 seconds:
[uquote="tonyk",url="/forum/viewtopic.php?p=4153807#p4153807"]А ещё есть RAM c I2C/SPI интерфейсом. На одном конденсаторе неделями живут.
А ещё есть источники питания с небольшими АКБ.[/uquote]Это подойдёт если отключить надолго не могут. Или отключив, положить на холодный склад к примеру.

Добавлено after 5 minutes 16 seconds:
[uquote="Jack_A",url="/forum/viewtopic.php?p=4153811#p4153811"]Конечно, FRAM - хорошее решение. Но всё же - внешний элемент, не дешёвый к тому же.[/uquote]Не обязательно. Можно заменить МК на MSP430FRxxxx и будет вполне себе внутренний элемент.
Есть у меня работающий проектик на MSP430FR5739 - хорошая вещица для простых задач!

насвсяк для программистов-электротехников маленький скетч:
питание падает с 11V(порог детектирования потери питания) до 5V(~4V после 78L05) при потреблении 30mA и конденсаторе 1000uF за время
~=(11-5)1e-3/30e-3 = 0.2s
это всю eeprom несколько раз перезаписать можно, кодом хеминга с избыточностью x10

теперь менее удачный вариант: конденсатор прямо на питании mcu, пусть с 3.3>>3.1V(порог нашего прерывания) падает до 2.7V(bod), те же 30mA,1000uF
~=(3.1-2.7)1e-3/30e-3 = 13mS -уже тяжелее, можно 4700uF и будет 60mS.

ps ну и 30mA это зверский ток, скажем att2313 это скорее 1-6mA. ток что емкость можно и поменьше скореевсего.

AlexS4 писал(а):это всю eeprom несколько раз перезаписать можно

а сколько времени тратится на запись одного байта, например, в АТмега8 - ты никогда не интересовался?

[uquote="AlexS4",url="/forum/viewtopic.php?p=4154226#p4154226"]можно 4700uF и будет 60mS.[/uquote]Только кроме кондёра нужно ещё построить остальную схему монитора питания. И написать код, в котором сделать выравнивание износа. И учесть вариант, когда входное питание может дергаться скажем так пару раз в секунду в течение нескольких месяцев - чтобы дырка в EEPROM-е не протёрлась при этом.
Потом выпустить серию девайсов и внезапно обнаружить, что если в момент после срабатывания монитора питания, при работе кода сохранения проскакивает помеха и МК перезапускается (например от WDT), то никакого сохранения не происходит, а происходит разрушение содержимого EEPROM.

А затем зайти в магазин и обнаружить, что цена одного такого кондёра будет уже побольше, чем у минимальной FRAM. С которой организовать систему хранения, устойчивую к перезагрузкам и протираниям на порядок проще, чем с EEPROM. И нафига тогда оно надо?

Добавлено after 1 minute 29 seconds:
[uquote="Starichok51",url="/forum/viewtopic.php?p=4154330#p4154330"]а сколько времени тратится на запись одного байта, например, в АТмега8 - ты никогда не интересовался?[/uquote]
+++ И не просто записи, а "записи с предварительным стиранием". Которая выполняется ещё дольше.
Про атмегу не скажу, но например у XMC4700 (с которым сейчас работаю) только одно стирание выполняется до 5.5 сек(!) Это ж какой кондёр надо впендюрить, чтобы столько продержаться?!

[uquote="Starichok51",url="/forum/viewtopic.php?p=4154330#p4154330"]а сколько времени тратится на запись одного байта, например, в АТмега8 - ты никогда не интересовался?[/uquote]
около 8mS в старых мегах, в свежих (1.8..6V) мегах и тайни 1.8mS.
немножко преувеличил, не всю eeprom, но создать условия чтоб успеть несколько байт загнать на предворительно подготовленное место - вовсе не проблема.

jcxz писал(а):+++ И не просто записи, а "записи с предварительным стиранием".

заранее стереть конечно нельзя

jcxz писал(а):И написать код, в котором сделать выравнивание износа.

его тоже писать надо после аварии питания, чтоб интереснее было ...
это опция, если байты не используются - да можно таким способом увеличить число допустимых выключений... со 100k скажем до 10M
но невсегда это нужно. алгоритм же приметивен и не требует увеличения времени записи, напр: записываем актуальное число на границе стертого участка, когда стертого места не остается - стираем весь массив выделенный под это (заранее стираем, до аварии)

jcxz писал(а):Только кроме кондёра нужно ещё построить остальную схему монитора питания.

2 резистора это сложно)) посчитаем нестабильность порога?)

jcxz писал(а):если в момент после срабатывания монитора питания, при работе кода сохранения проскакивает помеха и МК перезапускается (например от WDT), то никакого сохранения не происходит, а происходит разрушение содержимого EEPROM.

а если то же самое произойдет при записи в fram?

jcxz писал(а):И учесть вариант, когда входное питание может дергаться скажем так пару раз в секунду в течение нескольких месяцев - чтобы дырка в EEPROM-е не протёрлась при этом.

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

jcxz писал(а):А затем зайти в магазин и обнаружить,

что реальных аргументов нет и осталось только высасывать из пальца сравнивая розничную цену самого дорого электролита с оптовой ценой самого дешевого fram.
https://www.chipdip.ru/catalog/aluminum ... 6.3V&ps=x3 =14р
https://www.chipdip.ru/catalog-show/ic- ... fram&ps=x3 =210р

я вот так сделал: поставил от блока питания на плюсовой вывод диод и на +5 v ардуино. и конденсатор на 1000мкф на +5 v адуино , остальные потребители просто от блока питания запитал (то есть после пропадания питания конденсатор на 1000мкф питает одну ардуину) и если не поставить задержку delay(3500); то код успевает пробежать несколько раз и перезаписать значения day_0, month_0, bme_temp_0
в day_1, month_1, bme_temp_1 и day_2, month_2, bme_temp_2 значения 0_дня, 0_месяца, 0_тепературы.
с июня 2020года пока все работает как задумывал

[uquote="AlexS4",url="/forum/viewtopic.php?p=4154591#p4154591"]заранее стереть конечно нельзя [/uquote]Заранее это когда? При выключенном питании?
Попробуйте представить ситуацию: питание включилось и сразу выключилось. И так 100 раз подряд. Когда предлагаете стирать?

[uquote="AlexS4",url="/forum/viewtopic.php?p=4154591#p4154591"]но невсегда это нужно. алгоритм же приметивен и не требует увеличения времени записи, напр: записываем актуальное число на границе стертого участка, когда стертого места не остается - стираем весь массив выделенный под это (заранее стираем, до аварии)[/uquote]Я вам конкретный пример привёл: XMC4700 у которого время стирания сектора может доходить до 5.5сек. Предложите алгоритм, который позволит фиксировать время выключения при кратковременном включении/выключении.
В студию.

[uquote="AlexS4",url="/forum/viewtopic.php?p=4154591#p4154591"]а если то же самое произойдет при записи в fram?[/uquote]То всё нормально - время выключения во FRAM остаётся.

[uquote="AlexS4",url="/forum/viewtopic.php?p=4154591#p4154591"]просто это редкий частный случай, неболее.[/uquote]Может и редкий, но мы с таким сталкивались. Точнее - наши заказчики. И не однократно. И обнаружить эти факты смогли только потому, что выключения писались в журнал во FRAM.
Без этого - гадали бы почему некоторые устройства у заказчика иногда почему-то не работают по несколько дней....

[uquote="AlexS4",url="/forum/viewtopic.php?p=4154591#p4154591"]что реальных аргументов нет и осталось только высасывать из пальца сравнивая розничную цену самого дорого электролита с оптовой ценой самого дешевого fram.[/uquote]Я сравнил цены первых попавшихся конденсатора указанной вами ёмкости и минимальной FRAM (объёма достаточного для сохранения события выключения), на одном и том же ресурсе:

Почувствуйте разницу!
Кроме того ещё один плюс FRAM: для записи события выключения достаточно несколько байт, а остальной объём из 512байт можно использовать ещё для чего-то (например хранения конфига). Бесплатно! И гораздо удобнее использовать чем с EEPROM.

jcxz писал(а):Попробуйте представить ситуацию: питание включилось и сразу выключилось. И так 100 раз подряд. Когда предлагаете стирать?

это не нормальный режим жля устройства с mcu. это норм режим для светодиода в режиме передатчика морзе
но и это элементарно обходится если такое тз, я выше писал.
и тогда уже неважно питать только fram или весь mcu )).
и если исходить из того что питание всетаки чаще есть чем наоборот и выключается не 100раз подряд то подготовить (стереть) сектор eeprom заранее нет никаких проблем. хоть 5.5s хоть 6.

jcxz писал(а):То всё нормально - время выключения во FRAM остаётся.

если _в процессе записи_ будет сбой то консистентность данных неизбежно будет нарушена
обойти это можно лок-алгоритмами записи, независимо от вида носителя, да с eeprom запись будет дольше и ресурс перезаписей ограничен но с этим никто и не спорил

честно говоря не понимаю о чем тут спорить, есть способы:
-периодическая (сравнительно редкая) запись в eeprom
-запись в eeprom по аварии
-периодическая (частая) запись в fram или запись по аварии, неважно
-резервное микро-питание остановленного mcu для сохранения sram
-резервное питание работающего mcu
каждый из способов имеет набор очевидных и неочень плюсов и минусов...
абсолютно лучшего способа во всех смыслах не существует,
это не "винилово-ламповый звук против 24x96" это "бензин против лития"

-=Vovka=- писал(а):от 20,20руб за штуку

добавьте доставку и умножте на риски получить муляж. китайские электролиты в мешках всеравно дешевле потому что это более массовый товар, да дело даже не в том что дешевле, иногда еще +1 чип неприемлем потому что скажем нет места или свободных ног у att10 c 4 gpio )).

[uquote="AlexS4",url="/forum/viewtopic.php?p=4154847#p4154847"]

jcxz писал(а):То всё нормально - время выключения во FRAM остаётся.

если _в процессе записи_ будет сбой то консистентность данных неизбежно будет нарушена
обойти это можно лок-алгоритмами записи, независимо от вида носителя[/uquote]ТЗ необходимо фиксировать время выключения устройства с точностью не хуже 1сек. Режим работы устройства = 24x8.
Решение на FRAM - простой алгоритм: пишем непрерывно несколько раз в секунду, чередуя записи в 2 разных области FRAM. Если даже в момент записи (при выключении) последняя запись порушилась - останется предпоследняя, да точность времени будет чуть хуже (на период записи). Ну и что? Всё равно погрешность времени - менее 1сек.
А с EEPROM как? Опишите алгоритм решения задачи по ТЗ "не зависимый от вида носителя" и устойчивый к сбоям/перезагрузкам при записи?

[uquote="AlexS4",url="/forum/viewtopic.php?p=4154847#p4154847"]да дело даже не в том что дешевле, иногда еще +1 чип неприемлем потому что скажем нет места или свободных ног у att10 c 4 gpio )).[/uquote]На чип в SOIC-8 нет места, а на в несколько раз больший электролит 4700мкФ x 16V - есть?

PS: И кстати - у электролитов со снижением температуры значительно падает ёмкость. А работоспособность устройства должна обеспечиваться во всём диапазоне температур. Так что ваш расчёт длительности работы при аварии неверен. Надо ещё добавить ёмкости, если необходим индастриал температурный диапазон.