вы должны записывать всё, что есть данные
после утверждения документов заказчиком, да, некоторые данные можно удалить
но лучше перевести в weak, чтобы удалить не сразу, но при недостатке места в порядке очереди

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

Для всего описанного Вами выше (манагеры, отчёты, СТО и т.п.) для чего именно нужна "мгновенная запись на скорости клока" или "побайтовый доступ"?
Для описанных Вами условий задачи я, естественно, выбрал бы HDD (или SSD). По всем параметрам для указанной задачи он подходит в разы лучше чем FRAM, а тем более - чем описанный вами зоопарк из FRAM+FLASH+SD.
Против FRAM ничего не имею. Не раз применял (и применяю) её в своих проектах. Только всему своё место.

Ставить серьезные диски ради 512К (по факту их там около 490к) данных?) Нет никакого зоопарка. На FRAM рабочие данные, на FLASH - резервная копия, на SD - логи. Всё в меру.

Ну тут, как говорят, хозяин-барин, но если уж так, то зачем буферировать-то все это - "SDRAM не бесконечна, 64 Мбайта на всё. Там и так крутится кэш(зеркало на чтение) AT45DB641 и нескольких FM25V10, память GUI, куча lwIP и виртуальный диск в FatFs (помимо карточки)."???

Там и так крутится кэш(зеркало на чтение) AT45DB641 - особенно это, гда по вашим словам - резервная копия, или во т это "виртуальный диск в FatFs ", тоже непонятная шняга
Получается какой-то дисковый маниакализм, аля RAID5 в квадрате

Кэши(зеркало) удобнее читать чем тянуть байты из AT45. Проц меньше нагружается да и скорость чтения выше. Можно и без них, просто всё будет помедленнее, заметно медленнее. Если sdram позволяет, отчего нет? Хотел сделать кэш еще и на запись, но не стал, хотя тоже ничего сложного. FRAM читается чуть медленнее ( клок максимум 40мгц, spi настроен на 22.5мгц), но там и объемы меньше. Библиотечка из 4х микрух делает единое адресное пространство в 512к, удобно работать. Виртуальный диск это просто область памяти в sdram отформатированной в Fat32 на случай отказа карты памяти, чтобы спасти хотя бы часть логов. Написано много, однако реализация простая и логичная. Диск в sdram делается вообще за 5 минут : объявляется буфер нужного размера в sdram и функции чтения записи, хоть через memcpy.

Это я в курсе, что РАМ диск проще простого, у самого такой в системе, но не для копий, а для быстрой загрузки картинок. Я писал про то, зачем делать в памяти буферизацию того, что у вас там в АТ45 й находится, по вашим словам там резервная копия, предполагается, что читаться она должна только в случае нештатной ситуации, а при нормальной работе туда только что-то редко когда записывается, или я что-то не так понимаю в понятии "резервная копия"??

Эти самые резервные копии через фтп верхнее ПО раз в сутки сливает себе. Там же прошивка, которую также можно закачать/ прочитать. В общем чтение присутствует.
Я понимаю ваш скепсис, я и сам, иногда оглядываясь, думаю - зачем так всё усложнять. Я привык рассчитывать на самые фиговые ситуации которые могут произойти. Всё что может отказать, когда нибудь откажет, невероятная ситуация, для которой должно сложиться вместе 100 разных факторов когда-нибудь обязательно произойдет.

"Верхнее ПО" - это ПО для компа? Тогда зачем оно хранится в МК вообще?
Т.е. каждые сутки вы сливаете по фтп прошивки, даже если они не были изменены? Зачем?

Сливаются копии FRAM а не прошивка. Но да, прошивку тоже можно слить, хотя штатно это не делается, т.к. как вы сказали - смысла нет, она не меняется. Бэкап fram хранится на случай ошибок fram и отсутствия связи с ПО компа, либо глюком ПО компа, чтобы восстановить работоспособность, откатиться на рабочую версию данных. Если ПО есть, то уже при серсисе вручную можно выбрать точку отката.

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

И часто такое бывает? По какой причине?

Я так же юзаю эту же фрам и отвечу: бывает питание пропадает при записи, и, возможно, заряда ионистора не хватит дописать страницу.

Я все как раз так и понял, просто в моем понимании, ПО для компа должно храниться на компе, а резервная копия на отдельно выделенной флешке или компакт-диске. Кстати там же и резервную копию прошивки устройства нужно держать.



В случае питания и ионистора - это просчет проектирования устройства. Питания должно хватать при записи максимально возможного блока и еще +25-40% на деградирование ионистора.

Иногда есть масса-габаритные ограничения, поэтому приходится применять то, что есть и перестраховываться.

Лет надцать это наверно имело место быть, но сегодня и ионисторы и литиевые аккумы стали очень маленькие, и китайцы умудряются в спичечный коробок засунуть плату с МК и памятью, экранчик, камеру, динамик и литиевый аккум на 2 часа работы

Питания ионистора хватает на то, чтобы несколько раз перезаписать всю FRAM. У LTC3226 LDO на выходе, поэтому 3.3 держится до последнего. Точно не вспомню, но около 2-3 секунд есть. Плюс, имеет выходы, сигнализирующие о переключении на резерв, и тогда проц штатно завершает все операции и готовится отрубиться.
Верхнее ПО не хранится нигде в устройстве, это действительно бессмысленно. Возможно я несколько двусиысленно написал.
Насчет ошибок FRAM - никто не может дать гарантию, что их не может быть при штатной работе. За все время она была одна и бэкап спас. Причину её возникновения выяснить не удалось. Просто один битик записался не так и crc не сошлась.

Видимо для этого и нужно держать в кеше в ОЗУ образы AT45. Чтобы (не дай бог!) не вызвать задержку с ответом верхнему ПО в целую миллисекунду(!!!) когда оно, раз в сутки, наконец-то решит обратиться.



Столько слов о неких мифических глюках в софте и компа и SD-карты и чего там ещё.... А когда эти самые "бэкапы FRAM" Вы у себя в AT45 пишете, то что при этом делается со штатной работой ПО, которое эти данные во FRAM пишет? Атомарность этих данных у Вас конечно поддерживается? И как Вы этого добиваетесь? Приостанавливаете всю работу устройства на время бэкапа FRAM?
А если при модификации любых рабочих данных во FRAM произойдёт сбой питания к примеру? Или сбой питания при записи всех этих бекапов/логов в AT45/SD?


Наверное каждый раз при взрывах сверхновых в соседней галактике. Вы разве не защищаетесь от этого??


А причём тут заряд ионистора и "не хватит дописать страницу"? Может всё-таки руки?
А если не выключение питания, а скажем мощная помеха по цепям питания? Или ещё хуже - пачка помех (что очень часто бывает в жизни).

У меня в проекте, где было много сложных и больших объектов данных во FRAM, вообще никакого ионистора или супервизора питания не было.
Записи/модификации этих объектов шли непрерывно каждые несколько десятков/сотен мсек, различными независимыми асинхронными процессами.
Изделие проверялось на воздействие пачек помех и сбоев питания при работе в штатном режиме.
Так вот - никаких разрушений данных не было. Были естественно только случаи, когда что-то не успевало записаться. Но вот чтобы "недописалось" - такого не было.
Потому что систему хранения надо строить с умом, а не городить зоопарк для мифической защиты от мифических космических частиц.


Это нужно только если все данные хранить и модифицировать в ОЗУ и скидывать их в энергонезависимую память только при аварии питания.
Если писать в энергонезависимую память при каждом изменении данных, то никаких ионисторов не нужно вообще.


А если у автора его СТО находится где-нить зимой в ХМАО к примеру? И нерадивый слесарь не закрыл ворота? Что будет если на этот "спичечный коробок" дунет ветерком этак под минус 60 по Цельсию? Вот уж точно - ошибка FRAM будет обеспечена


Причины "ошибок FRAM" как правило: либо баги ПО, управляющего этой самой FRAM; либо помехи по шине из-за плохой разводки.

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

Ну ладно. Но атомарность записи блоков данных во FRAM к примеру обеспечиваете?
Что будет если во время записи такого блока в его середине отключится питание или произойдёт перезапуск МК по помехе?

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

Атомарность != совместный доступ.
Атомарность - это непрерывность операции или неделимость данных. В данном случае я имел в виду, что любой записываемый функциональный блок данных на FRAM, должен записываться как единый неделимый объект. Т.е. - если стартовала операция записи объекта то в конце концов будет или записан новый объект или остался старый объект (до записи) и никаких промежуточных состояний (часть нового объекта успела записаться поверх старого, остальная часть - осталась от старого).


Т.е. - новые данные у Вас пишутся поверх старых и никакой защиты от внезапного прерывания записи и перезапуска устройства у вас нет?
Если перезапуск случится в момент записи некоего важного объекта данных, то и новый объект будет потерян и старый тоже.
В моих устройствах, где нужно ответственное хранение, я обеспечиваю атомарность модификации объектов (во FRAM/FLASH).
Вы пытаетесь защищаться от каких-то мифических проблем, нагромождая винегрет из разных типов памяти, при этом совершенно не решая очевидную проблему.
Если её корректно решите - больше никакие дублирования и троирования данных не нужны будут.

Да там столько дублирований, ну произойдет...Продублируется еще раз и так до победы!

На STM32F407 сделал mass storage in ram. Выделил 64 КБайта. Мне нужно с компа писать файл на этот раздел и его использовать в микроконтроллере. Для чтения файла использую fatfs.
RAM не инициализирую поэтому после каждого включения винда просит отформатировать раздел.
Под Win10 все работает как надо. Форматирую раздел, записываю файл с нужным мне именем, читаю.
Под Win8 не хочет, говорит что файла не существует.
Для отладки добавил вывод содержимого раздела как здесь http://elm-chan.org/fsw/ff/doc/readdir.html
Под win10 все отлично, показывает имена папок и файлов которые я создаю на разделе.
Под win8 не видит ни файлов ни папок созданных на разделе. Файлы туда пишутся, в дебаггере вижу что в этих 64 КБ памяти появляется и имя файла и содержимое.
Что с этим делать?

Признаться да, такой защиты у меня нет, новые данные пишутся поверх старых. Единственный способ отследить ошибку - несоответствие crc. Выделять временный буфер в той же fram, туда писать новые данные, а затем перекидывать в рабочую область? Что помешает контроллеру сброситься в момент перезаписи?
Дублирование только одно - ежедневная копия fram во flash. Никаких других нет. Буду рад конструктивным советам. От внезапного прерывания по питанию спасает ионистор.

Да пускай сбрасывается хоть 1000 раз - всё будет ок.
Атомарная модификация объектов во FRAM/FLASH у меня реализована примерно так:
Во FRAM имеется некая бэкап-область. При необходимости выполнить опасную операцию (перезапись объекта), в бэкап-область заносится полная инфа о планируемой операции (она журналируется): кто, куда, чего и сколько. Также, если операция планируется во flash и требуется модифицировать часть сектора (т.е. - выполнить стирание всего сектора, а потом запись новые данные + старые), то в бэкап-область заносится целевое содержимое всего сектора (новые записываемые данные + старые уже имеющиеся на странице). Потом в бэкап-области ставится флажок, что она содержит данные бэкапа (флаг валидности бэкапа). Далее - производится собственно сама опасная операция. Далее - стирается флаг валидности бэкапа.
Вот и всё - операция становится безопасной, атомарной.
При старте Службы хранения (старт МК), считывается флаг валидности бэкапа и, если он установлен, то выполняется указанная в бэкапе операция и после этого флаг сбрасывается.
МК может перезапуститься сколько угодно раз в любом месте этой процедуры - данные останутся атомарными и валидными.
Естественно область бэкапа должна иметь размер достаточный для хранения максимально возможного объекта хранения во FRAM/FLASH (вся инфа во FRAM/FLASH у меня разбита на независимые объекты хранения) и для хранения одного объекта стирания FLASH (сектор).
Для примера:
Если производится модификация объекта во FRAM, то в бэкап-области появится запись: "начиная с адреса XXXX записываются данные DD,DD,...DD".
Если производится модификация сектора во FLASH, то в бэкап-области появится запись: "производится стирание сектора SSSS, затем запись в него со смещения XXXX данных DD,DD,...DD".
Если производится дозапись (без стирания во FLASH), то в бэкап-области появится запись: "производится запись в сектор SSSS со смещения XXXX данных DD,DD,...DD".

CRC тут никакой почти не надо. Единственное в чём CRC может помочь - обнаружить начальное состояние бэкап-области до первого запуска firmware (мусор во FRAM). После первого запуска состояние бэкап-области однозначно определяется по флагу валидности бэкапа.

Для файловой системы безопасная модификация у меня устроена немного по-другому (без использования бэкап-области), так как файловая система позволяет оптимальнее это сделать с меньшим количеством операций.