SE4Binome2024-7

Code Source et autre programmes

TESTS PRELIMINAIRES

Vérification des connecteurs HE-10

Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.

Lecture Carte SD

Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.

Fonctionnement des LEDs

Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.

ORDONNANCEUR

SQUELETTE BASIQUE DE L'ORDONNANCEUR

Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.

Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (diviseur), le mode de la minuterie (CTC1)) et la période (periode)).

Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes

des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).

Nous définissons donc en parallèle deux macros SAVE_REGISTERS() et RESTORE_REGISTERS() que nous appelons respectivement au début et à la fin de chaque interruption.

Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.

STRUCTURE DES TÂCHES

La structure des tâches est la suivante :

typedef struct Task {

   void (*fonction)(void);    // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien

   uint16_t SPointer;         // Pointeur de pile

   int state;                 // État de la tâche

   struct prog_data data;     // Données de la tâche

} Task;

struct prog_data {

   int Type;

   union {

       int delay;  // On peut ajouter d'autres types de données ici si nécessaire

   } data;

};

Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.

Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.

Finalement, nous ajoutons cette ligne :

currentTask = (currentTask + 1) % NB_TASKS;

dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.

CLIGNOTEMENT DES LEDs

Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, task_led1 et task_led2, dans ordonnanceur1.c à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction _delay_ms de la bibliothèque delay.h, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction delay, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.

FONCTION DELAY

Pour cette fonction delay, nous changeons l'état de la tâche à endormir en SLEEPING, puis assignons la valeur time donnée en paramètre au delay de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le delay soit le bon(la fonction delay s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le delay).

void delay(int time)

{

  TaskList[currentTask].state = SLEEPING;

  TaskList[currentTask].data.data.delay = time;

  TCNT1 = 0;

  TIMER1_COMPA_vect();

}

Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état SLEEPING.

*Si la currentTask est en mode SLEEPING:

**Si son delay est positif, nous soustrayons une durée elapsed_time fixe correspondant à une période d'éxecution au delay de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque elapsed_time est fixe et indépendant du timer TCNT1, il ne prend pas en compte le temps auquel s'est éxecuté le delay (le timer n'était pas à un multiple fixe de la période).

**Si son delay est négatif ou nul, nous restaurons l'état de tâche à ACTIVE.

Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est SLEEPING. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode ACTIVE, que l'on va alors éxecuter.

COMMUNICATION SERIE

Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans comm_serie.c. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions serie_recevoir et serie_envoyer ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.

Dans serie_envoyer, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur UDR0 correspondant au port série. Puis, la fonction donne la valeur 0 a is_data_received (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.

Dans serie_recevoir, nous attendons qu'une valeur soit écrite sur UDR0 puis assignons cette valeur à data, et passons is_data_received à 1, signifiant que nous avons reçu une data qu'il faut envoyer.

Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.

Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable is_data_received passe à 1 grâce à la fonction serie_recevoir. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction serie_envoyer. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.

COMMUNICATION SPI

Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans comm_spi.c.

Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.

Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction spi_init, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.

Nous avons des fonctions  spi_select et spi_deselect qui (dé)sélectionnent le pin slave sur lequel communiquer.

A chaque message ou commande spéciale à envoyer, nous devrons faire appel à spi_activer et spi_desactiver avant et après respectivement, pour (dés)activer le périphérique.

La fonction spi_echange envoie un octet sur le port SPI, correspondant à output qui est en paramètre.

Finalement nous avons spi_clearDisplay qui réinitialise l'affichage à l'aide de la commande 0x76, et spi_setLight qui configure la luminosité de l'afficheur.

Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de spi_échange, et désactiver le périphérique.

Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction sevenseg, disponible dans ordonnanceur1.c

Schéma, PCB & KiCAD

Shield

Photos et vidéos	description
	Le shield soudée avec juste le BootLoader dans le microP

Carte RNDIS

Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.

La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.

Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :

SCHEMATIQUE de la Carte RNDIS
Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet	Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA en réseau avec un ordinateur connecté à Internet

PINOUT

PIN UTILITY	PIN NAME
ChipSelect	PB0
CLK/SCK	PB1
MOSI	PB2
MISO	PB3
Pin d'Interruption	PB4
LED[1-4]	PC[0-3]

NOTES

deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45