IMG - Bienvenue sur Catalogue des mémoires de projets de fin d

Mémoire de Projet de Fin d'Etudes
Sujet : Réalisation d’une interface Ethernet sur FPGA pour une
centrale d’acquisition basses températures rapide
Auteur : Fabien AUBERT
INSA de Strasbourg, Spécialité Génie Electrique
Tuteur entreprise : Daniel COMMUNAL
Tuteur INSA Strasbourg : Bertrand BOYER
Du 01/03/2011 au 29/07/2011
CEA GRENOBLE
17, rue des Martyrs
38054 Grenoble Cedex 9
REMERCIEMENTS
Avant de commencer ce rapport, je souhaite remercier Alain GIRARD, chef du SBT, de
m’avoir permis d’effectuer ce projet de fin d’études au Service des Basses Températures du
CEA Grenoble pendant cinq mois.
Je tiens à adresser mes plus vifs remerciements à mon maître de stage Daniel COMMUNAL,
pour m’avoir proposé un sujet aussi riche qu’intéressant, pour sa très grande disponibilité
ainsi que ses nombreux conseils.
Je remercie Patrick BONNAY, chef du groupe GEA, de s’être intéressé à mon travail et aux
problèmes auxquels j’étais confronté.
Je souhaite remercier :
- Christophe MARIETTE, pour ses conseils et remarques pertinentes.
- Anthony ATTARD et Guillaume FEGE, pour leur aide et explications sur la version actuelle
de la Centrale d'Acquisition ainsi que sur l'utilisation des logiciels Xilinx.
- Thierry JOURDAN, pour son aide et ses conseils sur tout ce qui touche au logiciel.
- Michèle MOUCOT, secrétaire du SBT, pour son implication dans toutes les démarches
administratives.
Je voulais également remercier l’ensemble du groupe GEA au sein duquel il règne une très
bonne ambiance.
Merci à Bertrand BOYER, tuteur enseignant de l'INSA, pour avoir suivi l’évolution de mon
projet de fin d’études.
Enfin, je remercie toutes les personnes qui se sont impliquées de près ou de loin dans le
déroulement de mon stage.
PFE / Génie Electrique / Fabien AUBERT
2
INTRODUCTION
J’ai effectué mon Projet de fin d’études au « Commissariat à l’Energie Atomique et aux
énergies alternatives » (CEA) de Grenoble dans le Groupe Electronique et Automatique
(GEA). Ce groupe figure au sein du Service des Basses Température (SBT) faisant partie de
l’Institut Nanoscience et Cryogénie (INAC).
Le Service des Basses Températures développe et utilise de l'instrumentation
spécifiquement adaptée à la cryogénie. Un projet de centrale d'acquisition pour les basses
températures (1 K à 300 K) est en cours de réalisation, une première partie concernant
l'acquisition et le traitement des mesures a été mise au point sur la base d'un composant
FPGA. Nous souhaitons maintenant intégrer la partie post-traitement et stockage des
données ainsi que la communication via le protocole Ethernet MODBUS TCP sur ce même
composant FPGA. Le but du stage est d'une part de synthétiser les composants réseau
nécessaires et d'autre part de développer le logiciel applicatif associé pour le processeur
embarqué dans ce FPGA.
La carte électronique de la centrale comporte 8 voies de mesure adaptées uniquement aux
capteurs à résistance. Le principe est de mesurer des tensions et des courants pour obtenir
une valeur de résistance qui est ensuite convertie en température. Dans l'état actuel des
choses, une carte processeur est couplée à plusieurs cartes de mesure. Elle se charge du
post-traitement des données, de leur stockage et de leur transfert via Ethernet.
Le but de mon stage est de développer une version mono-carte de ce système (8 voies
seulement). Cette autre version, dite « stand-alone » (autonome) est en quelque sorte une
version « allégée » qui comportera moins de capacités de traitement mais sera autonome et
moins chère. Elle vise à se passer de la carte réalisant le post-traitement des données et
l’interface Ethernet et de tout intégrer sur une seule et même carte, en se servant des
ressources non utilisées dans le FPGA. L’objectif est donc d'un côté, de récupérer les
mesures, les traiter (calculer les valeurs de résistance puis les convertir en température), les
stocker et d'un autre côté de les rendre disponibles sur le réseau via Ethernet. Un autre
aspect de mon projet est de répondre à certaines requêtes, permettre de modifier (à
distance) des paramètres du système sans avoir à reprogrammer le FPGA, transférer des
fichiers via TFTP, etc. Cet autre aspect n’était, à l’origine, pas prévu dans le sujet de mon
stage mais vu l’avancement, cette partie a aussi été traitée.
Mon travail consiste donc à réaliser une application comportant plusieurs tâches qui doivent
respecter des contraintes de temps réel (en particulier la tâche d’acquisition des mesures).
Dans ce rapport de nombreux termes techniques et acronymes sont utilisés dont une
définition est donnée dans le lexique, à la fin du mémoire.
PFE / Génie Electrique / Fabien AUBERT
3
RESUME
Réalisation d'une interface Ethernet sur FPGA pour une centrale
d'acquisition basses températures rapide
Le Service des Basses Températures du CEA de Grenoble développe et utilise de
l'instrumentation spécifiquement adaptée à la cryogénie. Un projet de centrale d'acquisition
pour les basses températures (1 K à 300 K) est en cours de réalisation, une première partie
concernant l'acquisition et le traitement des mesures a été mis au point sur la base d'un
composant FPGA.
L'objectif est maintenant d'intégrer la partie post-traitement et stockage des données ainsi
que la communication via le protocole Ethernet MODBUS/TCP/IP sur ce même composant
FPGA.
Le projet consiste d'une part à synthétiser les composants nécessaires et d'autre part à
développer le logiciel applicatif associé, pour le processeur embarqué dans ce FPGA. Il faut
pour cela réaliser une application comportant plusieurs tâches qui doivent respecter des
contraintes de temps réel (en particulier la tâche d’acquisition des mesures).
Development of an Ethernet interface on a FPGA for a fast low
temperatures data logger
Service of Low Temperatures of the CEA Grenoble develops and uses instrumentation
specifically tailored to cryogenics. A data logger for low temperatures (1 K to 300 K) is in
progress, a first part concerning the acquisition and processing steps has been developed
based on an FPGA.
The goal is now to integrate the part of the project concerning post-processing and data
storage as well as communication via the Ethernet protocol Modbus / TCP / IP on the same
FPGA.
The project consists in synthesizing the necessary components and developing the
application associated software, for the embedded processor in the FPGA. This requires an
application with multiple tasks that must meet real time constraints (especially the acquiring
measurements task).
PFE / Génie Electrique / Fabien AUBERT
4
SOMMAIRE
REMERCIEMENTS ....................................................................................................................... 2
INTRODUCTION .......................................................................................................................... 3
RESUME ...................................................................................................................................... 4
1
2
Présentation de l’entreprise .............................................................................................. 7
1.1
Historique .................................................................................................................... 7
1.2
Chiffres (2010) et activité ............................................................................................ 7
1.3
Le CEA de Grenoble ..................................................................................................... 8
1.4
Le service des basses températures (SBT) ................................................................... 9
Introduction du sujet ........................................................................................................ 11
2.1
2.1.1
Contexte ............................................................................................................. 11
2.1.2
Principales spécifications de la CABTR ............................................................... 12
2.1.3
Fonctionnement et problématique .................................................................... 13
2.2
4
Principe de fonctionnement général ......................................................................... 15
2.2.1
Acquisition et mise en forme des signaux.......................................................... 15
2.2.2
Conversion des mesures de tension et courant ................................................. 16
2.2.3
Stockage et transfert des données .................................................................... 17
2.3
3
La centrale d’acquisition de température ................................................................. 11
Protocoles de communication ................................................................................... 17
2.3.1
TCP/IP et OSI....................................................................................................... 17
2.3.2
Le protocole Modbus TCP .................................................................................. 19
Développement de la partie matérielle ........................................................................... 21
3.1
Réalisation d’une carte d’interface Ethernet pour le prototype ............................... 21
3.2
Environnement de travail .......................................................................................... 24
3.3
Mise en place d’un système multitâches temps réel ................................................ 25
3.3.1
Ordonnancement des tâches ............................................................................. 25
3.3.2
Accès aux données ............................................................................................. 26
Développement de la partie logicielle ............................................................................. 28
4.1
Architecture du système............................................................................................ 28
4.2
Initialisation ............................................................................................................... 30
PFE / Génie Electrique / Fabien AUBERT
5
4.2.1
Initialisation du système de fichier .................................................................... 30
4.2.2
Initialisation des coefficients de calibrage (ou calibration) ............................... 32
4.2.3
Initialisation des coefficients de linéarisation .................................................... 32
4.2.4
Démarrage du noyau .......................................................................................... 33
4.3
4.3.1
Implémentation de la couche TCP ..................................................................... 34
4.3.2
Serveur Modbus TCP .......................................................................................... 35
4.3.3
Serveur web, serveur TFTP, echo server ............................................................ 40
4.4
Traitement et stockage des acquisitions ................................................................... 40
4.4.1
Calcul de résistance et de température ............................................................. 40
4.4.2
Archivage des mesures....................................................................................... 42
4.4.3
Visibilité des mesures depuis l’extérieur ........................................................... 43
4.5
5
Communication réseau.............................................................................................. 34
Ordonnancement des tâches .................................................................................... 44
Portage sur la carte prototype CABTR ............................................................................. 45
5.1
Problèmes liés à l’utilisation d’une mémoire de type SDR SDRAM .......................... 45
5.2
Intégration de la récupération des mesures ............................................................. 47
5.3
Evolutions .................................................................................................................. 48
CONCLUSION ............................................................................................................................ 49
LEXIQUE .................................................................................................................................... 50
BIBLIOGRAPHIE ......................................................................................................................... 52
PFE / Génie Electrique / Fabien AUBERT
6
1 Présentation de l’entreprise
1.1 Historique
C’est en 1945 que le Général De Gaulle décide de créer le CEA afin de poursuivre la
recherche nucléaire et plus particulièrement des « recherches scientifiques et techniques en
vue de l’utilisation de l’énergie nucléaire dans le domaine de la sciences, de l’industrie et de
la défense nationale ». (Article premier du décret du 18 octobre 1945).
En 1956, les premiers Kilos Watt heure d’origine nucléaire sont produits sur le centre de
Marcoule.
Au fil du temps, le CEA a su se diversifier dans d’autres domaines tels que les
nanotechnologies ou l’électronique. Le CEA porte depuis mars 2010 le nom de Commissariat
à l’Energie Atomique et aux énergies alternatives.
Aujourd’hui, il est un acteur majeur en matière de recherche, de développement, et
d’innovation. Il intervient dans quatre grands domaines : les énergies bas carbone, les
technologies pour l’information et les technologies pour la santé, les Très Grandes
Infrastructures de Recherche (TGIR), la défense et la sécurité globale.
Le CEA est un établissement public industriel et commercial (EPIC).
1.2 Chiffres (2010) et activité
Le CEA est implanté sur 10 centres répartis dans toute la France. Il développe de nombreux
partenariats avec les autres organismes de recherche, les collectivités locales et les
universités.
Le CEA dispose d’un budget de 4,2 milliards d’euros dont 60% est destiné aux programmes
civils contre 40% pour les programmes de défense. 15989 salariés se répartissent sur les 10
centres de recherche. Plus de 600 dépôts de brevets prioritaires déposés dans l’année et 130
entreprises créées depuis 1984.
Le CEA se divise en 4 pôles fonctionnels et en 4 pôles opérationnels qui sont :
- Le pôle Energie. Le CEA cherche à optimiser le parc actuel des réacteurs nucléaires et
à mettre au point des solutions pour le traitement des déchets radioactifs. Il participe aussi
au développement des énergies nucléaires du futur tel que le projet ITER (International
Thermonuclear Experimental Reactor), plus sûres, plus économiques et générant moins de
déchets.
- Le pôle Défense. Il vise à garantir la pérennité de la dissuasion nucléaire et la
sécurité. Il met en œuvre des programmes de simulation (laser mégajoule) afin de palier à
l’arrêt des essais nucléaires.
PFE / Génie Electrique / Fabien AUBERT
7
Il est aussi responsable de la conception et de la maintenance des réacteurs de propulsion
nucléaire (sous marins, porte-avions).
- Le pôle Recherche Technologique. Destiné à valoriser l’innovation industrielle, le CEA
exerce ses compétences dans le domaine des technologies logicielles telles que les systèmes
embarqués et interactifs, les capteurs et le traitement du signal.
Il est aussi un acteur de la recherche médicale grâce à ses compétences autour des
biotechnologies et des technologies nucléaires pour la santé (marquage biomoléculaire,
imagerie médicale…).
- Le pôle Recherche. Ce pôle contribue à l’ensemble du CEA de part ses activités en
recherche fondamentale reconnue pour son excellence. Les principaux domaines sont la
fusion thermonucléaire, l’étude du climat et de l’environnement, la connaissance de la
matière et du vivant.
1.3 Le CEA de Grenoble
Le CEA de Grenoble a été fondé en 1956 sous le nom de Centre d’Etudes Nucléaires de
Grenoble (CENG) par le professeur Louis Néel, prix Nobel de physique.
Bien qu’initialement destiné à la recherche nucléaire, en 1965 y est créé le premier circuit
intégré français, composé de 10 transistors. C’est deux ans plus tard que le Laboratoire
d’Electronique et de Technologie de l’Information (LETI) est créé, détenteur du record en
1999 du plus petit transistor (20nm).
Depuis janvier 2001, ce centre s'est engagé dans un plan d'assainissement
démantèlement de ses installations
nucléaires (projet « passage »). Le
dernier démantèlement étant prévu pour
2012.
et de
Le CEA Grenoble est le premier centre de
recherche technologique en RhôneAlpes. 4200 personnes travaillent sur le
site dont 2300 salariés CEA, 225 brevets
sont déposés par an.
Le CEA de Grenoble est ainsi à l’origine
des accéléromètres de nos airbags, du
Figure 1 - Vue aérienne du CEA Grenoble
SOI (Silicon On Insulator) améliorant les
performances des puces, de nombreux brevets pour les écrans plats…
Aujourd’hui, la recherche technologique représente 80% de l’activité du centre.
PFE / Génie Electrique / Fabien AUBERT
8
Le pôle de Recherche Fondamentale dépendant de la direction des sciences de la matière
mène toutefois une activité très riche.
En effet, l’Institut Nanoscience et Cryogénie (INAC) est présent dans :
- les cryotechnologies (cryogénie spatiale, fusion par confinement inertiel et
magnétique, instrumentations et automatisme…),
- le développement de connaissances fondamentales (chimie moléculaire,
magnétisme, supraconductivité…),
- la physique et chimie pour l’électronique organique (électronique plastique, projet
Chimtronique),
- la physique et chimie pour les technologies de la santé.
- la physique et chimie pour les technologies de l’énergie.
1.4 Le service des basses températures (SBT)
C’est dans ce service que j’ai eu la chance d’effectuer mon stage.
Le SBT a été crée en 1957 sous l’influence du professeur Weil, pionnier des basses
températures en France. Il est composé actuellement d’environ cinquante personnes.
Le SBT est rattaché à L’Institut des NAnosciences et de la Cryogénie (INAC), lui-même
dépendant de la Direction des Sciences de la Matière (DSM). De nos jours, le domaine de
compétence du SBT est la cryotechnologie allant d’une température de quelques dizaines de
milli Kelvin à 120 K (-153,15 °C). Cette limite représente la température limite à partir de
laquelle les gaz de l'air se liquéfient.
L’activité du SBT se concentre aujourd’hui autour de 3 axes de recherches :
-
-
Développement de composants et études thermohydrauliques nécessaires à la mise
en œuvre de l’hélium superfluide ou super critique pour le refroidissement des
grands aimants supra conducteur (LHC, ITER, JT60).
Cryogénie pour la production de cibles, propulsion de glaçons D2 et pompage
cryogénique pour la fusion nucléaire.
Développement de la réfrigération autonome (réfrigérateurs à 4K, tubes à gaz pulsé,
adsorption 3He) pour applications sol et spatiales
Il mène des activités de Recherche et Développement en cryogénie pour les grands projets
du CEA et de grands projets européens et mondiaux dont le CEA est partenaire. Les travaux
vont de l’étude système (en cours avec ITER par exemple) jusqu’à la fourniture de
cryoréfrigérateurs pour le spatial en passant par l’étude et la validation de solutions
techniques pour les cibles cryogéniques du laser Mégajoule.
PFE / Génie Electrique / Fabien AUBERT
9
Le SBT a par exemple mis au point une solution de moins de 5kg permettant de produire en
continu 1μW de puissance de refroidissement à 50mK en environnement spatial. Il a ainsi pu
remporter un appel d’offre de l’Agence Spatiale Européenne pour équiper le futur satellite
d’observation SPICA qui opérera dans l’infrarouge.
Le SBT mène aussi une des expériences sur la station OLGA (Oxygen Low Gravity Apparatus)
visant à étudier le réchauffement de l’oxygène liquide en apesanteur.
La mise en œuvre de l’hélium superfluide sur des installations de grande taille permet au SBT
de participer à de grands projets tels que les réfrigérateurs 1,8K du LHC ou le design du
réacteur de fusion par confinement magnétique ITER à Cadarache.
Ce service se décompose en en six groupes (3 groupes thématiques et 3 groupes
fonctionnels) :
Groupes thématiques :
•
Cryoréfrigérateurs et Cryogénie Spatiale (GCCS)
•
Réfrigération THermohydraulique (GRTH)
•
Cryogénie Fusion (GCF)
Groupes fonctionnels :
•
Liquéfaction Réfrigération et Caractérisation (GLRC)
•
Electronique Automatique (GEA)
•
Calculs et Conception Cryogéniques (G3C)
J’ai été rattaché au groupe Electronique Automatique. Ce groupe est responsable de
l’automatisme, de l’instrumentation et de l’électronique associé à la cryogénie. Il a ainsi
développé des pressostats, des centrales d’acquisition de températures, des modules de
commandes de chauffage, des automates de processus cryogénique…
PFE / Génie Electrique / Fabien AUBERT
10
2 Introduction du sujet
2.1 La centrale d’acquisition de température
2.1.1 Contexte
La mesure de température en cryogénie est un élément des plus importants et des plus
complexes. L’instrumentation est réellement spécifique. Il faut en effet transmettre une
puissance minimale au capteur afin de ne pas perturber la mesure. Dans le cas contraire,
l’effet joule viendrait à la fois réchauffer le capteur et la température ambiante du milieu.
Le GEA a donc développé une Centrale d’Acquisition Basse Température pour Réseau Fip
(CABTF) qu’elle utilise depuis 1993 (Figure 2).
Figure 2 - Centrale d'Acquisition Basse Température pour Réseau Fip (CABTF)
Cette centrale utilise des capteurs résistifs. Elle dispose de 8 voies (extensible à 16 par
boitier), d'une bande passante de 1,4Hz et d'une résolution de quelques milli Kelvin à la
température de 4,2 K (température de liquéfaction de l’hélium).
Toutefois, de nos jours, il devient parfois nécessaire d’observer des
phénomènes thermiques transitoires rapides ce que ne permet pas la
CABTF.
Un des projets du SBT consiste à améliorer la sécurité et la fiabilité des
cryostats. Lorsque le vide d’isolement d’un cryostat, contenant un
réservoir d’hélium, est rompu de manière accidentelle, la pression du
réservoir augmente. Si l’organe de sécurité, tel que soupape ou disque
de rupture associé est sous dimensionné, la pression du réservoir va
continuer à croitre jusqu’à provoquer son explosion. Il est donc
nécessaire de quantifier le flux de chaleur déposé aux parois du
réservoir. La pression, suite à une telle rupture, va croitre de 1 bar à 14
bars en 3,5 secondes, la température variant dans le même temps de
quelques Kelvins à plusieurs centaines (Figure 3).
PFE / Génie Electrique / Fabien AUBERT
Figure 3 - Test de
comportement d'un
rupture de vide
d'isolement
11
D’autres applications nécessitent des instruments permettant d’étudier des oscillations de
température à une fréquence de quelques dizaines de hertz (tubes à gaz pulsés). La CABTF
ne le permet pas.
C’est grâce à l’apparition de nouveaux capteurs résistifs (Cernox) avec des temps de réponse
de 1,5 ms à 4,2 K, des plages de température de 100 mK à 420 K qu’il est concevable de
mettre au point des centrales d’acquisition de basses températures avec une bande
passante plus élevée que la CABTF.
2.1.2 Principales spécifications de la CABTR
Afin de répondre aux nouveaux besoins du SBT, le GEA a décidé de développer une nouvelle
Centrale d’Acquisition de Basses Températures Rapide (CABTR). L’objectif étant toujours de
fournir le signal d’excitation le plus faible sur le capteur résistif tout en augmentant la bande
passante.
Le cahier des charges indique une dynamique de mesure de 0 à 100kΩ, une bande passante
de 100Hz, une fréquence d’échantillonnage de 1kHz.
Deux modes de récupération des données seront disponibles :
- Un mode « lent » qui permet de récupérer les échantillons à une fréquence de
100Hz. Pour cela, la bande passante des signaux est limitée à 10Hz.
- Un mode « rapide » qui permet quant à lui d’échantillonner à 1kHz. La bande
passante des signaux est alors limitée à 100Hz.
Contrairement au modèle précédent, le signal d’excitation est de forme sinusoïdale et
d’amplitude maximale 7mV. Afin de palier au mieux aux problèmes de bruit et à la
composante 50Hz du secteur, il a été décidé de faire de la modulation/démodulation
synchrone.
Jusqu’à une fréquence de modulation d’environ 500Hz, l’influence des capacités parasites de
liaison au niveau du capteur reste négligeable. C’est la fréquence limite retenue par le cahier
des charges.
Pour des raisons économiques, le cahier des charges impose de traiter 8 voies de mesure
simultanément. Il est nécessaire d’avoir une capacité de calcul importante.
La partie traitement du signal (modulation, démodulation numérique) est effectuée grâce à
un FPGA.
PFE / Génie Electrique / Fabien AUBERT
12
Fréquence
d’échantillonnage
Bande passante
Nombre de voies
Excitation
Gamme de résistance
CABTF
CABTR
6.2Hz
1kHz
1.4Hz
8 à 16
Continue
0-40kΩ
100Hz
8 à 16
Sinus 512Hz/128Hz
0-100kΩ
2.1.3 Fonctionnement et problématique
La version actuelle de la CABTR peut se décomposer en trois grands blocs (Figure 4). Le
premier, assure le conditionnement du courant et de la tension. Il transmet ces données à
l’aide d’un convertisseur analogique numérique (CAN) au second bloc purement numérique
composé d’un FPGA. Une fois la valeur de la résistance déterminée, elle est transmise au
troisième bloc appelé « module unité centrale ». Ce bloc se charge du post traitement des
données, de leur stockage (en mode « rapide ») et les rend accessibles sur le réseau.
CARTE D’ACQUISITION
SPI entrant
CARTE
PROCESSEUR
Traitement
numérique
FPGA
Bloc analogique
SPI sortant
CARTE D’ACQUISITION
Bus //
Module unité
centrale (MUC)
SPI entrant
Traitement
numérique
FPGA
Bloc analogique
Réseau
SPI sortant
Figure 4 - Schéma de fonctionnement de la version actuelle de la CABTR
Cette version offre la possibilité de connecter deux cartes d’acquisition et donc d’avoir 16
voies de mesures. Le module unité centrale est réalisé à l’aide d’une carte processeur
vendue par l’entreprise MII (Modèle « UC06 » à base d’un processeur ARM9 fonctionnant à
une fréquence de 200Mhz).
PFE / Génie Electrique / Fabien AUBERT
13
La version à développer sera allégée mais autonome dans le sens où elle offrira moins de
capacités de traitement/stockage mais tous les composants nécessaires au fonctionnement
se trouveront sur une seule et même carte. Cette version ne possèdera que 8 voies de
mesures. L’espace de stockage permettant entre autre le stockage de fichiers sera
grandement réduit puisque les seuls éléments de stockage disponibles sont une EEPROM
flash de 16Mo et une SDR SDRAM de 16Mo. En contrepartie, elle intègrera les
fonctionnalités principales du module unité centrale dans le FPGA en se servant des
ressources non utilisées. Le coût de cette version en sera donc grandement réduit
puisqu’elle permettra d’économiser le coût de la carte processeur (soit environ 1000€).
Il faudra mettre en place tous les éléments nécessaires à la communication Ethernet, un
système de gestion de fichier, un « système d’exploitation », etc.
CARTE D’ACQUISITION
FPGA
SPI entrant
Traitement
numérique
Carte analogique
Module Unité
Centrale (MUC)
Réseau
SPI sortant
Figure 5 - Schéma de fonctionnement de la version de la CABTR à développer
Un prototype de la carte d’acquisition a déjà été réalisé (Figure 6). Celui-ci est utilisable pour
les deux versions puisque la partie acquisition est la même dans les deux cas, seuls le posttraitement et la communication Ethernet diffèrent. Les composants nécessaires à l’interface
Ethernet ne sont toutefois pas intégrés.
Un connecteur a été prévu permettant d’ajouter une extension pour une interface Ethernet.
Lors d’une future étape du projet, ces composants seront directement intégrés sur la carte
et l’interface avec la carte processeur ne sera plus présente. En attendant, pour mener à
bien mon travail, je devrai dans un premier temps réaliser cette carte d’interface Ethernet
pour pouvoir travailler sur le prototype.
PFE / Génie Electrique / Fabien AUBERT
14
Connecteur pour
l’interface Ethernet
Figure 6 - Prototype réalisé de la carte d'acquisition
2.2 Principe de fonctionnement général
2.2.1 Acquisition et mise en forme des signaux
La mesure de température s'effectue en plusieurs étapes. La première consiste à mesurer
des températures à l'aide de capteurs résistifs dont l'excitation est sinusoïdale et réalisée par
un montage spécifique. Ces capteurs délivrent une tension ou un courant proportionnel à la
température sous forme de signaux analogiques. Ils sont ensuite amplifiés puis convertis en
signaux numériques. Ceux-ci sont ensuite démodulés et filtrés dans le FPGA qui se charge de
réaliser la partie traitement numérique.
Pour des raisons d'auto échauffement du capteur il est impératif de pouvoir commuter la
source d’excitation : tension ou courant.
La plage de résistance étant importante (0-100kΩ), afin de rester à pleine échelle lors des
mesures, il a été décidé de pouvoir commuter également la gamme, c'est-à-dire rajouter
une résistance en série modifiant ainsi la valeur de la résistance de shunt. Des registres à
décalage permettent de commuter la gamme et la source depuis le FPGA.
La figure 7 résume le fonctionnement de la partie analogique. Le signal d’excitation est
généré par le bloc numérique, il traverse un convertisseur numérique analogique (CNA) et
est injecté dans le capteur après avoir été filtré (passe-bas).
Une isolation galvanique est placée au niveau des deux liaisons SPI qui servent pour la
communication entre la partie analogique et la partie numérique.
PFE / Génie Electrique / Fabien AUBERT
15
Figure 7 - Fonctionnement de la partie analogique
2.2.2 Conversion des mesures de tension et courant
A ce stade-ci nous avons une valeur de tension et de courant sous forme de signaux
numériques qui vont pouvoir être convertis pour obtenir une valeur de température.
Une fois qu'une mesure de tension et de courant sont disponible pour une voie de mesure,
une interruption est déclenchée pour indiquer au module unité centrale qu'il peut venir les
récupérer pour les convertir.
La première conversion consiste à obtenir une valeur de résistance à partir des valeurs de
tension et de courant. La conversion va dépendre de la gamme et de la source utilisée.
Cette valeur de résistance est alors convertie en température à l'aide de l'étalonnage fourni
par le fabriquant du capteur.
PFE / Génie Electrique / Fabien AUBERT
16
Figure 8 - Variation de la résistance en fonction de la température (échelle log) pour différents capteurs
Cernox. Document fournit par le fabriquant du capteur
La figure 8 montre les variations de résistances en fonction de la température suivant le
capteur Cernox choisi. Le fabriquant donne les plages de variations maximales de ses
capteurs. Pour des raisons évidentes de précisions, il fournit également un étalonnage précis
pour chaque capteur. Dans tous les cas, la variation de résistance est loin d'être linéaire,
même sur une échelle de type log. Le calcul de température est donc complexe.
2.2.3 Stockage et transfert des données
Les valeurs manipulées (tension, courant, résistance et températures) sont enregistrées en
"flottant" (simple précision) c'est à dire qu'elles sont codées sur 32 bits, ce qui donne une
précision de l'ordre de 10-6.
Les valeurs de résistances et de températures courantes sont disponibles via la
communication Modbus. Elles sont également archivées pendant une seconde. Si
l'utilisateur le souhaite, il peut également sauvegarder les mesures, pendant un certain laps
de temps, dans un fichier qui sera accessible via le réseau Ethernet.
2.3 Protocoles de communication
Dans ce chapitre nous allons présenter brièvement les protocoles de communication utilisés
dans ce projet. Le but n’étant pas de faire un cours sur les protocoles mais d’expliquer
rapidement leur fonctionnement. Nous allons dans un premier temps parler du modèle
TCP/IP puis du protocole Modbus.
2.3.1 TCP/IP et OSI
A l’origine des réseaux, chaque constructeur avait son propre système ce qui engendrait des
incompatibilités entre les réseaux. C’est pourquoi L’organisation Internationale de
Standardisation (ISO) à mis au point le model OSI. Le rôle de ce modèle est de normaliser la
PFE / Génie Electrique / Fabien AUBERT
17
communication entre les machines afin que différents constructeurs puissent mettre au
point des produits (logiciels ou matériels) compatibles.
Le modèle TCP/IP est très proche du modèle OSI. En réalité le modèle TCP/IP a été
développé à peu près au même moment que le modèle OSI, c'est la raison pour laquelle il
s'en inspire mais n'est pas totalement conforme aux spécifications du modèle OSI.
Afin de pouvoir appliquer le modèle TCP/IP à n'importe quelle machine, c'est-à-dire
indépendamment du système d'exploitation, le système de protocoles TCP/IP a été
décomposé en plusieurs modules effectuant chacun une tâche précise. De plus, ces modules
effectuent ces tâches les unes après les autres dans un ordre précis, on a donc un système
stratifié, c'est la raison pour laquelle on parle de modèle en couches. Chaque couche du
modèle communique avec une couche adjacente (celle du dessus ou celle du dessous).
Chaque couche utilise ainsi les services des couches inférieures et en fournit à celle de
niveau supérieur.
Le modèle TCP/IP, inspiré du modèle OSI (7 couches), reprend l'approche modulaire
(utilisation de modules ou couches) mais n’en contient uniquement quatre. Les rôles des
différentes couches du modèle TCP sont les suivants :




Couche Accès réseau : spécifie la forme sous laquelle les données doivent être
acheminées quel que soit le type de réseau utilisé
Couche Internet : chargée de fournir le paquet de données (datagramme)
Couche Transport : Assure l'acheminement des données, ainsi que les mécanismes
permettant de connaître l'état de la transmission
Couche Application : Englobe les applications standard du réseau (Telnet, FTP, etc.)
Modèle OSI
Modèle TCP/IP
Couche Application
Couche Application
Couche Présentation
ex : HTTP,
FTP, DNS
Couche Session
ex : TCP, UDP
Couche Transport
Couche Transport (TCP)
Couche Réseau
Couche Internet (IP)
ex : IP, ARP, RARP
Couche Accès réseau
ex : Ethernet
Couche Liaison données
Couche Physique
Figure 9 - Comparaison entre le modèle OSI et le modèle TCP/IP
PFE / Génie Electrique / Fabien AUBERT
18
Lors d'une transmission, les données traversent chacune des couches au niveau de la
machine émettrice. A chaque couche, une information est ajoutée au paquet de données, il
s'agit d'un en-tête, ensemble d'informations qui garantit la transmission. Au niveau de la
machine réceptrice, lors du passage dans chaque couche, l'en-tête est lu, puis supprimé.
Ainsi, à la réception, le message est dans son état originel (Figure 10).
MACHINE ÉMETTRICE
MACHINE RÉCEPTRICE
Application
Application
Transport
Transport
Internet
Internet
Accès réseau
Accès réseau
Figure 10 - Transmission de données par protocole TCP
2.3.2 Le protocole Modbus TCP
Modbus est un protocole de communication utilisé pour des réseaux d'automates
programmables. Il fonctionne sur le mode maître / esclave ou client / serveur. La centrale
d’acquisition réalisée a le rôle de serveur.
Ce protocole est constitué de trames contenant l'adresse de l'automate concerné, la
fonction à traiter (écriture/lecture de n bits/octets), ainsi que la donnée. Le protocole
Modbus peut être implémenté via une trame TCP/IP, il porte alors le nom de « Modbus
TCP ». C’est ce que nous allons faire dans ce projet. Il diffère légèrement du protocole
Modbus de base en cela que l’adresse de l’automate ainsi que le CRC sont inclus dans la
trame TCP. Une fois « décortiqué » il reste les champs suivants :
- Identifiant de Transaction : sert à synchroniser les différentes requêtes entre un
serveur et son/ses client(s).
- Identifiant du Protocole : sert à indiquer le protocole utilisé. Vaut 0 pour le Modbus.
- Longueur de Champ : nombre d’octets dans la suite de la trame (contient l’identifiant
de l’unité, le code fonction ainsi que les données). Cette valeur sert à connaître le
nombre d’octets que contient la trame.
- Identifiant de l’Unité : adresse du client. C’est un octet que nous n’utilisons pas.
- Code Fonction : code indiquant la fonction à réaliser (lecture/écriture).
- Données : mots de données. Les deux premiers mots correspondent à l’adresse de
départ où effectuer les opérations. Les mots suivants servent à indiquer les données
à écrire (dans le cas d’une écriture) ou le nombre de bits/octets à lire (dans le cas
d’une lecture).
PFE / Génie Electrique / Fabien AUBERT
19
Voici la représentation d’une trame :
Identifiant
de
Transaction
(2 octets)
Identifiant
de
Protocole
(2 octets)
Longueur
de Champ
Identifiant
de l’Unité
Code
Fonction
(2 octets)
(1 octet)
(1 octet)
Données
(N octets)
Figure 11 - Représentation d'une trame Modbus TCP
Champs
Longueur
Description
Client
Identifiant de
Transaction
2 octets
(1 mot)
Identification de la
requête Modbus
Initialisé par le
client
Identifiant de
Protocole
2 octets
(1 mot)
0 pour le protocole
Modbus
Initialisé par le
client
Longueur de
Champ
2 octets
(1 mot)
Initialisé par le
client (dans le cas
d’une requête)
Identifiant de
l’Unité
1 octet
Code Fonction
1 octet
Nombre d’octets
dans la suite de la
trame
Identification d'un
esclave distant
connecté sur un port
série ou d’autres bus
Code de fonction
représentant l’action
à exécuter
Données
N octets
(voir ci-dessous)
Données transmises
Initialisé par le
client
Initialisé par le
client
Initialisé par le
client (dans le cas
d’une requête)
Serveur
Recopié par le
serveur à partir de
la requête reçue
Recopié par le
serveur à partir de
la requête reçue
Initialisé par le
serveur (dans le
cas d’une réponse)
Recopié par le
serveur à partir de
la requête reçue
Recopié par le
serveur à partir de
la requête reçue
Initialisé par le
serveur (dans le
cas d’une réponse)
Le protocole Modbus repose sur une trame avec un
nombre d’octets multiple de 2 et d’une longueur
maximum de 256 octets. N est donc un nombre pair
ayant pour valeur maximum 248. 248 correspond à
la taille maximum d’une trame moins les champs
autres que les Datas. Les différents champs
mentionnés ci-dessus sont encodés dans le format
Big Endian c'est-à-dire de l’octet de poids fort vers
l’octet de poids faible (de gauche à droite).
Les communications Modbus via TCP se font sur le
Figure 12 - Représentation des données dans
port 502.
la mémoire
(A : octet de poids fort et D : octet de poids faible)
Flèche dans le sens des adresses croissantes
PFE / Génie Electrique / Fabien AUBERT
20
3 Développement de la partie matérielle
3.1 Réalisation d’une carte d’interface Ethernet pour
le prototype
Le prototype (de la carte d’acquisition) fabriqué, ne comportant pas les composants
nécessaires à une communication Ethernet, une carte d’interface pour l’Ethernet a été
réalisée. Pour des raisons de délais de fabrication, le stage a débuté, par la réalisation de
cette carte. La première étape a été de se documenter sur les différents composants
nécessaires à la connexion Ethernet.
Les trois principaux composants nécessaires sont :
Un connecteur Ethernet. C’est lui qui
assure le contact physique entre le câble
RJ45 (nécessaire au transport des données
dans le cadre d’une connexion filaire) et le
reste de la carte.
Il comprend :
- Un connecteur RJ45 femelle.
- Les transformateurs de lignes.
- Deux LEDs indiquant l’état du réseau.
Figure 13 - Connecteur Ethernet utilisé
Un transceiver (émetteur-récepteur
en Français). Le mot « transceiver » provient
de la contraction en anglais de
« TRANSmitter » (« émetteur ») et de
« reCEIVER » (« récepteur »). Ce mot est
parfois francisé en « transcepteur ».
Ce composant assure la réception et
l'émission des trames de données entre le
réseau et la centrale d’acquisition.
Concrètement, ce composant s’interface
entre le contrôleur Ethernet et le
connecteur Ethernet. Le composant choisi
est un petit circuit intégré de 5mm par 5mm
qui comporte 32 broches. L’espace entre les
broches est de 0,5mm. Il supporte des débits
de 10 et 100Mbps ce qui est suffisant pour
notre application.
-
PFE / Génie Electrique / Fabien AUBERT
Figure 14 – Emetteur récepteur Ethernet choisi
21
Un contrôleur Ethernet ou Media
Access Controller (MAC). Il sert d'interface
entre la partie logicielle et la couche
physique (matérielle). Celui-ci sera intégré
dans le FPGA qui est actuellement sur le
prototype. Nous avons utilisé un composant
fourni par Xilinx (le fabriquant du FPGA) non
soumis à une licence. Ce composant (le «
XPS Ethernet Lite ») est limité à 100Mbps
mais cela convient pour notre application. Il
a pour but de fournir les fonctions
minimales nécessaires à une interface
Ethernet tout en utilisant le moins de
ressources possible.
-
Figure 15 - FPGA de type Spartan-6 dans lequel sera
intégré le contrôleur Ethernet
Le schéma typique d’une interface Ethernet est celui de la Figure 16.
Figure 16 - Schéma typique d'une interface Ethernet
Dans notre application, le connecteur Ethernet intègre les transformateurs d’isolement
(Magnetics).
L’interface utilisée pour relier le contrôleur Ethernet et l’émetteur-récepteur dépend
principalement de la vitesse de la connexion Ethernet. Pour une connexion de type
10/100Mbps nous pouvons utiliser les interfaces MII (Media Independent Interface) ou RMII
(Reduced Media Independent Interface).
La principale différence entre ces deux interfaces réside dans le nombre de connexions
nécessaires pour l’interface. Le principe de fonctionnement reste le même. A titre de
comparaison, l’interface MII comporte 7 connexions supplémentaires par rapport à
l’interface RMII. Ce rajout de connexions peut être gênant sur des microcontrôleurs ou des
FPGA car cela engendre une utilisation de broches plus importante. Pour compenser la
PFE / Génie Electrique / Fabien AUBERT
22
diminution du nombre de lignes de transmission et de réception, l’interface RMII nécessite
l’utilisation d’une horloge à 50Mhz contre 25Mhz pour la MII.
Dans le cadre de ce projet, le prototype réalisé prévoyait suffisamment de broches pour une
interface de type MII. La seule contrainte était donc de sélectionner des composants
alimentés en 3,3V pour correspondre au niveau d’alimentation distribué. Lors de la
réalisation de la carte d’interface Ethernet, pour des raisons de fonctionnalités, de prix et de
simplicité d’utilisation, nous avons choisi l’émetteur-récepteur 78Q2123 de chez TERIDAN.
Celui-ci répond au cahier des charges, il offre toutes les fonctionnalités que nous souhaitons
et communique en mode MII.
L’horloge (clock source) dépend, comme dit précédemment, de l’interface utilisée. Nous
avons donc choisi une horloge à 25Mhz puisqu’elle correspond à l’interface MII. Pour réaliser
le signal d’horloge, nous avons utilisé un oscillateur du commerce en faisant
particulièrement attention à sa tension d’alimentation.
Nous avons réalisé une carte d'interface Ethernet pour permettre la communication via
Ethernet entre le prototype et le réseau. Cette carte vient se greffer à un connecteur prévu à
cet effet sur la carte prototype. Elle comporte le connecteur de carte, le connecteur
Ethernet, l’émetteur-récepteur, un oscillateur à 25MHz, des condensateurs et des
résistances. Tous les composants à l’exception du connecteur Ethernet sont en CMS.
Cette carte a été réalisée en double couche à l’aide du logiciel Proteus. Sa taille est d’environ
5 cm par 4 cm. Sa fabrication a été sous-traitée.
Figure 17 - Carte d'adaptation Ethernet réalisée durant le stage
PFE / Génie Electrique / Fabien AUBERT
23
3.2 Environnement de travail
Le SBT s’est procuré un kit de développement contenant un FPGA de type Spartan-6 LX45T
de chez Xilinx. Ce kit, nommé « SP605 » est montré en page de garde.
Il dispose d’une horloge à 200MHz, d’une mémoire DDR3 SDRAM de 128Mo, d’interfaces
USB 2.0, Ethernet, VGA, CompactFlash, etc.
Comme tous les modèles Spartan ne disposent pas de processeur hardcore, il est seulement
possible d’implémenter un ou deux processeurs softcores « Microblaze ». Le Microblaze est
un processeur 32bits RISC avec une architecture Harvard c'est-à-dire disposant d’un bus
pour la mémoire d’instruction et d’un bus pour la mémoire de données. L’architecture du
Microblaze est donnée en annexe.
Les éléments qui nous intéressent sont les nombreuses options dont il dispose, telles que la
possibilité d’intégrer un FPU et/ou un MMU afin d’assurer une compatibilité avec les OS
linux. Pour notre application nous allons nous limiter à implémenter un « Noyau de système
d’exploitation » qui est la partie fondamentale d’un OS car l’emploi d’un OS n’est pas
nécessaire et serait une solution plus lourde, surtout au regard des ressources matérielles
dont nous disposons. Le FPU permettra d’accélérer l’ensemble des calculs en flottant
(codage des réels en simple précision).
Avec cette carte de développement, les logiciels ISE (Integrated Software Environment), EDK
(Embedded Development Kit) et SDK (Software Development Kit) sont fournis.
-
ISE permet de gérer un projet, de concevoir des blocs matériels, de synthétiser,
d’implémenter et configurer le FPGA.
EDK est utile pour réaliser des systèmes embarqués avec un processeur. Il permet de
réaliser l’architecture matérielle à implémenter dans le FPGA.
SDK est un outil basé sur l’environnement de développement Eclipse destiné à
développer la partie logicielle et à la debugger.
La version utilisée de cette suite de logiciels est la 13.1, la dernière en date lors du début du
stage. Pour ce projet nous avons principalement utilisé EDK et SDK puisque nous nous
sommes servis de composants préexistants.
Nous avons commencé à développer le système sur le kit « SP605 » avant de travailler sur le
prototype réalisé par le SBT.
PFE / Génie Electrique / Fabien AUBERT
24
3.3 Mise en place d’un système multitâches temps
réel
Le système doit être capable de procéder à la lecture des mesures et leur traitement
cyclique tout en répondant à des requêtes diverses de façon asynchrone. Ces requêtes
proviennent essentiellement de la communication Ethernet. Plusieurs d’entre elles
(affichage d’une page web, demande d’envoi de mesures, etc.) peuvent arriver en même
temps et sont traitées en parallèle, d’où la nécessité d’un système multitâche. La seule
opération non « aléatoire », dans le sens où l’on peut la prévoir puisqu’elle arrive à une
fréquence donnée (1kHz), est celle indiquant l’arrivée de nouvelles mesures à traiter. Celle-ci
est prioritaire puisqu’elle doit être traitée avant l’arrivée de la suivante sous peine de perdre
les mesures.
Dans le FPGA, nous avons installé plusieurs composants comme un Microblaze, un
contrôleur de RAM, le contrôleur Ethernet, etc. Ces composants sont déjà créés par le
fabriquant, nous n’avons qu’à les sélectionner lorsque nous préparons la plateforme
matérielle sous EDK. L’environnement de développement se charge de connecter entre eux
ces composants. Toute la partie VHDL est donc transparente tant que nous utilisons des
composants déjà existants.
3.3.1 Ordonnancement des tâches
Le programme à exécuter par le microprocesseur est écrit en langage C puis converti en
assembleur par le compilateur. Nous lui avons implémenté un noyau d’OS temps réel fourni
par Xilinx : le « Xilkernel ». Celui-ci permet la gestion des threads et donc d’avoir un système
avec plusieurs tâches en parallèle. Bien évidemment, n’ayant qu’un seul processeur installé,
les tâches ne s’exécutent pas exactement en parallèle car à un instant t, il n’y a qu’un seul
processus qui utilise les ressources CPU.
Deux modes de fonctionnement sont disponibles pour l’ordonnanceur :
- Le premier mode : « Round-Robin », attribue des tranches de temps à chaque thread en
proportion égale, sans accorder de priorité aux threads.
- Le deuxième mode permet de donner des priorités aux différents threads. Dans ce cas, si
tous les threads ont des priorités différentes, les threads seront exécutés dans l’ordre de ces
priorités. Le thread dont la priorité est la plus importante gardera la main tant qu’il aura
besoin des ressources CPU. Si deux threads ont la même priorité, l’ordonnanceur agira pour
ces threads de la même façon que le ferait le premier mode.
Ce deuxième mode est très intéressant dans notre cas. En effet, la partie récupération des
mesures et traitement de celles-ci doit être effectuée à intervalles réguliers. Nous risquons
de perdre des mesures si l’ordonnanceur ne laisse pas la main au thread correspondant
PFE / Génie Electrique / Fabien AUBERT
25
lorsque les mesures sont envoyées. C'est pour cela que nous lui avons donné la priorité
maximale.
Cependant, dans ce mode-ci, le thread de plus grande priorité doit-être mis en « veille »
régulièrement, sinon les autres threads n’auront jamais la main et ne pourrons pas
s’exécuter. Ce second mode est très pratique pour notre application mais doit être manipulé
avec précaution.
3.3.2 Accès aux données
Réaliser une application multitâche nécessite de prendre des précautions pour éviter
certains problèmes de conflits entre les tâches. En effet, lorsque plusieurs threads ont accès
à une même variable (Figure 18), si l’un modifie sa valeur pendant que l’autre cherche à la
lire, cela peut engendrer des problèmes.
Thread 1
Thread 2
Lec
tur
e
/E
cri
tur
e
Ressource
partagée
tur
Lec
re
itu
Ecr
/
e
Figure 18 - Ressource partagée par plusieurs threads
Pour permettre de synchroniser les différents threads, nous utilisons des mécanismes prévus
à cet effet : les sémaphores. C’est un mécanisme atomique qui est utilisé dans les systèmes
multithreads et permet de (entre autre) verrouiller l’accès à des « zones critiques »
(ressources partagées). Lorsqu’un thread veut accéder à une zone critique il verrouille le
sémaphore correspondant et le libère quand il a fini. Ainsi lorsqu’un autre thread tente
d’accéder à cette zone, si le sémaphore est verrouillé, il se met en « veille » jusqu’à ce que
celui-ci soit libéré. Ce mécanisme permet à la fois d’éviter les conflits et d‘éviter d’utiliser les
ressources CPU pendant l’attente.
Un sémaphore peut prendre différentes valeurs. Si sa valeur est 0 alors le thread est
« verrouillé ». Sinon il est « libre ».
PFE / Génie Electrique / Fabien AUBERT
26
Thread
Souhaite accéder à une
ressource partagée
Le sémaphore
protégeant l’accès à
cette ressource est
libre?
Non
Se mettre en
veille jusqu’à ce
que le
sémaphore soit
libre
Oui
Verrouiller le sémaphore
Effectuer les opérations nécessitant l’accès
aux ressources partagées
Déverrouiller le sémaphore
Figure 19 - Principe de fonctionnement d'un sémaphore
A titre d’exemple, dans le but de garantir l’intégrité des données, des sémaphores sont
utilisés lors du calcul de résistance ou de température. En effet ces calculs font appel à des
coefficients qui peuvent être modifiés via Modbus et ne doivent pas être modifiés pendant
un calcul afin d’éviter des erreurs. C’est pourquoi, des sémaphores sont utilisés pour
empêcher l’accès à ces coefficients par deux threads différents où l’un chercherait à les
modifier et l’autre à les lire. Le sémaphore correspondant est alors initialisé à la valeur 1, ce
qui permet de n’avoir qu’un seul thread accédant à ces coefficients à un instant t.
Une autre utilité des sémaphores est celle de la synchronisation d’une opération sur un
événement. Le stockage des acquisitions dans un fichier en est un exemple. Cette opération
ne se fait pas automatiquement, elle est déclenchée par un automate ou un utilisateur. Afin
de limiter l’attente active (attente consommant des ressources processeur), le thread
réalisant cette fonction attend la libération d’un sémaphore avant de démarrer ses
opérations. La libération de ce sémaphore se fait lors d’une demande de déclenchement de
stockage des mesures. Dans ce cas-ci, le sémaphore correspondant est initialisé à 0, ce qui
indique qu’il est bloqué à la base.
PFE / Génie Electrique / Fabien AUBERT
27
4 Développement de la partie logicielle
4.1 Architecture du système
Le fonctionnement chronologique du système peut se synthétiser comme sur le schéma cidessous (Figure 20).
Initialisation
Communication
réseau
Acquisition
Archivage dans un
fichier
Récupération
de U et I
Conversion
en R et T
Filtrage
Serveur
Modbus
Attente du
signal, Archivage
Serveur Web,
Serveur TFTP,
Serveur d'écho
Légende :
Fonctions réalisées
durant le stage
Fonctions
préexistantes
Figure 20 - Synthèse du fonctionnement du système
Au lancement du programme, le système est initialisé. Voici la séquence d’initialisation :
-
Mise en place d’un système de fichiers.
Chargement des coefficients de calibrage et de linéarisation
Démarrage du « système d’exploitation ».
Initialisation des sémaphores
Initialisation de la partie acquisition des mesures
Implémentation de l’interface réseau.
PFE / Génie Electrique / Fabien AUBERT
28
L’initialisation est terminée, les threads suivants sont alors démarrés :
- Réseau (serveur Modbus, server web, serveur TFTP, serveur d’écho)
- Acquisition
- Stockage dans un fichier
Le schéma (Figure 21) ci-dessous représente de manière simplifiée l’agencement des
différents threads et des ressources partagées.
-
En bleu, les threads
En jaune, les variables partagées
En vert, le système de fichier
Les flèches indiquent le sens de déplacement des données :
Donnée
Donnée
Donnée
Thread : Ecriture et Lecture
Thread : Lecture seule
Thread : Ecriture seule
Par exemple, le thread « Serveur Modbus TCP » accède aux variables à la fois en écriture et
en lecture. En revanche, le thread de « Stockage des mesures dans un fichier » n’effectue
que des lectures de données, il ne vient pas modifier leur contenu. L’importance des
sémaphores prend alors tout son sens.
Thread
Routine
d’interruption
Serveur
Modbus TCP
Données
Thread
Traitement
des mesures
R, T
Coefficients
Paramètres
statut
Thread
Stockage des
mesures dans
un fichier
Système de fichier
Thread
Thread
Thread
Serveur web
Serveur TFTP
Serveur écho
Figure 21 - Agencement des différents threads et des ressources partagées
PFE / Génie Electrique / Fabien AUBERT
29
4.2 Initialisation
4.2.1 Initialisation du système de fichier
4.2.1.1
Intérêt d’un système de fichier
Lors du démarrage du système, avant de démarrer le noyau, nous commençons par créer un
système de fichier (file system) dans un espace bien délimité de la RAM. La taille de cet
espace doit être ajustée pour permettre de stocker suffisamment de fichiers sans toutefois
empiéter sur les espaces réservés au code source et aux autres données nécessaires au
fonctionnement du programme.
Ce système permet de gérer des fichiers comme nous avons l’habitude de le faire sur un
ordinateur. Ceci offre la possibilité de voir les données comme étant des fichiers et non plus
comme des blocs de données mémoires. Ceci facilite l’accès à ces informations.
4.2.1.2
Sauvegarde du système de fichier
Ce système de fichier est stocké (dans son intégralité) au préalable dans la mémoire de type
EEPROM flash présente sur la carte. Cette mémoire, contrairement à la RAM, est non
volatile. Ceci permet donc de conserver certaines données même lorsque l’alimentation de
la carte est coupée.
L’idéal aurait été de pouvoir stocker uniquement les fichiers que l’on souhaite conserver
dans la flash et ainsi économiser de la place, mais les bibliothèques disponibles, permettant
l’accès à la flash, ne permettent pas l’écriture de fichiers dans celle-ci.
Lorsque l’on définit la taille du système
de fichier, cela signifie que nous allouons
une zone de cette taille, dans la
mémoire, qui sera réservée au stockage
de fichier. Que cette zone soit vide ou
pleine, cet espace reste le même, ce qui
nous oblige à copier l’intégralité du
système de fichiers dans la ROM. La
taille du système de fichier sera la même
dans les deux mémoires.
Cette solution est très contraignante. En
effet, elle est « gourmande » en terme
de place mémoire et la copie de la SDR
SDRAM vers la EEPROM flash peut être
Figure 22 - Zone mémoire allouée pour le système
de fichiers
très longue (plusieurs secondes) suivant
la taille du système de fichiers. La question s’est posée de savoir si le système de fichier
devait donc être implémenté ou non. Nous avons estimé que les gains engendrés par ce
PFE / Génie Electrique / Fabien AUBERT
30
système, notamment en termes de flexibilité, de simplification d’accès aux données, valait la
peine de le mettre en œuvre.
4.2.1.3
Contrôle de l’intégrité des données
Pour contrôler l’intégrité des données, une « signature » est stockée dans la flash avant et
après la zone où est stocké le système de fichier. En plus de cela, un checksum est stocké
entre la fin de l’emplacement du système de fichier et le début de la signature de fin.
Lors de l’initialisation, nous commençons par tester les deux signatures. Si elles sont bonnes,
nous venons copier l’ensemble du système de fichier dans la RAM à un emplacement prévu
à cet effet. Nous calculons ensuite le checksum et nous le comparons à celui stocké dans la
flash pour vérifier que la copie a été réalisée correctement. Si les deux coïncident, nous
initialisons le système de fichier à partir de celui qui vient d’être recopié.
Signature (0xAA55AA55)
Système de fichier
Checksum
Signature (0x55AA55AA)
Figure 23 - Archivage du système de
fichiers dans la EEPROM Flash
Si pour une raison ou une autre, une de ces vérifications n’est pas bonne, un système de
fichier vide est initialisé et les fichiers minimum nécessaires au bon fonctionnement du
système sont créés. Ces fichiers sont :
-
un fichier html pour le serveur web,
un fichier contenant les coefficients de linéarisation par défaut (calcul de
température à partir des valeurs de résistance)
un fichier d’initialisation par défaut.
Ce dernier permet de stocker le nom des voies ainsi que les types de linéarisation souhaité. Il
contient aussi les paramètres réseau (adresse IP, passerelle, masque de sous réseau).
Les données par défaut de ces fichiers sont contenues dans le code source du programme ce
qui permet de les recréer. Après cette séquence d’initialisation, nous recopions le nouveau
système de fichier dans la flash en ajoutant les signatures et le checksum pour avoir un
système de fichiers fonctionnel lors d’un prochain redémarrage.
PFE / Génie Electrique / Fabien AUBERT
31
4.2.2 Initialisation des coefficients de calibrage (ou
calibration)
Les coefficients de calibrage servent à calculer les résistances à partir des valeurs de tension
et de courant. Ces coefficients sont ajustés pour chacune des voies lors du calibrage en
usine. Ils permettent de compenser les différences physiques entre les voies. Huit
coefficients par voie sont nécessaires au calcul de résistance. Chacun de ces coefficients est
codé sur 4 octets (float). Ces coefficients sont stockés dans la flash de la même façon que le
système de fichier (signature avant et après ainsi que checksum) mais hors du système de
fichier et ne devraient pas avoir à être modifiés sauf lors d’un nouveau calibrage. La
modification de ces coefficients se fait à l'aide d'une commande Modbus.
Après avoir initialisé le système de fichier, si les signatures et le checksum sont bons, nous
venons copier les coefficients de calibrage dans une structure (au sens du langage C) prévu à
cet effet. Si ce n’est pas le cas, des coefficients de calibrage par défaut sont chargés. Ils sont
identiques pour chacune des voies et correspondent à des valeurs théoriques.
Dans tous les cas, un fichier est créé, dans lequel ces coefficients sont stockés, ce qui permet
d’avoir accès aux coefficients depuis l’extérieur via transfert TFTP ou le serveur web (voir
partie sur la communication Ethernet).
4.2.3 Initialisation des coefficients de linéarisation
La linéarisation est le calcul permettant de passer d’une valeur de résistance à une valeur de
température. Plusieurs types de linéarisation sont possibles mais nous n’en avons
implémenté que 3. Voici la liste de ces types de linéarisation, par ordre de précision
croissante :
-
Polynôme
Table de points
Polynôme de type log (la variable n’est pas R mais log(R) et le calcul n’est pas
exactement le même que celui du polynôme "simple")
Le type de linéarisation à utiliser pour chacune des voies est défini dans le fichier
d’initialisation. Par défaut c’est le polynôme d’un capteur platine (pt100) qui est utilisé. Les
coefficients sont stockés dans des fichiers. Le nom du fichier correspondant à chacune des
voies est stocké dans le fichier d’initialisation. Si le fichier correspondant à la voie n’est pas
présent dans le système de fichiers, celui contenant les coefficients du polynôme par défaut
est utilisé. Ce dernier fichier est forcément présent puisque s’il n'existe pas il est créé lors de
l’initialisation.
PFE / Génie Electrique / Fabien AUBERT
32
4.2.4 Démarrage du noyau
Après l’initialisation décrite précédemment, le noyau est lancé et les sémaphores sont
initialisés. La valeur à laquelle le sémaphore est initialisé dépend de la raison pour laquelle il
est utilisé. Si le but est de verrouiller l’accès à des variables, il faut l’initialiser à 1 : état
« libre » mais n’autorisant qu’un seul thread à la fois, à accéder à la zone. Dans ce cas là le
sémaphore est utilisé comme un « mutex » (mutuelle exception) qui est un autre moyen de
synchronisation comme les sémaphores mais ne pouvant posséder que 2 états (0 ou 1).
Le cas le plus courant d’utilisation des sémaphores, pour notre application, est celui de la
protection des données accessibles par Modbus. Si un automate vient lire des données,
comme par exemple les valeurs de températures courantes, et que le thread principal est en
train de les mettre à jour, il y aura un conflit.
Thread
Routine
d’interruption
Serveur
Modbus TCP
Données
Thread
Traitement
des mesures
R, T
Coefficients
Paramètres
statut
Figure 24 - Exemple de cas nécessitant l'utilisation de sémaphores
Afin d’éviter ce problème, nous utilisons un sémaphore qui bloque l’accès à ces données
venant de deux threads différents. Ce thread sera donc initialisé à 1.
Nous initialisons ensuite toute la partie concernant la mesure. Cette partie n’a pas été
traitée lors de ce stage puisqu’elle est identique à celle de l’autre version de la CABTR. Les
opérations à réaliser lors de cette étape sont l’initialisation des différents paramètres liés
aux mesures (mode d’acquisition, mise à zéro des flags d’interruption, initialisation des
structures de donnée, etc.) et la mise en place des interruptions liées à l’arrivée de ces
mesures pour pouvoir les traiter ensuite.
La mise en place des interruptions est différente selon la présence d’un noyau ou non. Cette
partie a donc été modifiée pour correspondre à l’utilisation d’un noyau.
La dernière étape de l’initialisation est la mise en place de la couche TCP/IP (chapitre 4.3.1).
PFE / Génie Electrique / Fabien AUBERT
33
Une fois l’initialisation terminée, la partie réseau est démarrée avec tous les types de
communication souhaités ainsi que le thread principal, qui s’occupe de la partie acquisition
(conversion en résistance et température et archivage).
4.3 Communication réseau
Le kit SP605 contient tous les composants nécessaires à la mise en place d’une interface
Ethernet. Cependant, les composants utilisés, notamment l’émetteur-récepteur
(transceiver), ne sont pas les mêmes que ceux qui vont être utilisés pour la réalisation du
projet. La vitesse de transmission sera plus faible.
Nous cherchons à utiliser un contrôleur Ethernet fournit par Xilinx appelé « EthernetLite ».
L’intérêt principal de ce contrôleur est sa gratuité. Cependant celui-ci est limité à une vitesse
maximum de fonctionnement de 100Mbps. L’émetteur-récepteur, du kit, est toutefois
capable d’établir une connexion à 1Gbps. Il doit être impérativement réglé pour limiter le
transfert à un maximum de 100Mbps.
Une fois le programme implémenté sur le prototype, la vitesse s’établit automatiquement à
100Mbps puisque le matériel ne permet pas une connexion plus rapide donc ces soucis
n’apparaissent plus. Dans le cas d’une évolution éventuelle de ce projet vers une vitesse de
communication plus élevée il faudra tenir compte de ces problématiques.
4.3.1 Implémentation de la couche TCP
La couche « accès réseau » du model TCP/IP (voir chapitre 2.3.1) est réalisée par le
contrôleur Ethernet et l’émetteur-récepteur.
Pour implémenter les couches Internet et Transport, nous utilisons la pile « lwIP ».
« LwIP (lightweight IP) est une pile TCP/IP open source largement utilisée pour le
développement de systèmes embarqués. LwIP a été développé à l'origine par Adam Dunkels
au Swedish Institute of Computer Science et est maintenant développé et maintenu par un
réseau de développeurs répartis dans le monde entier, et conduit par Kieran Mansley.
L'un des objectifs de l'implémentation de lwIP est de réduire l'utilisation des ressources tout
en ayant un module TCP le plus complet possible. Cela rend l'utilisation de lwIP parfaitement
adaptée dans des systèmes embarqués. » (Source : Wikipedia)
Nous avons particulièrement fait attention à ce que les fonctions utilisées faisant appel à
cette librairie ne soient pas bloquantes, dans le sens où elles ne gardent pas la main alors
que le thread d’acquisition en aurait besoin, ce qui provoquerait beaucoup de problèmes.
Le mécanisme de fonctionnement de la communication réseau repose sur des interruptions.
Celles-ci étant prioritaires sur n’importe quel Thread, nous avons effectué plusieurs tests, de
façon empirique, pour nous assurer que la partie réseau n’interfère pas de façon critique
PFE / Génie Electrique / Fabien AUBERT
34
dans le processus d’acquisition des mesures. Nous avons pu constater que la partie
acquisition effectuait son travail correctement et que les transferts de données s’exécutaient
après la tâche d’acquisition.
4.3.2 Serveur Modbus TCP
Les installations cryogéniques sont pilotées par des automates. Ils se servent des centrales
d’acquisition, comme la CABTR, pour récupérer les mesures de température au sein de ces
installations. Pour permettre aux automates de dialoguer avec les centrales d’acquisition, le
protocole Modbus TCP est utilisé. Pour les informations théoriques sur le fonctionnement de
ce protocole, se référer au paragraphe 2.3.2.
4.3.2.1
Le plan mémoire Modbus TCP
Un certain nombre d’informations relatives au fonctionnement de la centrale d’acquisition
sont disponible via Modbus. Ces informations sont répertoriées dans ce que l’on appelle un
« plan mémoire ».
Ce plan est une table indiquant :
-
L’adresse de la donnée (pour le client Modbus)
Le type de donnée (entier, réel, caractère ascii, etc.)
Son label
Une description succincte de cette donnée
L’unité de la donnée (dans le cas d’un nombre)
Son type d’accès (lecture seule, écriture seule ou lecture et écriture)
Un exemple de variables dans le plan mémoire est donné dans le tableau ci-dessous
Adresse
Type
Label
Modbus
Hex Dec
0018 24 Octets
OSName
0034 52 Short Declench_Acqui
0100 256
Float
Rx
Description
Nom de l'OS (char [16])
Déclenchement de l'acquisition
(0 : Off, 1 : On)
Mesure résistance 1
Unité R/W
R
R/W
Ω
R
Lorsque l’automate souhaite accéder à une donnée, il doit indiquer son adresse dans le plan
Modbus. Le système ne va pas forcément toujours allouer le même emplacement dans la
RAM pour cette donnée. C’est le plan mémoire qui permet de résoudre ceci. Il existe pour
permettre d’attribuer une adresse « arbitraire » fixe à la variable, qui sera l’adresse à
indiquer pour accéder à celle-ci, mais qui n’a rien à voir avec l’adresse réelle dans la
mémoire. Ce plan sert donc « d’interface », de lien, entre la mémoire et l’automate (Figure
25).
PFE / Génie Electrique / Fabien AUBERT
35
Figure 25 - Interfaçage du plan mémoire entre le client Modbus et la RAM dans laquelle est stockée la
donnée voulue
Le plan mémoire est réalisé par le concepteur du système, pour l’utilisateur. En théorie,
l’attribution des adresses, pour chacune des variables, n’a aucune importance. En pratique,
ce plan ne doit pas être réalisé au hasard afin d'optimiser la communication.
En effet, lors d’une requête Modbus, le client indique le nombre de mots qu’il souhaite
récupérer à partir d’une certaine adresse, dans la limite des 248 octets (124 mots) maximum
de donnée contenus dans une trame Modbus TCP.
Par exemple, si l’automate (le client) veut récupérer les valeurs de résistance et de
température des 8 voies de mesures et que celles-ci sont éparpillées dans le plan, il lui
faudra plusieurs requêtes pour les avoir. Cependant, si ces données sont contigües dans le
plan mémoire, il pourra les récupérer en n’ayant besoin que d’une seule requête ce qui
diminue grandement la durée de l’opération. Le but est donc de regrouper les données
susceptibles d’être demandées en même temps pour optimiser les échanges.
Il n’y a pas de « recette miracle » indiquant comment organiser un plan mémoire, il faut
donc bien réfléchir lors de son établissement. Bien entendu, il arrive souvent que l’on n’ait
pas tout anticipé la première fois et que des modifications soient apportées après coup.
4.3.2.2
Agencement des données dans le plan mémoire Modbus
L’unité de base dans le protocole Modbus est le mot et non pas l’octet. Un mot est composé
de deux octets. La norme pour le Modbus stipule que les données doivent être codées au
format Big Endian (de l’octet de poids fort vers l’octet de poids faible).
Par exemple, un nombre codé sur 32 bits comme le nombre : 0xA0B1C2D3 sera enregistré
dans l’ordre suivant en mémoire : A0 B1 C2 D3. L’octet de poids le plus fort (ici A0) est
enregistré à l'adresse mémoire la plus petite, l'octet de poids inférieur (ici B1) est enregistré
à l'adresse mémoire suivante et ainsi de suite.
PFE / Génie Electrique / Fabien AUBERT
36
…
0
1
2
3
A0
B1
C2
D3
…
Le Microblaze (le processeur implanté dans le FPGA) fonctionne aussi au format Big Endian.
Cependant, pour des raisons d’homogénéité entre les différents systèmes développés par le
SBT et le fait que les automates utilisés fonctionnent au format Little Endian, des
ajustements ont été apportés. Lors de l’envoi de données via Modbus, une variable codée
sur plusieurs mots gardera le format Big Endian à l’intérieur d’un mot mais les mots de poids
fort et de poids faible seront inversés (format Little Endian).
Ainsi, si l’on reprend l’exemple précédent, la même valeur sera envoyée de cette manière :
…
0
1
2
3
C2
D3
A0
B1
…
Un autre problème s’est posé pour ce qui est de l’envoi de chaînes de caractères. Les chaînes
de caractères sont des suites de caractères (chacun codé sur un octet) indépendants entre
eux. L’automate, lors de la réception, vient inverser les octets d’un mot pour correspondre
au format Little Endian dans lequel il fonctionne. Ainsi, les caractères de la chaîne sont
envoyés en étant inversés deux à deux. Afin d’éviter les problèmes dus aux caractères de fin
de chaînes (« \0 »), qui pourraient « arriver » avant le dernier caractère du mot, nous
n’écrivons que des chaîne de longueur paire (au besoin nous rajoutons un espace à la fin de
la chaîne) et nous ajoutons deux fois le caractère « \0 » à la suite.
Par exemple :
Mot
VOITURES
VOITURE
O
O
V
V
T
T
I
I
Codage
R
U
R
U
S
-
E
E
\0
\0
\0
\0
Certains ajustements dans le plan mémoire Modbus contenu dans le programme ont été
réalisés pour correspondre à la forme des données envoyées via Modbus. Ces artifices
internes ne sont pas vus de l’extérieur. Afin d’être certain que le décodage se fasse
correctement, des valeurs types sont disponibles au début du plan Modbus :
Adresse
Modbus
Hex Dec
Type
Label
Description
0028
0029
002B
Short
Int
Float
Valeur
Valeur
Valeur
Lecture mot valeur 4660 (0x1234)
Lecture int valeur 439041101 (0x1A2B3C4D)
Lecture float valeur 123456.789 (0x47F12065)
40
41
43
PFE / Génie Electrique / Fabien AUBERT
Unité R/W
R
R
R
37
4.3.2.3
Fonctionnement d’une requête Modbus TCP
La centrale d’acquisition a le rôle de serveur dans la communication Modbus, autrement dit,
elle agit comme un esclave, elle ne fait que répondre à des requêtes qui lui sont envoyées.
Comme vu dans le paragraphe 2.3.2, une trame Modbus se présente de cette façon :
Identifiant
de
Transaction
(2 octets)
Identifiant
de
Protocole
(2 octets)
Longueur
de Champ
Identifiant
de l’Unité
Code
Fonction
(2 octets)
(1 octet)
(1 octet)
Données
(N octets)
Par exemple, si l’automate veut venir lire 10 mots à partir de l’adresse 8, la requête sera la
suivante :
Identifiant de
Transaction
00 00
(+1 à chaque
requête)
Identifiant de
Protocole
00 00
(Modbus)
Longueur
de Champ
00 06
Identifiant
de l’Unité
02
(Non utilisé)
Code
Fonction
03
(Lecture)
Données
00 08
00 0A
(Adresse) (Quantité)
La longueur de champ indique le nombre d’octets derrière ce champ. Ici il y en a 6 car :
- 1 pour l’Identifiant de l’Unité,
- 1 pour le code fonction,
- 2 pour l’adresse,
- 2 pour la quantité de mots à lire.
La réponse à cette requête serait la suivante :
Identifiant de
Transaction
00 00
(recopiée par
le serveur)
Identifiant
de Protocole
00 00
(Modbus)
Longueur
de Champ
00 17
(23 en
décimal)
Identifiant
de l’Unité
02
(Non utilisé)
Code
Fonction
03
(Lecture)
Données
00 14
(Nombre
d’octets : 20
en décimal)
20 octets
de
données
(10 mots)
Dans le cas d’une écriture, le code fonction serait de 6 ou 16 suivant si l’on écrit un ou
plusieurs mots.
Du point de vue requête, à la place de la « quantité », il y aurait les données à écrire. Le mot
indiquant la « longueur de champ » serait modifiée pour correspondre au nombre de
données à écrire.
La réponse indiquerait l’adresse mémoire de début et le nombre de mots écrits. La réponse
dans le cas d’une écriture a plus pour vocation de confirmer que la requête a été traitée et
traitée correctement, qu’autre chose.
PFE / Génie Electrique / Fabien AUBERT
38
4.3.2.4
Mise en place de la communication Modbus
Comme indiqué dans le paragraphe précédent (voir chapitre 4.3.1), la pile TCP/IP est
implémentée grâce à la « lwip ». Nous utilisons donc des fonctions de cette bibliothèque
pour réaliser les différentes connexions réseau.
Le principe d’une connexion repose sur l’utilisation de sockets. Un socket est « une interface
logicielle avec les services du système d’exploitation, grâce à laquelle un développeur
exploitera facilement et de manière uniforme les services d’un protocole réseau. »
L’utilisation de socket permet donc de
mettre en place des communications
réseau et de gérer l’interface réseau
de façon transparente pour le
développeur.
Au début d’une connexion, le client
envoi une demande de connexion que
le serveur accepte si il le peut
(nombre maximum de connexions en
même temps). A partir de là une
connexion durable est établie entre le
client et le serveur, de telle façon que
l'adresse de destination n'est pas
nécessaire à chaque envoi de
données. C’est ce que l’on appelle
travailler en mode « connecté ». Ce
type de fonctionnement peut
s’apparenter à une communication
téléphonique. Du point de vue du
système,
lors
d’une
nouvelle
connexion, un nouveau thread est
lancé et se charge de répondre aux
requêtes du client. Il y aura autant de
thread que de connexion.
La connexion reste établie jusqu’à ce
qu’elle soit volontairement coupée
par l’un des deux protagonistes ou
jusqu’à ce qu’elle se coupe faute
d’activité pendant une certaine durée
(quelques dizaines de secondes).
PFE / Génie Electrique / Fabien AUBERT
Figure 26 - Connexion entre un client et un serveur avec
l'utilisation de sockets
39
4.3.3 Serveur web, serveur TFTP, echo server
Xilinx met à disposition de nombreuses notes d’application pour les composants qu’ils
proposent. Ces notes d’application sont généralement accompagnées d’exemples assez
détaillés. Dans la note d’application de la lwIP (« XAPP 1026 »), plusieurs exemples étaient
proposés comme notamment un serveur web (permettant une interface via un navigateur
web), un serveur TFTP (Protocole simplifié de transfert de fichiers en français) ou encore un
« echo serveur ». Ce dernier est un programme simple permettant de renvoyer ce qu’on lui
envoie via le réseau.
Nous avons repris ces éléments et les avons implémentés dans notre programme. Ceci nous
permet d’avoir plusieurs moyens d’accès aux fichiers présents sur la carte. En modifiant
l’ « echo server » nous avons réalisé une sorte de mini invité de commande comme sous
Windows ou Linux. Nous avons rajouté la possibilité d’afficher les fichiers présents dans le
système de fichier, de supprimer des fichiers, de sauvegarder le système de fichier dans la
flash, etc.
Le fonctionnement reste le même que celui utilisé pour la communication Modbus
(utilisation de sockets, écoute sur le port, etc.).
4.4 Traitement et stockage des acquisitions
Après l’initialisation des sémaphores, le thread principal est lancé. C’est celui de plus haute
priorité car il ne doit pas être interrompu par un autre thread. Ayant, la plus haute priorité,
c’est lui qui prend la main sur n’importe quel thread même si ce dernier n’a pas fini son
action en cours.
Lors du démarrage de ce thread, celui-ci lance à son tour un autre thread, de priorité plus
faible qui va servir à stocker des mesures pendant un cours laps de temps, dans un fichier.
A une fréquence d’1kHz, une nouvelle série d’acquisition arrive, c'est-à-dire 8 valeurs de
tension et de courant, une pour chaque voie de mesure. Une interruption est alors
déclenchée. Cette interruption va libérer un sémaphore qui va déclencher une série de
calculs dans le thread principal. Après la libération du sémaphore, le thread principal
démarre le calcul de résistance et de température pour les 8 voies, stocke ces valeurs dans
une mémoire tampon et met à jour les données venant du Modbus.
4.4.1 Calcul de résistance et de température
Le calcul de résistance est assez rapide même si ce n'est pas juste U/I, il faut appliquer les
fameux coefficients de calibrage. La durée est de l'ordre de la µs.
Par contre pour le calcul de T il faut « linéariser » à partir d’un polynôme, d’un polynôme en
logarithme ou d’une table de conversion suivant la précision souhaitée.
PFE / Génie Electrique / Fabien AUBERT
40
Nous avons vu dans le paragraphe 2.2.2 que la variation de résistance en fonction de la
température est grandement non linéaire.
Le calcul de température à l'aide d'un polynôme nécessite d'avoir un ordre élevé pour
obtenir une bonne précision, ce qui augmente le temps de calcul. Nous avons choisis
d'utiliser des polynômes d'ordre 4 ce qui permet de limiter le nombre de calculs et donc de
diminuer les temps de conversion au détriment de la précision.
La conversion à l'aide d'une table de point permet d'avoir un résultat rapidement mais
nécessite un grand nombre de points pour garantir une bonne précision ce qui engendre une
quantité plus importante de données à garder en mémoire. Nous avons choisi d'utiliser des
tables contenant un maximum de 100 points.
Le polynôme de type log est la méthode de conversion la plus précise implémentée dans ce
système mais nécessite des capacités de traitement plus importantes. Le calcul est le
suivant :
Avec X = ln(R).
Lors de la création de la plateforme matérielle, un composant permettant d'optimiser les
calculs en flottant (simple précision : codé sur 4 octets) a été activé (FPU). Le calcul des
additions, multiplications et divisions en flottant est alors très rapide (quelques cycles
d'horloges). Par contre, la fonction log provenant de la librairie « math.h » effectue le calcul
en double précision. Pour calculer le log elle commence par convertir la valeur de R (qui est
en flottant) en double, calcule le log et reconverti en flottant. L’exécution de ce calcul
n'utilise pas le composant d'optimisation ce qui fait que rien que le calcul du log prend
environ 300µs.
Sachant que 8 calculs (un pour chaque voie) de R et T doivent être exécutés à chaque
interruption, la durée totale est d'environ 2,5ms. Or, lors de l'acquisition, les échantillons
arrivent à une fréquence de 1kHz (toutes les 1ms). Dans l'état actuel des choses, le calcul des
températures ne pourrait pas être fait en temps réel.
Nous avons essayé de trouver s’il existait une autre librairie effectuant le calcul de
logarithme en flottant mais nous n’en avons pas trouvé. Nous avons donc reprogrammé la
fonction logarithme à partir de l’algorithme de Cordic. C’est un algorithme de calcul des
fonctions trigonométriques et hyperboliques, notamment utilisé dans les calculatrices. Il
permet d'avoir un résultat très précis (de l’ordre de 10-6) en très peu d’itérations. Ce procédé
a permis de diviser le temps de calcul par environ 10. L’économie sur le temps de calcul
essentiellement du au fait de travailler avec des flottants plutôt que des doubles et ainsi
permettre l’utilisation du FPU. Ainsi, maintenant, en environ 250µs, il est possible de faire
les 8 calculs de résistance et de température, contre plus de 2ms sans cette méthode.
PFE / Génie Electrique / Fabien AUBERT
41
4.4.2 Archivage des mesures
Après avoir calculé les résistances et les températures, celles-ci sont archivées dans une
mémoire tampon tournante. Cette mémoire permet d’archiver n échantillons avant de les
effacer un par un, en commençant par le plus ancien pour les remplacer par de nouveaux
échantillons. Ceci offre la possibilité, lors du démarrage d’une acquisition en mode
« rapide », d’ajouter dans le fichier un certain nombre de mesures précédentes. Ceci permet
aussi, dans le cas où entre deux acquisitions nous n’arriverions pas, pour n’importe quelle
raison, à archiver l’acquisition dans le fichier, de pouvoir le faire un peu plus tard.
Figure 27 - Représentation de la mémoire tampon tournante
La profondeur de cette mémoire dépend du nombre d’éléments que l’on souhaite pouvoir
conserver. Cette profondeur doit être ni trop grande, pour ne pas monopoliser trop
d’emplacements mémoire, ni trop petite pour que ceci ait un intérêt. Cette mémoire est en
réalité un tableau de structures contenant les valeurs de résistance et de température pour
chacune des voies, ainsi qu’un statut codé sur 4 octets qui indique la validité des mesures
(pas de saturation, de défaillance matérielle, etc.). Chaque valeur de résistance ou de
température étant codée sur 4 octets, la taille d’un échantillon (8 résistances + 8
températures + 1 statut) est de 68 octets. Nous avons opté pour une profondeur de 1000
échantillons (1 seconde d’acquisition) soit une taille d’environ 68 ko car cela nous semble
être un bon compromis.
PFE / Génie Electrique / Fabien AUBERT
42
Il est possible d’activer la sauvegarde de ces mesures, pendant quelques minutes maximum,
dans un fichier. La durée dépend de la taille maximum que peut prendre le fichier, donc de la
taille disponible dans le système de fichier. Il est possible de modifier le nombre de voies que
nous souhaitons stocker dans le fichier ainsi que le fait de stocker uniquement les
résistances ou à la fois les résistances et les températures. Pour permettre d’augmenter
encore le temps d’enregistrement, les données sont stockées dans le format binaire qui est
le plus compact.
4.4.3 Visibilité des mesures depuis l’extérieur
Le fichier de mesures est disponible via le serveur web ou un transfert TFTP. Un programme
en C a été réalisé pour permettre de convertir le fichier au format ASCII une fois transféré
sur le PC.
Le second canal d’accès aux mesures utilise la communication Modbus. Ceci permet à
l’automate de récupérer les mesures. Cependant, la vitesse à laquelle ces mesures sont
disponibles est réduite à 100hz soit un échantillon sur dix. Ce qui est amplement suffisant au
contrôle de process. Pour éviter des erreurs dues aux repliements de spectres, la bande
passante est réduite à 10Hz. Les valeurs de résistances doivent être alors être filtrées avant
d’être disponibles. Un filtre numérique de type IIR : filtre à réponse impulsionnelle infinie,
d’ordre 4 est donc mis en place. Toutes les 10 acquisitions un nouveau calcul de
température est réalisé à partir des valeurs de résistance filtrées courantes. Ces mesures
sont alors mises à disposition pour être réceptionnées via Modbus. En revanche, par ce
moyen toute acquisition non récupérée est perdue car elle n’est pas stockée en mémoire.
PFE / Génie Electrique / Fabien AUBERT
43
4.5 Ordonnancement des tâches
Par défaut, le noyau utilisé (Xilkernel) propose 32 niveaux de priorité pour les threads. Le
thread de priorité 0 aura la plus haute priorité et plus ce chiffre augmentera plus la priorité
sera faible. Les interruptions restent cependant prioritaires sur n’importe quel autre thread.
Dans ce système, nous n’utilisons que deux niveaux de priorité. Tous les threads ont une
priorité de 1 à l’exception d’un seul : le thread d’acquisition qui a une priorité de 0. Il est
absolument indispensable que ce dernier prenne la main lors de l’arrivée de nouvelles
mesures et qu’il ait fini avant l’arrivée des mesures suivantes (1 ms plus tard). Pour garantir
ceci, il a une priorité 0 mais, de plus, il est le seul à l’avoir donc il n’y a que lui qui utilise les
ressources processeurs pendant qu’il effectue ses opérations.
A titre d’information, sur le kit SP605 avec la gestion du cache par le processeur et le FPU
(Floatting Point Unit) activé, l’ensemble de ces taches durait moins de 300µs. A ceci, il faut
rajouter environ 70µs pour venir récupérer les valeurs de U et I. Cette opération est
effectuée dans la routine d’interruption. Il reste alors environ 630µs durant lesquelles les
autres threads peuvent se partager les ressources processeur.
Les autres threads ayant tous une priorité de 1, l’ordonnanceur va leur attribuer à chacun, et
de façon alternée, des courts laps de temps (une dizaine de µs à chaque fois) d’utilisation du
CPU.
I
N
T
E
R
R
U
P
T
I
O
N
Conversion
en R et T
+
Filtrage
70µs
300µs
Serveur Modbus TCP
Serveur web
Serveur TFTP
Sauvegarde des mesures
dans un fichier
Autres
PFE / Génie Electrique / Fabien AUBERT
630µs
44
5 Portage sur la carte prototype CABTR
Un prototype de la CABTR a été réalisé avant que je ne commence mon stage. Ce prototype
comporte 8 voies de mesures et, peut être utilisé pour les deux versions de la CABTR.
Pour ce qui est de la version autonome, la carte réalisée en début de stage, permettant
l’interface Ethernet fonctionne correctement.
Le FPGA utilisé est identique à celui présent sur le kit SP605. Les principales différences
matérielles résident dans les mémoires utilisées.
La mémoire flash est de la même famille que celle présente sur le kit mais n’a qu’une taille
de 16Mo contre 32Mo.
La principale différence, et non des moindres, réside dans la mémoire RAM utilisée. Le
prototype est équipé d’une SDR SDRAM de 16Mo alors que le kit comporte 128Mo de
mémoire DDR3.
5.1 Problèmes liés à l’utilisation d’une mémoire de
type SDR SDRAM
Ce choix de mémoire avait été fait pour plusieurs raisons dont voici les principales:
-
La DDR3 nécessite une alimentation 1,5V et une référence à 0,75V pour les
résistances de terminaisons,
La simplicité de mise en œuvre,
Le coût du composant,
Le fait que la fréquence de fonctionnement est limitée par le Microblaze (83,3Mhz)
et ne permet pas d’exploiter les avantages de rapidité liés à la DDR3.
Etc.
Cependant, ce type de mémoire étant jugé obsolète par Xilinx, l’entreprise ne fournit plus de
contrôleur pour les versions 6 et supérieures de leurs FPGA (Spartan-6, Virtex-6, etc.). Une
équipe du CEA de Saclay qui travaille conjointement sur ce projet et qui avait proposé ce
type de SDR, car ils avaient l’habitude de travailler avec, avaient développé un contrôleur
pour celle-ci.
Malheureusement, le contrôleur développé ne permettait pas l’utilisation des bus « XCL »
(« Xilinx Cache Link ») qui sont les connexions privilégiées entre le Microblaze et la RAM pour
l’utilisation du cache d’instructions et de données. Dans la version actuelle de la CABTR (avec
l’interface processeur MII) le code exécuté par le Microblaze est minime et il n’y a pas de
système d’exploitation. L’ensemble de la partie logicielle peut tenir directement dans la
PFE / Génie Electrique / Fabien AUBERT
45
mémoire cache du processeur (64ko), ce qui n’est pas possible dans la version autonome
puisque le code dépasse les 200ko.
Les performances du système se sont donc écroulées car à chaque instruction le processeur
devait venir chercher l’instruction et les données nécessaires dans la SDR or les temps
d’accès sont beaucoup plus long que ceux de la mémoire cache.
Afin d’avoir une idée de la différence de performance obtenue, nous avons mesuré la durée
de calcul des 8 logarithmes, avec l’algorithme de Cordic et le FPU activé, dans les deux cas.
Avec l’utilisation du cache processeur ces 8 calculs s’exécutent en 90-100µs au total contre
1000-1200µs (1-1,2ms) sans. Ce qui fait environ un facteur 10. Sachant qu’en 1ms nous
avons pour contrainte d’au moins récupérer les 8 mesures, d’effectuer les 8 conversions en
résistance puis en températures ainsi que leur filtrage, nous ne respectons largement plus
les contraintes de temps.
Nous avons trouvé un contrôleur de SDR compatible réalisé par l’entreprise « Logic Bricks »,
permettant l’utilisation des bus XCL et donc du cache. Ce composant est cependant soumis à
une licence payante mais nous utilisons pour l’instant une version de démonstration
gratuite. Cette version possède les mêmes fonctionnalités et caractéristiques de la version
payante à ceci près que son utilisation est limitée à quelques heures. Dépassé ce cours laps
de temps, le FPGA doit de nouveau être programmé, ce qui n’est pas viable pour un
déploiement à grande échelle du projet.
Nous avons passé plusieurs semaines (avec l’aide de leur support technique) à essayer de
faire fonctionner ce contrôleur. Le composant n’avait pas été testé pour une utilisation avec
les dernières versions du Microblaze et comportait plusieurs bogues.
L’entreprise a donc procédé à certaines modifications de leur composant, et ce n’est qu’au
bout de la quatrième semaine que ces bogues ont étés corrigés.
Nous avons alors pu tester les performances de notre projet avec une SDR. Celles-ci sont
quasiment similaires à celles obtenues avec de la DDR3.
En théorie, le système devrait être plus rapide avec de la DDR3 puisque cette technologie est
réputée pour sa rapidité. De plus comme son nom l’indique, une RAM de type SDR (Simple
Data Rate), n’échange des données que sur les fronts montants d’horloge. Alors que la
technologie DDR (Double Data Rate) permet des échanges à la fois sur fronts montants et
sur fronts descendants (2 échanges par période).
Cependant, si l’on regarde de plus près, ceci peut aisément se comprendre. La fréquence
d’horloge, fixée par le Microblaze à 83,3 Mhz, est la même pour les deux type de RAM, donc
la DDR3 n’est pas utilisée à son plein potentiel. La DDR3 devrait quand même être plus
rapide puisqu’il y a 2 échanges par période mais la taille du bus de données de la DDR3 est
de 16 bits contre 32 bits pour la SDR, donc les performances s’équilibrent.
PFE / Génie Electrique / Fabien AUBERT
46
De plus, les instructions et les données étant dans le cache processeur, qui est identique
dans les 2 cas, les temps d’accès aux informations sont identiques.
Le choix de la SDR semble donc judicieux mais, à moins de développer nous même un
contrôleur de SDR permettant la gestion des bus XCL, les économies réalisées sur le prix du
composant, du routage, etc. sont malheureusement contrebalancées par le coût de la
licence du contrôleur de l’entreprise « Logic Bricks » qui s’élèvent à 2000€ pour 3 ans.
Un nouveau prototype doit être réalisé pour cette version de la CABTR, intégrant
notamment les composants pour l’interface Ethernet. Nous avons décidé de modifier le type
de RAM utilisé et passer sur de la LPDDR (Low Power DDR) ou de la DDR3 qui seraient
compatibles avec le contrôleur fournit par Xilinx.
Ce choix a été renforcé par le fait que les FPGA de type Spartan-6, comme celui que nous
utilisons, intègrent « en dur » dans le composant un contrôleur pour ce type de mémoire. Le
terme « en dur » signifie que ce bloc est gravé dans la puce du FPGA lors de sa création.
Comparé à un composant équivalent réalisé en VHDL, le fait d’intégrer le contrôleur :
-
Améliore fortement les performances,
Réduit la consommation énergétique,
Réduit la durée de la synthèse par le compilateur VHDL, puisque le composant n’a
pas à être synthétisé,
Libère des ressources du FPGA pour une autre utilisation.
5.2 Intégration de la récupération des mesures
L’autre différence importante par rapport au projet sur le kit SP605 correspond à la gestion
des mesures. En effet sur le kit l’arrivée des mesures était simulée par un signal délivré par
un GBF (Générateur Basse Fréquence) qui permettait de déclencher une interruption toutes
les millisecondes.
Sur le prototype, la gestion/traitement des mesures est réellement exécutée. Les blocs
correspondant à l’interface entre la partie analogique et le prétraitement numérique dans le
FPGA ont été réalisés pour la version actuelle de la CABTR. Cette partie ayant déjà été traitée
antérieurement elle a été reprise telle qu’elle.
Le fonctionnement est quelque peu différent, par rapport au projet sur le kit de
développement, car cette fois-ci, toutes les millisecondes, nous n’avons pas 1 mais 8
interruptions espacées chacune de 10µs. Ceci provient du fait que le composant envoyant le
signal d’interruption, ne stocke la mesure que d’une voie à la fois et déclenche une
interruption dès qu’une voie est prête à être transférée.
Ce fonctionnement rajoute une contrainte assez forte que l’on ne peut pas respecter dans
cette version avec un OS et différents threads. Une des sources du problème provient du
PFE / Génie Electrique / Fabien AUBERT
47
cache dans lequel le code de l’interruption ne se trouve pas forcément au moment où elle
est appelée. Ce qui nécessite un rechargement du cache et donc fait perdre quelques
précieuses microsecondes. De manière générale, pour chaque interruption, nous
commençons par masquer les interruptions, puis nous exécutons les instructions de
l'interruption, acquittons que celle-ci a été traitée et finissons par démasquer les
interruptions. La durée moyenne d’une interruption, obtenue de manière empirique, est
supérieure à 15µs ce qui fait que nous perdons environ un tiers des mesures.
5.3 Evolutions
Il sera nécessaire de faire évoluer le fonctionnement du composant délivrant l’interruption
pour permettre de stocker au minimum les 8 mesures simultanément. Par exemple il
pourrait contenir une FIFO permettant de stocker temporairement quelques échantillons
supplémentaires pour rendre le système plus robuste.
Un seul signal d’interruption devra être délivré pour indiquer que les 8 voies de mesure sont
disponibles. Ceci permettra d’être plus souple et réduira le temps global de récupération des
données puisque le code ne devra être chargé qu’une seule fois, le masquage/démasquage
ainsi que l’acquittement des interruptions ne se fera aussi qu’une fois. De plus lors d’une
interruption plusieurs autres actions sont effectuées comme la sauvegarde du contexte par
le processeur par exemple, chose qui ne sera faite plus qu’une fois avec cette nouvelle
méthode.
A titre de comparaison, nous avons effectué d’autres tests qui nous ont permis d’évaluer le
temps mis par le processeur pour effectuer la récupération des 8 voies de mesures en une
seule interruption. En moyenne, la durée totale d’une interruption dans ce cas-ci est
d’environ 70µs, contre plus de 120µs dans le cas présent si l’on met bout à bout tous les
temps.
PFE / Génie Electrique / Fabien AUBERT
48
CONCLUSION
Le but initial du projet qui était de développer une interface Ethernet pour la centrale
d’acquisition basses températures est atteint.
L’application multitâche développée durant ce stage, permet de traiter puis convertir en
température des échantillons tout en respectant les contraintes temporelles liées à l’arrivée
des mesures à une fréquence de 1kHz. Les tâches réseau fonctionnent en parallèle sans
toutefois perturber la fonction principale du système qui est la mesure de température.
Cette version de la centrale d’acquisition n’est cependant pas encore totalement terminée.
Certaines modifications doivent encore être réalisées pour avoir un système entièrement
fonctionnel. Un nouveau prototype dédié à cette version est en cours d’étude. Certaines
modifications vont y être apportées comme l’intégration sur la carte des composants
réalisant l’interface Ethernet, le remplacement de la mémoire SDR SDRAM par une LPDDR
DRAM, etc. Des modifications au niveau des composants VHDL permettant l’acquisition des
mesures doivent encore être apportées pour correspondre avec les nouvelles spécifications
de cette version.
D’un point de vue personnel, ce stage a été très instructif puisqu’il m’a permis d’utiliser les
connaissances apprises tout au long de mon cursus scolaire, de développer mes
connaissances sur les FPGA, sur les réseaux, les systèmes multitâches, etc.
Durant ce stage, j’ai pu me rendre compte de l’énorme potentiel des FPGA. Même si le
modèle utilisé dans ce projet, Spartan-6, est considéré comme un FPGA « low-cost » les
possibilités qu’il offre sont impressionnantes. Au vu du travail effectué durant ce stage, je
peux dire que des connaissances en VHDL ne sont pas forcément indispensables, suivant
l’application, pour réaliser un système relativement complexe en utilisant des FPGA.
PFE / Génie Electrique / Fabien AUBERT
49
LEXIQUE
Ce chapitre regroupe différents termes ou acronymes utilisés dans ce rapport
CEA : Acronyme de « Commissariat à l’Energie Atomique et aux énergies alternatives ».
INAC : Acronyme de « Institut Nanoscience et Cryogénie ».
DSM : Acronyme de « Direction des Sciences et de la Matière ».
GEA : Acronyme de « Groupe Electronique et Automatique ».
Flottant : Type de variable représentant les nombres réels en simple précision (32 bits).
Double : Type de variable représentant les nombres réels en double précision (64 bits).
Linéarisation : Nom du procédé de conversion permettant de passer d’une valeur de
résistance à une valeur de température.
Calibrage / Calibration : Synonyme d’étalonnage. Sert à compenser les différences
physiques entre les voies de mesure.
FPGA : Acronyme de « Field-Programmable Gate Array ». Circuit intégré faisant partie de la
famille des Composants à Logique Programmable. Ce composant est programmé à partir
d’un langage de programmation spécifique : le VHDL.
Processeur softcore : Processeur (CPU) implémenté sur un système reprogrammable comme
un FPGA.
Processeur hardcore : Processeur (CPU) intégré dans la puce d’un composant, comme un
FPGA, lors de sa création. C’est le contraire d’un processeur softcore car il ne provient pas
d’une programmation et ne peut pas être remplacé par un autre composant.
Microblaze : Cœur de processeur softcore 32 bits de la société Xilinx. Il est conçu pour être
implémenté sur les FPGA de ce fabricant.
OS : Acronyme de « Operating System ». Se traduit en Français par système d’exploitation.
Xilkernel : Mini système d’exploitation (OS) temps réel développé par Xilinx pour pouvoir
être implémenté sur Microblaze.
CABTR : Acronyme de « Centrale d’Acquisition Basse Température Rapide ». C’est le nom
donné par le SBT au système de mesure de température pour lequel est réalisé ce projet.
Modbus : Protocole de communication utilisé par des réseaux d'automates programmables.
PFE / Génie Electrique / Fabien AUBERT
50
FPU : Acronyme de « Floating Point Unit » (unité de calcul en virgule flottante). Partie d'un
processeur, spécialement conçu pour effectuer des opérations sur des nombres à virgule
flottante.
Socket : Peut se traduire par « connecteur réseau ». Il s’agit d’une interface logicielle avec
les services du système d’exploitation, grâce à laquelle un développeur exploitera facilement
et de manière uniforme les services d’un protocole réseau.
SDRAM : Acronyme de « Synchronous Dynamic Random Access Memory » (en français,
Mémoire Dynamique Synchrone à Accès Aléatoire). Type particulier de mémoire vive ayant
une interface de communication synchrone.
SDR SDRAM : Acronyme de « Single Data Rate » SDRAM. Mémoire de type synchrone avec
des échanges uniquement sur fronts montants d’horloge. L’amalgame est souvent fait entre
SDR SDRAM et SDRAM.
DDR SDRAM : Acronyme de « Double Data Rate » SDRAM. Mémoire de type synchrone avec
des échanges à la fois sur fronts montants et descendants d’horloge.
FIFO : Acronyme de « First In First Out » qui se traduit littéralement par « Premier arrivé,
premier sorti ». C’est un système de traitement des éléments d’une file suivant leur ordre
d’arrivé.
Thread : Peut se traduire en français par « processus léger ». Les threads se distinguent du
multiprocessus plus classique par le fait que deux processus sont typiquement indépendants
alors que les threads partagent des zones de mémoires ainsi que d'autres ressources.
Zone critique ou section critique : Portion de code dans laquelle il doit être garanti qu'il n'y
aura jamais plus d'un thread simultanément. Il est nécessaire d'utiliser des sections critiques
lorsqu'il y a accès à des ressources partagées par plusieurs threads.
PFE / Génie Electrique / Fabien AUBERT
51
BIBLIOGRAPHIE
Documentation Microblaze :
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/mb_ref_guide.pdf
Documentation Xilkernel :
http://xlnx.lithium.com/xlnx/attachments/xlnx/EMBEDDED/4789/1/xilkernel_v5_00_a.pdf
Note d’application lwIP :
http://www.xilinx.com/support/documentation/application_notes/xapp1026.pdf
Documentation modèle TCP :
http://www.commentcamarche.net/contents/internet/tcpip.php3
Note d’application Nationnal Semiconducter sur l’implémentation de l'émetteur-récepteur :
http://www.national.com/an/AN/AN-1469.pdf
Explication et démonstration de l'algorithme de Cordic pour calculer le logarithme :
http://www.mlfmonde.org/IMG/pdf/31_40_ams62.pdf
PFE / Génie Electrique / Fabien AUBERT
52