[haker_fox 60]

9 hours ago, miheyk said:

Yaffs

Спасибо большое! Но, понимаете, мы используем FreeRTOS и IAR, так что вряд ли получиться прикрутить эту ФСку...

[miheyk 0]

Не все так плохо, без линукса, но на фриртос ) Хотя эта FS заточена прежде всего под NAND, с NOR таких проблем нет. Вот тут, как и советовали ранее, как раз описано преимущество LittleFS на случай сбойного питания.

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

Про безбажные ПЛК порадовали

[haker_fox 60]

6 hours ago, miheyk said:

Про безбажные ПЛК порадовали

Ну я только про одного производителя слышал, который делает такие... и имя ему "Овен"))))))))))

[AlexandrY 2]

6 hours ago, miheyk said:

Не все так плохо, без линукса, но на фриртос ) Хотя эта FS заточена прежде всего под NAND, с NOR таких проблем нет. Вот тут, как и советовали ранее, как раз описано преимущество LittleFS на случай сбойного питания.

Такой дешевой писанины полный интернет.
Лучше найдите серьезные проекты с результатами тестов на производительность и ресурсы.  

Я склоняюсь к мысли, что FAT подобные системы более производительны чем линейные типа LittleFS в случае SPI NOR, поскольку требуют меньше циклов чтения. 
Поэтому да, файловая от Micrium c FTL хороший выбор.
Еще в закромах есть  очень надежная TFFS от  VxWorks.
Ну и можете конечно взять более легально FAT систему из MQX с FTL, правда не знаю во что обойдется портирование на FreeRTOS, но за то там все под IAR.   

[miheyk 0]

За деньги можно вообще ничего не делать, только плати. Ту же uOS со стеком ФС пилят и продают все, кому не лень

[AlexandrY 2]

1 hour ago, miheyk said:

За деньги можно вообще ничего не делать, только плати. Ту же uOS со стеком ФС пилят и продают все, кому не лень

Эт вот это что ли - https://github.com/sergev/uos-embedded
Забавная поделка. Мужик понасибирал всех открытых проектов в кучу. И слепил какой-то довольно убогий шедулер для всего этого.
Благо большинство затащеных в проект опенсорсов никак не привязаны  к  RTOS. 

Обратите внимание что в его FS нет уровня FTL. А это значит для NOR и NAND она не подходит. 
И деньги тут не при чем.
Если бы вы были здесь свой, то знали бы контекст.     

[haker_fox 60]

9 hours ago, miheyk said:

За деньги можно вообще ничего не делать

Ну, кстати, практика показывает, иногда если много эпотажа и самоуверенности, то тоже не очень стабильно получается. Обычно недоделка, ибо успеть отладить всё на 90% нет сил, времени и знаний. Поэтому, чтобы сосредоточиться на основной разработке, может быть имеет смысл и заплатить. Хотя, есть уникумы, которые и ФС, и коммуникационные протоколы, и оси могут пилить. Себя к ним не отношу, поэтому с радостью воспользуюсь чужим опытом истинных профессионалов.

[miheyk 0]

Некорректно написал название - µC/OS. 

Не понял про свой, ну да ладно) 

[AlexandrY 2]

1 hour ago, miheyk said:

Некорректно написал название - µC/OS. 

Хм, а жаль.  uOS стоило бы еще пообсуждать. 

Нашел тут у себя случайно в старых записях такую ссылку - https://sites.google.com/site/gouffs/
В ней честно пишут сколько нужно RAM-а. И даже у них цифры получаются немалые. Для сравнения FAT может обойтись двумя килобайтами. 
YAFFS вообще монстр по пожиранию памяти, там даже посчитать трудно, поскольку все выделяется через malloc. 
littlefs не имеет исправления ошибок, т.е. очевидно не так надежна как хочет себя представить. 

 

[miheyk 0]

Увы, но надежность и размер буфера в ОЗУ противоречат друг друга. Любой журнал, любая таблица перемещений, будь то борьба с бэдблоками или неравномерным износом флеши требуют громадных затрат по ОЗУ. Пример - файловая система от Segger потребляет ~50 КБ для флеша в 64 МБ и тоже через malloc.

[esaulenka 5]

2 hours ago, AlexandrY said:

Для сравнения FAT может обойтись двумя килобайтами. 

Тёплое с мягким сравнивать - не очень большой смысл. Это разные FS, и применяться должны в разных условиях. Сколько памяти будет потреблять FAT + FTL ?

 

И про фразу "littlefs не имеет исправления ошибок" хотелось бы подробности услышать. Не обрабатывает ecc ? А что, это ФС должна делать, не драйвер?

[AlexandrY 2]

27 minutes ago, esaulenka said:

Тёплое с мягким сравнивать - не очень большой смысл. Это разные FS, и применяться должны в разных условиях. Сколько памяти будет потреблять FAT + FTL ?

 

И про фразу "littlefs не имеет исправления ошибок" хотелось бы подробности услышать. Не обрабатывает ecc ? А что, это ФС должна делать, не драйвер?

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

[esaulenka 5]

Словоблудие - вся эта тема, к сожалению.

Потому что hacker_fox только ближе к середине сказал, что у него не NAND, не FRAM и не SD, а NOR. Возможность записывать что угодно и куда угодно (только 1->0, разумеется), довольно мелкий размер стираемого сектора, гарантия от производителя, что данные не побьются - с одной стороны (в сравнении с NAND).

Необходимость делать-таки FTL (или заметно урезать функционал) - с другой стороны (в сравнении с SD).

Какие тут цифры могут быть, я не очень понимаю. Сначала определяемся с хотелками, потом начинаем сравнивать (с цифрами, да) хоть сколько-то похожие предметы.

 

Единого списка "что должна делать ФС" тоже не существует. Читать должна. Возможно, писать. Возможно, форматировать под себя диск. Возможно, обеспечивать какие-то средства отказоустойчивости.

Непосредственно процедурами обмена с носителем должен заниматься драйвер. Управлять динамической памятью должна ОС (если ФС нужна такая память). Кофе должна варить кофеварка.

 

Но что-то я сомневаюсь, что выше написано хоть что-то новое. Опять словоблудие...

[AlexandrY 2]

20 minutes ago, esaulenka said:

Но что-то я сомневаюсь, что выше написано хоть что-то новое. Опять словоблудие...

Для логов важнее всего скорость записи. Если записи будут пропускаться, то не нужны и такие логи. 
А скорость может сильно зависеть от количества уже записанных файлов и фрагментированности файловой системы.
Нужно знать скорость открытия и закрытия файлов, удаления и создания.
Также важный параметр количество одновременно открытых файлов и изолированность файловых дескрипторов в разных задачах, т.е. адаптированность FS к RTOS.
Поскольку общий модуль FS для всех задач вызовет взаимное влияние задач друг на друга и приведет к нарушению реального времени. 
Вот такие вопросы над прояснять при обсуждении FS. 

Я против FS (т.е. я их рефакторю) которые предлагают себя на разные носители не обращая внимание на особенности интерфейсов.  Мы ж не линукс обсуждаем.
Т.е. то что называют драйверами, а в реальности несколько функций с унифицированным интерфейсом  - это лишний навесок в целом вызывающий дополнительные тормоза.  ECC должен обрабатываться на уровне файловой системы как это делается в YAFFS2.  

 

  
 

[jcxz 184]

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

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

Так можно хорошо залететь. Воспользовались чем то чужим и сложным. А через некоторое время там проявится баг. Будете сами потом в этом лесу разбираться? А чем ПО сложнее - тем больше вероятность количество багов в нём.

Лучше не усложнять своё ПО без необходимости. А чужим пользоваться вообще - очень осторожно. Разве что от проверенных производителей.  

1 час назад, AlexandrY сказал:

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

Скорость больше будет зависеть от объёма отданного под кеш места в ОЗУ МК.