[sadat 0]

"Верхнее ПО" - это ПО для компа? Тогда зачем оно хранится в МК вообще?

Т.е. каждые сутки вы сливаете по фтп прошивки, даже если они не были изменены? Зачем?

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

А прошивку просто есть возможность загнать в устройство, ну или проверить файл на флешке на актуальность.

[mantech 37]

Бэкап fram хранится на случай ошибок fram

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

[sadat 0]

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

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

[mantech 37]

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

 

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

 

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

 

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

[sadat 0]

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

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

[mantech 37]

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

 

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

[Hold 0]

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

Верхнее ПО не хранится нигде в устройстве, это действительно бессмысленно. Возможно я несколько двусиысленно написал.

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

Изменено 18 октября, 2017 пользователем Hold

[jcxz 192]

Эти самые резервные копии через фтп верхнее ПО раз в сутки сливает себе. Там же прошивка, которую также можно закачать/ прочитать. В общем чтение присутствует.

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

 

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

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

А если при модификации любых рабочих данных во FRAM произойдёт сбой питания к примеру? Или сбой питания при записи всех этих бекапов/логов в AT45/SD?

 

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

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

 

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

А причём тут заряд ионистора и "не хватит дописать страницу"? Может всё-таки руки? ;)

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

 

У меня в проекте, где было много сложных и больших объектов данных во FRAM, вообще никакого ионистора или супервизора питания не было.

Записи/модификации этих объектов шли непрерывно каждые несколько десятков/сотен мсек, различными независимыми асинхронными процессами.

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

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

Потому что систему хранения надо строить с умом, а не городить зоопарк для мифической защиты от мифических космических частиц.

 

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

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

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

 

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

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

 

Причину её возникновения выяснить не удалось. Просто один битик записался не так и crc не сошлась.

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

[Hold 0]

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

[jcxz 192]

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

Ну ладно. Но атомарность записи блоков данных во FRAM к примеру обеспечиваете?

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

[Hold 0]

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

[jcxz 192]

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

Атомарность != совместный доступ.

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

 

может быть, но пока с таким не сталкивался. В любом случае при старте память проверяется.

Т.е. - новые данные у Вас пишутся поверх старых и никакой защиты от внезапного прерывания записи и перезапуска устройства у вас нет?

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

В моих устройствах, где нужно ответственное хранение, я обеспечиваю атомарность модификации объектов (во FRAM/FLASH).

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

Если её корректно решите - больше никакие дублирования и троирования данных не нужны будут.

[mantech 37]

Т.е. - новые данные у Вас пишутся поверх старых и никакой защиты от внезапного прерывания записи и перезапуска устройства у вас нет?

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

 

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

[uriy 5]

На STM32F407 сделал mass storage in ram. Выделил 64 КБайта. Мне нужно с компа писать файл на этот раздел и его использовать в микроконтроллере. Для чтения файла использую fatfs.

RAM не инициализирую поэтому после каждого включения винда просит отформатировать раздел.

Под Win10 все работает как надо. Форматирую раздел, записываю файл с нужным мне именем, читаю.

Под Win8 не хочет, говорит что файла не существует.

Для отладки добавил вывод содержимого раздела как здесь http://elm-chan.org/fsw/ff/doc/readdir.html

Под win10 все отлично, показывает имена папок и файлов которые я создаю на разделе.

Под win8 не видит ни файлов ни папок созданных на разделе. Файлы туда пишутся, в дебаггере вижу что в этих 64 КБ памяти появляется и имя файла и содержимое.

Что с этим делать?

 

[Hold 0]

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

Дублирование только одно - ежедневная копия fram во flash. Никаких других нет. Буду рад конструктивным советам. От внезапного прерывания по питанию спасает ионистор.