Господа, нет ли у кого 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 контроллера, довольно дохленькая, и справляется.

А самому внимательно посмотреть лень?
- ФС активно используется уже 3 года без нареканий в 4-х видах изделий, релизы конца 2006 г. вполне работоспособны и надежны (у меня работает под АРМом).
- Там не мусор лежит, а полный комплект нормальных исходников с тестовыми примерами, в т.ч. и в режиме эмуляции флеша, с небольшими изменениями за 1-3 часа запускается под MSVS - для отладки/изучения.
- Примеры написания драйверов есть, тем более если без ОС или под ОС типа uCOS достаточно написать пару примитивных аппаратно-зависимых подпрограмм записи сектора/чтения сектора/стирание блока флеш-памяти и вперед .

1. Она справляется с частью необходимой Вам работы
2. Там, где объемы Flash гигабайтами измеряются, там и RAM не килобайтами измеряется.
3. 51 на 4x проводнои 25Mhz SD интерфейсе явно ловить нечего - нету там его. Специализированные "железные" контроллеры там
4. Габаритных размеров у SD аж три варианта. Самый маленький ну очень маленький

Насколько смотрел контроллеры FLASH USB накопителей, там действительно стоят дохлые чипы типа 51-го мегагерц на 20-ть.
Но никто и не говорил что на этих чипах хороший wear leveling.
Дисков на них не сделаешь и никто не позиционирует их как диски.
Я уже пару штук выкинул. Перестали писаться когда пытался использовать для очень частой перезаписи файлов.
С другой строны в профиле USB Mass Storage используется SCSI transparent command set, т.е. от USB флеши требуется только тупо по DMA отдавать блоки из NAND в PC, а трансляция адресов физических в логические делается уже драйвером на PC, соответственно и здоровая таблица мапинга может находится на PC.
Эффективный wear leveling должен базироваться на верхнеуровневых связях с FAT как это говорится в мануале на TrueFFS, значит тупой USB FLASH не может содержать в себе TrueFFS.
Ну и как вариант для пытливых умов рекомендую посмотреть как сделан драйвер SMC (он же для NAND) в файловой системе от Micrium-а.
Wear leveling там зачаточный но тем не менее с десяток килобайт для мапинга все равно требует.

Речь идет о современных SD/MicroSD гигабайтовых размеров, а не о USB брелках "на 128Mb" абы как работающих или больших, но требующих от PC поддержки блоков десятки-сотни килобайт. Для USB, как минимум проблема RAM снимается PC.

Можно ли в подробностях изучить реализацию FS в микроС/FS триальной версии? Есть у кого-нибудь в распоряжнии микроС/FS не триал-версии?

Попробуйте поизучать...

Какая это версия? Это нужно для изучения соответствующего описания. Судя по иронии, за этим кроется какая-то засада?

Сильно не рекомендую связываться с NAND FLASH chip - кроме чисто технических проблем(wear-leveling, error-correction), есть и другие - производители часто меняют номенклатуру и, что важнее, критические параметры(мах число стираний, например) причем в сторону ухудшения(!) Особенно
этим грешит Samsung.

NAND FLASH chip - это не для небольших компаний/проектов.

В случае же использования FLASH карточки(любой - SD, MicroSD etc) таких проблем нет.

BTW. В современных FLASH карточках для основных операций используется hardware controller and
RAM up to 128 KBytes, процессор уровня 51 делает только вспомогательные операции.

Вот здесь коллеги меня спросили - а зачем же тогда у современных проц делают NAND FLASH интерфейс ?

В основном это делается для хранения ОС(Linux, Win CE).
При старте ОС загружается в RAM и оттуда выполняется
OS upgrade (те стирание/запиcь) делается ограниченное число раз (по сравнению с файловой системой общего назначения) те работа с NAND FLASH значительно упрощается.

Для файловых же систем общего назначения FLASH card - оптимальное решение (IMHO)

Но ведь внутри этих SD стоят теже самые NAND Flash чипы, которые управляются специализированным микроконтроллером или микроконтроллером общего назначения. В чем же разница - использовать чипы памяти напрямую или через разъем-ламели карточки-контроллер? Безусловно, часть работы по обслуживнию файловой системы берет на себя контроллер карточки, но мы здесь как раз собрались для того, чтобы выяснить все аспекты реализации этой же задачи.

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

Давайте рассмотрим драйвер NAND FLASH chip - эта та часть software, которая скрывает внутренние проблемы NAND FLASH и делает из него нормальный block device.
Так вот, для нормального функционирования этот драйвер должен хранить и использовать
значительное число так назыв метаданных:
- таблицу адресов(адрес блока <-> физический адрес (где этот блок нынче в памяти) )
- счетчики числа стираний для wear-leveling 1 го уровня
- таблицу плохих блоков
- etc.

Вся (или частично) эта информация при старте системы переписывается в RAM.
При размерах NAND FLASH больше нескольких Gbytes размеры RAM становятся сотни КВуtеs.
Далее - для нормальной работы с NAND FLASH совершенно необходим
error-correction coding/decoding.
Желательно еще иметь и wear-leveling 2 го уровня(статические блоки) ( какой-то background процесс, что также отнимает часть ресурсов процессора.)

Отсюда - для достижения ВЫСОКОГО быстродействия нужен или процессор уровня ARM9 или
некий специализированный hardware controller(особенно для error-correction coding/decoding).
В любом случае надо иметь достаточно RAM.

На практике, hardware controller в FLASH card не только делает вышеуказанные операции,
но и реализует параллельный (!) доступ к нескольким NAND FLASH chip для повышения быстродействия.

Есть ряд применений, где выдающегося быстродействия не требуется. В таких случаях можно все эти функции возложить на Файловую Систему с Драйвером NAND-Flash. Они могут делать все необходимое в фоновом режиме, буферизируя запись/чтение.

Я сейчас пытаюсь понять, делают ли это uC/FS+NAND Driver, emFile FAT Bundle + emFile NAND и пр. Если кто подскажет, буду рад.

Еще кроме быстродействия, место на плате не имеет значения, разводка не имеет значения, затраты RAM/ROM не имеют значения, цена не имеет значения.... Использование ставших абсолютно ширпотребными, компактными и дешевыми SD карточек для файловой системы оправдано в подавляющем числе случаев, а голых Nand соответственно нет.

В этом причина невысокого качества/надежности.

Последние ARM-ы все идут с контроллерами NAND с аппаратными корректорами ошибок.
Считывание из NAND ведется быстрее чем из SD.
Под сотню килобайт памяти должна иметь любая уважающая себя платформа на ARM которой нужна FS
NAND-ы делают стабильно по паре лет, их параметры четко специфицированы.
А вот SD карты меняются в асортименте каждый квартал стопроцентно.
Их единственный плюс только в переносимости. Вытащил - скачал, воткнул другую - проапгрейдился.
Но и выходят из строя они тоже очень часто.
А спецификаций на эти карты вообще никогда не найти.
В realtime приложениях с записью или считыванием видео или аудио на карту каждый раз надо делать пробную закупку и проверять тянут ли они по скорости ваш поток. Дурдом словом.
Я решил вообще по два слота ставить для SD, на случай выхода из строя одной из карт. Настолько велика вероятность выхода их из строя.
Вообщем NAND на борту, эт признак хорошего тона.
Именно на NAND надо делать диск.
А SD использовать только как хранилище постоянных данных или монотонный накопитель данных.

Если не брать совершенно левые noname вместо нормально маркированных по быстродействию, то все вполне стабильно, ожидаемо и надежно. И... по прежднему недорого. Контроллер, как и положено должен иметь SD контроллер на борту, что встречается много более часто, чем навороченные NAND контроллеры.


А запись

Или не должна..., как не обязяна иметь и нехилое количество ног.

Пару лет их конечно делают, только сначала они не доступны, поскольку "новые", а потом дорогие, поскольку "cтарые".

Существуют ли слоты для microSD карточек для установки на плату?

Слот под microSD-карты памяти.