А самому внимательно посмотреть лень?
- ФС активно используется уже 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 не триал-версии?

Сообщение отредактировал bigmaxtor - Oct 5 2008, 12:47

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

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

Сильно не рекомендую связываться с 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тарые".