фрагментирането има значение само ако има физическо време за местене от сектор на сектор.
при флашки е без значение какъв точно е адреса

Така е разбира се, зорът идва от алокирането на нови (все едно къде) клъстери, нали
има по 32 (или поне 12...) бита да се пишат на клъстер. Фрагментирането няма отношение
(докато не почнат да местят главите из картите, дискаджиите току виж ни изненадали
и с такъв "form factor", няма да им е за пръв път ).

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

Макар че като се замисля - той теоретичния максимум като дължина ми е зададен 1 час. При максимална скорост на стрима 16К/сек, ще имам 16К*3600 = около 58 Мбайта фаил. Ако сложа клъстера на максимум - 32 кбайта, ще имам 1800 клъстера, което си е 7 Кбайта само за да съхраня някъде номерата на клъстерите в които ще пиша.... сериозна работа....

И вече почвам да се ядосвам на прекалено общирните изисквания. Ще видя дали не мога да се преборя, картата само да се чете на PC-то. А да се пише (и форматира) само на устройството. Така ако искам да изтрия фаил просто ще го маскирам. Картата е достатъчно голяма за да не е проблем това. Така картата няма да се фрагментира и достъпа ще е максимално бърз. И тогава няма да правя всички тия фокуси с предварителната резервация.... То така или иначе за мойто приложение е най-добре да се форматира с максимален размер на клъстера (32К) а това прост юзер няма как да го прави на ПЦ.

Нямам append функции, слава богу.

Файловата система все ще я надхитриш някак да не пише друго освен твоя файл.
И да е фрагментиран файлът четенето на FAT-а няма да струва нищо при 16к/сек. данни,
надхитрянето ще е да го ограничиш до четене.

Но карта, дето да напише 50+ мегабайта без да запече тук-таме за повече от секунда....
не мисля, че ще имаш такъв късмет дори за пробите.

не съм опитвал, знам ли.... То ще си проличи.

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

За кеширането... Първо по спомен FatFs (което най-вероятно ще ползва Цецо) няма кеширане на високо ниво. А да се преработва си е на баир лозе..
Това което tqi загадна е кеширане на ниско ниво. Демек Цецо ти може да направиш read cache за определени сектори. Така когато файловата система бърника по ФАТ и чете и пише, ти ще спестиш физическото четене. Write cache е леко рисковано наистина...

Относно фрагментирането.... SD-картата има различни команди за поредица и за единичен сектор. Това си се управлява от файловата системка. За четенето няма голямо значение, разликата е малка. При писане обаче може да има много голяма разлика (до 5-10 пъти). Просто това е свойство на самите карти.
Но така или иначе не виждам какво може да се направи по въпроса.

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

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

Кеш при писане. Аз за направяне - ще го направя. Т.е. ще къстомизирам функцията write_file (или каквото е там). Според мен най-добре ще е ако може да кеширам цял клъстер. Ама ми се ще да маам с максимално големи клъстери (файловете на картата едва ли някога ще минат няколко десетки). Ама нямам толкоз рам. Незнам ще видя нещо компромисно - два буфера по 8К (16 сектора) и флип-флоп, нещо от сорта.

Доколкото те разбирам, ти ще си направиш write buffer на твоите си данни, това не е задължително да има нещо общо с cache-a на файловата система.

Дали да правиш read cache зависи дали ще създаваш или променяш ФАТ-а по време на критични секции. На практика като пуснеш операция с нов файл, то започва всичко "на чисто" - гледа типа на картата, после партишъните и така докато намери самия файл. Веднъж отворен файла вече имаш някакво кеширане на четене/запис от самия файл.

Тъй че може поведението е следното според мен:

1) При отваряне на файл има много операции (ще се бави яко)

2) При писане на малки порции (по 5 байта примерно) ще ти кешира до ниво сектор

3) При писане на голяма порция, ще пише директно целия клъстер от сектори.

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

Ъ това е тъпо. Не е ли организирано някакво маунтване, та да не се налага всеки път да рови едно и също?

Ами може и да греша, аз предупредих че говоря малко наизуст (не съм ползвал реално).

Най-добре провери сорсовете - не са големи или сложни....

Сега разглеждам fatfs и от един форум ме замислиха над следния казус.

Има си интерфейсни функции disk_read и disk_write които аз трябва да напиша. Хубаво. Подават ти пойнтер към буфер и ти трябва да го напълни/изпразниш. Поинтера е 8 битов. Дотук добре. Ама в документацията пише че пойнтера не е обезателно подравнен. Какво се рабира по "не е обезателно" не знам, не съм ровил сорса още.

То куртекс проблем с това няма, ама DMA-то на STM32 има. SDIO-то по неизвестна за мен причина работи в 32 битов формат. Честно казано незнам защо така са го направили. Както и да е, DMA-то иска адреса в паметта да му е подравнен.

Предполагам, че ако чета на порции подравнени по големината на сектора (512 байта), fatfs просто ще ми трансферират поинтера които пак аз им подавам, така, че грижата да им подам подравнен буфер е моя. Но ако ползвам нещо неподравнено по сектори, вероятно ще се пробва да кешира междинно и тогава вероятно проблема ще цъфне.

Баламурнишкия начин е ясен - междинен буфер в най-долната функция. Ама си мисля няма ли по елегантно решение?

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

Инак за DMA-то винаги има зорове, кога по-големи кога по-малки. Най-забавно е
като трябва scatter/gather по задание в логически адреси (и пръснати физически страници).

Но едва ли ще е това де, нали е малко MCU.

Абе и аз честно казано не разбирам какъв точно е проблема, че да ми подаде неподравнен буфер, при положение, че ниското ниво функции работят с цял сектор.... Трябва да и разбъзикам сорса... То без това няма да се мине де.

Просто проблема е принципен. Незнам как е на другите контролери от тоя клас, но DMA-то на STM32 го има тоя "проблем". Ако ползваш думи или полудуми, сорса и дестинейшъна трябва да са подравнени. То има логика - за просто и бързо е така. Но излизат подобни ядове.

По ми е интересно що SDIO модула работи с думи, като при флеш картите, се работи основно с байтове.....Или поне аз така си мислех

Е това е "нормален" проблем, примерно ако искаш да четеш от 32-бита порт
към адрес почващ на некратно на 4 и си готов в много от случаите. Ако няма
хардуер да прави прехвърлянето трябва да го правиш ти, и това се случва
да е така по-често отколкото би очаквал... .... и отколкото на мене би ми
се щяло, _винаги_ ми се е налагало да го правя. Ей сега последно на тоя 5200,
има суперумно DMA (най-умното което съм виждал/чувал, всъщност DMA не го
доописва като име). И в errata sheeta - oops, ами misaligned трансферите не работят
и няма да заработят, оправяйте се. И писах микрокодове за случаите на неподравнен
начален адрес до премаляване, кво да правя. Пак добре, можеше да стане
вътрешно (т.е. без да излиза на системния бъс много-много) буферирането. Е, добрата
новина е, че повечето (ама не всички) приложения почват дисковите си
операции от подравнен адрес де (поне в DPS е така).

Цецо виж как работи write_file()...

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

Но пуснеш голяма заявка за писане и тя е в началото на сектор, то естествено няма смисъл нито да чете нещо от диска, нито да го претаква. Директно ще извика dist_write() с твоя указател... и само ти знаеш дали е подравнен или не.