P19 Contrôle et synchronisation d'instruments en microscopie : Différence entre versions

Version du 28 janvier 2015 à 20:34

Présentation du projet

Comme l'indique l'intitulé du projet, le travail consiste à contrôler un microscope, plus précisément les éléments qui le constituent grâce à des signaux (ou séquences) définis par l'utilisateur. Il faut bien évidemment synchroniser les différents éléments entre eux pour assurer un fonctionnement viable du microscope. En ce qui concerne les signaux de commande, ils seront des signaux simples ou des assemblages de ceux-ci à savoir : rampes, impulsions rectangulaires, exponentielles ...

Le microscope utilise une technologie appelée fluorescence par feuilles de lumière. Le principe est le suivant : un dispositif se charge de créer une nappe ou lame de lumière infiniment fine en théorie, qui réalise une section de l'échantillon qu'on souhaite imager. En déplaçant cette lame de lumière perpendiculairement à la lentille du microscope qui image l'échantillon, on peut tout simplement reconstituer une image en 3D de ce dernier. Ci-dessous se trouve une image qui illustre ce principe.

Objectifs fixés

Une carte DE1 SoC (de chez Terasic) a été mise à disposition. Cette carte contient un FPGA Cyclone V ainsi qu'un HPS (Hardware Processor System) ARM Cortex A9. Plusieurs interfaces reliées au HPS et au FPGA sont également disponibles sur cette carte telles que : switches, LEDs, IO expanders, port micro USB avec USB to UART, ports USB, lecteur de carte micro SD, ... Une carte d'évaluation du DAC (Digital to Analog Converter) AD5791 a également été mise à disposition.

Le but premier est de réaliser la chaine suivante, la plus simplifiée possible :

-un utilisateur choisit le signal de son choix parmi des motifs de base (pour commander un des dispositifs du microscope) sur le PC et ce choix est transmis à la carte DE1 SoC.

-La carte DE1 SoC récupère et interprète ce que veut l'utilisateur.

-elle communique avec le DAC pour que ce dernier reproduise, le plus fidèlement possible, le signal que l'utilisateur voulait.

Travail réalisé

5 Janvier au 9 Janvier

Cette première semaine a mis en route le projet après la réunion qui avait eu lieu avant les vacances de Noël avec les encadrants du projet. La première tâche a consisté à expliquer plus en profondeur la chaine décrite dans les objectifs fixés pour déterminer les rôles précis de chaque "maillon". On arrive au schéma de principe suivant :

On peut donc distinguer 3 parties à réaliser :

-un programme en C sur le PC hôte qui va récupérer le choix de l'utilisateur et envoyer les données sous un certain formalisme.

-un programme pour le HPS, qui tournera sous Linux, pour récupérer les données arrivant depuis le PC et vers l'UART (connecté au HPS).

-un programme pour le FPGA qui va ranger les données récupérées par le HPS dans la SDRAM (qui est connectée au FPGA) et les transmettre au DAC pour produire le bon signal.

Il faut noter qu'il y aura une interface à exploiter entre le FPGA et le HPS pour qu'ils puissent échanger des données.

J'ai réalisé durant cette première semaine également, le programme en C capable d'envoyer des données à l'UART de l'HPS via la liaison micro USB et le convertisseur UART to USB de la carte DE1 SoC. J'ai d'abord commencé à développer un programme en utilisant la librairie libusb pour m'approprier l'interface USB sur le PC et ensuite envoyer des données. La led Rx de l'UART clignotait bien après chaque envoi d'un caractère. En revanche, après quelques recherches, je me suis rendu compte que l'utilisation de la librairie libusb n'était pas possible car j'ai dû changer de driver et utiliser le ftdi ft232r, incompatible avec la librairie libusb. J'ai donc réécrit un programme en C utilisant la librairie windows.h. Celui-ci marche également : clignotement de la led Rx à chaque envoi de caractère. En bas de paragraphe, les deux programmes sont joints.

J'ai également installé sur mon PC les outils nécessaires pour développer sur la partie FPGA de la carte : Quartus avec plusieurs outils intégrés (tels que QSys et Eclipse). J'ai également commencé à me documenter sur Internet à propos de la marche à suivre pour programmer le FPGA et se servir des interfaces connectées autour de lui.

Fichier:Com.txt

Fichier:ComLibUsb.txt

12 Janvier au 16 Janvier

Durant cette semaine, j'ai donc entamé la partie FPGA et essayé de familiariser avec la carte, les différentes interfaces liées au FPGA ainsi qu'à la manière de procéder pour développer un système basé autour du FPGA. Plusieurs interfaces sont utilisées autour du FPGA, à savoir :

-la mémoire SDRAM

-E/S parallèles (PIO) telles que les GPIO headers, LEDs, switches, boutons...

-l'interface entre le HPS et le FPGA

-un timer

Après mes recherches de la premières semaines, j'ai pu voir que la manière la plus ergonomique et efficace de réaliser mon système était d'utiliser le processeur Nios II implantable dans mon FPGA et programmable en C. Il suffit tout d'abord de définir schématiquement le système à travers ses constituantes (déjà énumérées) dans l'outil QSys de Quartus. Un modèle VHDL est ensuite généré. On l'importe dans notre projet Quartus, instancie le système et l'implante sur la carte. On peut ensuite, dans l'outil Eclipse de Quartus, programmer le processeur en C et interagir avec les différentes interfaces. La figure ci-dessous résume la logique de développement

J'ai donc pu m'habituer à cette façon de faire et au terme de la semaine, j'ai réussi à mettre en oeuvre un système composé de la mémoire, de PIO et d'un timer. J'ai par ailleurs fait fonctionner les interruptions pour ces deux derniers éléments. Interagir avec ces 3 interfaces permettait d'ores et déjà de pouvoir mettre en oeuvre la communication avec le DAC pour générer des formes d'ondes.

19 Janvier au 23 Janvier

N'ayant toujours pas de carte micro SD, je n'ai pas pu commencer à travailler sur le HPS et la récupération des données issues de PC et leur aiguillage vers la SDRAM du FPGA. J'ai donc décidé de commencer à compléter la partie en C sur le PC hôte pour permettre à l'utilisateur de constituer des signaux de base. Le but est de choisir entre :

-un triangle

-un signal carré de rapport cyclique 1/2

-une exponentielle où l'utilisateur saisit des points et les points restants sont calculés par interpolation lagrangienne

-des dents de scie (montantes ou descendantes).

Hormis l'exponentielle entièrement personnalisable par l'utilisateur, les autres signaux varient entre 0 et A (constante symbolisant l'amplitude max du DAC). Le programme se charge à partir du choix de l'utilisateur de calculer un certain nombre de points par période, période que l'utilisateur a également choisie. Ce nombre de points est, tout comme l'amplitude maximale A, une constante paramétrable. Ces points sont ensuite mis à l'échelle pour varier entre 0 et 2^20 - 1, qui est le plage de variation du mot d'entrée du DAC.

Il reste maintenant à déterminer un formalisme précis pour l'envoi des données, qui sera nécessaire pour savoir comment les interpréter du côté du FPGA. On pourra aussi améliorer ou ajouter de nouvelles fonctionnalités au programme, après consertation avec M. Anquez le chef de projet, pour répondre au mieux au besoin de l'utilisateur.

Le code source se trouve en fin de paragraphe.

Après avoir fait cela, je me suis attelé à piloter le DAC avec le FPGA. Le protocole utilisé pour la communication est le protocole SPI. Le but était donc d'envoyer sur les pins d'un des GPIO Headers, les bons signaux pour que la carte produise la bonne tension suivant le mot qu'on a envoyé. Ci-dessous se trouvent, des chronogrammes décrivant comment communiquer avec le DAC. Les temps annotés (ti) sont disponibles dans la datasheet.

Après 3 jours d'essais, je suis parvenu à communiquer avec le DAC et à reproduire un signal carré. Ci-dessous se trouvent deux images :

-la première montre un exemple de communication avec le DAC.

-la seconde, un signal carré en sortie du DAC.

D8 : Clk D9 : Data D11 : Slave Select D12 : LDAC (entrée de mise à jour de la sortie du DAC)

Fichier:SignalBackup.txt

26 Janvier au 30 Janvier