Я работаю с FATFS. Пишу/читаю файлы на SD. Как работать с одним файлом понятно.
Но если есть список файлов file#1.xml, file#2.xml,….file#100.xml. Как мне их перебрать эффективно?
Есть функции f_findfirst и f_findnext. Но что для них first а что next? Скажем если я задам маску "file#*.xml" - first будет первый по порядковому номеру?
Я хотел посмотреть если есть дырка, скажем file#1.xml, file#2.xml, file#4.xml - значит file#3 отсутствует то его и создать.

f_findfirst начинает процесс перебора файлов в каталоге, f_findnext продолжает этот процесс. Смотрите пример использоваания - http://elm-chan.org/fsw/ff/en/findfirst.html

Вам придется перебрать все файлы, и лишь потом вы сможете определить, каких именно файлов не хватает. FAT не гарантирует перебор файлов в каталоге в каком то определенном порядке.

я понял. то есть нужно считать все имена файлов сохранить их где то и перебрать. та еще морока. я так понимаю количество файлов можно узнать только перебрав все файлы.

придумал. буду перебирать номера и пытаться открыть файл с этим номером. открыл - значит файл есть, инкрементирую номер, получил ошибку – файла нет, создаю файл с этим номером.

Сообщение отредактировал Jenya7 - Dec 6 2016, 09:44

Да
Тоже вариант, хотя и довольно затратный.
Можно считать все имена файлов, выделить из них номер и именно его сохранять. Получится экономичнее, чем сохранять целиком имена. Можно еще сэкономить - сохранять не отдельные номера, а интервалы (хотя в реализации это сложнее)

так считать все файлы это полный пробег. к тому же не зная количество файлов затруднительно выделить размер буфера под номера, которые тоже потребуют полного пробега. а так есть надежда что где нибудь посередине нам повезет.

хотя... по команде открыть файл тоже идет перебор имен файлов.

кстати а как узнать сколько места осталось на SD карте?

Сообщение отредактировал Jenya7 - Dec 6 2016, 14:02

Вообще-то в таких случаях как бы само собой разумеющееся решение - битовая карта. Всего 1 бит на файл.


Если Вы ищете первое свободное место в порядке нумерации файлов, то зачем вообще что-то сохранять??? Нашли первую "дырку" и закончили перебор.

я думал про битовую карту. если учесть что может быть 100 файлов то либо создать 4 uint32_t либо

последнее вобще то из разряда извращений.



поэтому я и решил что оптимальней всего искать дырку.

Эти цифры "#1"..."#100" в названии несут смысловую нагрузку? они должны идти по порядку (более поздний имеет бОльший номер) или просто быть уникальными?
Если просто уникальными- то Ваш метод с поиском до первого ненайденного файла работает.
Если должны идти по порядку- то Вы должны проверить весть каталог и записать файл со следующим номером после максимального найденного.

Метод "перебирать номера и пытаться открыть файл с этим номером. открыл - значит файл есть"- с точки зрения ресурсов самый затратный и медленный путь, хуже и придумать сложно.

Чудес нет- ФАТ читается в том порядке, в котором сектор забит записями, и это никак не привязано ни к времени, ни к алфавиту. Так что перечитать нужно все до конца. Но один раз, а не как Вы хотите- столько раз, сколько файлов имеется.

Алгоритм такой. Пользователь создает новую задачу. Я решил под каждую задачу создавать файл. Ну а номера для удобства. Как мне кажеться лучше следить чтоб номера не шли вразброс а были упорядочены. А считывать один раз нужно что? имена файлов? проблема что заранее не знаешь сколько файлов имеется и сколько места отводить под массив имен.

Сообщение отредактировал Herz - Dec 10 2016, 10:19

Пролема однако. При перезаписи файла кусок старых данных остается. А как почистить файл перед записью?

Чтение документации из интернета вслух - 100 евро/час.

Дальше читайте сами.

спасибо.

а вот если мне в файле нужно найти какое нибудь слово. я должен скопировать файл в буффер в RAM и там искать? другого способа нет?

Ну да. С флешки лучше всего подойдет чтение блоками по 512 байт (если объем памяти под буфер критичен). Т.к. физически минимальная единица чтения/записи - 512 байт. Далее поиск нужного слова в буфере (надо, правда учитывать, что слово может быть "разорвано" между блоками). Адрес следующего блока всегда должен быть кратен 512 от начала файла. Тогда можно быть точно уверенным, что не читалось два 512-байтных блока.

А свободное место считается в FAT32 по структуре FS_Info. Как в остальных ФС не знаю. Но есть, правда уточнение, что не все устройства поддерживают обновление FS_Info и если чтение/запись еще будет на другом устройстве, то информация в FS_Info может и не соответствовать действительности. В FatFS сам проверял - FS_Info обновляется и в каждой копии FAT_TABLE. В ОС Windows тоже.

Если надо точно быть уверенным в случае использования флешки "на стороне" - нужно пройтись по всем DIR_ENTRY в файловой таблице.

Сообщение отредактировал kolobochishe - Mar 1 2017, 15:16

Если хотите читать неторопясь, особенно с SD карт, то 512 байт, а если "по уму", то по 4Кбайта