FatFs на STM32 - кеширование FAT32?, чтобы ускорить f_open() Опции

[sonycman]

Всем доброго времени суток.

На девайсе под управлением STM32 есть процедура, которая создаёт сортированный по алфавиту список файлов FAT32 диска на флеш карточке.
Используется FatFs версии 0.08.
Количество файлов в списке может быть максимум 500.

На днях обратил внимание, что львиная доля времени (около 90%), затрачиваемого на сортировку, потребляется функцией файловой системы f_open().
Поковырявшись в её дебрях, обнаружил, что в свою очередь это вызвано подфункцией move_window(), которая подгружает по одному сектору из, вероятно, каталога фат.

То есть чтобы открыть файл, файловая система продирается через структуру фат до того, как найдёт запись с информацией по нужному файлу.
Считывание ведётся по одному сектору.
И так для каждого файла.

Вот и подумалось тут, а почему бы не ввести кеширование для секторов, запрашиваемых функцией move_window()?

Главный вопрос здесь - хватит ли для этого 10-20 килобайт оперативки?
К сожалению, приходится довольствоваться только внутренним ОЗУ контроллера.

Наверное, для FAT32 с большим количеством файлов кеширование 20 килобайт (40 секторов) не будет эффективным?

[sonycman]

Получил результаты своего отладочного логгера, который сохранил историю запросов на чтение диска при работе функции f_open().
Цифры - LBA сектора в шестнадцатеричном виде:

CODE

00004000
00004001
00004002
00004003
00004004
00004005
00004006
00004007
00004008
00004009
0000400a
0000400b
0000400c
0000400d
0000400e
0000400f
00004010
00004011
00004012
00004013
00004014
00004015
00004016
00004017
00004018
00004019
0000401a
0000401b
0000401c
0000401d
0000401e
0000401f
00004020
00004021
00004022
00004023
00004024
00004025
00004026
00004027
00004028
00004029
0000402a
0000402b
0000402c
0000402d
0000402e
0000402f
00004030
00004031
00004032
00004033
00004034
00004035
00004036
00004037
00004038
00004039
0000403a
0000403b
0000403c
0000403d
0000403e
0000403f
0000386c
00004040
00004041
00004042
00004043
00004044
00004045
00004046
00004047
00004048
00004049
0000404a
0000404b
0000404c
0000404d
0000404e
0000404f
00004050
00004051
00004052
00004053
00004054
00004055
00004056
00004057
00004058
00004059
0000405a
0000405b
0000405c
0000405d
0000405e
0000405f
00004060
00004061
00004062
00004063
00004064
00004065
00004066
00004067
00004068
00004069
0000406a
0000406b
0000406c
0000406d
0000406e
0000406f
00004070
00004071
00004072
00004073
00004074
00004075
00004076
00004077
00004078
00004079
0000407a
0000407b
0000407c
0000407d
0000407e
006006c0
006006c1
006006c2
006006c3
006006c4
006006c5
006006c6
006006c7
006006c8
006006c9
006006ca
006006cb
006006cc
006006cd
006006ce

Кластер на карточке равен 32 килобайтам.

Как видно, чтобы открыть файл, считывается два с лишним кластера каталогов (!!!) (а между ними проскакивает сектор FAT?).

И так практически для всех 57 файлов папки, а если точнее - методом односекторного чтения считывается 131 сектор для первого файла, и уже 143 сектора для последнего.

Хм, действительно, если читать сразу по 8 секторов за раз, то можно несколько выиграть.

ЗЫ: завтра посмотрю, какая картина будет при сортировке 500 файлов.
Аж страшно становится

ЗЗЫ: до чего убогая файловая система, господи.
Чтобы добраться до грошового файлика весом в сотню байт, требуется перерыть килобайты мусора в виде каталогов...