[haker_fox 60]

Добрый день, коллеги! В приборе, которому могут неожиданно отключить питание, необходимо сохранять логи (файлы длиной 50 - 150 кб). Допускается потеря лога в момент отключения питания (либо другого сбоя), но не разрушение ФС вместе с остальными данными. Прибор сделан на базе Cortex-M4F. Используем FreeRTOS. Из журналируемых "свободных" решений нашёл только uc/FS. Может быть есть какие-либо ещё доступные ФС с такими возможностями, пригодными для применения в embedded? В целом, не требуется совместимости с FAT, хотя и желательно.

Посоветуйте, пожалуйста, что-нибудь! Очень заранее благодарен!)))

[HardEgor 62]

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

[jcxz 184]

5 часов назад, haker_fox сказал:

Посоветуйте, пожалуйста, что-нибудь! Очень заранее благодарен!)))

Зачем вообще какая-то ФС? Пишите в кольцо. Тогда не будет потери и в момент выкл. питания. Тем более с вашей то областью применения, потери при выкл. питания имхо - недопустимы.

[Vasily_ 41]

Самая надежная ФС, это её отсутствие.

[Wese 0]

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

https://github.com/ARMmbed/littlefs

https://os.mbed.com/blog/entry/littlefs-high-integrity-embedded-fs/

[haker_fox 60]

49 minutes ago, jcxz said:

Зачем вообще какая-то ФС? Пишите в кольцо. Тогда не будет потери и в момент выкл. питания. Тем более с вашей то областью применения, потери при выкл. питания имхо - недопустимы.

Ну всё-таки в момент выключения питания потеряется минимум одна страница флеши.

 

34 minutes ago, Wese said:

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

https://github.com/ARMmbed/littlefs

https://os.mbed.com/blog/entry/littlefs-high-integrity-embedded-fs/

Спасибо, изучу её. На всякий случай вопросы: она поддерживает несколько разделов? Совместима с FAT (полностью)? Есть ли какие ограничения, прямо не указанные на сайте?

[jcxz 184]

1 минуту назад, haker_fox сказал:

Ну всё-таки в момент выключения питания потеряется минимум одна страница флеши.

Почему? Нет конечно.

[haker_fox 60]

26 minutes ago, jcxz said:

Почему? Нет конечно.

Простите, но я тогда не понимаю, как писать по кольцу? Допустим, я накапливаю на флешке файлы лога, длина которых варьируется от 50 до 150 кБ. Логов допустимо хранить 20, затем они переписываются, начиная со старшего. Т.е. сами логи пишутся в большом кольце, а внутри логи писать тоже по кольцу? Но как? Я понимаю, могу задавать тривиальные вопросы, но мне действительно не очень понятно. Буду премного благодарен, если "разъжуёте"))))

И можно ли при таком подходе писать файлы вперемешку, как на "настоящей" ФС? Например, файл лога + текстовый файл и т.п.

[artemkad 51]

12 minutes ago, haker_fox said:

Простите, но я тогда не понимаю, как писать по кольцу? Допустим, я накапливаю на флешке файлы лога, длина которых варьируется от 50 до 150 кБ. Логов допустимо хранить 20, затем они переписываются, начиная со старшего. Т.е. сами логи пишутся в большом кольце, а внутри логи писать тоже по кольцу? Но как? Я понимаю, могу задавать тривиальные вопросы, но мне действительно не очень понятно. Буду премного благодарен, если "разъжуёте"))))

И можно ли при таком подходе писать файлы вперемешку, как на "настоящей" ФС? Например, файл лога + текстовый файл и т.п.

Пишешь всё записями фиксированной длинны в каждой из которых есть уникальный непрерывно растущий идентификатор(время), контрольная сумма и идентификатор к какому логу эта запись относится. Перед записью всего лишь надо найти самую старшую/младшую/пустую запись по полю идентификатора(времени)

[jcxz 184]

42 минуты назад, haker_fox сказал:

И можно ли при таком подходе писать файлы вперемешку, как на "настоящей" ФС? Например, файл лога + текстовый файл и т.п.

Я же говорю: без ФС. Какие файлы?? Создаёте кольцевой буфер из N1 элементов - секторов стирания флешь. Каждый сектор состоит из N2 страниц записи флешь. Каждая страница - из N3 записей. Одна запись - это одно событие лога (одна запись лога). Запись имеет фиксированный размер (можно и переменный, но сложнее и вряд-ли нужно). Дальше работаете с этим кольцом как с обычным кольцевым буфером. Поддерживая перед головой кольца (позицией записи) стёртыми не менее одной страницы (если например нужно дописать запись, а размер стёртой дырки после этого станет меньше одной страницы, то сначала стирается ещё один сектор, и только потом пишется страница).

При старте ПО надо:

1) сперва найти положение дырки (она всегда есть и она >= размеру одной страницы);

2) от границ этой дырки дальше находим положение головы кольца и количество записей в нём (тестируя все записи), в процессе - метим все сбойные записи как "плохие";

3) создать в ОЗУ все необходимые переменные описывающие положение в кольце (позиция записи, кол-во записей и пр.);

4) можно начинать писать новые записи в кольцо.

Для ускорения первого пункта можно увеличить минимальный размер стёртой дырки до 1-го или даже нескольких секторов стирания (если доступный объём флешь позволяет). Тогда искать дырку можно с шагом по кольцу == размеру дырки.

Продумать формат записи так, чтобы она имела заголовок + тело. По заголовку должно быть возможным определить состояние записи, одно из: 1) запись стёрта (запись внутри дырки стирания); 2) запись заполнена данными, валидна; 3) запись "плохая" (при тестировании после старта обнаружено повреждение записи (CRC и т.п.) например в результате выключения питания в процессе записи во флешь этой записи).

Очевидно, что если например исходное (стёртое) состояние ячеек флешь Вашего чипа флешь == 0xFF, то для первого состояния лучше принять значение флага: ==0xFF, для последнего == 0x00, а для 2-го - любое другое. Тогда можно превращать невалидные записи в "плохие" простой операцией записи страницы "поверх", без стирания.

 

Если нужно несколько разных логов для разных типов событий - нужно создать несколько таких колец (назовём их "журналы"). Каждое будет занимать целое число секторов стирания. В наших устройствах (счётчиков и других для подстанций) количество таких журналов доходило до нескольких десятков. Все были устойчивы к сбоям питания. В некоторых случаях юзеры так монтировали счётчик, что там питание дёргалось чуть не каждую секунду. И так по месяцу. И ни одного журнала не было потеряно. Хотя все они пишутся там непрерывно при работе ПО.

[iliusmaster 5]

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

[jcxz 184]

10 минут назад, iliusmaster сказал:

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

Ну да - прилетает первая помеха, и девайс штатно перегружается (не из-за монитора питания). И все логи - коту под хвост. Проходили это. Как раз и начинали с такого решения. Потом отказались, именно из-за таких событий.

Попробуйте как-нить ваше решение поставить на реальную подстанцию, где всё непрерывно клацает и переключается, а по соседним коммутируемым проводам гуляют неслабые токи.

Кроме того - что будет с вашим ионистором в диапазоне -40...+70 (который норма для подстанции)? и через несколько лет?

 

[iliusmaster 5]

Это решение работало на электрической пилораме с двигателями под 40 кВт, и в моменты, когда  в бревне пила напарывалась на осколок, пильная лента(спецсплав шириной 150мм и толщиной в 1.2мм) рвалась. В момент заклинивания полотна , когда спецсплав сильно сопротивлялся разрыву, мотор резко стопорился, и мы получали 100-150 квт энергии в широком спектре, излучаемыми длиннющими проводами - антеннами.

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

 Так вот сам по себе контроллер не может перезагрузиться, что-то происходит по его входам - выходам и чаще всего это питание, по - крайней мере у нас так было. Удержать нулевой потенциал земли контроллера в момент 100 квт радиоимпульса не удавалось никакими доступными фильтрами. Но момент этот прекрасно регистрировался супервизором.

Покупайте промышленные ионисторы, рассчитанные на режим работы -40 - +70. Panasonic для некоторых серий 10 000 часов гарантирует при +65.

Дополнительно посоветую: для таких условий не плохо бы уже применять коробочки для электроники с контролем температуры и подогревом- охлаждением. Это как-бы промышленный стандарт пультов управления. Системы охлаждения и обогрева вполне себе штатно проектируются.

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

[jcxz 184]

21 минуту назад, iliusmaster сказал:

 Так вот сам по себе контроллер не может перезагрузиться, что-то происходит по его входам - выходам и чаще всего это питание, по - крайней мере у нас так было. Удержать нулевой потенциал земли контроллера в момент 100 квт радиоимпульса не удавалось никакими доступными фильтрами. Но момент этот прекрасно регистрировался супервизором.

И толку что регистрировался? Ведь МК в этот момент зависал или перегружался. А для вашей системы он должен продолжать функционировать. Т.е. - класс помехоустойчивости А. А для моего варианта достаточно класса Б.

Цитата

Покупайте промышленные ионисторы, рассчитанные на режим работы -40 - +70. Panasonic для некоторых серий 10 000 часов гарантирует при +65.

Дополнительно посоветую: для таких условий не плохо бы уже применять коробочки для электроники с контролем температуры и подогревом- охлаждением. Это как-бы промышленный стандарт пультов управления. Системы охлаждения и обогрева вполне себе штатно проектируются.

Ну да - ещё и печку-холодильник в комплект  

Мой вариант обходится без всего этого, т.е. - значительно дешевле по комплектации. Да и надёжнее. Потому что функционирования по классу А ещё добиться нужно. А это сложно и это тоже деньги.

А ещё нужно умудриться написать прошивку абсолютно без багов. Чтобы не нужен был WDT (чтобы не было перезагрузок по нему). Кто тут умеет писать гарантированно безбажные прошивки? Есть такие?  

[iosifk 3]

2 часа назад, haker_fox сказал:

Ну всё-таки в момент выключения питания потеряется минимум одна страница флеши

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

Так что во фрам можно сохранить не только логи, но и текущее состояние. Чтобы потом, после горячего сброса стартовать не с "исходного", а с "текущего"...