Господа, нет ли у кого SDK от TrueFFS или каких-то соображений как правильно делать блочное устройство на NAND Flash, чтобы равномерно использовать ресурс NAND и можно было реализовать на микроконтроллере с небольшим объемом RAM.

Посмотрите в сторону YAFFS2 (http://www.yaffs.net/), как раз разрабатывалась для NAND с учетом использования ресурса, если только удовлетворит требованиям по RAM. Там так же есть вариант интерфейса Direct позволяющий использовать эту ФС без ОС.

Вот еще ФС http://logfs.org/. Еще менее требовательна к RAM. Правда не уверен что она работает без ОС.
И еще одна легковесная ФС http://sourceforge.net/projects/uffs/. Работает без ОС.

Сами то пробовали?

Там просто мусор лежит.
Точнее нечто невменяемое и абсолютно без всяких драйверов.

Спасибо за наводки, это все сказочно, но у людей другое представление о компактности. Немного - говорят, 200К RAM на 4Г NAND'а. Мне бы меньше 8К на тот же объем.

А какой размер сегмента у 4 ГБ NAND-a?

Точнее, размер сектора.

Цитата с http://sourceforge.net/projects/uffs/ :

Так что, памяти требует на 2 порядка больше...

Сектор - 4К, стираемый блок - 64 сектора.

Если нужна эмуляция FAT или POSIX API подобных систем на NAND, то без огромной RAM не обойтись.

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

Например как Serial Flash File System из этого проекта http://aly.ogmis.lt/OpenProjects/ADP_LPC2148/ADP_LPC.htm

Нужна будет только модификация процедуры поиска свободного блока. Свободные блоки должны будут выбираться только по направлению вперед, и wear-leveling получится тогда автоматически.
Причем совершенно не будет волновать проблема статических файлов.

FAT или что-то другое - дело десятое, проблема в том, что нужно блочное устройство. Т.е. при линейной адресации сверху к набору блоков был ремапинг на структуру NAND со сменой блоков, чтобы не допускать записи в один и тот же много раз.

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

Чаще всего софт полагается по файловые системы типа FAT, где можно одновременно открыть много файлов, есть понятия директорий, путей и операций над ними и т.д.

И это критично, поэтому примитивные сиcтемы могут и не подходить

Но если приложение пишется для какого-нибудь PIC-а или ATмеги то вполне можно положить и на "блочность" устройства и на API и юзать линейную журнальную FS.
Как уже сказал в такого типа FS wear-leveling получается почти автоматом.

Alex11, что писать-то собираетесь?
И ещё, скорость работы при таком напряге с рамой видимо значения особо не имеет?

To AlexandrY: Если бы все ограничивалось только одним моим устройством, то проблем бы не было с любой файловой системой. Блочное - в том смысле, что приходящая сверху команда - это прочитать столько-то данных начиная с блока номер такой-то или записать такие-то данные начиная с блока номер такой-то. Т.е. собственно файловая система не так интересна. Сверху на все это должен быть натянут FAT, но это уже не большая проблема.
To GetSmart: Скорость, как всегда, тоже имеет значение. Вообще, будет некий регистратор, который пишет файлы на встроенный NAND, а затем подключается к PC и изображает из себя massstorage device с возможностью читать и удалять выборочно файлы. Можно, конечно, сделать PTP - там будет все сильно легче, но микрософт грозится снять его с поддержки. Очень не хочется через пару лет под очередные виндюки переписывать все по новой. Проц будет ARM7, но рама там 64К всего, а еще надо на дело оставить.

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

Это правильный ответ, но я же не все свои проблемы сюда выкатываю - там еще зажатые до нуля габариты и почти нет питания. SD жрет больше, чем весь девайс. Да и не влезает. Вот я пытаюсь понять, что сделано внутри SD или CF карточки. Там проц стоит не с сотнями килобайт, а некая деталь на базе 51 контроллера, довольно дохленькая, и справляется.