Доброго дня, коллеги. А есть ли на свете какая-нибудь легковесная ФС для нанд, если ОЗУ доступно только 100к?

Мда... В свое время в настольном компьютере было ОЗУ всего 56 килобайт, и файловые системы на нем работали, и это считалось немало. Теперь 100К уже мало....

А вообще, emFile, наверное, одна из самых малоресурсных.

100к думаю всем хватит.
Берите любую.

А подойдёт ли любая для памяти NAND?
Нужно ведь ремаппинг страниц делать для предотвращения износа.
extFAT нужен, ведь правда?

Учёт сбойных блоков обязателен. Самсунг обещает отсутствие ошибок только в нулевом блоке и только в течении первой 1000 стираний.

А SD карта не подходит?? Если это МК с внешней памятью для загрузки программ, то как правило имеется вариант загрузки с SD карты, и не надо учитывать сбойные блоки и всякие экзотические ФС, достаточно обычнной fatfs/

Срочно исправляем название темы на "NAND и большой объем RAM"

Я свои вопросы ТСу задавал, в качестве наводящих.
SD карта, конечно, сама перемешивает блоки и ремапит, пока есть резерв, сбойные.
Однако, самоновейшие SD уже перекладывают эти задачи на файловую систему и
тут или extFAT, на которую описание закрыто, или самодел.
Других решений я пока не видел.

Вот это новость!
В новых SD картах можно отключить wear leveling?

С одной стороны неплохо, но с другой стороны при 4-х битном интерфейсе это будет натужно для файловой системы.

А jffs[2], yaffs[2], ubifs (там правда этим командует ubi-прослойка), LogFS? А тот же FAT, обернутый в emFile (в нем wear leveling имеется для NAND/NOR)? Зачем упираться в микрософтовскую закрытую бодягу?


Ну это то обычно скрыто внутри железа контроллера. Для файловой системы - просто передача блока данных в DMA и все, и без разницы, сколько там проводов, хоть SATA, там всего один бит, хоть SD, где 4.

Мне в продаже встретились, если не ошибаюсь, SDXC, на упаковке которых
русским по белому было написано, что переформатирование в FATотменяет
гарантию, только extFAT.
Я так понял - wear leveling там сразу отменён.




Уважаемый SM, можно ссылок на эти вещи?
Мне будет актуально, для NAND.

Все первые - скачайте linux kernel - они все там живут скопом, абсолютно открытые, и вполне понятные, благодаря очень удачному соглашению по форматированию исходников, принятых у линуксоидов. Кстати, они же присутствуют и в u-boot, это я к тому, что выдираются довольно легко. emFile - это у SEGGER на сайте (платная, возможно, где-то уже есть и стыренная).

Дополню вопрос - что бы Вы посоветовали из этих ФС, если требуется
работа без ОС. То есть собственная реализация.

Посоветовал бы, наверное, jffs2 или yaffs2 ( http://www.yaffs.net ), хотя, конечно, вопрос в ресурсах. А вообще любая из них без ОС работает - я Вам пример привел - u-boot - это загрузчик ОС, и в нем все они есть.
Но, если есть жесткое ограничение на RAM, то emFile (с FAT, не EFS)

Как вы думаете применять эти ФС без ОС если не знаете ничего об их времени исполнения.
Вот зависнет jffs2 на десятки секунд в какой-нибудь своей функции и что ваше все остальное ПО будет делать?

Или всю свою логику переведете в процедуры вызываемые по прерываниям?



Нет там их. Одни названия, либо фрагменты только что-то читающие.
Увы, не все так просто.

Так и надо делать. Всегда, когда без ОС. По дефолту.

Вот не надо, ydevconfig + ymount + ywrm отлично работают с yaffs2 в u-boot
А с LogFS, понятно, еще просто не успели.

Правильно. Только Yaffs2!
А все остальное назвали просто чтобы показаться умнее, не так ли?
Мы ж здесь не первый год.

Да-да. А "ubifssave" по аналогии с "ubifsload" добавить - сутки работы (естественно, если смотришь на код ю-бута не как баран на новые ворота). Экая мегасложность. Вот именно, что не первый день мы тут.

Понимаете, у меня есть вредный бзик.
Я крайне редко использую сторонние библиотеки,
особенно если не понимаю, как она работает.
И не пользую ОС для контроллеров, не сталкивался пока с необходимостью.
Поэтому меня интересуют приципы работы, а ФС и сам напишу.
Не впервой

Этот ю-бут уже считай мертвец.
Щас Freescale сделает че-нить на Cortex-M7 и приделаем мы туда универсальный лодер на базе MQX с любых коммуникационных каналов.



Нет, не понимаю.
Такого не может быть в природе.
Люди которые поняли как работает Yaffs2 и портировали ее ну никак не могут не использовать ОС.
Потому что ОС это реальная экономия времени.

Ну а мы научили грузить линукс напрямую x-loader (думая только о скорости старта устройства в целом, на Cortex-A8), так что у каждого свой путь убить юбут. Но это не значит, что он совсем мертвец. Он бывает еще нужен... В том числе, и как пример работы с файловыми системами без ОС.


Зато, разбазаривание ресурсов. Так что вопрос крайне спорный. Где надо сэкономить неделю разработки - да, ОС очень пригодится. А где надо сэкономить последние 10 центов стоимости ресурсов - ОС категорически вредна. Так что, не надо все подводить под одну гребенку. Каждому решению свое место. Причем, очень много решений, где, сначала, в убыток себе, но быстро, делается решение на базе ОС, а затем, за три-четыре месяца, делается уже массовое решение без ОС, которое окупает и расходы на первое, быстрое и расточительное решение, и приносит прибыль.

PS.
Давайте к теме ближе, а не к личным предпочтениям о вкусе и цвете.

PPS.
Я сам отношусь к поклонникам решений без излишеств, навроде ОС и прочих внешних либ, и аккуратной экономии ресурсов - применения наиболее дешовой комплектации и минимизации цены BOM. Но вполне себе понимаю, что бывают случаи, когда надо наплевать на цену, и сделать быстро. И вот тогда...

От вас ли я слышу сделать быстро не жалея ресурсов?
кстати что такое ВОМ?

Мне операционка мешает четко контролировать времянку работы. И за ней прячутся разгельдяйские баги.

А че тема? С темой все ясно.
Все wear leveling движки используют динамическое выделение памяти.
Эти механизмы выделения всегда требуют портирования.
Я бы даже может заплатил тому, кто точно скажет слолько же памяти в пике может забрать тот или иной движок.
Так что только ось и помогает в этой неопределенности с ее сервисами постановки выделения памяти в очередь и контроля за пулами памяти.

Потому и говорю уверенно, кто хочет использовать FS под NAND тот точно подсядет на RTOS.

Да и самые доступные движки под NAND это FTL в составе RTOS vxWorks (в хранилище кстати лежит) и FFS в составе RTOS MQX (бесплатно).

Про FFS была недавно тут тема, мы ее тестировали. Показала очень детерминированные тайминги.
Не в сравнение с SD картами где тайминги одних и тех же операций могут отличаться на порядок в зависимости от фазы луны.

Что же касается RTOS, то я вижу их основное достоинство в возможности реюзинга.
Можно взять какую угодно тормозную и монструозную библиотеку и заставить ее работать на своей платформе не нарушая таймингов остальных процессов.
Мне просто интересно, ну что такого можно сэкономить отказавшись от RTOS, а заодно и от кучи софта который вам просто в лёт может обеспечить дополнительную добавочную стоимость.

Да вот один из примеров приведу. Делали когда-то один девайс по некоей специфической обработке речи. Первую версию сваяли на плавучем TMS под управлением DSP/BIOS, чтобы просто успеть в срок - модель из матлаба за день переложили на систему на TMS320C6713. Получили с первой партии некие убытки, так как дорогая это платформа, не укладывающаяся в бюджет. Зато сделали именно мы, а не соседи. Затем, пока заказчику хватило первой сотни девайсов, переработали на дешовый TMS320VC5501, в который уже не умещается RTOS, уместив туда на голом ассемблере все тоже самое, но без ОС, и без ухудшения потребительских свойств. В результате на следующих партиях окупили и расходы на первую, убыточную, и получили прибыль. И никакой левый софт там не может обеспечить добавочную стоимость, так как стоимость прописана в контракте, как и требуемая функциональность.
Еще сколько хотите примеров в крупносерийке, где поставить процессор на 10 центов дешевле принесет либо прибыль в $100K, либо конкурентное преимущество в цене. Зато в этот процессор ОС уже не влезет, а функциональность всего необходимого он обеспечит, на грани своих ресурсов с совсем малым запасом.

А сделать свой менеджер памяти для работы FS - это копейки и по времени и по работе. Как и исследовать пиковые объемы в условиях теоретических максимумов для конкретной задачи, которую решает конкретный девайс, где четко известно заранее, сколько может быть открыто файлов, как они читаются/пишутся, и т.д.


Bill Of Materials - список компонентов

Странный пример.
На TMS320VC5501 RTOS помещается, да еще и не слабая.

А не поставили вы ее туда, потому что TI на халяву не предлагал тогда, а купить денег не было.
Но поэтому функциональность вашего дивайса стала урезанной. И вы потеряли кокое-то количество денег из-за потери некоторых потребительских сегментов.
Вот так мне эта история видится.



Может с конкретными задачами и конкретными дивайсами это и так.
Но на конкретных задачах далеко не уедешь.
Рынок требует решения непредсказуемых задач.

Во первых, да, RTOS влезает, но тогда не влезает функциональность. А если влезает функциональность - причем, даже написанная на С не влезает, а только на ассемблере, и с трудом, то RTOS никак не влезает.
Во вторых, у нас DSP/BIOS была в полном объеме для всех нужных семейств (я же, заметьте, написал прямо - первая версия, убыточная, была сделана на ней).
В третьих, функциональность была полная и соответствующая заказу. Других же потребительских сегментов изделие не имеет, если его начать продавать "на сторону", то незамедлительно можно уехать в длительную командировку в места, не столь отдаленные.

Так что, очень советую пройти курсы телепатии, у Вас с ней явные проблемы, ни разу не угадали ничего вообще.


UPD
Вдогонку, добавлю. Да, RTOS уже внатяг влезала в TMS320VC5502, но это +$2 к себестоимости, что при общей себестоимости девайса в $10-12 совершенно недопустимо, лишь ради того, чтобы ради непонятных понтов применить RTOS.



Не согласен. Я, например, работаю в основном на конкретных задачах, и наибольшее время из всей работы занимает именно минимизация себестоимости изделия - оптимизация схемы и минимизация занятых программой ресурсов. Вплоть до разработки ASIC под задачу уже с минимизацией его площади (а это уже не две-три добавочные недели на софт без ОС, а полгода минимум), чтобы уменьшить цену. Да, есть и исключения, когда надо "сделать быстро и пофигу сколько оно стоит", но это, скорее, исключение, среди реальных случаев, с которыми я сталкивался. Основная же работа, как правило, сводится к "впихнуть невпихуемое".

PS
Зачем тут этот бессмысленный спор? Я также знаю немало успешных проектов, где вполне допустимо практически без потерь в прибыли добавить лишних ресурсов и упростить себе жизнь с использованием левых библиотек и ОС. Но это не отменяет и другой доли проектов, где это сделать нельзя. Поэтому я отлично понимаю желание автора запустить FS в NAND без ОС, тем более, сам когда-то это делал, правда не в NAND, а в датафлешах, изобретая свою простую FS, удовлетворяющую задаче, с информацией о файлах только в OOB, и реализуя все это полностью на ассемблере, чтобы оно хоть как-то влезло в имеющийся ресурс.

Вот только не смешите и не называйте DSP/BIOS тех лет RTOS.
Надо так понимать что с RTOS у вас тогда вообще опыта не было.



Да ну!
Приблизительно в те же годы мы поднимали платформу GSM модема.
Его вся себестоимость была в тех же 12$.
На RTOS-ах никто не экономил.

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


DSP/BIOS тех лет была вполне себе продвинутая для тех лет RTOS, из того выбора, что вообще можно было запустить на TMS320C55xx. Видимо, Вы с ней тогда дела не имели.

Естественно не имел. Подбирать и иметь дело со всем мусором который выложен с сети не хватит никакой жизни.
Достаточно было ознакомится с предлагаемымии DSP/BIOS сервисами и все стало ясно.

Но может я что то упустил и в DSP/BIOS есть уникальные файловые системы особенно для NAND?

Мой подход такой: сначала выбрать софт, а потом железо.
Общеизвестно, что софт в разработке самый трудоемкий процесс и ему естественно отдавать приоритет если живете за счет разработок.

Аргументы вроде того, что вот сижу и схемотехнически тут минимизирую BOM за счет отказа от сотни другой килобайт памяти тоже меня не убеждают.
Если бы так переживали за BOM то в первую очередь следили бы за курсом валют и логистикой.
Одно суточное плавание соотношения курсов и запасов в стоках меняет мои BOM на десятки процентов.
Это явление на порядок сильнее всех потуг экономить BOM за счет пары компонентов.

А кто-то говорит о том, что об этом не переживаем и за этим не следим? Опять неудачный сеанс телепатии? Одно другому не мешает. Если заложить лишние деньги изначально, то никакая логистика потом не спасет.

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

Не так давно была у меня мечта, не выделять отдельное место в nand-е под ядро и его резервную копию, сложить всё в один ubifs. Загуглил поддержу ubifs в u-boot (в доке об этом ни слова). И оно сработало, u-boot достал ядро из указаного места, смог его запустить.
Но радость была недолгой, когда u-boot достаёт ядро из ubifs он её безнадёжно портит. Поудивлялся немного, вокруг исходников поплясал и удалил u-boot совсем.
Может в более новых версиях он починен, но я пока останусь на простом bootstrap загрузчике.