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

Version du 16 février 2015 à 13:04

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.

Ci-dessous, se trouve une image montrant la définition d'un système sous QSys, qui sera ensuite généré et instancié en VHDL, puis implanté sur la carte.

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.

En fin de paragraphe, j'ai également joint le code du processeur Nios II en C qui a été réalisé pour cette partie.

D8 : Clk

D9 : Data

D11 : Slave Select

D12 : LDAC (entrée de mise à jour de la sortie du DAC)

Fichier:SignalBackup.txt

Fichier:CodeNiosSPIFonctionnel.txt

26 Janvier au 30 Janvier

Modifications importantes du cahier des charges

Après une réunion avec M. Anquez, le chef de projet, et M. Rodriguez, un de mes encadrants, le projet a pris un tournant légèrement différent. La solution du processeur Nios II est abandonnée car d'une part, les performances fréquentielles ne sont pas au rendez-vous (le timer servant d'horloge pour la communication avec le DAC ne dépasse pas 12.5 kHz). D'autre part, certains signaux, commandant des dispositifs du microscope, doivent être synchronisés entre eux à la micro-seconde. Un processeur éxécutant les instructions d'un programme séquentiellement, synchroniser à une échelle de temps si stricte l'envoi de plusieurs signaux sera impossible, d'autant plus avec le Nios II.

La solution retenue pour cette partie du travail est donc d'écrire en VHDL la partie communication avec les DACs. Vu les possibilités d'écrire plusieurs "process" en parallèle et de monter plus haut en fréquence, les objectifs seront atteignables. On peut noter que pour l'instant, l'aspect "contrôle de la SDRAM" est mis de côté et sera traité plus tard.

De plus, il faudra modifier légèrement le programme qui permet de choisir, à l'utilisateur, les signaux de commande. Dans un premier temps nous avons redéfini une version du programme qui offre le choix parmi les signaux suivants :

-trapézoïdal périodique (un temps bas t1, un temps de montée t2, un temps haut t3 et un temps de descente t4), qui peut être triangulaire si on choisit t3 nul

-carré/rectangulaire périodique (un temps bas t1, un temps bas t2)

-exponentiel périodique (de période t1).

Ajoutés à cela, il y aura évidemment toujours le choix d'une amplitude et d'une période pour chaque catégorie de signaux.

Réalisation hebdomadaire

Prenant en compte les dernières nouveautés, j'ai décidé de refaire la partie communication avec les DACs en VHDL. Après avoir écrit le code, j'ai définitivement constaté une nette amélioration des performances avec cette solution. J'arrive à synchroniser l'envoi de trames à 2 DACs très précisément et à une fréquence bien plus élevée qu'avec la solution du processeur NIOS II. Ci-dessous se trouvent respectivement :

- une image montrant les signaux SPI pour obtenir un signal carré sur le DAC

- une image à l'oscilloscope du résultat produit par l'envoi des précédents signaux

- une image à l'oscilloscope d'un signal en dents de scie croissantes à 10 points par période

- une image montrant les signaux SPI pour obtenir deux signaux carrés sur 2 DACs distincts, parfaitement synchronisés

- le code VHDL réalisant cela.

D8 : Clk

D9 : Data

D11 : Slave Select

D12 : LDAC (entrée de mise à jour de la sortie du DAC)

800px

800px

D3/D4 : LDAC (entrée de mise à jour de la sortie du DAC)

D8/D9 : Clk

D11/D12 : Data

D13/14 : Slave Select

Fichier:SPISynchroBackup.txt

2 Février au 6 Février

9 Février au 13 Février

16 Février au 20 Février