Раз уж подели тему 10-летней давности... Конечно, FRAM - хорошее решение. Но всё же - внешний элемент, не дешёвый к тому же. Но для ответственных применений - лишнего 1$ не жалко.
А еще копеечные SPI Serial EERAM и I2C Serial EERAM, которым вообще кроме одного внешнего конденсатора ничего не нужно.
Это которые внутри имеют ОЗУ и EEPROM и запись из 1-й во 2-ю по сигналу аварии питания? Когда то давно заменили FRAM в одном из серийных изделий на такой чип (от Cypress). В результате получили периодические разрушения содержимого памяти. ПО не менялось, и по идее - что FRAM что такой чип ОЗУ+EEPROM должны вроде работать одинаково. Но что то было не так. Происходило изредка, невоспроизводимо (если бы это было не серийное изделие, может и не заметили бы). Причину так и не нашли (были подозрения на сбои системы аварийного сохранения из-за каких-то помех в момент аварии питания, но подтвердить не удалось). Просто откатили обратно на FRAM - экономия копеечная по сравнению с FRAM, а гемору на порядок больше.
С тех пор не доверяю им. Но это только моё личное впечатление.
Конечно, FRAM - хорошее решение. Но всё же - внешний элемент, не дешёвый к тому же.
Не обязательно. Можно заменить МК на 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. ток что емкость можно и поменьше скореевсего.
Только кроме кондёра нужно ещё построить остальную схему монитора питания. И написать код, в котором сделать выравнивание износа. И учесть вариант, когда входное питание может дергаться скажем так пару раз в секунду в течение нескольких месяцев - чтобы дырка в EEPROM-е не протёрлась при этом. Потом выпустить серию девайсов и внезапно обнаружить, что если в момент после срабатывания монитора питания, при работе кода сохранения проскакивает помеха и МК перезапускается (например от WDT), то никакого сохранения не происходит, а происходит разрушение содержимого EEPROM.
А затем зайти в магазин и обнаружить, что цена одного такого кондёра будет уже побольше, чем у минимальной FRAM. С которой организовать систему хранения, устойчивую к перезагрузкам и протираниям на порядок проще, чем с EEPROM. И нафига тогда оно надо?
а сколько времени тратится на запись одного байта, например, в АТмега8 - ты никогда не интересовался?
+++ И не просто записи, а "записи с предварительным стиранием". Которая выполняется ещё дольше. Про атмегу не скажу, но например у XMC4700 (с которым сейчас работаю) только одно стирание выполняется до 5.5 сек(!) Это ж какой кондёр надо впендюрить, чтобы столько продержаться?!
а сколько времени тратится на запись одного байта, например, в АТмега8 - ты никогда не интересовался?
около 8mS в старых мегах, в свежих (1.8..6V) мегах и тайни 1.8mS. немножко преувеличил, не всю eeprom, но создать условия чтоб успеть несколько байт загнать на предворительно подготовленное место - вовсе не проблема.
jcxz писал(а):
+++ И не просто записи, а "записи с предварительным стиранием".
заранее стереть конечно нельзя
jcxz писал(а):
И написать код, в котором сделать выравнивание износа.
его тоже писать надо после аварии питания, чтоб интереснее было ... это опция, если байты не используются - да можно таким способом увеличить число допустимых выключений... со 100k скажем до 10M но невсегда это нужно. алгоритм же приметивен и не требует увеличения времени записи, напр: записываем актуальное число на границе стертого участка, когда стертого места не остается - стираем весь массив выделенный под это (заранее стираем, до аварии)
jcxz писал(а):
Только кроме кондёра нужно ещё построить остальную схему монитора питания.
2 резистора это сложно)) посчитаем нестабильность порога?)
jcxz писал(а):
если в момент после срабатывания монитора питания, при работе кода сохранения проскакивает помеха и МК перезапускается (например от WDT), то никакого сохранения не происходит, а происходит разрушение содержимого EEPROM.
а если то же самое произойдет при записи в fram?
jcxz писал(а):
И учесть вариант, когда входное питание может дергаться скажем так пару раз в секунду в течение нескольких месяцев - чтобы дырка в EEPROM-е не протёрлась при этом.
а еще взрываются мины и гаммалучи плавающие затворы флэша теребят если такой частный случай то нужен просто больше запас, буфферный литиевый аккумулятор , или микроватное питание на msc переведенном в саспенд сохранять, или да fram, почему нет, просто это редкий частный случай, неболее.
if(analogRead(0)<475){ //если попало питание запомнить в память EEPROM.put(300, day_0);EEPROM.put(305, month_0);EEPROM.put(310, bme_temp_0); // Записать значение EEPROM.put(315,day_1);EEPROM.put(320,month_1);EEPROM.put(325,bme_temp_1); // Записать значение EEPROM.put(330,day_2);EEPROM.put(335,month_2);EEPROM.put(340,bme_temp_2); // Записать значение delay(3500); }
я вот так сделал: поставил от блока питания на плюсовой вывод диод и на +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года пока все работает как задумывал
Заранее это когда? При выключенном питании? Попробуйте представить ситуацию: питание включилось и сразу выключилось. И так 100 раз подряд. Когда предлагаете стирать?
но невсегда это нужно. алгоритм же приметивен и не требует увеличения времени записи, напр: записываем актуальное число на границе стертого участка, когда стертого места не остается - стираем весь массив выделенный под это (заранее стираем, до аварии)
Я вам конкретный пример привёл: XMC4700 у которого время стирания сектора может доходить до 5.5сек. Предложите алгоритм, который позволит фиксировать время выключения при кратковременном включении/выключении. В студию.
Может и редкий, но мы с таким сталкивались. Точнее - наши заказчики. И не однократно. И обнаружить эти факты смогли только потому, что выключения писались в журнал во FRAM. Без этого - гадали бы почему некоторые устройства у заказчика иногда почему-то не работают по несколько дней....
что реальных аргументов нет и осталось только высасывать из пальца сравнивая розничную цену самого дорого электролита с оптовой ценой самого дешевого fram.
Я сравнил цены первых попавшихся конденсатора указанной вами ёмкости и минимальной FRAM (объёма достаточного для сохранения события выключения), на одном и том же ресурсе: Почувствуйте разницу! Кроме того ещё один плюс FRAM: для записи события выключения достаточно несколько байт, а остальной объём из 512байт можно использовать ещё для чего-то (например хранения конфига). Бесплатно! И гораздо удобнее использовать чем с EEPROM.
Попробуйте представить ситуацию: питание включилось и сразу выключилось. И так 100 раз подряд. Когда предлагаете стирать?
это не нормальный режим жля устройства с mcu. это норм режим для светодиода в режиме передатчика морзе но и это элементарно обходится если такое тз, я выше писал. и тогда уже неважно питать только fram или весь mcu )). и если исходить из того что питание всетаки чаще есть чем наоборот и выключается не 100раз подряд то подготовить (стереть) сектор eeprom заранее нет никаких проблем. хоть 5.5s хоть 6.
jcxz писал(а):
То всё нормально - время выключения во FRAM остаётся.
если _в процессе записи_ будет сбой то консистентность данных неизбежно будет нарушена обойти это можно лок-алгоритмами записи, независимо от вида носителя, да с eeprom запись будет дольше и ресурс перезаписей ограничен но с этим никто и не спорил
честно говоря не понимаю о чем тут спорить, есть способы: -периодическая (сравнительно редкая) запись в eeprom -запись в eeprom по аварии -периодическая (частая) запись в fram или запись по аварии, неважно -резервное микро-питание остановленного mcu для сохранения sram -резервное питание работающего mcu каждый из способов имеет набор очевидных и неочень плюсов и минусов... абсолютно лучшего способа во всех смыслах не существует, это не "винилово-ламповый звук против 24x96" это "бензин против лития"
добавьте доставку и умножте на риски получить муляж. китайские электролиты в мешках всеравно дешевле потому что это более массовый товар, да дело даже не в том что дешевле, иногда еще +1 чип неприемлем потому что скажем нет места или свободных ног у att10 c 4 gpio )).
То всё нормально - время выключения во FRAM остаётся.
если _в процессе записи_ будет сбой то консистентность данных неизбежно будет нарушена обойти это можно лок-алгоритмами записи, независимо от вида носителя
ТЗ необходимо фиксировать время выключения устройства с точностью не хуже 1сек. Режим работы устройства = 24x8. Решение на FRAM - простой алгоритм: пишем непрерывно несколько раз в секунду, чередуя записи в 2 разных области FRAM. Если даже в момент записи (при выключении) последняя запись порушилась - останется предпоследняя, да точность времени будет чуть хуже (на период записи). Ну и что? Всё равно погрешность времени - менее 1сек. А с EEPROM как? Опишите алгоритм решения задачи по ТЗ "не зависимый от вида носителя" и устойчивый к сбоям/перезагрузкам при записи?
да дело даже не в том что дешевле, иногда еще +1 чип неприемлем потому что скажем нет места или свободных ног у att10 c 4 gpio )).
На чип в SOIC-8 нет места, а на в несколько раз больший электролит 4700мкФ x 16V - есть?
PS: И кстати - у электролитов со снижением температуры значительно падает ёмкость. А работоспособность устройства должна обеспечиваться во всём диапазоне температур. Так что ваш расчёт длительности работы при аварии неверен. Надо ещё добавить ёмкости, если необходим индастриал температурный диапазон.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
маленький скетч:
