Projet Light

UE PBD Plateform Based Design Master SESI

Olivier ROMAIN

[email protected] 01 44 27 96 33

1

Plateform Based Design

PROJET LIGHT EQUIPE TOURISTE

Conception d’un nœud de capteurs sans-fil pour

la surveillance des locaux du master SESI


Olivier ROMAIN


2

I. Introduction

1.1 Les réseaux de capteurs sans-fil

1.1.1. En quoi ça consiste?

Les capteurs sont des éléments essentiels dans tous les systèmes où les informations issues de l'environnement extérieur sont nécessaires pour évoluer et agir. De ce fait, avoir une connaissance précise et complète sur ce milieu exige le déploiement de plusieurs capteurs, et si possible, conjuguer toutes les informations renvoyées pour mieux ajuster les paramètres de chaque capteur. L'avancée remarquable dans le domaine des télécommunications a permis de supprimer les liaisons filaires de transmission fort encombrantes. D'autant plus que les câbles d'alimentations ne sont plus indispensables étant donné que la consommation de tels circuits n'a cessé de baisser. Toutes ces fonctionnalités nous permettent d'imaginer un système complexe construit autour de plusieurs capteurs en communication sans fils, capables de s'adapter selon les évolutions rencontrées. Un réseau de capteur est constitué d'un grand nombre d’unités (nœuds). Chaque nœud est composé d'un ou plusieurs capteurs, d'une unité de traitement et module de communication. Les unités d'un réseau dialoguent entres elles selon la topologie du réseau et l'existence ou pas d'une infrastructure (points d'accès) afin d’acheminer les informations à une unité de commande hors de la zone de mesure.

1.1.2. Les diverses réalisations pratiques

L'utilisation des capteurs en liaison sans fil devient une nécessité pour construire un système dont la mobilité est une caractéristique dominante. On parle alors de capteurs embarqués sur des unités mobiles, voir fixes repartis sur une surface considérable. Dans ce cas, la transmission des acquisitions est plus aisée qu'avec l'utilisation d'une transmission filaire. Les applications d'une telle architecture sont nombreuses dans différents domaines d’applications. Elles dépendent étroitement de la catégorie des capteurs utilisés :

- Capteurs d’Image : caméra CCD ou rétine CMOS.

- Son : voix, vibration, …

- Positionnement : gyroscope, boussole électronique, GPS…

- Capteurs d’environnement : température, pression, radiation, …


Olivier ROMAIN


3

L'une des principales applications est la construction d'un réseau d'unités autonomes mobiles capables de se déplacer dans des zones inconnues, inaccessibles ou hostiles à l'être humain. On arrive ainsi à fournir des informations sur le terrain afin d'établir une stratégie d'évolution selon le but souhaité. On peut par exemple localiser des victimes lors des opérations de sauvetage, ceci est possible grâce à de petits mobiles capables de s'infiltrer à travers les décombres ou d'autres plus étanches pour explorer les fonds aquatiques. Une autre application, et non la moindre, est l'exploitation militaire. Dans ce contexte, l'emploi des réseaux de capteurs peut aller des surveillances de routine des périmètres, jusqu'à assister des attaques aériennes ou terrestres et de conduire des opérations d'espionnage.

Pour cela, il faut qu'aucun élément ne soit indispensable pour le fonctionnement du réseau. Une telle architecture, dite en ad-hoc, permet de maintenir le réseau en action suite à la perte d'un ou de plusieurs éléments.

Figure 1 : Routage de l'information dans un réseau ad-hoc

En effet, un réseau Ad-hoc ne nécessite pas une infrastructure préexistante, où chaque nœud est capable de router l'information. Plusieurs autres applications sont possibles, essentiellement pour des systèmes embarqués.

A

B


Olivier ROMAIN


4

Quelques domaines d'application: - Environnement: Eau, forêt, animaux…

- Transport (MIT): Trafic, état des routes, …

- Spatial (Intel): Exploration de mars.

- Topologie de réseau.

Des laboratoires ont mis en œuvre des réalisations pratiques. Dans ce qui suit, quelques applications sont citées en guise d'exemples et données en annexes : Université de Berkeley (USA) + Intel + DARPA

C'est un réseau constitué de 800 capteurs différents. Chaque élément du réseau est constitué d'un capteur de température et un autre de lumière, une batterie, Module RF T1000, 10kb/s et un microprocesseur ATMEL Risc 8bits 4MHz + RTOS (TinyOs)

- Suisse (Institut fédéral des technologies)

Il s'agit d'une étude topologique d'un réseau Ad-Hoc. C'est un reseau de capteurs de température dotés d'un module Ericsson pour la communication sans fil et un microprocesseur RISC (8 bits, 4MHz et 128 Kbits de memoire flash.

- Université de Pennsylvanie (USA) C'est un système pour contrôler la qualité des eaux.


Olivier ROMAIN


5

- Université de Pise (Italie) Contrôle des parcs naturels : Gaz, feux, animaux, …

Présentation du Projet

• Spécifications • Volet technique • Annexe technique


Olivier ROMAIN


6

II. Spécifications

2.1 Introduction

L’objectif de ce projet consiste en la conception d’un réseau de capteur sans fil qui sera déployé dans les locaux du Master SESI de l’Université Paris 6. Celui-ci permettra en temps réel de mesurer la température afin de prévenir d’un éventuel incendie et de détecter des mouvements au moyen d’un capteur d’image en technologie CMOS. Ainsi par le biais de ce mini réseau, nous pouvons imaginer plusieurs scénarios comme par exemple :

Détecter un incendie par la mesure conjointe de la température et de l’image du feu. Réguler la température dans les salles en fonction de l’exposition solaire. En utilisant,

le réseau de capteur nous pourrons obtenir la cartographie thermique du des bâtiments de l’entreprise, et ainsi optimiser le chauffage en plein hiver par exemple.

Surveiller d’éventuel vol de matériel.

Vérifier la présence des élèves dans la salle. Ainsi une feuille de présence est alors

créée automatiquement sans falsification.

Etc.

2.2 Spécification de l’architecture du réseau de capteur

L’architecture du réseau de capteur sera composée à l’issu de ce projet de plusieurs unités de mesures appelées balises et d’une unité de contrôle (voir Fig 1). Chaque balise envoie ses informations à l’unité de contrôle au moyen d’une liaison sans fil. L’unité de contrôle possède 3 fonctions élémentaires :

• Centraliser les informations de chaque balise en fonctionnement

• Afficher les paramètres de chaque salle mesurés par les balises

• Détecter les possibles scénarios présentés ci-dessus.


Olivier ROMAIN


7

fig. 1: Architecture du réseau de capteurs sans fil

2.2.1. Description de la balise

La balise est composée de trois unités distinctes (figure 2).

fig. 2 : Architecture interne de la balise

Unité d’acquisition

Le rôle de l’unité d’acquisition est d’obtenir des mesures numériques des paramètres environnementaux des salles. Pour cela, l’unité d’acquisition est basée sur l’utilisation de trois capteurs analogiques:

Balise n°1 Balise n°2 Balise n°3

Balise n°4 Balise n°5 Unité de contrôle

Salle 1 Salle 2 Salle 3

Salle 4 Salle 5 Salle 6

Tâche n°0. T°

Tâche n°1. Image

Interface capteur

Interface

µP

Zigbee

T°

Vision

Unité d’acquisition

Unité de traitement Unité de communication


Olivier ROMAIN


8

• un capteur de température

• une caméra CMOS numérique

Le champ de vue d’une caméra étant restreint (<90°), toute la salle ne pourra alors être acquise par ce capteur de vision. Afin d’étendre le champ de vue de la caméra, une monture gyroscopique (azimut et élévation) commandé par deux servomoteurs seront utilisés. Le déplacement de la caméra sera fait par l’unité de traitement suivant deux modes :

o Un mode automatique ou l’unité de traitement déplacera suivant un chemin de positionnement prédéfini par l’utilisateur, la caméra.

o Un mode manuel ou la caméra sera déplacé par l’utilisateur au moyen d’un

joystick de type PS2. Unité de traitement

L’unité de traitement est basée sur l’utilisation de la carte Altera Nios CycloneII. Celle-ci utilise un FPGA de la famille des Cyclones ou un processeur de type Nios II y sera implanté. Le rôle de l’unité de traitement est d’acquérir les informations en provenance de l’unité d’acquisition de les traiter et de les envoyer à l’unité de radiocommunication afin que l’unité de contrôle puisse les réceptionner correctement. Pour cela, le processeur Nios devra intégrer deux interfaces. Unité de radiocommunication

Pour réaliser notre réseau de capteurs sans fil, trois normes peuvent être utilisées, la norme Bluetooth (IEEE802.15), la norme Wifi (IEEE802.11b) et la norme Zigbee (IEEE802.15.4). Le choix entre ces deux normes dépend essentiellement de plusieurs caractéristiques comme la consommation, la possibilité de réaliser des réseaux Ad-hoc, la simplicité d’interfaçage avec la plate forme Altera. Par rapport à l’application envisage, nous avons choisi d’utiliser la norme Zigbee au moyen de module de radiocommunication de type Xbee Pro de la société Maxstream du fait des avantages qu’il confère.


Olivier ROMAIN


9

fig. 3 : Module de radiocommunication de type Xbee pro

2.2.2. L’unité de contrôle

L’unité de contrôle est basée sur l’utilisation d’un PC ou interface de radiocommunication est adjointe. Cette interface sera la même que celle qui sera utilisée dans les balises. La liaison utilisée entre le PC et le module de radiocommunication sera de type série (RS232) comme le montre la figure 4 ci-dessous :

fig. 4 : Architecture de l’unité de contrôle

2.3 Organisation du projet

Le projet sera organisé de la manière suivante :

Des équipes de 4 personnes seront formées avec un responsable. Le responsable de l’équipe aura en charges d’organiser, de gérer et de coordonner les différentes tâches à réaliser pour mener à bien ce projet. Il sera l’interface permanente avec l’encadrant.

Chaque équipe devra réaliser conformément au cahier des charges :

o Une balise o Une unité de contrôle (si le temps le permet)

Chaque équipe devra suivre une méthodologie de type cycle en V comme suit :

Zigbee RS232


Olivier ROMAIN


10

Le volume horaire alloué est de 6 séances de 4h00 le mardi après-midi de 13h30 à

17h30.

Tâche n°0. Un encadrant sera là pour vous débloquer lorsque vous estimerez être

désespéré !

Tâche n°1. L’évaluation sera faite sur quatre critères :

a. Qualité du travail i. Autonomie, travail en équipe, management, produit fini, etc.

b. Rapport de projet i. Clarté, orthographe, grammaire, synthèse et possibilité d’être reprit par

une tierce personne, etc. c. Présentations

i. Clarté, expression orale, qualité des slides, organisation des slides, etc. d. Démonstration

i. Opérationnelle en fin de projet.

III. Volet technique

3.1 Fonctionnalités de la balise

Chaque balise possédera les propriétés fonctionnelles suivantes.

Expression des besoins

Spécifications

Conception générale

Conception détaillée

Réalisation

Maintenance

Validations

Tests Intégration

Tests Unitaires


Olivier ROMAIN


11

3.1.1. Acquisition des données

Les spécifications des capteurs présentés dans le paragraphe sur l’architecture détaillée de la balise sont données en annexe. Les capteurs permettent de mesurer localement des paramètres physiques. 3.1.2. Traitement des données

Les mesures numériques de température devront être corrigées. Un traitement de celles-ci devra être fait afin de les rendre exploitable avant leurs émissions. Les traitements seront réalisés en langage C pour le Nios. L’image acquise par la caméra correspondra à une image de luminance. L’image sera monochromatique avec des pixels codés sur 8 bits (256 niveaux de gris). 3.1.3. Enregistrement des données pour un suivi temporel

On souhaite pouvoir avoir un historique des données acquises. Lorsque l’unité de contrôle enverra un ordre de type « historique requis » la balise devra être capable de lui envoyer les données acquises (température) toutes les minutes pendant une journée. 3.1.4. Affichage local des données

Afin de contrôler les valeurs acquises par la balise avant leurs émissions à l’unité de contrôle, on souhaite que la balise possède un écran LCD ou les orientations (azimut et élévation) de la caméra seront affichées. D’autre part, l’unité de contrôle est pourvue de deux afficheurs 7 segments ou le mesure de la température locale sera affichée. Avant d’envoyer une image à l’unité de contrôle, on souhaite avoir un suivi local. Pour cela, l’unité de contrôle sera pourvue d’une interface VGA. Celle-ci sera capable d’envoyer sur un moniteur d’ordinateur, l’image acquise en temps réel. 3.1.5. Emission des données à l’unité de contrôle

La balise devra avant d’émettre ses données, rechercher l’unité de contrôle à laquelle elle appartient (recherche par identifiant), assurer la non rupture de la communication établie et assurer le dialogue avec l’unité de contrôle. L’émission des données sera faite par l’intermédiaire d’un module Bluetooth décrit ci-dessus et en annexe. Son interfaçage avec l’unité de traitement de la balise devra être fait. 3.1.6. Outils de conception HW et SW

Pour la conception matérielle de la balise et de l’unité de contrôle, les outils suivants seront utilisés :


Olivier ROMAIN


12

• Quartus II • SOPC Builder • SignalTap Analyzer II • Analyseur logic USB (à demander à l’encadrant)

Pour la conception logicielle de la balise, les outils suivants seront utilisés :

• Langage C • Eclipse IDE Nios II

3.2 Architecture détaillée de la balise

L’architecture détaillée de la balise que vous allez concevoir est donnée ci-dessous. Elle s’articule autour du processeur Nios II implémenté dans un FPGA. Plusieurs interfaces sont utilisées, afin de connecter les périphériques au processeur (UART, Bus Avalon, PIO, …). Ces interfaces sont soit directement disponible dans les MegaCores d’Altera, soit ce sont des périphériques que vous aurez conçu.

Nios II

IP Contrôleur

SMT160

Interface Caméra

UART

Module Zigbee

Capteur de température

Affichage Température

PIO

IP Contrôleur

PS2

IP Contrôleur

PPM

Bus Avalon

Servomoteurs Pan / Tilt

Bus Avalon

Interface VGA Bus

Avalon


Olivier ROMAIN


13

3.3 Fonctionnalités de l’unité de contrôle

Chaque unité de contrôle devra posséder les fonctionnalités décrites ci-dessous. 3.3.1. Réception des données émises

Une unité de contrôle devra pouvoir dialoguer avec une balise spécifique mais aussi avec l’ensemble de celles qui seront présentes. Pour cela, l’unité de contrôle sera pourvue d’une interface de communication basée sur le même module Zigbee que les balises. Vous devrez développer cette interface. Un programme en langage C devra être de plus développer afin de piloter l’interface conçue. 3.3.2. Affichage des données émises

L’unité de contrôle sera pourvue d’une interface graphique afin d’afficher les données acquises par une balise spécifique. Sur l’ordre d’un opérateur, une évolution graphique des paramètres devra être faite. Dans sa version finale, l’interface graphique devra permettre d’afficher l’ensemble des balises présentes et d’afficher les paramètres d’une balise choisie.

3.4 Organisation du projet

Afin de mener à bien la conception de la balise et de l’unité de commande, l’ensemble du projet peut être découpé en plusieurs tâches qui sont détaillées dans le document. Chaque tâche est indépendante et peut être menée par une ou plusieurs personnes d’une même équipe. Le découpage donné est à titre indicatif. Il n’y a aucune obligation de le suivre. Par contre, il conviendra d’argumenter la stratégie choisie à la fois dans le rapport et lors de la soutenance du projet.

Tâche n°0. Prise en main de l’environnement de développement QUARTUS

a. Prise en main de Quartus

b. Applications : développement d’IP

c. Compte rendu

Tâche n°1. IP Contrôleur de température

a. Conception de l’IP Contrôleur SMT160

b. Tests et validation

Affichage orientation

caméra


Olivier ROMAIN


14

c. Compte rendu

Tâche n°2. Processeur Nios II

a. Conception du système à base du processeur Nios

b. Gestion de la balise par le Nios

c. Compte rendu

Tâche n°3. Déplacement de la caméra

a. Conception de l’IP contrôleur des servomoteurs

b. Gestion par le Nios II

c. Compte-rendu


Olivier ROMAIN


15

TÂCHE N°0

Prise en main de l’environnement de développement Quartus Application à la conception d’IP

Objectif : L’objectif de cette première séance est de se familiariser avec les outils de conception Quartus. Vous allez apprendre dans ce TP un flow de conception top-down, c'est-à-dire de la spécification à la synthèse de composants décrits en VHDL, en passant par la simulation. Pour cela, cette séance portera sur la conception de plusieurs IP, des registres, ALU, filtre de type FIR et une UART basée à base de FSM. La difficulté des exercices est croissante. I. Prise en main de Quartus II 1.1 Conception d’un nouveau Projet Généralement, un système électronique est composé de plusieurs composants. Chaque composant est décrit, compilé et simulé indépendamment des autres avant d’être relié aux autres. Pour cela, il est nécessaire de créer un projet. Lancer Quartus II dans le menu Démarrer\Altera\Quartus II si vous êtes dans un environnement Windows, sinon, lancer un terminal et aller dans le répertoire Altera pour trouver l’exécutable. La fenêtre suivante apparaît :


Olivier ROMAIN


16

Allez dans le menu File et lancer New Project Wizard. Cet assistant va vous guidez pas à pas pour créer votre projet.

Sous Quartus II, les projets sont liés à des cibles matériels (FPGA ou CPLD). La principale raison provient du fait que les simulations sont post-synthèse par défaut. Vous allez créer un répertoire tache0 et vous nommerez votre premier projet, tache0. La famille de FPGA que vous sélectionnerez sera la famille Cyclone avec le circuit correspondant à la carte que vous utiliserez. Demander à ce niveau à l’encadrant. Les autres options seront celles par défaut. Une fois terminé, appuyer sur Finish.

Vous pouvez alors observer dans la fenêtre Project Navigator la composition de votre projet (entité de haut niveau et circuit utilisé).


Olivier ROMAIN


17

Edition et compilation Une fois le projet crée, il est possible d’y insérer plusieurs fichiers de description de composants : des descriptions structurelles à l’aide de fichier BDF (Block Diagram File) ou des descriptions comportementales à l’aide de fichier VHDL, AHDL ou Verilog. Description comportementale

Sélectionner dans le menu File, la commande New. La fenêtre suivante apparaît.


Olivier ROMAIN


18

Une fenêtre, éditeur de fichier Vhd1.vhd apparaît. Avant de commencer à écrire votre code, enregistré le fichier. Attention le nom du fichier correspond au nom que vous donnerez à votre entité. Ecrivez le code VHDL d’une bascule D.

Description structurelle

Dans le menu File\New, sélectionner Block Diagram/Schematic File. Une fenêtre vierge apparaît. Enregistrer votre fichier.

Quartus II vous offre toute une librairie de composant décrit en VHDL que vous pouvez vous servir. Pour cela, appuyer sur le bouton Symbol Tool matérialisé par le symbole d’une porte ET.


Olivier ROMAIN


19

Une nouvelle fenêtre apparaît. Prenez le composant Bascule D (dff) et intégré le sur votre feuille vierge.

Afin de pouvoir être simulé, il est alors nécessaire d’adjoindre à la bascule des entrées/sorties physiques, broches. Pour cela, sélectionner dans la fenêtre symbole, les composants input et output. Reliez les entrées/sorties du composant avec des fils (signaux 1 bit correspond au bouton « wire »). Enregistrer votre fichier.

Utiliser les composants disponibles pour réaliser un registre à décalage à gauche de 4 bits. Compilation Avant de simuler un circuit, il est nécessaire de vérifier qu’il ne comporte pas d’erreur de conception. Pour cela nous allons le compiler. Si votre projet comporte plusieurs descriptions, le compilateur par défaut synthétisera l’entité de haut niveau, celle qui correspond à la description de tout le système.


Olivier ROMAIN


20

Dans l’onglet Files du Project Navigator sélectionner le fichier que vous voulez compiler. Appuyer sur le clic droit de la souris et sélectionner Set as Top-Level Entity. En réalisant cette opération le compilateur ne synthétisera que ce composant.

Aller dans le menu Tools et appuyer sur Compiler Tool. Une nouvelle fenêtre apparaît. Lancer le compilateur. Le compilateur analyse, synthèse et réalise un placement routage du composant sur le circuit cible. L’ensemble des rapports de compilation et d’analyse des performances sont disponibles à partir de cette fenêtre (compiler tool). Simulation Cette étape consiste à vérifier le comportement du composant crée. Attention, cette étape nécessite d’avoir compiler au préalablement le circuit. Dans le menu File\New, sélectionner l’onglet Other files et Vector Waveform Files. Ce fichier permet de décrire visuellement le testbench que vous allez utiliser pour tester votre circuit.


Olivier ROMAIN


21

Enregistrez le fichier sous Bench_nom du composant. Par exemple pour la basculeD, le nom du test bench sera Bench_BasculeD.vwf.

Le fichier de simulation est divisé en deux parties. Une colonne pour le les broches d’entrées / sorties du composants et une zone graphique munie d’une échelle temporelle. Dans la colonne Name, à l’aide d’un clic droit de la souris, lancez la commande Insert a node or bus, puis l’outil Node Finder. Cet outil permet de récupérer les noms des entrées/sorties du composant que vous avez créé. Sélectionner les signaux, clk, D et Q. et terminer l’opération. D et clk sont des entrées. Nous pouvons leur affecter des valeurs manuellement ou utiliser des stimulis prédéfinis. Pour le signal clk, dans la barre d’outils Waveform Editor sélectionnez overwrite clock. Prenez une période d’horloge par défaut à 10ns. Pour le signal D, vous prendrez un compteur qui s’incrémente tous les 50 ns. Enregistrer votre fichier. Nous allons simuler le comportement du circuit avec le test_bench que vous venez de réaliser. Pour cela, dans le menu Tools, sélectionnez Simulator Tool. A l’aide du navigateur, recherchez votre fichier de simulation et lancez la simulation. Le résultat de la simulation apparaît.


Olivier ROMAIN


22

Programmation de la carte Une fois la conception du système terminé et dans le cas ou le comportement en simulation respecte les spécifications du cahier des charges, Quartus II permet de programmer une carte pour vérifier le système sur un circuit. Pour cela, dans le menu Tools, sélectionner Programmer. Nous ne ferrons pas cette étape ici mais nous l’approfondirons ultérieurement. II. Applications Maintenant que vous maîtrisez l’environnement de développement, c’est à vous de jouer ! 2.1 Registre et Additionneur 2.1.1 Registre sur n bits

Définir de façon comportementale un registre de taille variable sur n bits comportant un reset synchrone.

• Compilez le registre et observer les résultats de la compilation.

• En déduire la fréquence maximale d’utilisation de ce composant ?

• Combien de ressource prend ce composant dans le FPGA ?

• Simulez le composant avec n égal à 4 pour une horloge d’une période de 10 ns et 10µs.

• Déterminer un fichier de simulation Waveform Vector file afin d’observer les résultats sous Quartus.

• Comparer les résultats obtenus

2.1.2 Additionneur sur n bits

Définir de façon comportementale un additionneur ayant en entrée deux opérandes a et b sur n bits et en sortie un résultat y sur n bits.

• Compilez le composant conçu et observer les résultats de la compilation

• Simulez le composant avec n égal à 4, mesurer le temps nécessaire afin d’avoir le résultat en sortie.


Olivier ROMAIN


23

• Que se passe-t-il si on veut additionner les nombres 15 et 7 ?

2.2 Application à l’étude d’un premier Filtre FIR

Dans cette partie, on désire réaliser un filtre possédant l’équation suivante :

y(n) = x(n) + x(n-1)

x(n) est un échantillon de l’entrée x à l’instant n et x(n-1) est un échantillon du signal x à l’instant (n-1). Les deux sont codées sur 16 bits.

• Définir de manière comportementale ce filtre caractérisé par une architecture pipeline.

• Définir de manière structurelle ce filtre, avec une architecture pipeliné, en utilisant les

composants décrits dans la partie 1.

• Testez le bon fonctionnement de cette architecture en la simulant.

• Déterminer la fréquence d’horloge minimale pour l’architecture décrite

2.3 Conception d’un filtre réalisant une moyenne sur n échantillons Dans cette partie, on désire réaliser un filtre possédant l’équation suivante :

y(n) = x(n) + x(n-1) + x(n-2) + x(n-3) + …+ x(0)

x(n) est un échantillon de l’entrée x à l’instant n et x(n-1) est un échantillon du signal x à l’instant (n-1). Les deux sont codées sur 16 bits.

• Définir une architecture pour ce filtre. La solution retenue sera explicitée.

• Testez le bon fonctionnement de cette architecture en la simulant.

• Déterminer la fréquence d’horloge minimale pour l’architecture décrite

2.4 Conception d’une IP de type contrôleur UART On se propose de synthétiser un circuit d’émissionde données en mode asynchrone type start-stop. Chaque caractére est défini par un start bit, 8 bits de données et un stop bit. Le schema de principe est donnée par la figure 1.


Olivier ROMAIN


24

Figure 1 : Système d’émission

Les caractéristiques du circuit d’émission sont les suivantes :

• Les entrées d’horloge de tous les circuits sont actives sur un front descendent • Le registre à décalage 8 bits est chargé en parallèle par la donnée à transmettre D7…D0 • Les signaux de contrôle du registre à décalage sont : o SI : entrée série o SO : sortie série o MC : entrée de contrôle de Mode MC = 0 décalage a droite MC = 1 chargement parallèle o CLK : horloge pour le décalage • Le signal d’horloge TxCLK est obtenu par la division par 16 d’une horloge qui est aussi

utilisée par le circuit de réception série • Les entrées Set et Reset de la bascule D sont asynchrones • Le circuit de contrôle et la bascule sont initialisés par Reset


Olivier ROMAIN


25

• La commande Tx provoque la transmission série de l’octet D7…D0 • La sortie Zéro du détecteur de Zéro passe au niveau haut lorsque toutes ses entrées sont

à zéro • Le circuit de contrôle est notamment constitué par une Machine à États dont les sorties

sont synchrones. La commande de Reset est synchrone. • Le vecteur d’entrée est composé des signaux Zéro est Start • Le vecteur de sortie est composé des signaux MODE SEND DATA et Ti • Le signal SHIFT est le signal d’horloge appliqué sur la bascule D et sur l’entrée CLK du

registre a décalage • Les chronogrammes des différents signaux, correspondant à l‘émission d’un octet, sont

tracés sur la Figure 2.

Figure 2 : chronogramme 1. Décrivez en VHDL un registre 8 bits à chargement parallèle et à décalage 2. Décrivez en VHDL le détecteur de zéro 3. Réalisez le diagramme de transition de la machine à états à l’aide du chronogramme de la

Figure 2 4. À l’aide des outils Mentor, décrivez la machine à états 5. À l’aide d’un schéma structurel assemblez le tout, vous utiliserez les composants fournis

par le logiciel pour ce qui est le portes logique Et, Ou et bascule D avec RS 6. Ecrivez en VHDL les stimuli de test du circuit d’émission 7. Testez votre composant 8. Synthétiser sur cible FPGA ALTERA Cyclone en essayant différentes périodes d’horloge


Olivier ROMAIN


26

Compte-rendu

Le compte rendu consiste dans la prise en main du sujet, il ne doit pas seulement se limiter a l'écriture du code VHDL, mais plutôt a une analyse des questions, a une explication du code VHDL écrit, avec vos commentaires ainsi que vos résultats de simulations. A la fin de chaque partie de la séance il faudra faire valider l’exercice par un des deux enseignants responsables.


Olivier ROMAIN


27

TÂCHE N°1

Conception d’une IP de type contrôleur pour le capteur de

température SMT160-30

I. Introduction : Présentation d’un capteur de température Le SMT160-30 est un capteur de température intégré à trois bornes, doté d'un signal de sortie caractérisé par son rapport cyclique (Duty Cycle). Deux des bornes sont utilisées pour l'alimentation en 5V et la troisième pour le signal de sortie. Le résultat de la mesure est présent à la sortie sous forme de rapport cyclique et peut faire l'objet d'un échantillonnage par un microprocesseur. Par ailleurs l'information reste disponible sous forme analogique. Aucun convertisseur Analogique Numérique ou interface spéciale n'est nécessaire.

Le SMT160-30 permet de mesurer la température avec une précision absolue de 0.7 °C dans l'intervalle -30 °C à +100 °C et 1.2 °C de -45°C à +130 °C. Cela rend le capteur très utile dans toutes les applications où des conditions "humaines" (contrôle de climat, transformation des produits alimentaires etc.) doivent être contrôlées. La sortie du capteur, de technologie CMOS, peut être déportée par un câble jusqu'à 20 mètres. Ceci rend le SMT160-30 très utile dans des applications de télédétection et de commande. Vous pourrez trouver la documentation complète sur le site du constructeur SMARTEC à l’adresse http://www.smartec.fr

II. Description fonctionnelle La sortie du capteur est compatible avec les microcontrôleurs et peut être reliée directement à la plupart des processeurs. En mesurant numériquement (par échantillonnage) T1 et T2 (voir l'image du signal de sortie ci-dessus), la température se calcule facilement à l'aide de la formule suivante:


Olivier ROMAIN


28

On peut par ailleurs obtenir la valeur de la température en mesurant le signal de sortie à l'aide d'un système analogique. La tension moyenne (ainsi que la valeur RMS) est directement proportionnelle au rapport cyclique (Duty Cycle) et à la tension d'alimentation. Par conséquence Vout /Vdd représente également la valeur de T1/T2. En définitive la température peut être mesurée d'une manière simple et précise, aussi bien de façon analogique que numérique. III. Travail à réaliser On désire réaliser une IP d’un contrôleur SMT160 qui servira d’interface entre le capteur de température et le micro processeur de type Nios. Cette IP permettra d’obtenir une valeur numérique de la température à partir du Nios. Pour cela, dans un premier temps nous réaliserons une IP qui sera interfacée au Nios par le bais d’un port d’entrée/sortie de type PIO puis dans un second temps nous l’intégrerons directement au Nios en l’interfaçant au bus avalon. 3.1 Conception de l’IP SMT160 version PIO L’entité à développer en VHDL devra être conforme aux spécifications données ci-dessous :

L’IP devra comporter en entrée :

• un signal data_in : sortie du capteur de température • un signal de reset : • une horloge système à 50 MHz

L’IP devra comporter en sortie :

clk

reset

mesure

data_out[N..0]

IP contrôleur


Olivier ROMAIN


29

• un signal data_out : sur n bits (à vous de définir) correspondant à la valeur numérique de la température

3.1.1 Développement de l’IP SMT160-30 Vous êtes libre de concevoir cette IP comme vous le souhaité. C'est-à-dire, soit de manière comportementale ou structurelle. 3.1.2 Simulation et validation Effectuer les simulations du contrôleur. 3.2 Extension de l’IP SMT160 version bus Avalon Il existe deux manières de connecter une IP au processeur Nios, soit en utilisant un port d’entrée / sortie (PIO cf : synoptique du démonstrateur et cours), soit en utilisant le bus Avalon. Dans cette partie, nous allons modifier l’IP conçue auparavant afin que son interface prenne en compte les signaux disponibles sur le bus avalon. L’entité à développer en VHDL devra être conforme aux spécifications données ci-dessous :

L’IP devra comporter en entrée :

• un signal d’adresse sur 2 bits, qui permettra d’accéder aux registres de l’IP o address = 0x01 : registre d’horloge / échantillonnage o address = 0x10 : registre d’état de l’IP

clk

reset

data_out[31..0]

IP contrôleur

adress[1..0]

cs

rd

mesure

data_in [31..0]

wr


Olivier ROMAIN


30

• un signal data_in sur 32 bits : bus de donnée Avalon • un signal mesure : sortie du capteur de température • un signal cs : sélection du périphérique sur le bus Avalon • un signal wr : signal d’autorisation d’écriture dans les registres de l’IP • un signal rd : signal d’autorisation de lecture dans les registres de l’IP • un signal de reset : remise à zéro des registres • une horloge système


• un signal data_out sur 32 bits, qui permettra de récupérer les données acquises sur le bus avalon

3.2.1 Développement de l’IP Apporter à la première version de l’IP les modifications nécessaires afin qu’elle prenne en compte les signaux disponibles sur le bus avalon. Les spécifications des signaux disponibles sur les bus sont données dans la documentation de chez Alera (AN : Bus Avalon). 3.2.2 Simulation et validation Effectuer les simulations du contrôleur sous l’environnement que vous souhaitez, soit Modelsim ou soit Quartus. IV. Compte rendu Consigner dans votre compte rendu, les résultats que vous avez obtenus pour cette partie. Vous mettrez en annexe de votre compte rendu les différents programmes que vous avez développés ainsi que la méthodologie que vous avez adopté.

Fin tâche n°1


Olivier ROMAIN


31

TÂCHE N°2

Conception du système Nios 2

I. Introduction : Dans cette partie, nous allons nous intéresser à concevoir une IP de type micro processeur Nios 32 bits en utilisant l’outil SOPC Builder. L’entité Nios (I ou II) devra prendre en compte les ressources de la carte de développement mais aussi les différentes interfaces (IP) qui seront développées dans le cadre des tâches 1, 3, 4 et 5. II. Conception matérielle 2.1 Concevoir et définir les différentes interfaces que le Nios doit intégrer afin qu’il puisse avoir accès aux ressources de la carte de développement (SDRAM, SRAM, Led, Bouttons, etc.). Pour cela nous utiliserons l’outil SOPC Builder. (Manuel de conception HW en annexe). 2.2 En fonction de l’avancement des autres tâches, intégrer dans le Nios 2 les IP SMT160, IP PPM et IP PS2. 2.3 Compiler et synthétiser le système 2.4 Programmer la carte III. Conception logicielle Dans cette partie, nous allons utiliser les outils GNU (compilateur, linker et debugger) afin de développer un programme en C qui permettra au processeur Nios de mesurer au travers de l’IP la valeur de la température et d’afficher sur l’écran LCD l’orientation de la caméra 3.1 Développer un programme en C qui permettra de valider le fonctionnement du processeur Nios2 développé. 3.2 En fonction des IPs développées dans les autres tâches, réalisé un programme en C qui permettra :

• L’affichage sur les afficheurs 7 segments de la valeur de la température acquise • De gérer le déplacement de la caméra suivant deux modes :

o Automatique o Manuel : souris PS2


Olivier ROMAIN


32

• De récupérer l’information de mouvement issus du traitement de la caméra IV. Tests et validation 4.1 Connecter l’interface qui vous sera remise sur la carte ALTERA 4.2 Tester et valider pratiquement le comportement de votre balise VI. Compte Rendu Consigner dans votre compte rendu, les résultats que vous avez obtenus pour cette partie. Vous mettrez en annexe de votre compte rendu les différents programmes que vous avez développés.

Fin tâche n°2


Olivier ROMAIN


33

TÂCHE N°3

Conception d’une IP de type contrôleur PPM en VHDL pour le déplacement de la monture gyroscopique de la caméra

I. Introduction : Présentation d’un servomoteur Un servomoteur est un dispositif typiquement utilisé en modélisme pour, par exemple, contrôler la direction d'une voiture télécommandée. Il comprend :

• Un moteur électrique (continu), généralement assez petit.

• Une réduction en sortie de ce moteur pour avoir moins de vitesse et plus de puissance.

• Un capteur : un potentiomètre qui induit une résistance variable en fonction de l'angle de l'axe de sortie.

• Un asservissement électronique pour contrôler la position de cet axe de sortie.

L'utilisateur envoie à chaque instant un signal modulé qui représente un angle. Le servomoteur tourne vers cet angle et s'y maintient. Commande d’un servomoteur Un servomoteur s’interface avec un organe de commande à l’aide de trois fils (rouge, noir et de couleur). Le rouge correspond à l’alimentation +5v (généralement), la masse (le fils noir) et le signal de commande. Il est normalement blanc, mais il peut être jaune suivant le fabriquant. On pourrait penser qu'il faut fournir un PWM comme signal de commande au servomoteur pour qu’il tourne comme pour un moteur à courant continu, mais ce n’est pas le cas. On utilise généralement un signal de commande que l’on appelle PPM. La différence entre ces deux commandes quasi similaire est explicitée ci-dessous :


Olivier ROMAIN


34

1. Le PWM (Pulse Width Modulation, Modulation en largeur d'impulsion) est un signal dont le taux de modulation varie de 0 à 100% (TM=Ton/Tperiode) à fréquence fixe.

2. Pour un servomoteur on parle de PPM (Signal modulé en largeur d’impulsion) où seule la largeur de l'impulsion compte indépendamment de la fréquence (en théorie).

Plus précisément, il faut fournir au servomoteur une impulsion à 1 (suivie d'un retour à 0). Ainsi le servomoteur va prendre en compte la largeur temporelle de cette impulsion, qu'il va convertir proportionnellement (ou presque) en un angle. Le retour à 0 de l'impulsion peut avoir n'importe quelle durée. En pratique, il semblerait qu'il ne faille pas dépasser un temps de 20ms entre deux fronts montants. A noter aussi que ce système présente un avantage par rapport au PWM : une absence de signal (toujours à 1, ou toujours à 0) laisse le servomoteur en "roue libre" comme si il n'était pas alimenté. Les figures ci-dessous montrent les différences qu’ils existent entre une commande PWM classique et une commande PPM utilisée par les servomoteurs.

figure 1 : Commande de type PWM

figure 2 : Commande de type PPM


Olivier ROMAIN


35

Valeurs typiques : Dans la pratique, ont trouve généralement les valeurs suivantes :

• Milieu vers 1.44 ms • -70 deg vers 0.8 ms • -102 deg (butée) vers 0.51 ms • +55 deg vers 1.92 ms • +98.8 deg (butée) vers 2.31 ms

Soit un "pas" de 8µs correspond à 0.89 deg. Ou dans l'autre sens, un degré correspond à 9µs approximativement. Une étape de calibrage sera nécessaire afin d’ajuster la largeur de l’impulsion et ainsi d’obtenir une pleine échelle (de -90° à +90°). Attention, les chronogrammes donnés ci-dessus ainsi que les valeurs sont des exemples. Les valeurs temporelles dépendent du servomoteur que vous utiliserez. Il sera nécessaire de réaliser une phase de calibration, par le biais d’un GBF (Générateur Basse Fonction), préliminaire pour déterminer les valeurs temporelles à respecter. II. Travail à réaliser 2.2.1 Développement HW On désire réaliser une IP d’un contrôleur PPM qui servira d’interface entre le servomoteur et le micro processeur de type Nios II. Cette IP permettra de faire tourner la caméra à partir du Nios II. Pour cela, l’IP que nous allons concevoir sera directement intégré au Nios II par le biais du bus avalon. L’entité à développer en VHDL devra être conforme aux spécifications données ci-dessous :


Olivier ROMAIN


36

L’IP devra comporter en entrée : • un signal data sur 32 bits, qui permettra d’envoyer des données dans les registres

(réglage de l’horloge, rapport cyclique, …) • un signal d’adresse sur 2 bits, qui permettra d’accéder aux registres de l’IP

o address = 0x00 : registre de contrôle de l’IP Bit0 : reset de l’IP Bit1 : sortie active

o address = 0x01 : registre d’horloge o address = 0x10 : registre rapport cyclique o address = 0x11 : registre de calibration

Bit0 : positionne le rapport cyclique à 25% quelque soit le rapport cyclique programmé. Moins prioritaire que le Bit1.

Bit1 : positionne le rapport cyclique à 50% quelque soit le rapport cyclique programmé. Moins prioritaire que le Bit2.

Bit2 : positionne le rapport cyclique à 75% quelque soit le rapport cyclique programmé

• un signal cs : sélection du périphérique • un signal wr : écriture dans les registres • un signal de reset : remise à zéro des registres et du signal PPM • une horloge système à 50 MHz


• Le signal de commande PPM Après avoir développer l’IP, effectuer les simulations du contrôleur. Vérifier le comportement voulu et consigner vos résultats dans votre compte-rendu. 2.2.2 Développement SW Après avoir intégré l’IP dans le système Nios 2 (si la tâche correspondante a été réalisée), développé sous l’environnement Eclipse le logiciel qui permet de déplacer le servomoteur. Connecter la carte pour le servomoteur et vérifier le comportement du servomoteur. III. Compte rendu Consigner dans votre compte rendu, les résultats que vous avez obtenus pour cette partie. Vous mettrez en annexe de votre compte rendu les différents programmes que vous avez développés ainsi que la méthodologie que vous avez adopté.


Olivier ROMAIN


37

Fin tâche n°3


Olivier ROMAIN


38

Projet Light

Documents

Transcript of Projet Light