Програмная часть: файловые системы: концепция

Традиционный подход к коду, управляющим файловой системой, подразумевает использование уникальных символических путевых имён для каждого хранимого файла. Это удобно для универсальной операционной системы, но программное обеспечение плейера универсальным не является и к тому же работает в условиях жесткого ограничечения оперативной памяти: процессор ATmega32 имеет всего 2 кб ОЗУ на борту, какого либо внешнего ОЗУ в плейере не предусмотрено.

Плейер, работающий с универсальной операционной системой, при воспроизведении нескольких файлов подряд, должен иметь список этих файлов, хранящихся либо в отдельном файле либо составляемый на основании запросов к операционной системе. В такой операционной системе знание имени одного файла не позволяет предсказать имена других файлов, находящихся в данной директории или хотя бы за разумное время найти эти имена путём перебора. Имена соседей могут быть получены только в результате обращения к ОС, причём в большинстве операционных систем выяснить следующий или предыдущий файл можно только полностью запросив и проанализировав текущий каталог.

Для составления же списка файлов, расположенных в сложной древовидной структуре, придётся изучить её полностью, что требует как времени так и значительного объёма оперативной памяти для хранения результатов. Что полностью противоречит требованию быстрого запуска плейера. Плейлист (список файлов в виде отдельного файла) хотя и снижает требования к оперативной памяти, однако время на его генерацию (особенно, в условиях медленной файловой системы - опять же по причине малой оперативной памяти) будет весьма значительным.

В общем, мы пойдём другим путём.

В Orfey'e я отказался от использования в качестве идентификатора файла уникального символьного имени в пользу целочисленного массива. Каждый элемент массива описывает номер элемента очередного каталога, который составляет путевое имя файла. Например: "3.5.4" - третий элемент корневого каталога является подкаталогом, в котором пятый элемент также является подкаталогом, в котором четвёртый элемент является целевым файлом. Отмечу, что эта схема адресации совершенно совместима с традиционной схемой путевых имён и может быть применена для всех файловых систем, которые предполагается реализовать для Orfey'я: FAT, UFS, EXT2.

Что это даёт ? Самое главное - возможность за незначительное, конечное число итерраций найти соседей (причем оперируя числами, а не строками): т.е. - в терминах пользовательского интерфейса - перейти к следующему или предыдущему файлу, причём не только в пределах одной директории. Так же свободно можно переходить в любую другую точку иерархии. Несколько упрощенный пример:

  // Переход к предыдущему файлу
  procedure NextFile;
  begin
    repeat
      FileIndex[CurrentLevel]--;
      file_Test();
      if result = -1 then CurrentLevel--; // Достигнуто начало текущего каталога
    					  // - поднимаемся на уровень выше
    until result <> 0; // Такого файла нет - удаленная
		       // или специальная запись - пробуем ещё раз
    // успешное завершение
  end;

Вообще-то говоря, можно было бы реализовать подобный механизм и с использованием символьных имен, но - согласитесь - цифры компактнее и проще в обработке :)

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

Технический смысл конкретного значения числа в пути может быть различным: это может быть номер записи в каталоге или её смещение (делённое на размер записи - для номера отводится только 16 бит), причем могут учитываться все записи или же только фактически доступные (не удалённые, не являющиеся служебными, вроде имени тома или расширений LFN). Важно лишь, чтобы номер был уникальным для каждой каталожной записи.

Максимальная глубина путевого имени файла (т.е. число элементов массива-имени) выбрана равной 10. Элемент имеет разрядность 16 бит (например, в FAT это позволяет адресовать более 65000 имен формата 8.3 в каждом каталоге).

Специализация программного обеспечения плейера также накладывает другие особенности на код поддержки файловой системы:

• Нет файловых дескрипторов. В конкретный момент времени может быть открыт только один файл.
• Нет возможности выбора позиции в файле (seek). Только пропуск сектора без его чтения может быть использован внешним кодом для быстрого перехода от начала файла к нужной позиции.
• Нет операции закрытия файла: она не нужна, так как используются статические буфера и нет поддержки записи.
• Игнорируются любые данные об ограничениях прав доступа.
• Объем данных, возвращаемых операцией чтения, всегда равен 512 байт. Даже если объём данных файла не кратен этому числу.

Програмная часть: файловые системы: оболочка файловых систем

Оболочка файловых систем (файл fs.asm.inc) обеспечивает более высоким уровням програмного обеспечения универсальный механизм доступа к файлам. Её вызовы можно условно разделить на следующие группы:

• Инициализация: file_Init - считывает текущее имя файла, используемое устройство, номер раздела из энергонезависимой памяти, после чего вызывает инициализацию необходимой среды хранения и файловой системы. Вызывается при включении плейера; file_DvCh - записывает в энергонезависимую память используемое устройство и номер раздела, инициализирует необходимую среду и файловую систему. Вызывается при смене номера раздела или носителя.
• Доступ к файлу: file_Open - открывает заданный файл и сохраняет его имя в энергонезависимой памяти, file_Read - читает очередной блок 512 байт, file_Step - выполняет переход к следующему блоку файла.
• Переход к соседним файлам: file_Prev (file_Next) - пытается найти предыдущий (следующий) файл в текущей директории. Если файл был первым (последним) - переходит к последнему (первому) файлу предыдущей (следующей) директории.
• Переход к соседним директориям: file_PrvD (file_NxtD) - переходит к концу (началу) директории заданного уровня.
• Прочее: file_Idnt - пытается по содержимому файла определить, является ли файл содержащим что либо похожее на поток MP3 (NB: плейер никак не анализирует расширения файлов !). file_Name - возвращает заданную часть путевого имени файла.

Большинство функций возвращает признак успешного выполнения операций во флажке C. Некоторые функции могут возвращать расширенный код в переменной fs_errno.

Поддержка файловой системы FAT

Файл fs.FAT.asm.inc. Поддерживаются все три варианта файловой системы: FAT12, FAT16, FAT32. Никаких особенностей нет, если не считать того, что в следствие малого объёма оперативной памяти никакие структуры файловой системы не кешируются. Т.е. даже просто переход к очередному кластеру файла без чтения данных вызовет обращение к накопителю (для анализа таблицы расположения файлов, даже если именно она в данный момент хранится в буфере). Это, однако, для работы плейера совершенно не критично, так как имеющейся производительности хватает с запасом.

Параметры загрузочной записи анализируются полностью, код (в отличие от MS-DOS, например) не пытается делать своих предположений относительно корректности значений (как правило, это "умение" MS-DOS'у порой сильно вредило). Нет ограничений на использование не совсем стандартного размера кластера в 64 Кб (используется, например, в FAT16 на разделах 2-4 Гб).

Так как имена файлов не анализируются, любые символы в них считаются допустимыми (вы даже можете использовать имена, включающие символы "*", ":", "\", "/"... если сможете их создать ;) ). Процедура file_Name понимает длинные имена файлов (LFN), но будет урезать их слева, если длина превышает 63 знака. Правильно отображаться будут только символы, которые имеют эквиваленты в кодировке КОИ-8. Включая букву "ё". Если файл не имеет длинного имени, короткое имя только дополняется точкой между именем и расширением, суффиксные пробелы не удаляются, какой либо модификации регистра не происходит (т.е. вернутся заглавные буквы).

Поддержка файловой системы UFS

Пока не реализована.

Поддержка файловой системы EXT2

Пока не реализована.