Имам един 64 мегабитов SPI flash в устройство. Трие се на 4К сектори, пише се на 256 байта страници.
Ще бъде разделен на зони (partition-и) и на една от тия зони ми се иска да организирам файлова система (ФС). Предизвикателството е организацията в тази зона. Трябва да реша стандартните проблеми с wear leveling и големите erase зони, сигурност на валидността на данните.
ФС трябва да поддържа RW, ще съхранява не голям брой файлове, размера на "диска" е малък (никога няма да е над 256Мбит), да поддържа папки. Скоростта на достъпа не е критична (времето за запис/четене имам предвид).
Броят записи/четения е лимитиран също, няма да се пишат лог файлове, така че обявения брой цикли от 100'000 на чипа е напълно OK - но ми трябва организация на системните данни на ФС-а че да не се повреди примерно файловата таблица, ако стои на едно място. Може да се хвана да видя как са реализирани ФС за RO носители като CDFS примерно? Или нещо журнално?

Едната посока е да имам нещо като eeprom emulation, който да се грижи само за wear leveling-а, и отгоре да е нещо стандартно (fat например). Другото е flash-aware файлова система.
Та на пръв поглед не намерих нищо, което да е използваемо на конкретната платформа (cortex-m4, 256K flash, 64K RAM).
Варианти:
- ST има app notes за еепром емулация за вътрешния флаш, който може да се преработи за SPI flash-a (поне така изглежда на пръв поглед)
- купуване на нещо комерсиално - не е проблем, даже е много ОК, стига директно да покрива всички изисквания и да си изкара парите чрез спестено време
- нещо свободно - рових, рових, ама повечето неща са за линукс/posix и искат адаптиране за ОС-а, който ползвам
- да сменя ОС-a - nuttx-а имат тези неща (поне на първо четене)
- нещо custom

Имате ли опит с такива сценарии? (знам че СД карта решава тези проблеми, но е сложен чип заради мястото, броя пинове и механичните контакти).

Имаме много опит... и заради това ще ти препоръчам още веднъж да помислиш върху SD-то. Няма база за сравнение и като обем, скорост, цена, възможности, но най-важно като надеждност особено при вероятност от смущения. С SPI един бит смушение докато подаваш адрес примерно и язък за данните

Иначе организацията на една флаш фс е общо взето следната:

Имаш флаш, разделяш го на блокове. Ти си решаваш дали блоковете да са с фиксирана голема и различен брой според размера на флаша или пък фиксиран брой с различна големина. Примерно в първия вариант ако си избереш блок с размер 64к имаш 16 блока при 1МБ, 32 блока при 2МБ и т.н. Във втория вариант да речем си избираш 16 на брой блока, където всеки блок е 1/16 от размера на флаша ти. И при двата варианта условието е да може да изриеш кой да е блок, т.е. да е кратен на erase страница/сектор.
Сега от блоковете оставяш един винаги да ти е празен, а в останалите може да имаш данни. На всеки блок присвояваш логически номер, който си го пишеш в началото на блока. Да кажем че си избрал варианта с 16 блока, значи в началото си сканираш хедърите на всички физически блокове и си попълваш една табличка в паметта, кой логически на кой физически съответства. Идеята е, че с времето те се разместват...
От блоковете може да си направиш логически дискове. Да кажем един диск с големина 4 блока, един диск 2 блока, един диск 5 и т.н. Това е цел да си структурираш нещата, в смисъл ако търсиш даден файл да го търсиш само в блоковете на диска, а не из целия флаш.

Сега в рамките на един блок може да пишеш файлове. За целта от единия край на блока почваш да пишеш индекси, а от другия самите файлове. Индексите са записи с фиксиран размер, желателно много малък размер. Примерно размер на файла, crc на файла, crc на директорията.. плюс няколко вълшебни битчета. Идеята е като трябва да търсиш файл с определено име и/или директория, хващаш и четеш индексите подред и гледаш crc-тата. Табличката с индексите особено ако ползваш 16-бит crc-та и ако размера на файла ти е до 65kB е малка, така че с едно четене сканираш много записи...
Между другото докато четеш индексите си натрупваш и дължините, щото това ти е указател до текущия файл. И ако той те интересува това е от офеста от другия край на блока...
А самия файл започва с хедър от името на файла, директорията му, ако искаш CRC-та и после самите данни.

Това е организацията общо взето, пишеш файлчета от единия край, индекси от другия и така докато двете писания се срещнат, т.е. напълниш блока...
Сега за "вълшебните" битчета... Те са нещо като семафорчета, защото писането на един бит или ще мине, или няма да мине, но няма да остане в средно положение Докато писането на повече данни не е ясно какво ще стане ако го прекъснеш по един или друг начин. Затова критичните неща се "обграждат" с писане на битчета. Примерно трябва да запишеш нов идекс на файл, пишеш го обаче без един бит. Ако запишеш блока, сваляш и битчето. При четене ако видиш че има мазано в индекс, ама битчето за валидност не е свалено, значи тоя индекс го прескачаш... И те така си защитаваш данните....
Едно битче може да си оставиш и за това дали файла е изтрит. Като го свалиш, после си знаеш да не ползваш файла. А данните си напрактика си остават в блока, нещо като "дупки". Между другото, в хедъра на блока може да имаш и битче за това дали си трил файлове, т.е. дали имаш дупки. Така, когато ти се напълни даден блок може да го оптимизираш като хванеш и копираш всички файлове в празния блока (нали имаш един винаги празен). Копираш естествено без дупките. И естествено това защитено с битчета за валиден блок, така че първо правиш новия блок валиден, после инвалидираш стария. Ех, ако ти спре тока точно по средата може да ти се получат два физически блока с едни и същи логически адреси, ама ти ще го хванеш това при следващия буут докато си изграждаш табличката логически-физически и освен това ако си сложиш и ревизия ще знаеш коя весия е старата и ще я инвалидираш....

Тва е, не е сложно.. само дето някои бъгчета се откриват месеци или години по-късно

Но пак ще кажа, дейтафлаша няма защита при SPI комуникацията и ако имаш смущения (GSM, тоци разни..) забрави да имаш надеждност!

Мерси за изчерпателното инфо.
Както казах, хардуера е отдавна проектиран и към microSD не може да се мине (мястото е било основния проблем, както и наличието на механични конектори). Иначе няма спор че там са решени всичките ми проблеми. eMMC-то е в кофти корпуси и пак не се връзва. Не че и там няма подводни камъни, но са от друго естество.
Другият проблем е че нещата са за вчера, а разработването на такъв алгоритъм (заедно с верификацията му) ще отхвърли до коледа, и няма да се изплати после. За това питам за готово, специализирано, проверено и, по-всяка вероятност, платено решение. Т.е. най-късият път.
Има доста комерсиални продукти на различни фирми. Ще ги проучвам, а ако някой има опит с такъв вид middleware да помага.

Чиста ФС като комерсиален продукт не съм чувал, ама търси... Обикновено са към някой ОС и вървят комплект, само че комерсиалните такива дето са хубави хич не са евтини.
При всички случаи ще загубиш време, така че не съм убеден дали с пари ще спестиш време. Затова май е по-добре да разгледаш хер нът-а. Има си трески, но което съм гледал е изглеждало работещо...

http://www.cmx.com/ffsstd.htm
Това ми беше първата идея, RTOS независимо е, нищо че те правят и ОС. Има всичката нужна функционалност.

Това е алтернатива:
http://www.hcc-embedded.com/products/sa ... tion-layer

Както и това:
http://www.highintegritysystems.com/mid ... e-systems/