SE4Binome2023-6

Ordonnanceur / système d'exploitation

Pour débuter, je vais faire en sorte de faire clignoter deux LEDs, chacune correspondant à un processus différent, le but étant que l’ordonnanceur alterne entre les deux.

J'ai réussi à faire fonctionner l'ordonnanceur avec les deux tâches de clignotement de LED qui s'alternent entre elles.

Type de carte choisie

J'ai choisi de réaliser la carte mère du pico ordinateur sur laquelle on va venir brancher les cartes filles. Voici les choix que j'ai fait pour la conception de cette carte:

• Alimentation 5V provenant de l'USB (j'utilise un connecteur mini USB B).
• Programmation de la carte avec dfu-programmer grâce à un FTDI (FT232RL) mais connecteur AVR ISP inclus aussi.
• Régulateur de tension pour la puce mémoire et une adaptation des niveaux logiques pour cette dernière.
• ATmega328p traversant.
• Possibilité de brancher 5 cartes filles grâce à 5 connecteurs HE10.

Réalisation du bouclier de test

Parmi les activités disponibles, j'ai réalisé les choses suivantes :

J'ai soudé quatre de ces cartes, j'en ai gardé une pour moi puis j'ai donné les cartes en plus aux binômes 3, 7 et 10.

J'ai fait deux câbles comme ceci

J'ai soudé quatre de ces cartes pour afficheurs LED, j'en ai gardé une pour moi puis j'ai donné les cartes en plus aux binômes 1, 4 et 10.

Réalisation de la carte mère

Schematic de la carte mère

Tout d'abord, il a fallu réaliser le schématic de la carte sur KiCAD. Je me suis inspiré du Shield de test et ai inclus les nouveaux composants tels que le FTDI, le connecteur mini USB B ...

J'ai ajouté des condensateurs de découplages pour chaque composant important afind d'éliminer les parasites produits par les pistes. Lors de la réalisation du PCB, il faudra faire en sorte qu'ils soient physiquement proches pour être efficaces

Schematic réalisé pour la carte mère

PCB final réalisé

J'ai réalisé ce PCB en prenant en compte les contraintes liées aux composants.

PCB final

Soudage de la carte

Quelques semaines après avoir envoyé le .zip contenant les fichiers gerber de KiCAD, j'ai reçu mon PCB imprimé

Carte vierge reçue

Par la suite, j'ai commencé à souder les composants Cependant, j'ai rencontré plusieurs problèmes: - les pistes D+ et D- du FTDI sont inversées - Les connecteurs HE10 couvrent légèrement certains composants et la LED pour certains - La carte n'est pas reconnue en périphérique USB si on fait un lsusb. J'ai dû refaire une autre carte mère avec un FTDI qui fonctionne car je ne suis pas parvenu à inverser D+ et D- sur la carte originale. Après avoir mis un bootloader sur l'ATMEGA328P, je suis parvenu à téléverser des programmes à travers le FTDI en utilisant l'utilitaire avrdude. Le programme fait clignoter la LED à la bonne vitesse, cela signifie donc que le cristal 8MHz a été soudé correctement et que la carte fonctionne sans programmeur. Par la suite, je vais souder la carte SD et les connecteurs HE10 manquants.

Carte finale soudée

J'ai terminé de soudé la carte complète :

Programmation de la carte mère

Le but de cette partie est de réaliser un micro système de fichier. Pour cela, je dois implémenter les fonctions d'accès à la mémoire de la carte SD ainsi que les primitives qui permettront de manipuler les fichiers.

Ecriture et lecture sur la carte SD

Maintenant que la carte est terminée, il reste la partie accès mémoire pour ensuite écrire les fichiers du Pico ordinateur. J'ai rencontré des problèmes lors de l'écriture et lecture de la carte SD mais après avoir soudé à nouveau l'adaptateur de niveau et vérifié les tensions et les masses, je suis parvenu à écrire "0xac", "0xbc" et "0xcc" sur un bloc de la carte SD et récupérer ces informations pour les afficher sur le port série. Pour la suite du projet, je vais réutiliser ces fonctions de base d'accès à la carte SD pour écrire et lire les fichiers ainsi que les manipuler.

Sur minicom (port série), j'ai réussi à écrire sur un bloc mémoire de la carte SD puis lire ce bloc.

Fonctions d'accès à la mémoire

J'ai réalisé deux fonctions principales qui seront utilisées par les primitives du système de fichiers : writeBlock et readBlock

La fonction readBlock était la plus simple à implémenter, parmi les fichiers fournis dans le dossier de test de la carte SD, le fichier Sd2Card.c possède une fonction appelée readData qui correspond exactement à ce dont j'ai besoin pour écrire les primitives du système de fichiers cette fonction prend en paramètre:

• Un SD_info* (structure renvoyée par la fonction d'initialisation de la carte SD)
• Un numéro de bloc à lire
• Un offset (décalage en bits dans un bloc)
• Un string (tableau de char) qui contiendra les données lues dans le bloc
• La taille des données à lire

La fonction writeBlock est similaire et prend exactement les mêmes arguments mais je ne suis pas parvenu à avoir un offset fonctionnel.

• Un SD_info* (structure renvoyée par la fonction d'initialisation de la carte SD) - Un numéro de bloc (celui à modifier)
• Un offset (décalage en bits dans le bloc)
• Un string (tableau de char) qui contiendra les données à écrire dans le bloc
• La taille des données à écrire

problèmes rencontrés: Pour la fonction writeBlock, il n'y avait pas d'offset dans la fonction d'écriture de base dans Sd2Card.c, j'ai tenté de reproduire un offset avec des décalages mais cela fonctionne pas, je reçois des erreurs mémoires qui réinitialisent la carte. J'ai donc dû adapter la façon dont je stocke mes données en mémoire.

Organisation de la mémoire

J'organise la mémoire de la façon suivante:

Les 1024 premiers blocs de la carte SD sont réservés à la description des 64 fichiers du répertoire (superbloc), chaque fichier a une description de 16 blocs (16 x 64 = 1024). La description d'un fichier est la liste des numéros de blocs qui sont associés à ses données.

Les 16 blocs suivants sont réservés à la carte de disponibilité des blocs, chaque bloc fait 512 octets donc on a 16 x 512 x 8 = 65536 bits pour montrer la disponibilité d'un bloc. Chaque bit représente la disponibilité d'un bloc de donnée en mémoire (0 disponible / 1 pas disponible).

Les blocs restants sont les blocs de données qui commencent à partir du bloc 1040 et qui serviront à contenir les données des 64 fichiers.

Cependant, je ne peut pas utiliser d'offset cela limite considérablement l'efficacité de la gestion mémoire. Par exemple pour écrire le nom d'un fichier dans ses 16 blocs de description, je suis obligé d'utiliser un bloc entier (16 caractères donc 16 octets max) car je ne peux écrire que bloc par bloc. La description du fichier ne peut donc que contenir 15 blocs, soit 15 numéros de blocs de données, c'est à dire 15 x 512 = 7680 octets en théorie bien moins que si l'offset était présent. Par manque de temps je me suis contenté d'écrire que sur un bloc de donnée par fichier. Ce qui veut dire que la seule limitation est la taille des fichiers.

Primitives du système de fichiers

Les primitives système permettent de manipuler les fichiers du répertoire.

Je me suis inspiré du code ici: https://wiki-se.plil.fr/mediawiki/index.php/SE4_2022/2023_EC1

Le but est d'adapter le code en prenant en compte le fait que je ne peut pas utiliser d'offset à cause de writeBlock, que nous écrivons dans une carte SD au lieu d'un fichier et que les données lues ne proviennent pas de l'entrée standard mais du port série.

Voici les fonction que j'ai implémenté:

La fonction LS (list): pour lister les fichiers actuels dans le répertoire principal.

La fonction TYPE (append): pour créer un fichier si non existant et ajouter des données en fin de fichier, les paramètres sont le nom du fichier et les données à ajouter.

La fonction CAT (read): pour afficher le contenu d'un fichier, les paramètres sont le nom du fichier à lire.

La fonction MV (rename): pour renommer un fichier, les paramètres sont le nom du fichier à renommer et le nouveau nom.

La fonction CP (copy): pour copier un fichier et mettre ses données dans un nouveau fichier, les paramètres sont le nom du fichier copié et le nom du nouveau fichier.

La fonction RM (remove): pour effacer un fichier et ses données, les paramètres sont le nom du fichier à supprimer.

Démonstration

Afin d’interagir avec mon pico ordinateur, j'utilise minicom :

Commande pour ouvrir minicom :

minicom -b 9600 -D /dev/ttyUSB0

Au démarrage de l'ordinateur, on a l'interface suivante:

TYPE permet de créer un fichier avec des données s'il n'existe pas, sinon il ajoute les données en fin de fichier s'il existe déjà, CAT permet d'afficher un fichier existant:

démonstration de TYPE (append) et de CAT (read)

CP permet de copier les données d'un fichier et d'en créer une copie:

démonstration de CP (copy)

LS permet de lister les fichiers du répertoire:

RM permet de supprimer un fichier :

MV permet de renommer un fichier:

Ainsi le système de fichier est bien fonctionnel, les primitives de bases fonctionnent, mais la taille des fichiers est limitée.

Le programme principal se trouve dans un fichier appelé picofs.c et est disponible dans le gitlab du projet dans le dossier appelé "SD". Il suffit de faire un "make upload" pour téléverser le programme dans la carte et d'ouvrir minicom pour intéragir avec le système de fichier.

Primitives du bus SPI

Afin de pouvoir communiquer avec les cartes filles, la carte mère doit être capable de communiquer via le bus SPI.

lien gitlab du projet

https://gitlab.univ-lille.fr/dylan.ling.etu/projet_pico_ordi_b6.git