Абе сложно е да го сложиш на най-ниското ниво. Много объркана ще стане цялата логика - ще имам един софтуер, дето да лъже друг софтуер, че третия софтуер е ОК. Не ги обичам тия работи.

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

Стандартните примери са за fatfs но нищо конкретно не мога да ти кажа, щото не съм ги мъчил.

Порт на Fatfs върви с демотата на Луминари, но малко стара версия беше, аз портнах последната за тогава 0.07, работи с карта и усб флаш, няма дертове с нея. Както казва батето - имаш да си напишеш няколко функции... по-конкретно

* disk_initialize - Initialize disk drive
* disk_status - Get disk status
* disk_read - Read sector(s)
* disk_write - Write sector(s)
* disk_ioctl - Control device dependent features
* get_fattime - Get current time (ако имаш часовник )

efsl не съм я ползвал.

Използвам FatFs с SD карти и MMD FS на Microchip с SD и USB. И двете работят перфектно.
На FatFs просто няма какво да й бъзикаш, дописваш си функциите, които ти трябват за достъп на ниско ниво на конкретния хардуер и това е. Има и готов пример, в който можеш да използваш заготвките на съществуващите функции. Никакви портове
не се налагат да се правят.

Абе то без бъзикане няма да се мине, защото на мен ми трябва малко по особенна логика на писане на файловете.

Но явно модата е FatFs.

Интересно ще да е споделиш каква е тази по особена логика

Това, което мен ме притеснява в тези окастрени файлови системки е, че няма грам обработка на грешки или поне аз не видях такава...

Демек за read-only приложения стават, ама за приложения дето се пише честичко и трябва да работи дълго без човешка намеса нещо им нямам вяра. Не знам, може би ако се форматира картата с няколко FAT копия, самите алгоритми да гарантират че няма да се омаже всичко? дори и някой запис да бъде прекъснат?

Някой има ли опит на тая тема?

Ами едното което ме притеснява е това което казва Миро.

Другото е че при мен данните са стрим. Т.е. текат и картата, жива умряла трябва да пише. А ФАТ не е най-благодатната система (ама пък я искат по спецификация) за стримови данни, щото трябва непрекъснато да се чете и пише FAT-а. Благодатно пък е обаче, че знам колко е максималния размер на файла.

Идеята ми е преди да почне за записва, да алокира във ФАТ-а максималния размер на файла и да си направи в РАМА някъде карта на клъстерите в които ще пише. Така ще пише само физическите данни, без да бърника и ФАТ. Чак при затваряне на файла ще оправя тази бакия. Ако случайно тока спре, ще остане един омазан ФАТ, но мисля това да го оправям постфактум, като в един вътрешен Е2ПРОМ си пиша колко клъстера съм успял да запълня. Нещо такова, не ми е още съвсем кристално в главата

Ами ако това са особените неща, то мисля е безсмислено да се захващаш с FAT, по-добре е да си направиш нещо собствено, което да ти гарантира последователно използване на клъстери, а защо не и сектори, след това си правиш един драйвер от страната на ПК, който да ти чете твоята си дискова организация и това е.

А колкото до проверката дали е записана правилно информацията, след fwrite винаги можеш да си направиш проверка с fread. Същото може да се направи и вътре в самата fwrite, но мисля е по-сложно и неудобно, трябва да се пази локално стария файлов указател, да се стартира процес на четене и т.н. Поне на мен ми се вижда много по-удобно да извикаш fwrite, да ти върне управлението след края на записа, пък след това можеш и нещо друго да свършиш преди да направиш проверка дали всичко е записано правилно.

Въпросът е дали FAT-а ще се сбозва наистина?

FAT-ът няма много общо в ситуацията. Ако ще се пише непрекъснато, той ще _трябва_ да е
в кеш някъде, никой flash няма да издържи на такова темпо на писане/триене за разумен
период от време.

Но въобще това с писането жив/умрял е умряла работа, умрелите флашове не могат да се пишат.
Можеш само да имаш добра представа къде да _не_ опитваш да пишеш предварително, което
предполага някакъв тест и надежда, че при опит после на базата на теста няма да има изненанди.

По принцип разните SD карти - само съм ги чел де - сами се грижат за лошите си сектори и
едва ли ще намериш две еднакво държащи се.

Преди много години писах за DPS едно подходящо за подобни цели нещо, пише/чете всеки
сектор поотделно и мери времето - от някакво време нагоре го слага в LCAT (Lockout Cluster
Allocation Table) файла на диска. Та нещо такова ще трябва да правиш и ти, едва ли ще
дойде готово с файловата система. Инак във FAT-а има къде да се маркират лошите клъстери,
но гаранции че няма да има новопоявили се няма кой да ти даде.

@tqi, потенциалните проблеми са ни известни...

Въпросът е първо доколко са фатални, т.е. доколко често писане/триене може да се използва ФАТ. И второ има ли читава алтернатива?

Aз така или иначе съм зачеркнал фат-а, ма поне да знам дали е било основателно

Аз FAT-а не мога да го зачеркна, щото такова ми е заданието - картата трябва да се чете на компютър без никакви допълнителни хардуер или софтуер.

Относно лошите сектори - аз по скоро имах предвид, че когато картата има лоши сектори, тя сама се грижи да ги маркира и предложи алтернатива (както е при дисковете). И в рекламите уж го прави добре. Така, че аз лошите сектори напрактика не би трябвало да ги виждам въобще. Въпроса е че това неминуемо бави достъпа. Отделно, че когато файловата система е фрагментирана, това допълнително може да забави достъпа.

А ако всеки път правя достъп до FAT, това съвсем ще утежни нещата... Затова се търсят варианти да оптимизирам нещата.

Е дали ще намериш файлова система да ти кешва FAT-а и/или още работи не знам,
това наистина спокойно може да е във високото ниво. Можеш и ти да си го направиш
без особени зорове, разбира се - на ниското ниво.
Май картаджиите не специфицират максимално време за достъп - а че имат процесори
вътре и подменят умрели области в движение няма съмнение.
Но устройство, което да ти гарантира бездефектна "streaming" скорост много-много няма, и не би могло
да е много евтино. Достатъчно дълъг RAM буфер - може би дори десетки мегабайта - та да
има време да се справи някой с изненадите е реалното нещо, което можеш да направиш.
Стига теоретично най-ниската средна скорост да ти стига, разбира се.