Compte rendu informatique industriel

TP 3 : Périphériques E/S & Bus

Dans ce TP, nous avons pour objectif d’interfacer la carte FPGA DE1 à la carte d’extension sur laquelle sont implantés les convertisseurs CAN et CNA à l’aide du port d’extension GPIO_1.

Dans un premier temps, nous devons apprendre à utiliser le CAN et le CNA. A partir des données fournies sur ces 2 convertisseurs (chronogramme et datasheet), nous avons mis en place l’automate de contrôle rebouclant les 2 modules. Ici, on convertit le code donné par les switches (SW) à l’aide du CNA puis on reconvertit cette valeur à l’aide du CAN afin de l’envoyer sur les LEDs (LEDG).

[pic 1]

On peut remarquer dans cet automate la présence d’un compteur, en effet il est parfois nécessaire d’attendre plusieurs coups d’horloge afin de réaliser les conversions de manière optimale et selon les contraintes imposées par le chronogramme suivant.

[pic 2]

Nous allons ensuite interfacer ces 2 convertisseurs au microprocesseur NIOS-II grâce au bus AVALON. On utilise pour cela l’outil QSYS d’ALTERA. On utilise un port I/O configuré à l’adresse 0x20000080. On veillera par ailleurs à utiliser des registres à la place des SW et LEDG (annexe A).

On utilisera les périphériques suivants notamment :

Chaque adresse est le résultat d’une adresse de base assignée automatiquement par QSYS à laquelle la méthode Bit-31 Cache Bypass a été utilisée. Cette méthode consiste en l’ajout d’un bit de poids fort (0x80000000) afin de « by-pass » le cache de données qui n’est pas nécessaire dans le cas de ce TP.

De plus, les types C de ces variables sont volatiles car ce sont des périphériques extérieurs au programme (matériel) et peuvent donc être modifiés par un moyen extérieur.

Lors de la vérification du bon fonctionnement de nos conversions sur la carte d’extension n°4 (EXT 04), nous avons remarqué une erreur de conversion analogique numérique. Par exemple, lorsque nous avons un 0000 0100 en entrée, nous avons 0000 0011 en sortie. Pour chaque valeur, il y a une différence d'un bit de poids faible entre la sortie et l'entrée. Nous en avons déduit que cela était dû à l'accumulation des erreurs d’approximations lors des conversions. Nous avons donc tracé la courbe de tendance résultant de cet interfaçage (annexe B).

TP 4 : Interfaces séries

Lors de TP4, nous nous intéressons aux communications séries de type RS232 et I2C. La carte d'extension possède un écran graphique DIABLO 16 qui communique en série RS232/TTL, ainsi qu'un capteur de température qui lui est interfacé par un bus I2C.

Ecran graphique DIABLO16 :

On souhaite utiliser et piloter cet écran graphique afin d'être en mesure d'effectuer des affichages sur ce dernier.

La première étape consiste à interfacer l'écran au processeur NIOS II. Par l'intermédiaire de l'outil QSYS, on ajoute un composant de type RS 232 UART afin de réaliser la liaison entre le processeur et l'écran. Lors de l'implémentation de ce composant, il est nécessaire de respecter certaines contraintes comme la vitesse de transmission du composant. Dans la datasheet de l'écran graphique, il est indiqué que celui-ci fonctionne avec une vitesse de transmission de 9600 Bauds. Si celle du composant implémentée est différente, il sera impossible de d'échanger avec l'écran. Il faut également lui assigner une adresse.

Ensuite, on ajoute les composants et assignations matériels nécessaires en VHDL dans le design Quartus pour que le nouveau composant soit fonctionnel (annexe C). D'après la datasheet et le schéma fonctionnel de la carte DE1, le signal ecran_TXD est connecté au port 1 de la broche GPIO1 et le signal ecran_RXD au port 2.

Deuxièmement, nous écrivons une fonction en C simple, clear_screen(), permettant d'effacer ce qui est affiché à l'écran. Pour cela, on se réfère à la datasheet de l'écran pour savoir quelle est la commande à envoyer à l'écran (annexe D). Lors de l'appel de cette fonction, l'affichage initial d'allumage de l'écran est correctement effacé.

Il est important de préciser que les commandes à envoyer sont codées sur 16 bits et que pour chaque envoi la commande est scindée en deux octets envoyés successivement. Cela provient du fait que le registre UART_REG0 est un char, donc codé sur 8 bits, d'où l'envoi successif de deux octets pour une commande.

On veut ensuite réaliser une fonction qui affiche des cercles et prenant en paramètres les coordonnées du centre du cercle, son rayon et sa couleur.

Encore une fois, on fait appel à la datasheet de l'écran pour savoir quelle est la commande correspondante à l'affichage de cercles pleins sur l'écran. Ici, c'est 0xFF77 (annexe E).

On utilise un tableau statique pour faire les liens entre les paramètres de la fonction passés par copie afin de les garder et de les envoyer au registre UART-REG0.

Encore une fois, on scinde les paramètres à envoyer par octets pour s'adapter au type du registre UART_REG0.

Les constantes MAXX et MAXY correspondent aux dimensions de l'écran. Les coordonnées modulo les dimensions de l'écran permettent d'éviter les débordements.

Enfin, pour afficher un cercle rouge de rayon 50 et de coordonnées (150,150), on fait appel à notre fonction avec respectivement les paramètres suivants : 150, 150, 50, 0xF800 (couleur rouge). Un cercle rouge plein conforme aux paramètres apparaît alors sur l'écran.

...