Chapitre 48 : Baremetal lire un fichier sur la carte SD Partie 2 et 3

Maintenant que nous avons une routine pour lire un ou plusieurs blocs (ou secteurs) de la carte SD, il nous faut maintenant rechercher les informations sur le système de fichiers puis les informations permettant d’accéder au fichier recherché.

Attention : les contrôles de validité de la carte et du système de fichiers sont succincts !!. si nécessaire il faudra améliorer ces contrôles.
Avertissement : ce premier programme ne peut lire que des fichiers dont la taille est inférieure à 512 *64  = 32768 octets.

Comme la carte SD que nous utilisons est la carte de démarrage du Raspberry, le système de fichier est une FAT32 et donc je ne programmerais que l’accès à ses informations. Si vous voulez accéder à d’autres partitions, et bien il vous faudra rechercher les descriptions de chaque système et adapter ce projet en conséquence.  Tout le projet est ici.

Bien ! donc dans le module nouveau répertoire.s nous commençons à accéder au secteur 0 de la carte qui contient un code de vérification code  0x55AA à l’adresse 0x1FE et la table des partitions disponibles sur la carte. Sur ma carte il n’y a qu’une seule partition dont l’adresse est à la position 0x1C6.  Attention, il n’est pas possible de récupérer directement cette adresse dans un registre car elle n’est pas cadrée sur une frontière de mot et de plus toutes les adresses sont sous le format Little endian (voir les différents formats sur wikipedia).

Cette adresse est le nombre de secteurs de 512 octets avec laquelle nous allons accéder aux informations de la partition. Ces informations pour la FAT32 sont décrites dans le fichier structures.inc. Nous commençons par vérifier que la partition est bien une FAT32. C’est ici que vous devrez adapter la routine pour gérer d’autres types de partition. (voir sur internet la documentation pour les FAT12, FAT16, FAT32, NFTS et partition Linux)

Dans ces informations, nous trouvons les données qui vont nous permettre d’accéder au répertoire principal de la partition. Il faut effectuer un petit calcul, pour trouver le premier secteur de ce répertoire. Hélas en FAT32, il n’y a pas de donnée qui nous donne le nombre de secteurs à lire pour avoir tout le répertoire.

Le répertoire est composé d’entrées de 32 caractères qui donnent le nom court, l’extension, l’attribut, la date de création, le cluster de début du fichier et la taille en octet de chaque fichier stocké sur la carte (voir la description dans le fichier structures.inc).

Vous remarquerez que les fichiers supprimés ont leur premier caractère de leur entrée dans le répertoire avec la valeur E5 et donc on ne tient pas compte de ces entrées.

Dans la routine lecturerepertoire, nous nous contentons de balayer ces entrées et d’afficher le nom court, le cluster de début et la taille du fichier. Vous remarquerez que les noms sont affichés en majuscule alors que le gestionnaire de fichiers windows les affiche en minuscule. Et les noms longs sont convertis en un nom court ce qui va nous compliquer la tâche pour extraire un fichier particulier.

J’ai mis plus d’une semaine à trouver une anomalie bizarre lors de la lecture successive des blocs. En effet la deuxième lecture ne donnait pas le résultat attendu puis la 3^ième lecture donnait un résultat. J’ai fini par trouver une erreur dans la routine de lecture des blocs vue au chapitre précédent. En effet à l’instruction 250 j’avais mis un test sur l’égalité infériorité de la récupération des 128 mots alors qu’il fallait tester l’infériorité stricte. Donc la routine lisait 129 mots de 4 octets, ce qui entrainait un décalage dans les lectures suivantes. Il faut donc rester très prudent sur les tests !!! (et je pense qu’il reste encore quelques erreurs subtiles dans ce code.

La 3^ième routine consiste à rechercher un fichier dans le répertoire et d’afficher le début de son contenu. Dans celle-ci nous commençons par lire le répertoire principal et à stocker tous les secteurs en mémoire ! Cela est nécessaire car la gestion des noms longs oblige à effectuer une recherche vers le haut des entrées puis de revenir pour récupérer les caractères du nom long. Cette gestion complexe a été faite par Microsoft pour assurer le bon fonctionnement des logiciels de lecture de fichiers sous Msdos (noms courts limités à 8+3 caractères) puis sous Windows (noms longs < 256 caractères) il y a très très longtemps !!!.  

A partir de l’entrée du répertoire, l’attribut du fichier indique si le nom est court ou s’il est long. S’il est court, nous appelons une sous routine pour récupérer le nom complet en minuscule avec l’extension. S’il est long, nous appelons une autre sous routine qui va rechercher dans les entrées suivantes, la première entrée contenant le début du nom long puis remonter pour composer le nom au fur et à mesure. Vous remarquerez que chaque caractère est en minuscule codé sur 2 caractères (norme UTF-8).

Ensuite nous comparons le nom trouvé dans le répertoire et le nom recherché. Si égalité nous calculons le secteur de début puis à partir de sa taille le nombre de secteurs à lire. Pour trouver le secteur de début, il faut extraire le nombre de clusters qui se trouve sur 4 octets mais divisé en 2 octets se trouvant à 2 endroits différents !!! Et un cluster est un ensemble de secteurs et il nous faut donc multiplier ce nombre de clusters par la taille de chaque cluster et qui se trouve dans une donnée de la partition (ici nous trouvons 0x40 soit 64 secteurs par cluster). Ah oui, il faut aussi enlever 2 clusters au nombre de clusters trouvés (voir la documentation sur la structure d’un répertoire FAT32).

L’accès au fichier s’effectue ici correctement. Il y aura peut-être des cas où cela se passera moins bien car je n’ai peut-être pas vu dans ces calculs des options à prendre en compte. Par exemple la documentation de la FAT32 parle d’une table des clusters utilisés par les fichiers or  à ce jour je ne suis pas encore arrivé à trouver cette table. Ou elle est vide !! car peut être aucun fichier de la carte ne dépasse 1 cluster soit 64 secteurs soit 32768 caractères !! Ce n’est pas encore très clair pour moi mais j'y travaille.

Il restera encore à traiter le cas des répertoires secondaires !!   et puis l’écriture d’un fichier sur la carte et ça c’est du dur !!!