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

De Wiki de Projets IMA
(→‎Objectifs fixés)
(→‎Vidéo)
 
(39 révisions intermédiaires par le même utilisateur non affichées)
Ligne 24 : Ligne 24 :
  
 
=== 5 Janvier au 9 Janvier ===
 
=== 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 :
 +
 +
[[Fichier:Schéma.png]]
 +
 +
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
 +
 +
 +
[[Fichier:Nios2DF.png]]
 +
 +
 +
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.
 +
 +
[[Fichier:QsysExample.png]]
 +
 +
=== 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.
 +
 +
[[Fichier:DACCom.png]]
 +
 +
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.
 +
 +
[[Fichier:Scope_0.png]]
 +
 +
D8 : Clk 
 +
 +
D9 : Data 
 +
 +
D11 : Slave Select 
 +
 +
D12 : LDAC (entrée de mise à jour de la sortie du DAC)
 +
 +
[[Fichier:20150122_174017.jpg|800px|800px]]
 +
 +
[[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 à 60 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.
 +
 +
 +
[[Fichier:signalSPI.png]]
 +
 +
D8 : Clk
 +
 +
D9 : Data
 +
 +
D11 : Slave Select
 +
 +
D12 : LDAC (entrée de mise à jour de la sortie du DAC)
 +
 +
[[Fichier:20150219_103744.jpg|800px|800px]]
 +
 +
[[Fichier:20150219_111642.jpg|800px|800px]]
 +
 +
[[Fichier:signalSPIsynchro.png]]
 +
 +
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 ===
 +
 +
Ayant un programme permettant à un utilisateur de fabriquer des signaux de base et de transmettre le choix à la carte DE1 SoC, ainsi qu'un code VHDL permettant à la carte DE1 SoC de communiquer avec la carte d'évaluation du DAC pour produire des signaux, il ne restait plus qu'à développer le programme pour le processeur ARM qui doit réceptionner le choix de l'utilisateur via son UART et le transmettre au FPGA pour l'envoyer au DAC et produire le bon signal.
 +
 +
Grâce aux différents guides constructeur de la carte DE1 SoC, je suis parvenu assez rapidement à copier l'image d'un Linux bootable sur la carte micro SD ainsi qu'à faire booter la carte DE1 SoC dessus. L'interaction avec l'OS se fait via un terminal (de type Hyper Terminal) sur le PC relié à la carte par liaison micro USB. J'ai ensuite décidé d'implémenter le programme le plus simple en C : Hello World. La compilation se fait avec l'outil constructeur d'Altera "Embedded Command Shell".
 +
 +
Il faut ensuite transmettre l'éxécutable à la carte via la commande "scp" de l'"Embedded Command Shell". Pour ce faire, il a fallu que la carte DE1 SoC et le PC soient sur le même réseau. J'ai donc relié la carte au PC par une liaison Ethernet et configuré un pont entre ma carte réseau Ethernet et ma carte réseau Wifi pour que les deux soient sur le réseau local de ma Box. Après une assignation d'adresse IP à la main dans le fichier eth0/interfaces de la carte DE1 SoC, j'ai pu transférer avec succès l'éxécutable du PC à la carte et l'éxécuter avec succès pour voir "Hello World" effectivement s'afficher dans le terminal de communication.
 +
 +
L'étape suivante a donc constitué à développer le programme en C qui allait réceptionner les données depuis l'UART et les transmettre au FPGA pour obtenir le bon signal en sortie du DAC. Par conséquent, je me suis attelé à prendre en main l'UART grâce aux fonctions des libraires fournies par Altera. Après avoir écrit un programme simple pour initialiser l'UART et avoir compilé avec succès, je décide de tester. Malheureusement, Linux ne boote plus sur la carte et il est donc impossible de tenter quoi que ce soit.
 +
 +
Après quelques échanges avec le support, on me suggère d'implémenter quelques projets simples dans le FPGA pour voir si le problème serait de nature software ou hardware. Il s'avère que ce que j'ai développé en VHDL marche toujours donc le problème ne serait à priori pas physique. Après consertation avec mes encadrants / tuteurs, on a pensé qu'il pourrait s'agir du bootloader qui aurait été écrasé.
 +
 +
Ayant déjà perdu du temps à essayer de dépanner la carte, j'ai pris la décision d'avancer sur une autre partie du projet : à savoir la création d'une interface ergonomique pour l'utilisateur quand il choisit les signaux sur le PC. Le langage utilisé doit rester le C car le programme doit pouvoir être implémenté sur LabView dans le futur. Après une recherche de ce qui était possible en langage C, niveau programmation graphique, j'ai décidé d'utiliser l'API de Windows dont les librairies sont déjà inclues avec le compilateur.
 +
 +
J'ai passé le reste de la semaine à prendre en main cet API et à commencer le développement de l'interface utilisateur.
 +
 +
=== 9 Février au 13 Février ===
 +
 +
J'ai passé toute cette semaine à continuer à me familiariser avec l'API Windows pour programmer l'interface utilisateur. Après une semaine entière, j'ai créé une interface simple composée de 3 boutons pour choisir parmi les 3 types de signaux définis dans le CDC. Un 4ème sera ajouté pour les signaux personnalisables. Une fois que l'utilisateur est satisfait de son choix, il génère le signal. Dans le cas présent, je génère le signal dans un simple fichier texte. Il faudrait ensuite le transférer à la carte DE1 SoC. A noter également qu'il faut se mettre d'accord sur un formalisme pour la forme des données, pour que la carte DE1 SoC les interprète correctement après réception.
 +
 +
Ci-dessous, se trouve l'interface utilisateur développée, avec pour exemple la génération d'un signal carré/rectangulaire. L'utilisateur peut choisir le rapport cyclique grâce à un slider, ainsi que les amplitudes minimale et maximale et la période dans des zones de saisie de texte. J'ai également mis une image du fichier texte généré (et des commentaires pour légender les données) et le fichier source à la fin du paragraphe.
 +
 +
La librairie resource.h de ce dernier contient des constantes.
 +
 +
Une version console du programme de génération des signaux correspondant au CDC modifié se trouve en dernière pièce jointe.
 +
 +
 +
[[Fichier:UISquare.png|1000px|1000px]]
 +
 +
 +
[[Fichier:SquareGen.png|1000px|1000px]]
 +
 +
 +
[[Fichier:Hmi.txt]]
 +
 +
[[Fichier:SignalConsole.txt]]
 +
 +
=== 16 Février au 20 Février ===
 +
 +
A la suite de la réunion hebdomadaire le 13 Février, nous avons décidé que le reste du temps serait consacré à :
 +
 +
-l'écriture du rapport et la création du diaporama pour la soutenance
 +
 +
-le tournage d'une vidéo de démonstration au PhLAM
 +
 +
-une ou plusieurs journées avec M. Rodriguez pour un bilan de ce qui a été fait au niveau technique car il va reprendre le projet après mon départ.
 +
 +
 +
=== 23 Février au 26 Février ===
 +
 +
Semaine finale qui consiste à :
 +
 +
-remettre le rapport
 +
 +
-remettre la vidéo
 +
 +
-passer la soutenance
 +
 +
== Vidéo ==
 +
 +
[https://vid.me/FihO]
 +
 +
On notera que le laser commandé sur la deuxième démonstration est juste à gauche de l'oscilloscope.

Version actuelle datée du 24 février 2015 à 10:40

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.

Phlam microscope.jpg

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 :

Schéma.png

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


Nios2DF.png


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.

QsysExample.png

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.

DACCom.png

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.

Scope 0.png

D8 : Clk

D9 : Data

D11 : Slave Select

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

20150122 174017.jpg

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 à 60 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.


SignalSPI.png

D8 : Clk

D9 : Data

D11 : Slave Select

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

20150219 103744.jpg

20150219 111642.jpg

SignalSPIsynchro.png

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

Ayant un programme permettant à un utilisateur de fabriquer des signaux de base et de transmettre le choix à la carte DE1 SoC, ainsi qu'un code VHDL permettant à la carte DE1 SoC de communiquer avec la carte d'évaluation du DAC pour produire des signaux, il ne restait plus qu'à développer le programme pour le processeur ARM qui doit réceptionner le choix de l'utilisateur via son UART et le transmettre au FPGA pour l'envoyer au DAC et produire le bon signal.

Grâce aux différents guides constructeur de la carte DE1 SoC, je suis parvenu assez rapidement à copier l'image d'un Linux bootable sur la carte micro SD ainsi qu'à faire booter la carte DE1 SoC dessus. L'interaction avec l'OS se fait via un terminal (de type Hyper Terminal) sur le PC relié à la carte par liaison micro USB. J'ai ensuite décidé d'implémenter le programme le plus simple en C : Hello World. La compilation se fait avec l'outil constructeur d'Altera "Embedded Command Shell".

Il faut ensuite transmettre l'éxécutable à la carte via la commande "scp" de l'"Embedded Command Shell". Pour ce faire, il a fallu que la carte DE1 SoC et le PC soient sur le même réseau. J'ai donc relié la carte au PC par une liaison Ethernet et configuré un pont entre ma carte réseau Ethernet et ma carte réseau Wifi pour que les deux soient sur le réseau local de ma Box. Après une assignation d'adresse IP à la main dans le fichier eth0/interfaces de la carte DE1 SoC, j'ai pu transférer avec succès l'éxécutable du PC à la carte et l'éxécuter avec succès pour voir "Hello World" effectivement s'afficher dans le terminal de communication.

L'étape suivante a donc constitué à développer le programme en C qui allait réceptionner les données depuis l'UART et les transmettre au FPGA pour obtenir le bon signal en sortie du DAC. Par conséquent, je me suis attelé à prendre en main l'UART grâce aux fonctions des libraires fournies par Altera. Après avoir écrit un programme simple pour initialiser l'UART et avoir compilé avec succès, je décide de tester. Malheureusement, Linux ne boote plus sur la carte et il est donc impossible de tenter quoi que ce soit.

Après quelques échanges avec le support, on me suggère d'implémenter quelques projets simples dans le FPGA pour voir si le problème serait de nature software ou hardware. Il s'avère que ce que j'ai développé en VHDL marche toujours donc le problème ne serait à priori pas physique. Après consertation avec mes encadrants / tuteurs, on a pensé qu'il pourrait s'agir du bootloader qui aurait été écrasé.

Ayant déjà perdu du temps à essayer de dépanner la carte, j'ai pris la décision d'avancer sur une autre partie du projet : à savoir la création d'une interface ergonomique pour l'utilisateur quand il choisit les signaux sur le PC. Le langage utilisé doit rester le C car le programme doit pouvoir être implémenté sur LabView dans le futur. Après une recherche de ce qui était possible en langage C, niveau programmation graphique, j'ai décidé d'utiliser l'API de Windows dont les librairies sont déjà inclues avec le compilateur.

J'ai passé le reste de la semaine à prendre en main cet API et à commencer le développement de l'interface utilisateur.

9 Février au 13 Février

J'ai passé toute cette semaine à continuer à me familiariser avec l'API Windows pour programmer l'interface utilisateur. Après une semaine entière, j'ai créé une interface simple composée de 3 boutons pour choisir parmi les 3 types de signaux définis dans le CDC. Un 4ème sera ajouté pour les signaux personnalisables. Une fois que l'utilisateur est satisfait de son choix, il génère le signal. Dans le cas présent, je génère le signal dans un simple fichier texte. Il faudrait ensuite le transférer à la carte DE1 SoC. A noter également qu'il faut se mettre d'accord sur un formalisme pour la forme des données, pour que la carte DE1 SoC les interprète correctement après réception.

Ci-dessous, se trouve l'interface utilisateur développée, avec pour exemple la génération d'un signal carré/rectangulaire. L'utilisateur peut choisir le rapport cyclique grâce à un slider, ainsi que les amplitudes minimale et maximale et la période dans des zones de saisie de texte. J'ai également mis une image du fichier texte généré (et des commentaires pour légender les données) et le fichier source à la fin du paragraphe.

La librairie resource.h de ce dernier contient des constantes.

Une version console du programme de génération des signaux correspondant au CDC modifié se trouve en dernière pièce jointe.


UISquare.png


SquareGen.png


Fichier:Hmi.txt

Fichier:SignalConsole.txt

16 Février au 20 Février

A la suite de la réunion hebdomadaire le 13 Février, nous avons décidé que le reste du temps serait consacré à :

-l'écriture du rapport et la création du diaporama pour la soutenance

-le tournage d'une vidéo de démonstration au PhLAM

-une ou plusieurs journées avec M. Rodriguez pour un bilan de ce qui a été fait au niveau technique car il va reprendre le projet après mon départ.


23 Février au 26 Février

Semaine finale qui consiste à :

-remettre le rapport

-remettre la vidéo

-passer la soutenance

Vidéo

[1]

On notera que le laser commandé sur la deuxième démonstration est juste à gauche de l'oscilloscope.

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=P19_Contrôle_et_synchronisation_d%27instruments_en_microscopie&oldid=17687 »