Embed Size (px)
Citation preview
Université du Québec à Chicoutimi
MODULE D’INGÉNIERIE
PROGRAMME GÉNIE ÉLECTRIQUE
6GIN555 PROJET DE SYNTHÈSE EN INGÉNIERIE
Rapport final
Autodrome Saguenay
Préparé par
HUARD Didier
SAGNA Benjamin
Pour
Frédéric Delisle
DATE
23 Avril 2010
COORDONNATEUR : PARADIS Jacques
CONSEILLER : Bui Hung-Tien
I
Approbation du rapport final pour diffusion
Nom du conseiller Hung Tien BUI
Date 23 Avril 2010
Signature
II
RÉSUMÉ
L’autodrome Saguenay fait peau neuve. Dans le cadre de son réaménagement et de sa
conversion en piste d’accélération de 1/8 de miles (200 mètres) on demandait aux étudiants
d’effectuer la conception de la partie électrique /électronique. Les étudiants avaient comme mandat
de :
• Concevoir le feu de circulation pour le départ
• Effectuer le choix des capteurs pour relever les données aux différents points de
contrôles
• Faire la conception de l’interfaçage des capteurs et de la séquence de l’allumage
• Créer le protocole de communication pour gérer les différents modules
• Implémenter les principes de la communication série sans-fils
Les différentes cartes électroniques ont été conçues et les plans ont été envoyés pour la
fabrication. Les capteurs sont choisis et commandés. Le protocole de communication est élaboré
et les principes de communication série des divers modules sont développés.
Les désirs du promoteur font en sorte que la livraison du bien est prévue pour le début de l’été. On
est en mesure de présenter les preuves de concepts ainsi que le cheminement effectué. Les
capteurs ont été montés en laboratoire et plusieurs simulations de course ont été effectuées. Ainsi,
nous avons pu tester que les données étaient adéquatement traitées et affichées grâce à la
programmation des différents modules et la communication sans-fil. Il reste l’assemblage du
produit fini. Une série de réglages seront nécessaires afin de concrétiser le fonctionnement parfait
de l’ensemble.
Mots-clés : FPGA, Microcontrôleur, Programmation, Communication, Sans-fil, Capteurs, Circuits
Imprimés, Schémas
Benjamin Sagna
Didier Huard
III
Table des matières
1.0 Introduction 1 1.1 Description de l’équipe de travail ...........................................................................................1
1.2 Contexte ................................................................................................................................2
1.3 Problématique et état de l’art .................................................................................................3
1.4 Objectifs du projet ..................................................................................................................4
1.5 Recherche bibliographique ....................................................................................................5
2.0 Objectifs généraux et spécifiques du projet 6
3.0 Aspects techniques et éléments de conception 7 3.1 Méthodologie utilisée .............................................................................................................7
3.2 Avancement du projet............................................................................................................7
4.0 Éléments de conception 9 4.1 Choix des capteurs ................................................................................................................9
4.1.1 Ligne de départs ............................................................................................................9
4.1.2 Capteurs le long de la piste ........................................................................................ 11
4.1.3 Remarques et considérations d’ordre générales concernant les capteurs ................. 13
4.2 La mécanique ..................................................................................................................... 14
4.2.1 Modélisation ............................................................................................................... 14
4.2.2 Plans .......................................................................................................................... 16
4.2.3 Réalisation .................................................................................................................. 17
4.3 Études ................................................................................................................................ 19
4.3.1 Télécommande .......................................................................................................... 19
4.3.2 Afficheurs géants ........................................................................................................ 20
Au vu de l’analyse effectuée, l’utilisation de lampe LED sera priorisée pour réaliser les
afficheurs géants. ............................................................................................................................... 21
4.3.3 Imprimantes ................................................................................................................ 22
4.3.4 Le logiciel de gestion .................................................................................................. 22
4.4 L’Électronique ..................................................................................................................... 23
4.4.1 Boîtier - Électronique de l’arbre de noël ...................................................................... 24
4.4.2 PCB réalisé ................................................................................................................ 27
4.5 La programmation .............................................................................................................. 29
4.5.1 Module télécommande ............................................................................................... 30
4.5.2 Module piste ............................................................................................................... 30
4.5.3 Module chronomètre .................................................................................................. 30
4.5.4 Module capteur ........................................................................................................... 31
4.5.5 Module convertisseur BCD et module additionneur 3 ................................................ 31
IV
4.5.6 Module Horloge 2Khz ................................................................................................. 32
4.5.7 Module traitement des données ................................................................................. 32
4.5.8 Module de mémoire Ram ........................................................................................... 32
4.5.9 Module UART ............................................................................................................. 34
4.5.10 Module d’affichage ..................................................................................................... 35
5.0 Bilan des activités 37 5.1 Arrimage formation/pratique universitaire ........................................................................... 37
5.2 Travail d’équipe .................................................................................................................. 38
5.3 Respect de l’échéancier ..................................................................................................... 38
5.4 Analyse et discussion ......................................................................................................... 39
6.0 Conclusion 41
7.0 Annexes 42 7.1 Documentation ................................................................................................................... 42
7.1.1 Caractéristiques critiques ayant menée au choix du capteur de la série S30 DC ...... 42
7.1.2 Caractéristiques critiques ayant menée au choix du capteur QS30LLP ..................... 43
7.2 Schéma électriques ............................................................................................................ 44
7.2.1 Carte optocoupleurs et alimentations ......................................................................... 44
7.2.2 Carte d’acquisition des capteurs................................................................................. 45
7.2.3 Carte FPGA ................................................................................................................ 46
7.2.4 Carte Télécommande ................................................................................................. 47
7.3 Programmation ................................................................................................................... 48
7.3.1 Code Verilog - Module principal.................................................................................. 48
7.3.2 Code Verilog - Module Piste ....................................................................................... 53
7.3.3 Code Verilog - Module Télécommande ..................................................................... 62
7.3.4 Code Verilog - Module Horloge 2 kHz ........................................................................ 71
7.3.5 Code Verilog - Module Horloge 2 kHz ........................................................................ 72
7.3.6 Code Verilog - Module UART ..................................................................................... 81
7.3.7 Code Verilog - Module Convertisseur Binaire BCD ................................................... 83
7.3.8 Code Verilog - Module Chronomètre .......................................................................... 88
7.3.9 Code assembleur – Contrôle de l’affichage ................................................................ 92
V
Liste des figures
Figure 1 - Schéma de l'autodrome ................................................................................................... 3
Figure 2 - Schématisation du mode opposé et du monde avec une réflexion sur une pastille ......... 9
Figure 3 - Schématisation pour déterminer l'Output Response Time ............................................. 12
Figure 4 - Vue de face .................................................................................................................... 14
Figure 5 - Vue isométrique ............................................................................................................. 14
Figure 6 - Vue de côté .................................................................................................................... 15
Figure 7 - Zoom sur "Stage" et "Prestage" ..................................................................................... 15
Figure 8 - Mise en plan de l'assemblage ........................................................................................ 16
Figure 9 - Ampoule de l'arbre de noël ............................................................................................. 17
Figure 10 - Socle des ampoules ..................................................................................................... 18
Figure 11 - Vue de face et de côté .................................................................................................. 18
Figure 12 - Afficheur télécommande ............................................................................................... 19
Figure 13 - Bouton poussoir ........................................................................................................... 19
Figure 14 - Boitier de la télécommande .......................................................................................... 19
Figure 15 - Afficheurs incendecents de la piste de drag de Napierville .......................................... 20
Figure 16 - lampes incandecentes et leur représentation 7 segments ........................................... 20
Figure 17 - Afficheur 1 ligne ............................................................................................................ 20
Figure 18 - Lampe LED .................................................................................................................. 21
Figure 20 - Exemple de logiciel de gestion de piste d'accélération ................................................. 22
Figure 19 - Imprimante située en fin de course pour affichage des résultats aux concurenrts ...... 22
Figure 21 - Relation entre les boîtiers électriques ........................................................................... 23
Figure 22 - Schéma bloc du boîtier de l'arbre de noël .................................................................... 24
Figure 23 - Alimentation des capteurs ............................................................................................ 26
Figure 24 - Carte électrique opto-isolateur triacs ........................................................................... 28
Figure 25 - Carte d'acquisition et de communication sans fil Xbee ................................................. 28
Figure 26 - Carte FPGA .................................................................................................................. 28
Figure 27 - Structure du FPGA programmé en Verilog HDL .......................................................... 29
Figure 28 - Fonctionnement du module convertisseur BCD ........................................................... 31
Figure 29 - Organigramme résumant le fonctionnement du microcontrôleur dédié à l’affichage .... 36
6
Liste des tableaux
Tableau 1 - Tâches effectuées ......................................................................................................... 8
Tableau 2 - Caractérisation de l'Excess Gain ................................................................................. 10
Tableau 3 - Comparaison des deux types d'affichages .................................................................. 21
Tableau 4 - Caractéristiques du transformateur des capteurs ........................................................ 26
Tableau 5 - Caractéristiques du transformateur des composants .................................................. 27
Tableau 6 - Légende des informations de la block Ram port A ...................................................... 32
Tableau 7 - Block Ram port A ......................................................................................................... 33
Tableau 8 - Exemple de paquet ..................................................................................................... 34
1
1.0 Introduction
Ce projet de synthèse en ingénierie porte son intérêt vers la conception et la mise en œuvre du
système électrique de l’Autodrome Saguenay. Pour mener à bien ce projet, il faudra prendre en compte
les concepts de fiabilité, d’instrumentation, de génie logiciel, d’ergonomie, de protocole de communication
ainsi que de facilité de maintenance. Ces notions font partie de vecteurs importants du domaine de
l’ingénierie et la mise en œuvre du projet au complet aura mis en relief l’ensemble de ces aspects
techniques ainsi que d’importantes notions relationnelles et de coopération.
Le présent document exposera le cheminement effectué afin d’aboutir à un produit fini dans le
domaine de l’instrumentation d’une piste d’accélération. Dans un premier temps, nous présenterons le
choix de capteurs industriels permettant d’assurer la fiabilité de la mesure des performances des
compétiteurs. Par la suite, nous exposerons le travail de conception concernant des plans mécaniques
avec le logiciel de conception Solidworks ainsi que la réalisation finale qui en a suivi. Dans un second
temps nous ouvrirons un volet sur l’architecture électronique de l’autodrome ainsi que son mode de
fonctionnement et son protocole de communication. Nous parlerons de programmation en langage de bas
niveau gérant l’ensemble des événements de la piste d’accélération et pour finir nous illustrerons la
conception de plans électroniques ainsi que la réalisation des circuits imprimés associés.
1.1 Description de l’équipe de travail
L’équipe de travail du projet de l’autodrome Saguenay est principalement composé des étudiants Didier
Huard et Benjamin Sagna, finissants en génie électrique 2010. Le projet de l’autodrome relevant du
domaine multidisciplinaire n’aurait jamais pu voir le jour sans l’ensemble des employés du département
des sciences appliquées.
Ce projet a permis d’être réalisé essentiellement grâce à M. Frederic Deslile, promoteur et propriétaire de
l’autodrome Saguenay. Une communication périodique nous a permis de répondre aux différentes
attentes de M. Deslile et de lui faire part de nos différents avancements tout au long des 8 mois de projet.
Une communication régulière avec M. Hung-Tien Bui au titre d’ingénieur conseiller sur le projet nous a
permis de nous orienter quant aux méthodes de travail et aux outils à utiliser. Ses conseils avisés furent
largement appréciés pour nous permettre d’avancer dans les moments les plus difficiles du projet. Nous
tenons aussi à faire part du soutien technique qui nous a été très largement apporté du coté électronique
par les techniciens Richard Martin et Francis Deschenes ainsi que du côté mécanique par M. Yannick
Gagnon et Denis Tremblay sans lesquels aucun de nos calculs et plans d’études n’auraient vu le jour
concrètement.
2
1.2 Contexte
Le projet de l’Autodrome Saguenay, vise à mettre en œuvre un système électrique et électronique
permettant la compilation et la gestion des données d’une course automobile. Le système servira de
support technique au personnel de l’autodrome dans le but d’exposer au public les performances réalisées
par les concurrents. Le promoteur souhaite être en mesure de pouvoir effectuer deux types de courses sur
son site soit, la course d’accélération ainsi qu’une course sur circuit. Pour ce faire, il nous faudra aborder
deux approches de conception afin d’extraire les paramètres pertinents pour chaque type de course.
La course d’accélération se déroule sur une piste en ligne droite d’une distance de 1/8 mile,
environ 200 mètres. Elle met en opposition deux véhicules à la fois, chacun ayant un couloir attitré.
La course sur circuit se déroulera sur un tracé en boucle fermé qui empruntera la piste
d’accélération. Elle mettra en opposition plusieurs véhicules.
Note : l’objectif principal du projet est de concevoir le système de la piste d’accélération, la course sur
circuit étant un objectif secondaire. C’est dans cet ordre d’idée que le contenu du présent document est
orienté.
La Figure 1 à la page suivante, représente le site de l’Autodrome Saguenay. Sur ce schéma sont
illustrés les bâtiments et équipements pertinents relatifs au projet. La tour centrale est l’édifice où sera géré
l’ensemble de l’équipement électrique de l’autodrome via un logiciel et une connexion sans fil. Le poste 1
contiendra un boîtier électronique qui intégrera le microcontrôleur qui gère l’intégralité des capteurs de la
piste d’accélération. Sur ce boîtier seront connectés les feux de circulation du départ de la course ainsi
qu’une télécommande permettant le démarrage manuel de l’arbre. Il sera relié par un réseau sans fil à
l’ordinateur de la tour centrale. Le poste 2 contiendra deux imprimantes qui seront reliées par réseaux
sans fils au boitier électrique du poste 1. Ces imprimantes indiqueront aux concurrents certaines
informations relatives à leurs performances. Pour finir, deux afficheurs seront reliés au logiciel de la tour
centrale par connexion sans fil afin d’exposer au public les temps de parcours et la vitesse de chaque
concurrent.
3
1.3 Problématique et état de l’art
Le défi majeur est de concevoir les éléments nous permettant de différencier chacun des
véhicules tout en imaginant une approche minimisant le nombre de capteur, le câblage ainsi que les
interférences possibles entre nos instruments. Il faudra également tenir compte de l’aspect fiabilité /
entretien tout autant que de l’aspect ergonomie.
Dans un premier temps, concernant la piste d’accélération, les paramètres pertinents à retirer
pour chaque voiture sont :
• Chronométrage intermédiaire à 60 pieds, environ 18 mètres
• Chronométrage final à 1/8 mile, environ 200 mètres
• Vitesse de pointe
En deuxième lieu, concernant la course sur circuit, les paramètres pertinents à retirer pour chaque
voiture sont :
• Temps au tour pour chaque véhicule
• Classement et intervalle de temps
PISTE
CIRCUIT
Poste 1
Poste 2
Tour
centrale Estrades Estrades
Afficheurs
Arrivée
Capteur ligne
départ
Capteur 60‘ Capteurs 1/8 mile
Départ
Figure 1 - Schéma de l'autodrome
4
1.4 Objectifs du projet
L’objectif du projet est de concevoir l’ensemble du système électrique et électronique de la piste
de course de l’Autodrome Saguenay. Les points principaux du projet sont les suivants :
• Sélectionner les composants pertinents pour construire un feu de circulation à l’épreuve des
intempéries.
• Choisir la bonne technologie de capteurs optiques permettant la mesure du temps de parcours de
chaque concurrent.
• Programmer un FPGA pour permettre la récupération des données des capteurs infrarouges.
• Programmer le FPGA pour gérer l’allumage des feux de circulation du départ.
• Programmer quatre types d’allumage de l’arbre pour la piste d’accélération : La course seule dans
le couloir gauche, la course seule dans le couloir droit, la course à deux, la course à départs
différés.
• Fabriquer et interfacer une télécommande pour démarrer l’arbre manuellement et gérer les
différents modes de fonctionnement de l’arbre.
• Interfacer le FPGA avec un module sans fils Xbee pour permettre la communication avec le poste
de commande.
• Programmer un microcontrôleur PIC pour la gestion des deux imprimantes se situant à la fin de la
piste d’accélération.
• Faire les plans pour les afficheurs géants.
• Créer un logiciel permettant de superviser l’ensemble de l’autodrome Cela comprend la
récupération des informations des capteurs de la piste, l’enregistrement des informations dans
une base de données SQL, la gestion de deux imprimantes et de deux écrans géants. Le logiciel
communiquera avec les différents modules électroniques de la piste via une connexion sans fil
Xbee.
5
1.5 Recherche bibliographique
Tout au long de notre projet, nous nous sommes référés à plusieurs documents. Voici une liste des plus importants.
Site Internet
Documentation technique pour les capteurs de la ligne de départ
BANNER ENGINEERING. (1er mars 2010). The S30 Sensors – dc-Voltage Series, [En ligne]. Adresse
URL: http://info.bannersalesforce.com/xpedio/groups/public/documents/literature/121520.pdf
Documentation technique pour les capteurs de le long de la piste
BANNER ENGINEERING. (1er mars 2010). WORLD-BEAM® QS30 Series, [En ligne]. Adresse URL:
http://info.bannersalesforce.com/xpedio/groups/public/documents/literature/112355.pdf
Documentation relative à l’Excess Gain
BANNER ENGINEERING. (1er mars 2010).The undisputed leader in sensors, [En ligne]. Adresse URL:
http://www.bannerengineering.com/en-US/.
Documentation relative au Verilog HDL
Telecom Paris Tech. (5 mars 2010).Cours en ligne verilog, [En ligne]. Adresse URL:
http://comelec.enst.fr/hdl/verilog_intro.html
Livres
Documentation relative au FPGA Xilinx Spartan 3
Pong P. Chu, FPGA Prototyping by VHDL Examples, 2008, 437 pages.
Documentation relative au PIC18F
Muhammad Ali Mazidi, IC microcontroller and embedded systems: using Assembly and C for PIC 18,
2008, 816 pages.
Dessins technique
Frederik E. GIESECKE. Dessin technique, Pearson Education, Inc.,2004, 784 p.
6
2.0 Objectifs généraux et spécifiques du projet
La réalisation de ce projet a, dans un premier temps, été planifiée pour permettre la course sur circuit et la
course sur piste d’accélération. L’objectif principal du projet a été réévalué au niveau de l’étude de la
conception et de la réalisation de la piste d’accélération seulement. En effet, tout au long des trois rapports
de progrès, l’échéancier n’a eu de cesse d’évoluer dans le but de s’adapter au mieux aux avancements
des travaux réalisés. Plusieurs paramètres lors de la période des deux premiers rapports de progrès ont
fait en sorte que l’échéancier a difficilement pu être tenu tout au long de la session. La multidisciplinarité du
projet en lui-même ainsi que le manque d’organisation dans les méthodes de travail et de gestion du
temps ont fait en sorte que des étapes prévues comme rapidement exécutables n’ont pu êtres menées à
terme dans le temps imparti. Cependant, le projet de la piste d’accélération sera livré en bon et du forme
au promoteur M. Fréderic Deslile pour le début de l’été afin qu’il puisse ouvrir l’autodrome au public. Il est
cependant important de prendre note que le présent document ne relate que les avancements en date de
la remise du rapport final et ne représente qu’une partie du travail qui sera finalement effectué d’ici la
livraison du produit au promoteur.
7
3.0 Aspects techniques et éléments de conception
3.1 Méthodologie utilisée
Gardant en tête que le projet est une somme de sous parties distinctes, les tâches on été séparées entre
les deux membres de l’équipe. Chacun avance ses parties et une mise à niveau des connaissances est
faite entre les deux membres sur une base hebdomadaire.
3.2 Avancement du projet
Le Tableau 1 permet de prendre connaissance rapidement des différents avancements effectués
depuis la remise du plan de travail en date du 15 septembre 2009. Soit la légende suivante pour le
Tableau 1:
ÉTAPE 1 :
Début : Après la remise du plan de travail (15 septembre 2009)
Fin : Remise du premier rapport d’étape (30 octobre 2009)
ÉTAPE 2 :
Début : Après la remise du premier rapport d’étape (31 octobre 2009)
Fin : Remise du deuxième rapport d’étape (11 décembre 2009)
ÉTAPE 3
Début : Après la remise du deuxième rapport d’étape (12 décembre 2009)
Fin : Remise du troisième rapport d’étape (4 mars 2010)
ÉTAPE 4
Début : Après la remise du troisième rapport d’étape (5 mars 2009)
Fin : Remise du troisième rapport d’étape (16 Avril 2010)
8
Tâches Étape
1
Étape
2
Étape
3
Étape
4
Choisir le type microcontrôleur et se familiariser avec l’outil de
programmation MPLAB
Se familiariser avec la programmation du microcontrôleur en langage
assembleur
Programmer la séquence d’allumage
Programmer les quatre différents modes de course
Choisir le mode de course désiré
Valider et tester à l’aide d’une plaquette de prototypage
Choisir et acheter le matériel constituant la partie centrale de l’arbre
Choisir et acheter les lumières de l’arbre et les socles
Élaborer le circuit de commande des lumières et déterminer les
composantes électroniques nécessaires
Faire les plans de l’arbre sur Solidworks et envoyer le tout au machiniste
pour fabrication
Choisir et acheter les capteurs
Choisir tous les composantes électroniques pour interfacer le FPGA
Faire les schémas électroniques de la carte principale
Programmer un FPGA pour traiter les données et informations provenant des
capteurs afin de retirer les paramètres d’intérêts.
Élaborer le protocole de communication
Faire les plans de l’afficheur géant
Programmer un PIC pour permettre l’affichage sur écran géant et un autre
pour gérer les imprimantes
Développement de la télécommande
Programmer un logiciel nous permettant de lier toutes les sous-parties
Configurer un module Xbee pour faire le lien entre les PIC de l’afficheur et
des le module de l’arbre
Test et simulation en laboratoire
Créer l’approche RFID pour pouvoir gérer la course sur circuit routier
Tableau 1 - Tâches effectuées
9
4.0 Éléments de conception
4.1 Choix des capteurs
Choisir le bon capteur n’est pas une tâche facile de par le fait qu’il existe sur le marché une multitude
de produits et de modèles qui ont parfois des différences très minimes. Pour une même application, divers
produits peuvent être adéquats pour réaliser la tâche.
Commençons par faire un premier tri et citons les types de produits « phares » que l’on retrouve sur le
marché et qui sont susceptibles de nous intéresser.
Il existe à la base deux types de capteurs (ayant chacun un mode de détection différent) qui sont
envisageables. Les capteurs fonctionnant en mode opposé et ceux fonctionnant en mode avec réflexion
sur une pastille réfléchissante.
Le mode opposé est composé d’un émetteur dont le faisceau est aligné face à celui du récepteur. Pour le
mode avec réflexion sur une pastille, c’est la pastille qui est alignée face à l’émetteur qui renvoie le
faisceau en direction du récepteur qui se trouve dans le même boîtier que l’émetteur. À la Figure 2 nous
retrouvons une schématisation du tout.
À ce stade on peut encore rétrécir la gamme de produits potentiels. Il existe des capteurs qui fonctionnent
en CC et d’autres en CA. Les capteurs fonctionnant en CC seront préférés, puisque leur temps de
réponse est plus rapide. En CA, lorsque le faisceau est coupé, la réponse est envoyée lors du cycle
suivant, ce qui fait que l’on perd quelques millisecondes. De plus, les capteurs fonctionnant en CA sont
plus dispendieux. Le seul avantage du CA est qu’on peut les brancher directement sur une prise 120V.
4.1.1 Ligne de départs
Cette section à pour but de donner les caractéristiques incontournables concernant les capteurs
de la ligne de départ. Le tout mènera au choix final pour instrumenter la ligne de départ.
Les capteurs de départ servent à détecter et confirmer (grâce aux lumières prestage et stage) que la
voiture est adéquatement placée pour la suite des procédures et le lancement de la course.
Pour la ligne de départ, le premier critère à respecter est la portée. Cet aspect est en fonction de la taille
d’un couloir qui a une largeur de 30 pieds, soit 9,144 mètres.
Figure 2 - Schématisation du mode opposé et du monde avec une réflexion sur une pastille
10
Le deuxième point qui influence le choix du capteur est le gain.
Pour désigner le gain, certains manufacturiers l’appellent « Excess Gain ». Ce terme peut être défini
comme étant l’énergie supplémentaire du signal afin de palier l’atténuation de ce dernier (due aux aléas
de l’environnement comme la vapeur d’eau, la poussière, la fumée, etc.)
Pour une cellule photoélectrique, l’ « Excess Gain », est le ratio de l’énergie lumineuse reçue sur l’énergie
minimale requise pour activer le capteur. Le tout peut être vulgarisé selon la relation suivante :
������ �� ��. �. = É���� ������� ������ ��� ��é�é��� �é�������
���� ���� ���� �é����ℎ�� �� �������
Selon le tutoriel explicatif du manufacturier « Banner Engineering Corp. », on retrouve les lignes directrices
aidant à déterminer la valeur de « l’Excess Gain » requis. Ces chiffres incluent un facteur de sécurité pour
tenir compte du possible désalignement graduel des capteurs et des modifications des conditions
environnantes.
On en retrouve un résumé qualitatif dans le Tableau 2
Excess Gain Type d’environnement Exemples
1.5
(minimum absolu)
Environnement
« parfaitement propre »
Industrie pharmaceutique
Industrie des semi-conducteurs
≈ 5 Environnement
« légèrement sale »
Bureaux
Certaines usines
≈ 10 Environnement modéré
Industrie lourde
Industrie de l’automobile
Transformation d’aliments
≈ 50 Environnement souillé Fonderies
Industrie minière
L’environnement qui accueillera la piste d’accélération est évidemment extérieur. De plus, il faut tenir
compte du fait que les compétiteurs à la ligne de départ feront survirer leurs pneus afin de les réchauffer et
de déposer de la gomme sur l’aire de départ ce qui aura pour effet d’offrir plus de traction au départ. Il faut
donc un capteur à gain élevé à la distance de détection (9 mètres).
Pour les capteurs de départs, le mode de détection opposé est préféré. La raison est qu’il est
extrêmement difficile d’avoir un gain élevé à 9 mètres de distance si on utilise le mode de détection
Tableau 2 - Caractérisation de l'Excess Gain
11
utilisant une pastille réfléchissante. Du câblage devra cependant être acheminé des deux côtés de chaque
couloir.
Le capteur choisi est donc le modèle de la série « S30 DC en mode opposé» provenant du manufacturier
« Banner Engineering ».1 Ce capteur a une portée allant jusqu’à 60 mètres et un gain à 9 mètres d’environ
40.
Ceci est conforme aux spécifications imposées et tient compte des considérations élaborées ci-haut dans
cette même section. Le gain pour la distance de détection désirée est adéquat considérant le type
d’environnement en présence.
4.1.2 Capteurs le long de la piste
Pour assurer la partie du chronométrage des temps intermédiaires et finaux, il faut faire la
sélection de capteurs qui se situeront le long de la piste. Les exigences engendrées sont différentes de
ceux utilisées pour le départ de la course.
Le gain des capteurs le long de la piste peut être plus faible puisque les aléas de l’environnement proche
de la ligne de départ ne devraient plus êtres présents. Cependant, la distance de détection de 9mètres
reste la même.
Ainsi nous ne sommes plus limités aux capteurs en mode opposé. De plus, le promoteur préfère que nous
utilisions le mode avec une réflexion sur une pastille de façon à ne pas avoir à faire traverser du câblage
sous la piste.
En plus de la contrainte de gain, les capteurs le long de la piste devront aussi respecter une autre
condition. Ce deuxième type de capteur sera appelé à détecter des objets se déplaçant à haute vitesse.
Pour s’assurer que le capteur est adéquat, il faut se référer à l’« Output Response Time » dans la
documentation technique. Cela correspond au temps minimal pendant lequel le faisceau doit être coupé
pour que l’objet soit détecté. Considérons le cas d’une voiture qui se déplace à une vitesse de 250 km/h
(vitesse maximale pouvant être atteinte selon le promoteur). Il faudrait que les capteurs soient capables de
bien fonctionner dans une telle situation.
1 Pour avoir les parties des spécifications correspondantes se référer à la section 10.1 Annexe – Caractéristiques ayant menées au choix du capteur de la série S30 DC. Pour avoir accès à la fiche technique complète, se référer à la section 2.1 Recherche bibliographique
12
Pour déterminer l’ « Output Response Time » minimal on suppose :
- un pneu de 16 pouces de diamètre
- un capteur à 2 pouces du sol (la détection se fait obligatoirement au niveau des pneus et
certaines voitures ont des ailerons très bas
La Figure 3 illustre les dimensions différentes sur la roue.
À l’aide de cette figure et de l’hypothèse de vitesse précédente il est possible de calculer le temps durant
lequel une roue coupera le faisceau lumineux.
� = 2�8! − 6! = 10,58 ������ = 0,269 �è����
250*�ℎ
∗1000�
1*�∗
1ℎ3600�
= 69,44��
.���� ����� ��/��� �� ��� 0��/���� �� 1������ =������
������=
0,26969,44
= 0.00387� = 3,87��
Il faut donc un capteur ayant un « Output Response Time » inférieur à 3,87 ms.
Le capteur choisi est donc le modèle de la série « QS30LLP en mode réflexion sur une pastille» provenant
du manufacturier « Banner Engineering ».2 Ce capteur à une portée allant jusqu’à 18 mètres et un gain à
9 m d’environ 14. L’« Output Response Time » est de 0,5 ms ce qui satisfait notre contrainte de temps
évoquée précédemment.
2 Pour avoir les parties des spécifications correspondantes, se référer à la section 10.2 Annexe – Caractéristiques ayant menées au choix du capteur de QS30LLP. Pour avoir accès à la fiche technique complète, se référer à la section 2.1 Recherche bibliographique
Figure 3 - Schématisation pour déterminer l'Output Response Time
13
Dans le but de se garder une marge de sécurité, lorsque nous avons effectués les calculs relativement à
l’ « Output Response Time », nous avons été conservateur par rapport à la hauteur du capteur et au
diamètre d’une roue. Comme le calcul le montre, nous disposons avec ces données de 3,87 ms pour
effectuer une détection qui a besoin de 0,5 ms (selon les spécifications du capteur sélectionné) ce qui
donne un facteur de sécurité d’environ 8.Le facteur est encore plus élevé en réalité puisque le diamètre
moyen de l’objet à détecter est supérieur à 16 pouces.
4.1.3 Remarques et considérations d’ordre générales concernant les capteurs
Concernant les réflecteurs, nous avons choisi un facteur de réflexion de 3. Ceci est un indice de l’énergie
réémise par la pastille réfléchissante en direction du récepteur. Le standard (facteur de réflexion de 1) a
été désigné comme étant la réflexion sur une pastille de leur gamme de produit, soit le modèle BRT-3. La
marge de manœuvre est augmentée. Le tout n’a pas été surdimensionné simplement pour avoir une
marge de sécurité. Il y a une considération d’ordre pratique relativement au nettoyage et à l’entretien. Si on
avait moins de latitude en termes de gain/facteur de réflexion, le nettoyage des lentilles des capteurs
devrait être plus fréquent pour assurer la détection en tout temps.
Avec les informations élaborées tout au long de cette section, nous avons communiqué avec un
distributeur de capteurs qui a proposé des solutions. Nous avions les informations et connaissances
techniques nécessaire pour valider le choix. Il restait par la suite à regarder le prix de l’ensemble. Le
soumissionnaire est arrivé avec un prix global de : 1647,35$ taxé.
� On y retrouve :
� les quatre paires émetteur/récepteur de la ligne de départ
� les six capteurs le long de la piste
� les six pastilles réfléchissantes y étant rattachées
Si on compare au prix proposé par un soumissionnaire qui fut contacté avant qu’on nous confie la
tâche3:
� Start line Emitter/Receiver : 1260$
� Downtrack Retroreflective Infrared 1050$
� Silver Reflectors for Downtrack Sensors 60$
Ceci fait un total de 2370$
Comme nous comparons des produits destinés à des fonctions identiques, il apparaît évident que le moins
cher semble le meilleur parti surtout que la démarche effectuée pour en arriver à ce choix a été faite de
façon rigoureuse garantissant le fonctionnement dans les conditions spécifiées.
3 Voir plan de travail
14
4.2 La mécanique
La réalisation du feu de départ a demandé la conception de plans à l’aide du logiciel SolidWorks. Cette
étape de modélisation a permis au promoteur de nous apporter des remarques afin que le produit final
réponde totalement à ses attentes.
4.2.1 Modélisation
De conception acier-carbone pour son ensemble, l’arbre de noël est
divisible en deux parties distinctes qui sont le pied et le poteau central.
La Figure 4 expose la vue de face du pied et du poteau central tel que
simulé dans le logiciel de conception alors que la Figure 5 en montre
une vue isométrique.
La masse totale de l’arbre de noël est de 49kg et son centre de gravité
est situé à 53 cm du sol. Le poteau central, qui devra être amovible si
le promoteur veut le ranger durant les fermetures de l’autodrome, a un
poids total de 25,59kg. Finalement, le pied (qui assure la stabilité via
un abaissement du centre de gravité) a un poids de 24,24kg.
Ces évaluations ont été simulées à l’aide du logiciel SolidWorks en
paramétrant le poids volumique de l’acier-carbone sans tenir compte
du poids des globes lumineux.
Nous avons estimé que cette
approximation était assez proche
de la réalité pour entamer la production.
Le poteau central supporte 28 ampoules de 100W qui auront pour
fonction d’indiquer le départ aux concurrents. Cette puissance
d’ampoule est le minimum requis pour être visible de jour et cela à une
distance de 200 m. Notons que nous utilisons des globes à
incandescence pour des raisons de prix et de disponibilité dans les
quincailleries régionales. Il est aussi important d’introduire le fait qu’il
est impossible d’alimenter en même temps les 28 lampes. En effet,
nous aurions besoin d’une puissance de 2,8kW ce qui est actuellement
impossible sur une prise 110V.
Le standard d’alimentation qui ne demanderai aucune modification
particulière de l’équipement électrique de l’autodrome impose un
Figure 5 - Vue isométrique
Figure 4 - Vue de face
15
courant disponible maximum de 15 A. En effectuant un rapide calcul, nous pouvons déduire que pour 28
lampes de 100W, il nous faudrait un courant disponible de 25,45 A. Nous reviendrons sur cette
problématique dans la section traitant de la programmation et des schémas électriques.
Lors de la production de l’arbre, nous devions choisir entre l’acier et l’aluminium pour créer le pied et le
poteau central. Le meilleur compromis de fabrication aurait été de concevoir le pied en acier et le poteau
central en aluminium. Cette combinaison aurait permis d’abaisser le centre de gravité de l’arbre tout en
ayant l’avantage de faciliter les manipulations d’insertion et d’extraction du poteau central dans le pied. En
effet, l’aluminium est trois fois moins lourd que l’acier. Cependant son prix est trois fois supérieur. Ce
simple argument a finalement porté le choix de fabrication à une structure entièrement en acier.
La taille du poteau central est de 6 pieds et son emprise au sol est de 36 pouces soit environs 91 cm. Ces
caractéristiques lui assurent un centre de gravité assez bas pour éviter tout basculement inopportun. Le
design du pied a été étudié pour pouvoir ajouter des poids tels que des sacs de sable afin de maintenir le
poteau. La Figure 6 montre la vue de coté de l’arbre.
Les douilles des 8 lampes de « Stage » et « Prestage » sont visibles plus en détails en haut de la Figure 7.
Elles seront modifiées dans la réalisation finale puisque celles-ci sont trop imposantes au goût du
promoteur.
-
Figure 6 - Vue de côté Figure 7 - Zoom sur "Stage" et
"Prestage"
16
4.2.2 Plans
La réalisation de l’arbre de noël a nécessité la mise en plan de plusieurs pièces afin de créer l’assemblage
précédemment illustré. Afin de se donner un ordre d’idée des dimensions réelles de l’arbre, un plan
illustrant les cotations réelles est montré à la Figure 8. Les cotations sont en système impérial au désir du
machiniste.
Notons que le suivi de construction et de respect des plans a demandé un temps de fabrication plus
important que celui estimé dans nos précédents rapports de progrès.
Figure 8 - Mise en plan de l'assemblage
17
4.2.3 Réalisation
Après plusieurs semaines de développement, nous sommes maintenant à même de présenter l’arbre de
noël tel qu’entreposé dans l’atelier de mécanique de l’Université. Nous regarderons dans un premier
temps quel type de luminaire nous avons choisi et présenterons le résultat final de la réalisation.
4.2.3.1 Choix des luminaires
La liste des critères qui ont permis le choix des luminaires est la suivante:
- Lumière d’extérieur
- Capable de résister aux intempéries
- Avoir une puissance suffisante pour être visible de jour
- 12 lumières jaunes, 4 lumières vertes et 4 lumières rouges
Deux choix se posaient à nous pour ce qui était des feux de l’arbre de noël. Ceux-ci étant l’achat de
lampes incandescentes où bien à technologie LED.
Malgré les importants avantages de la technologie LED, notre choix s’est porté pour les ampoules
incandescentes. Cela se justifie principalement par leur prix raisonnable de 5$ par ampoule ainsi que leur
disponibilité en magasin à des fins de remplacement. C’est la commodité de la lampe usuelle qui a fait
pencher notre promoteur vers cette technologie. En effet, la durée de vie de ces ampoules est
considérablement plus faible que celle des technologies LED et leur temps de réponse à la consigne
d’allumage est considérablement plus long. Ce dernier point est tout de même non négligeable lorsque
l’on sait qu’une course de type «dragster» peut se gagner sur le simple fait d’avoir le moins de temps de
réaction à l’allumage du feu de départ.
Parenthèse faite, nous avons opté pour une ampoule décorative à
faisceau large de 100 Watts incandescente, étanche. Tous les critères
sont rencontrés et cette ampoule est disponible en différentes colories
qui sont le jaune, le rouge ou le vert. La Figure 9 expose une des
ampoules achetées. Nous avons testé le tout pour s’assurer que la
lumière serait visible de jour, à l’extérieur.
Figure 9 - Ampoule de l'arbre de noël
18
4.2.3.2 Choix et achat des socles pour les lumières
Pour cette partie, il fallait s’assurer que le socle choisi soit étanche
pour résister aux intempéries et que le culot de l’ampoule s’adapte
bien au socle.
La Figure 10 illustre un de ces socles que nous nous sommes
procurés.
4.2.3.3 Présentation du résultat final
Encore en construction, il restera à changer les douilles des lumières de « stage» et «prestage » ainsi
que de passer un coup de peinture pour harmoniser l’ensemble.4
Le câblage électrique sera fini dans les prochains jours et nous devrions avoir un arbre fonctionnel dans
les deux semaines qui suivent. Pour que l’arbre puisse fonctionner, celui-ci a besoin de la carte
électronique de contrôle qui est actuellement terminée. La Figure 11 montre la vue de face (tel que verrons
les compétiteurs) ainsi qu’une vue de côté.
4 Le modèle construit diffère légèrement des plans présentés à la section 5.2 Plans. La raison est une mauvaise lecture des plans du machiniste lors de la fabrication du pied. Lorsque nous insérions l’arbre à l’intérieur du pied, le haut du pied coïncidait avec la lumière du bas. Nous avons donc rallongé le poteau central de 5 pouces pour palier ce petit défaut.
Figure 11 - Vue de face et de côté
Figure 10 - Socle des ampoules
19
4.3 Études
Cette section expose les composants de l’autodrome qui sont encore en cours de développement en date
de la rédaction de ce document. Les pièces électroniques ont été sélectionnées et une partie d’entre elles
sont en commande.
4.3.1 Télécommande
La télécommande est le point le plus important de la piste de type «dragster». En
effet, elle sera finalement la seule interface homme machine pour contrôler
l’ensemble des fonctionnalités de la piste d’accélération. Pour ce faire, nous avons
opté pour l’utilisation d’un afficheur à cristaux liquides de 20 caractères sur 4 lignes,
comme illustrée à la Figure 12.
Elle sera munie d’un ensemble de boutons ergonomiques pour naviguer dans les
menus des modes de la piste de drag. De plus, la télécommande aura en sa
possession deux boutons poussoirs étanches de type industriel pour donner un
départ ou bien remettre à zéro une course. Un exemple de bouton est à la Figure
13. L’utilisateur sera capable de définir entre autre des temps de départ différés
pour les couloirs de course. Il aura aussi la possibilité de choisir un mode de départ.
De plus, l’utilisateur pourra obtenir des informations de la course qui vient de se
dérouler tel que la vitesse des deux concurrents, leur temps de réaction au départ,
leur temps à 60 pieds et à 1/8 mile, etc.
Nous pouvons aussi implémenter un mode «départ automatique» qui fait en sorte que le départ soit donné
après un temps aléatoire compris entre 0 et 5 secondes lorsque les voitures sont correctement placées sur
la ligne de départ. La télécommande sera composée d’une pile au lithium rechargeable par port USB. La
pile pourra faire en sorte de fonctionner durant une journée complète sans recharger la batterie.
Le boitier de la télécommande illustré à la Figure 14 a été
commandé et se trouve avoir une hauteur de 18 cm, une largeur
de 10 cm et une profondeur de 4 cm. Il contient un emplacement
spécifique pour recevoir un clavier, une batterie et un écran LCD
tel qu’en sont nos besoins. Deux circuits électriques ont été
conceptualisés pour être insérés à l’intérieur du boitier. Le routage
de ces circuits est actuellement en cours.
Figure 12 - Afficheur télécommande
Figure 13 - Bouton poussoir
Figure 14 - Boitier de la télécommande
20
4.3.2 Afficheurs géants
Les afficheurs géants ne sont pas encore développés.
L’idée de cet élément est de récupérer les mêmes informations de vitesse et de
temps visibles aussi sur la télécommande de l’opérateur, afin de les afficher sur des
afficheurs à lampes incandescentes. Un exemple de ce type d’afficheur est exposé
à la Figure 15.
L’idée est de créer des afficheurs à 7 segments géants. Nous pouvons calculer dès
maintenant le nombre de globes incandescents dont nous avons besoin.
Nous utiliserons 17 lampes pour chaque chiffre, soit la configuration décrite à la
Figure 16.
Cette figure expose à gauche la disposition des lampes
incandescentes et à droite une image représentative des
segments.
Nous considérons que 3 chiffres de nombres entiers pour
représenter la vitesse du véhicule sont suffisants. Avec une précision au
centième, cela nous demande 5 chiffres. Comptons aussi une lampe pour faire
la virgule, nous arrivons à :
= 17�3 3 2 3 1 = 86
Pour indiquer la vitesse il nous faut 86 lampes. Il est possible de faire le même calcul pour afficher le
temps. En supposant que nous ayons besoins de 2 chiffres avant et de 3 chiffres après la virgule, nous
obtenons le même nombre de lampes. Cela implique que, si nous voulions afficher la vitesse et le temps
simultanément, il faudrait utiliser un total de 172 lampes. Pour réduire radicalement le nombre de lampes
utilisées afin de réduire le coût de l’afficheur nous pouvons simplement utiliser 5 chiffres et faire alterner le
temps et la vitesse aux yeux du public. Cela présenterait la configuration illustrée à la Figure 17.
En utilisant le type d’afficheur de la Figure 17, nous aurions besoin de 5 chiffres, soit 85 lampes ainsi que 2
lampes pour les virgules et 2 lampes pour indiquer quel est l’affichage courant, soit un total de 89 lampes
au lieu des 172 requises.
En considérant le prix d’une ampoule de 100W comme coûtant 5$, nous pouvons imaginer les prix suivant
listés dans le Tableau 3.
Figure 16 - lampes incandecentes et leur
représentation 7 segments
Temps
Vitesse
Figure 17 - Afficheur 1 ligne
Figure 15 - Afficheurs incendecents de la piste de drag
de Napierville
21
Type de solution Nombre de lampe Prix du système
luminaire ($) Consommation (kW)
Économie à
l’achat ($)
Deux afficheurs 172 860 17,2
Un afficheur 89 445 8,9 415$
De plus, notons que pour l’autodrome, il y aura deux afficheurs de ce type situés le long de la piste
d’accélération (un pour chaque couloir de course).
Étudions maintenant la comparaison entre la conception d’un afficheur géant à lampe incandescente et un
afficheur à lampe LED.
Observons que la consommation minimale est de 8,9 kW avec l’utilisation de lampes incandescentes et
que la contrainte de courant disponible sur une prise d’alimentation standard est de 15 A. Si nous
effectuons un calcul rapide, nous nous rendons compte que pour des ampoules de 100W il faudrait un peu
plus de 80 A pour alimenter les lampes incandescentes en même temps.
Cette solution n’étant pas réalisable, une solution à lampe LED se trouve être le compromis idéal. En effet,
dans ce type de technologie nous arrivons à trouver des ampoules fournissant l’intensité lumineuse
d’ampoule incandescente de 75W pour une consommation de 6,8 W. ainsi pour 89 lampes nous n’aurons
seulement besoin que de 5,5 Ampères. Un exemple de ce type de lampe est disponible à la Figure 18.
Au vu de l’analyse effectuée, l’utilisation de lampe LED sera priorisée pour réaliser les afficheurs géants.
Tableau 3 - Comparaison des deux types d'affichages
Figure 18 - Lampe LED
22
4.3.3 Imprimantes
Les deux imprimantes, dont un exemple est illustré Figure 19, ont
pour rôle de fournir sur format papier les informations sur la course
des concurrents. Nous retrouvons une imprimante pour le couloir de
gauche et une pour le couloir de droite. Nous avons besoin de deux
imprimantes car une imprime sur un papier blanc et l’autre sur un
papier jaune afin de différentier le gagnant du perdant.
Chacune des imprimantes sera reliée à un microcontrôleur pic par port
série.
4.3.4 Le logiciel de gestion
Le logiciel de gestion entièrement réalisé à l’aide du logiciel Visual basic permettra à l’opérateur de
configurer l’autodrome à distance afin de pouvoir modifier certains paramètres tel que le choix de
l’affichage géant en MPH ou Km/h. Le logiciel se trouvant être une des étapes de conception les moins
essentielles au fonctionnement de l’autodrome sera développée une fois que l’ensemble des autres
modules du site seront fonctionnels. Un exemple d’interface professionnel de gestion d’autodrome est
présenté à la Figure 20. Nous pouvons dès lors imaginer nous en inspirer et en conceptualiser une version
plus allégée
Figure 20 - Exemple de logiciel de gestion de piste d'accélération
Figure 19 - Imprimante située en fin de course pour affichage des résultats aux
concurenrts
4.4 L’Électronique5
La piste d’accélération aura besoin d’un ensemble de composants électriques afin de permettre la
visualisation des performances des véhicules au public ainsi qu’à l’opérateur d’effectuer certaines
opérations. Pour ce faire, nous devons créer plusieurs cartes électroniques capabl
informations à haute vitesse. Il y aura un total de 5
de plusieurs cartes électroniques.
Notons que le boîtier de l’arbre de noël
de Xilinx et que l’ensemble des autres
Le boîtier de réception pour le logiciel
permettra de créer une interface utilisateur pour opérer l’autodrome.
5 L’ensemble des schémas électriques produit durant le projet sont disponibles en Annexe dans la section 7.2
Boitier
récepteur
pour le
logiciel
2 Cartes
Figure
aura besoin d’un ensemble de composants électriques afin de permettre la
visualisation des performances des véhicules au public ainsi qu’à l’opérateur d’effectuer certaines
opérations. Pour ce faire, nous devons créer plusieurs cartes électroniques capabl
informations à haute vitesse. Il y aura un total de 5 boîtiers électriques qui eux-mêmes seront composés
plusieurs cartes électroniques. La relation entre ces boîtiers est illustrée à la Figure
de l’arbre de noël (celui du centre sur la Figure 21) est équipé d’un
Xilinx et que l’ensemble des autres boîtiers seront pilotés par des microcontrôleurs PIC de la série 18F.
de réception pour le logiciel sera, quant à lui, équipé d’un serveur WEB RABBIT 5100 qui
permettra de créer une interface utilisateur pour opérer l’autodrome.
ble des schémas électriques produit durant le projet sont disponibles en Annexe dans la section 7.2
Boitier
arbre de
noël
3 Cartes
Boitier
télécom-
mande
1 Carte
Boitier
panneaux
d’affichage
1 Carte ou
plus
Boitier
imprimantes
1 Carte
Boitier
récepteur
pour le
logiciel
2 Cartes
Figure 21 - Relation entre les boîtiers électriques
23
aura besoin d’un ensemble de composants électriques afin de permettre la
visualisation des performances des véhicules au public ainsi qu’à l’opérateur d’effectuer certaines
opérations. Pour ce faire, nous devons créer plusieurs cartes électroniques capables de s’échanger des
êmes seront composés
Figure 21.
est équipé d’un FPGA Spartan-3
s seront pilotés par des microcontrôleurs PIC de la série 18F.
équipé d’un serveur WEB RABBIT 5100 qui
ble des schémas électriques produit durant le projet sont disponibles en Annexe dans la section 7.2
panneaux
d’affichage
1 Carte ou
24
4.4.1 Boîtier - Électronique de l’arbre de noël
Nous travaillons actuellement sur le boîtier électronique de l’arbre de noël (boîte centrale) qui se compose
d’un ensemble de cartes interfacées ensembles. Il y a une carte mère et deux cartes filles telle que la
Figure 22 l’illustre :
Descriptions des cartes du boîtier
La carte mère
Constituée d’un FPGA, la carte mère aura le rôle principal dans le fonctionnement de l’autodrome. Elle
possède entre autre un oscillateur 25Mhz pour effectuer le chronométrage du circuit, une mémoire ROM
pour garder en mémoire le programme de l’autodrome ainsi que de multiples entrées/sorties.
Nous reviendrons en détails sur ses fonctionnalités lors de la section traitant de la programmation.
Cependant, pour les résumer, son rôle sera de traiter les données des capteurs de la pistes, de gérer les
différents modes de courses, d’enregistrer les paramètres de chacun des compétiteurs, d’envoyer les
données traitées vers les autres modules de l’autodrome, etc.
La carte mère sera aussi composée du module radiofréquence Xbee qui permettra l’envoi de données en
série vers les autres modules du circuit via un réseautage sans fil à 2,4GHz.
La carte fille Opto-isolatrice
La carte fille Opto-isolatrice aura deux rôles majeurs. Le premier est la transformation des signaux de
commandes LVTTL du FPGA vers une tension 110V pour l’allumage des feux de départ de l’arbre. Le
Carte Opto-isolateurs
Alimentation Arbre de
noël
Carte Mère
FPGA + Rom
Horloge
Carte Acquisition
données capteurs
Xbee
Lumières Arbre de noël
Signaux Capteurs
110V
Figure 22 - Schéma bloc du boîtier de l'arbre de noël
25
second est d’être la carte d’alimentation des composants électronique de la carte mère en 3,3V ainsi que
l’alimentation de l’ensemble de tous les capteurs de la piste. Ceux-ci seront alimentés sous une tension de
15V.
La carte fille d’acquisition
La carte fille d’acquisition a pour rôle de récupérer les signaux des capteurs de la piste d’accélération et de
les rendre compatibles au voltage du FPGA pour analyse.6
Étude des courants de la boîte électrique de l’arbre
Comme expliqué précédemment, le boîtier électrique de l’arbre contiendra deux transformateurs de
tensions qui auront pour rôles d’alimenter l’électronique du boîtier ainsi que les capteurs de la piste. Avant
de passer à la fabrication de la plaque nous avons dû effectuer une étude des courants minutieuse afin de
dimensionner correctement les transformateurs ainsi que les pistes du circuit électrique (PCB) qui sera
confectionné par le technicien. Le résumé des calculs permettant de solutionner le dimensionnement des
transformateurs sont présentés ci-dessous. Notons que nous n’exposons que les calculs de la carte
d’alimentation opto-isolatrice du boîtier de l’arbre de noël étant donné qu’il en va de la même logique pour
tous les autres boîtiers qui posséderons des transformateurs.
Transformateur des capteurs
Le transformateur des capteurs sera dimensionné tel que fournissant 24V et 1 ampère. Voici le
raisonnement venant à ce choix :
La consommation totale des capteurs électriques est la suivante 7:
Pour la ligne de départ : Nous avons 4 émetteurs et 4 récepteurs (2 par ligne de départ). Ceci nous
donne un courant de :
45678 9:76;8 = �4:<:8 × 4 3 �4;:5:78 × 4 = �25�> × 4 3 �20�> × 4 = 180 �>
Les récepteurs doivent êtres capables de fournir 10mA supplémentaire chacun pour fournir le signal au
FPGA. Ce courant vient s’ajouter au courant trouvé précédemment :
45678 9:76;8 = 180�> 3 �10�> × 4 = 220 �>
Pour les capteurs le long de la piste : Nous avons 6 émetteurs et 6 pastilles réflectrices qui utilisent un
courant de 35mA.
45678 5?@;A: = �4:<:8 × 6 = �35�> × 6 = 210 �>
Les émetteurs font office de récepteur étant donné que nous utilisons des pastilles réfléchissantes. Celle-ci
doivent êtres capables de fournir 10mA supplémentaire chacun pour fournir le signal au FPGA.
45678 5?@;A: = 210 �> 3 �10�> × 6 = 270 �>
6 Le schéma électrique en production actuellement est disponible à la section 10.4 Annexe – Plans optocoupleurs et alimentations 7 Les valeurs des courants Iemet et Irecept se retrouvent dans la documentation technique des capteurs. Pour avoir accès à leur fiche technique complète, se référer à la section 2.1 Recherche bibliographique
26
Au final, le transformateur devra être capable de fournir :
45678 9:76;8 3 45678 5?@;A: = 220�> 3 270�> = 490�>
Nous avons choisi un régulateur de tension de 15V étant donné que les capteurs doivent êtres alimentés
entre 0 et 30V. Sa tension d’entrée minimale pour fournir 15V DC est de 23V ce qui justifie le fait que notre
transformateur soit un 110V / 24V.
En considérant un 20% de marge de dimensionnement ainsi que les pertes engendrées dans le
régulateur, le courant que nous devrions êtres capables de fournir pour alimenter l’ensemble des capteurs
se trouve être de 600mA. Cependant, nous avons choisi un transformateur de 1 A car nous avons mis en
première importance le poids et la taille du transformateur choisi.
Le meilleur compromis poids/dimension/prix/puissance se trouve être un transformateur de la société
« Signal Transformers » qui nous propose les caractéristiques résumées dans le Tableau 4. La Figure 23
illustre l’alimentation des capteurs.
Voltage(V) Ampérage (A) Hauteur (mm) Largeur (mm) Longueur (mm) Poids (g) Prix ($)
24 1A 34,93 57,2 41,3 340 17,52
Transformateur de l’électronique
Par le même raisonnement, nous faisons la somme de tous les courants que ce transformateur devra
alimenter et nous trouvons :
4BC:: 3 4?78? 3 4D7E6 3 4;?< 3 4?A5FGG68:@; = 48;6HAD?
215 3 60 3 260 3 10 3 10 = 555�>
On major ce résultat de 20% ce qui nous donne environs 670mA.
Tableau 4 - Caractéristiques du transformateur des capteurs
Figure 23 - Alimentation des capteurs
27
Nous avons alors choisis un transformateur de la même compagnie dont les caractéristiques sont
résumées dans le Tableau 5.
Voltage (V) Ampérage (A) Hauteur (mm) Largeur (mm) Longueur (mm) Poids (g) Prix ($)
6,3 0,7 34,92 31,9 41,3 140 17,52
Pour ce qui est des autres boîtiers, nous nous contenterons de les développer en détail seulement dans le
rapport final du projet.
4.4.2 PCB réalisé
Note : Les cartes électroniques réalisées en collaboration avec le technicien de l’université peuvent différer
quelque peut des fonctions respectives annoncées pour chacune d’elles. Par exemple, sur les cartes
présentées, les transformateurs de tensions ne sont pas implémentés.(L’alimentation externe se faisant
directement en 12V au lieu de 110V).
Une première version des cartes électroniques du boitier électrique de l’arbre de noël a été produite. Le
résultat visuel de cette conception est présenté dans cette section. Théoriquement, l’ensemble du boitier
est complet et fonctionnel avec les cartes électroniques présentées dans cette section. Cependant nous
avons révisé quelques éléments de conception et de ce fait nous allons renvoyer en production une
seconde version des cartes électroniques. Dans cette nouvelle révision, nous allons optimiser la
dissipation de chaleur générée par les triacs ainsi que modifier la connectique entre les différentes cartes
électroniques. Aussi, nous allons restructurer le connecteur de distribution d’alimentation des capteurs de
piste situés le long des deux couloirs d’accélération.
Sans entrer plus profondément dans les détails, nous vous présentons la réalisation qui a découlé de la
conception des circuits électriques. La Figure 24 présente le circuit électrique opto-isolateur triac ainsi que
les connecteurs alimentant en 110V les lampes de l’arbre de noël. La Figure 25 expose, quant à elle, la
carte d’acquisition des capteurs de piste qui est implémentée sur la même carte que le module Xbee avec
les différents régulateurs de tension nécessaires au fonctionnement du système.
Tableau 5 - Caractéristiques du transformateur des composants
28
Pour finir, nous présentons la carte FPGA à la Figure 26, qui dans cette version du produit se trouve être
une carte électronique déjà élaborée à l’UQAC. Le schéma électrique correspondant en annexe 7.2.3 n’a
pas été utilisé pour la conception de cette carte électronique. Cependant nous retrouvons exactement les
mêmes composants sur les deux concepts (celui développé et celui utilisé). Dans la version livrable du
produit au client, nous utiliserons notre conception.
Figure 24 - Carte électrique opto-isolateur triacs Figure 25 - Carte d'acquisition et de communication sans fil Xbee
Figure 26 - Carte FPGA
29
4.5 La programmation8
Nous avons choisi de programmer l’ensemble des fonctionnalités de l’autodrome vers un FPGA Xilinx
Spartan-3 XC3S200 permettant une flexibilité de programmation accrue comparativement au PIC
18F4221. Les principaux avantages de ce nouveau système de contrôle sont la gestion des informations
en parallèles ainsi qu’un nombre important d’entrées/sorties. Il est aussi équipé de 216kbits de «block
Ram» permettant de sauvegarder en mémoire les performances d’un grand nombre de véhicules.
Ce FPGA se programme en langage Verilog HDL qui est un langage de description logique. Pour
simplifier, nous pouvons résumer le fonctionnement de la puce par le fait qu’elle permet de modifier son
architecture interne afin de créer plusieurs modules de traitements d’informations indépendants. Chaque
module à l’intérieur du FPGA fonctionne en parallèle. Les modules s’échangent des informations à une
vitesse d’opération de 25MHz.
Le schéma bloc de la structure interne de la puce programmée pour les besoins du projet l’autodrome est
décrit dans la Figure 27 à la page suivante. Il est possible de voir que la méthode de conception utilisée
est l’approche hiérarchique. Dans une telle approche, les modules sont créés de façon à pouvoir les
réutiliser plusieurs fois. Chaque fois que ces modules sont utilisés, nous dirons qu’ils sont instanciés.
8 L’ensemble du codage en langage Verilog est disponible en Annexe à la section 7.3
Module Piste
Module
Chronomètre
Module
Capteur
Module Télécommande
Module Horloge 2Khz
Module Traitement des
données
Module
Ram
Module
UART
Module Convertisseur
BCD
Additionneur
3
FPGA
Figure 27 - Structure du FPGA programmé en Verilog HDL
30
4.5.1 Module télécommande
Le module télécommande est instancié une fois. Il a pour rôle de contrôler les modes de fonctionnements
de la piste d’accélération qui sont au nombre de quatre.
� Mode 1 - Essai seul à gauche : active le système que pour le couloir de gauche. � Mode 2 - Essai seul à droite : active le système que pour le couloir de droite. � Mode 3 - Duel sans Dial-in : active la piste pour deux voitures de puissance équivalente.
Permet à l’opérateur de rentrer un numéro de voiture via à la télécommande. � Mode 4 - Duel avec Dial-in : active la piste pour deux voitures de puissance différentes et
permet alors à l’opérateur d’entrer un temps de retard pour la voiture la plus rapide ainsi que d’indiquer les numéros des voitures.
Ce module contrôle si les voitures sont en train de concourir et bloque tout changement de mode durant
une course.
4.5.2 Module piste
Le module piste est instancié deux fois pour faire la gestion des deux couloirs de courses de la piste
d’accélération. Ses fonctions se résument en 6 points.
� Gérer l’allumage des feux de placement des véhicules, soit le «Prestage» et le «Stage».
� Gérer la séquence d’allumage des feux de départ : allumage des feux par intervalle de 500
millisecondes.
� Gérer le faux départ d’un véhicule : extinction de tous les feux et allumage de la lampe
rouge.
� Gérer un décompte de temps aléatoire entre 0 et 2 secondes. Ce temps aléatoire est inséré
entre le moment ou l’opérateur appuie sur le bouton de départ et le moment d’allumage du
premier feu orange de départ. Le but est que le pilote ne prenne pas l’habitude de regarder
l’opérateur appuyer sur le bouton de départ et ainsi compter dans sa tête pour démarrer plus
rapidement.
� Calculer la vitesse de pointe du véhicule lors du franchissement de la ligne d’arriver : la
vitesse mesurée possède une marge d’erreur inférieure à 0,2%.
� Enregistrer tous les temps caractéristiques de la course dans des registres 32 bits afin de
les transférer au module de traitement après le franchissement du capteur d’arrivée.
4.5.3 Module chronomètre
Le module chronomètre est instancié deux fois pour servir de chronomètre dans chaque couloir de course.
Ce module est un simple compteur binaire cadencé à 1kHz. Le registre est incrémenté à chaque
milliseconde ce qui nous permet d’obtenir un chiffre différent pour chaque milliseconde passée. Nous
avons décidé que l’ensemble des registres de notre FPGA auraient une taille maximum de 32bits. La
valeur maximum pour le registre représentant le temps est alors de :
31
232 = 4,3. 109��
Cette taille de registre nous donne plus de 1190 heures de temps de chronométrage ce qui est largement
suffisant pour la piste d’accélération.
4.5.4 Module capteur
Le module capteur est instancié trois fois par couloir de course ce qui donne un total de six instanciations.
Nous avons besoins du capteur de 60 pieds et de deux capteurs de fin de parcours pour enregistrer la
vitesse pour chaque couloir. Ce module ne fait qu’enregistrer le temps du chronomètre dans un registre
spécifique lorsque le capteur envoie un signal indiquant que le faisceau du capteur a été coupé par un
véhicule.
4.5.5 Module convertisseur BCD et module additionneur 3
Le module convertisseur BCD est instancié une fois. C’est un convertisseur qui transforme les nombres
binaires de 20 bits en 7 quartets limités de 0 à 9 qui représentent chacun un nombre décimal. Par
exemple, considérons le nombre 14 qui s’écrit en binaire 1110. En l’introduisant dans le convertisseur,
nous obtiendrons en sortie deux quartets: un quartet pour le chiffre 1 (0001) et un quartet pour le chiffre 4
(0100). La Figure 28 expose graphiquement comment fonctionne ce module. On retrouve sur la ligne
«Start» le nombre binaire 1110 correspondant à 14. On décale 3 fois les bits vers la gauche et ensuite on
ajoute 3 au nombre binaire décalé (module additionneur 3). On retrouve ainsi le nombre 14 codé sur les
deux quartets. (ligne «BCD» de la Figure 28).
Figure 28 - Fonctionnement du module convertisseur BCD
32
4.5.6 Module Horloge 2Khz
Le module d’horloge 2khz est instancié une fois et a comme rôle de générer un signal qui oscille à 2KHz.
Ce signal est distribué à plusieurs modules dans le FPGA qui s’en servent pour synchroniser les
opérations.
4.5.7 Module traitement des données
Le module traitement des données est instancié une fois et a le rôle principal dans la puce FPGA. Ses
tâches se résument en 3 points qui sont les suivants :
� Enregistrement des données dans la mémoire Ram.
� Envoi des données par le module UART.
� Gestion des modes de fonctionnement de l’autodrome pour la mise en forme des données vers les autres boîtiers électriques en utilisant le module UART.
4.5.8 Module de mémoire Ram
Le module Ram est instancié une fois et se trouve être une mémoire Ram de 216 kbits à deux ports. Cela
veut dire que l’on peut enregistrer simultanément des données dans deux mémoires différentes qui sont
instanciées dans le même module. Ces deux « block Ram » permettent d’enregistrer un ensemble de
paramètres de la course. Afin de comprendre l’architecture de la mémoire Ram, nous présentons deux
tableaux. Le Tableau 6 représente la légende des numéros placés dans la mémoire (Tableau 7). Ainsi,
dans la colonne «Identifiant» du Tableau 6 nous retrouvons la définition de chaque numéro présent dans
le Tableau 7.
Le Tableau 6 est organisé comme suit :
La colonne «Adresse» indique à quelles adresses de la mémoire sont écrites les informations. La colonne
«Identifiant» fait la correspondance entre les chiffres illustrés au Tableau 7. La colonne «Position (taille)»
indique la dimension en nombre de bits dans lesquelles sont enregistrées les informations. La colonne
«Commentaires» indique quel type d’information est enregistrée dans l’adresse correspondante.
Adresse Identifiant Position (taille) Commentaires
0x00 1 [7 : 0] Mémorise le mode dans lequel se trouve l’autodrome
0x00 X [31 :8] Non utilisé encore
(Id_voiture x5) - 4 2 [7 : 0] Nombre de course
(Id_voiture x5) - 4 3 [15 : 0] Nombre de faux départs
(Id_voiture x5) - 4 4 [23 : 16] Nombre de victoires
(Id_voiture x5) - 4 5 [31 : 24] Nombre de défaites
(Id_voiture x5) - 3 6 [31 : 0] Temps de réaction au feu vert
(Id_voiture x5) - 2 7 [31 : 0] Temps aux 60 pieds
Tableau 6 - Légende des informations de la block Ram port A
33
(Id_voiture x5) - 1 8 [31 :0] Temps de course
(Id_voiture x5) - 0 9 [31 :0] Vitesse de pointe
Comme expliqué précédemment, le Tableau 7 représente un des deux ports de la «block Ram», soit ici le
port A, image de la course du couloir gauche. Dans ce tableau, on remarque que l’adresse 0 du port A est
réservée pour les paramètres de l’autodrome. Par la suite, 5 adresses sont réservées pour chaque
numéro de véhicule.
PORT A
Couloir
Gauche
Adresse [7 :0] Bits[7 : 0] Bits[15 : 8] Bits[23 : 16] Bits[31 : 24]
0x00 1 x x x
(Id_voiture x5) – 4 2 3 4 5
(Id_voiture x5) - 3 6 6 6 6
(Id_voiture x5) - 2 7 7 7 7
(Id_voiture x5) - 1 8 8 8 8
(Id_voiture x5) - 0 9 9 9 9
… … … … …
L’adressage maximum pouvant être atteint avec un adressage de 8 bits est de 256.
La première adresse est réservée pour le mode de configuration dans lequel l’autodrome opère. Cela
porte à 255 les adresses restantes dans la Ram pour enregistrer les performances des véhicules.
Notons que l’adressage est fonction de l’identifiant de la voiture. On remarque tout de suite que pour un
véhicule, nous avons besoin de 5 adresses mémoires. Nous trouvons alors que le nombre maximum de
véhicules qui peuvent êtres enregistrés dans un port de la Ram est 51. Nous possédons un port pour
chaque couloir donc le nombre total de véhicule pouvant participer à l’événement est de 102. Selon le
promoteur, ce chiffre est suffisant pour l’Autodrome Saguenay.
Tableau 7 - Block Ram port A
34
4.5.9 Module UART
Le module UART est instancié une fois et a pour fonction de se charger d’encapsuler les données 32 bits
afin de les envoyer par paquet de 8 bits comme le désire le protocole série.
Le port série du FPGA sera connecté directement à un module radiofréquence Xbee afin de communiquer
par médium aérien les données aux autres modules. Pour ce faire, nous devons cadencer le module
UART à une fréquence compatible au module Xbee à une vitesse de 115,2kHz. Ce débit est largement
suffisant pour l’ensemble des informations que nous devons faire transiter. Afin que les modules
récepteurs récupèrent seulement l’information nécessaire à leur besoin, un protocole de communication a
été établi. Celui-ci peut être résumé par le Tableau 8 qui expose au travers d’un exemple, une série de
paquet de données envoyées au boîtier récepteur pour le logiciel.
Le récepteur du boîtier logiciel attend 6 paquets de données qui se retrouvent êtres les mêmes
informations que les données de la mémoire Ram sur fond gris dans le Tableau 7. Le bit le moins
significatif est envoyé en premier pour chaque paquet de 8 bits. Le récepteur vérifie premièrement l’entête.
Si celui-ci ne correspond pas au module, l’opération de réception est interrompue par le module. Dans le
cas contraire, chaque paquet est lu et enregistré en mémoire. À chaque réception d’un paquet, le
récepteur envoie un signal au boitier émetteur afin de lui indiquer que l’ensemble des données a bien été
reçue.
Exemple du Paquet 1 :
� Entête : Numéro du boîtier récepteur ici (1 pour l’exemple)
� Octet 1 : Nombre de courses
� Octet 2 : Nombre de faux départs
� Octet 3 : Nombre de victoires
� Octet 4 : Nombre de défaites
Entête [7 :0] Octet 1 [7 :0] Octet 2 [7 :0] Octet 3[7 :0] Octet 4 [7 :0]
Exemple du paquet 2 :
� Entête : Numéro du boîtier récepteur ici (1 pour l’exemple)
� Octet 1 : Temps moyen de réaction au feu vert
� Octet 2 : Temps moyen de réaction au feu vert
� Octet 3 : Temps moyen de réaction au feu vert
� Octet 4 : Temps moyen de réaction au feu vert
Il en va de même pour les 4 autres informations à transmettre.
L’entête a pour rôle d’identifier chacun des boîtiers et se trouve être un chiffre compris entre 0 et 4.
Chaque boîtier ayant son propre numéro.
Tableau 8 - Exemple de paquet
35
4.5.10 Module d’affichage
Ce module a pour but de contrôler un afficheur à sept segments. L’afficheur test utilisé est multiplexé, ce
qui permet de réduire le nombre de sorties. Il y a huit sorties, chacune correspondante à un des segments.
La sortie restante étant pour le point décimal. Il faut également une sortie pour chaque chiffre afin de
l’alimenter ou non. Pour avoir l’illusion d’un affichage continu, il faut afficher à tour de rôle chaque chiffre à
une cadence que l’œil humain n’est pas capable de percevoir. Si la fréquence n’est pas assez élevée, l’œil
humain percevra les oscillations. On s’est également dit qu’on pouvait procéder par bloc. Le promoteur
veut pouvoir afficher à la fin de chaque course le temps et la vitesse de pointe, soit deux données de cinq
chiffres à afficher à tour de rôle. Le temps d’affichage doit être de cinq à sept secondes pour chaque
donnée.
Choix du langage de programmation :
Pour contrôler le tout, on a utilisé un microcontrôleur soit le PIC18F4680. On a décidé de le programmer
en langage assembleur, au détriment du langage C, pour les raisons suivantes :
- On a appris à programmer les microcontrôleurs en langage assembleur. Les bases apprises en C
datent des premières sessions, alors que le langage assembleur fut appris plus récemment.
- Les exemples de codes dans les feuilles de spécifications du manufacturier sont en langage
assembleur ce qui est toujours utile pour « debugger » quand on rencontre un problème.
Philosophie de programmation :
Nous avons un microcontrôleur qui utilise une horloge interne à 32MHz. Un microcontrôleur fonctionne de
façon séquentielle. On veut un programme robuste et fonctionnel. On ne veut pas nécessairement
programmer de façon optimale (qui consiste à minimiser les lignes de codes).
Ainsi, le code fut écrit de la façon suivante :9
Nous avons trois choses à gérer : la réception, le traitement des données qui permet de faire le lien entre
la réception (codée sur un octet pour les transformer en BCD Binary Coded Decimal) et l’affichage. Il a
donc fallu utiliser les fonctions d’interruption à haut et bas niveau de priorité.
Comme la réception est asynchrone, elle peut survenir à tout moment. Afin de minimiser les interférences
entre ces 3 parties, pour éviter tout problème potentiel avec les interruptions qui font sortir
momentanément du programme pour y retourner une fois complétées, on a compartimenté notre
programme, en instaurant des conditions de passage, initialisées par programmation une fois l’étape finie.
9 Pour avoir le code complet et commenté, se référer à la section 7.3.9 Code assembleur.
36
Pour ce faire on a créé des registres de surveillance. L’interruption de réception était en priorité élevée. On
boucle donc dans la routine principale tant et aussi longtemps que le bit 7 du registre « réception_fini »
(que nous avons créé pour les besoin) n’est pas à « 1 ». Quand une interruption de haut niveau arrive, le
microcontrôleur se dirige à l’adresse correspondante. Une fois que les dix chiffres sont reçus, l’interruption
de réception est désactivée et le bit 7 du registre de surveillance est mis à « 1 ». Ceci est la condition pour
sortir de la boucle infinie et permet au programme de passer à la conversion binaire à BCD. Une fois que
cela est fait, le compteur est activé. Cela permet d’afficher les valeurs sur l’afficheur à sept segments de
façon adéquate, selon le temps voulu. Une fois que tout est terminé, l’interruption de réception est
réactivée. Un nouveau lors de données provenant d’une autre course peut être reçu, traité et affiché.
On peut procéder de cette manière puisque les données sont toujours envoyées à la fin d’une course. On
peut facilement prévoir plus de trente secondes entre la fin de deux courses consécutives. Le fait de
désactiver l’interruption pendant le temps d’affichage (une dizaine de secondes) ne fera donc perdre
aucunes données. L’organigramme présenté à la résume le fonctionnement du microcontrôleur
programmé.
Figure 29 - Organigramme résumant le fonctionnement du microcontrôleur dédié à l’affichage
37
5.0 Bilan des activités
5.1 Arrimage formation/pratique universitaire
Le projet présent cadre très bien dans l’esprit d’un projet de synthèse. Des notions provenant d’une
multitude de cours effectués durant le cheminement académique ont été utilisées :
Contrôle de systèmes mécaniques : -Choix des capteurs
Sciences graphiques : -Dessin de plans sur ordinateur
Systèmes à microprocesseurs : -Microcontrôleur pour gérer les modules périphériques
Système digitaux : -Puce à logique programmable (FPGA) pour le module central
Conception de systèmes digitaux : -Puce à logique programmable (FPGA) pour le module central
Interface et instrumentations : -Conception des différents circuits imprimés
-Permettre la séquence d’allumage à partir de la tension du secteur
-Permettre au module central de recevoir les bonne informations afin
d’en effectuer le traitement adéquat
Globalement, nous avons pu apprécier la richesse des informations données lors des cours académiques.
C’est à ce point que nous réalisons que les cours académique préparent l’étudiant à affronter toutes les
situations possibles. On arrive à comprendre que chaque cours est un condensé d’une matière
extrêmement riche et diversifiée et qu’il est donc impossible de tout traiter en profondeur. Ainsi les
professeurs et chargés de cours ont fait un travail exceptionnel pour introduire l’étudiant à ces disciplines
en mettant l’emphase sur :
• Les notions classiques et générales
• Le vocabulaire spécifique de la spécialité.
Armé de ces connaissances, lorsque l’on arrive face à un problème pratique, on est en mesure d’orienter
nos recherches, de se mettre des balises afin de ne pas trop se perdre et ainsi être plus efficace. Il est
toujours impressionnant et gratifiant pour un étudiant de faire face à un problème précis « classique » et
d’être capable de relier rapidement le cours théorique en cause.
Petit bémol qui est pourtant pratiquement impossible à palier, est le fait que le projet de synthèse s’est fait
aux mêmes semestres que les « cours de spécialisation ». Cela est dommage, car ce sont ces cours qui
sont les plus orientés sur les applications pratiques. Au cours du projet, nous avons eu besoin de certaines
notions avant que la matière précise soit traitée selon l’ordre du plan de cours. Les exemples les plus
flagrant sont reliés à la programmation du FPGA de façon plus poussée qui est abordée dans le
« Conception de système digitaux » qui se trouve être un cours se donnant au dernier semestre du cursus
d’un étudiant au cheminement régulier. Ainsi, l’interfaçage d’une mémoire RAM, la programmation d’un
38
convertisseur Binaire à BCD ainsi que la programmation d’un module UART ont été vues sur le tard au
cours du semestre. Beaucoup de temps a donc été perdu à ce niveau. Lorsque le professeur abordait la
matière il réglait instantanément le problème.
5.2 Travail d’équipe
Le travail d’équipe fut très formateur pour les membres de l’équipe. Tout au long du cursus universitaire,
on insiste sur le fait de montrer aux étudiants à bien vulgariser. On invoque l’argument que la majorité du
temps l’interlocuteur ne maîtrise pas le projet et les notions aux mêmes niveaux que ceux qui baignent
dedans. On demande aux étudiants d’agir en présumant que l’interlocuteur ou le lecteur ne connait rien de
ce que l’on fait afin d’être clair et bien compris tout en restant le plus concis possible. Cet état de fait fut
flagrant dans nos relations avec le promoteur où on pouvait sentir qu’on le perdait sur certains points
technique où de par la latitude qu’il nous laissait paraître.
On a parfois retrouvé le même clivage dans les relations étudiants/techniciens. Cela peut sembler plus
surprenant, car les deux parties ont chacun une base dans le domaine et pourtant cela a fait ressortir de
façon plus marqué l’importance d’une bonne communication. Pour la conception de la seule pièce
mécanique de notre projet on a fait appel à un machiniste. Plusieurs révisions de plan et d’itérations ont
été nécessaires afin d’en arriver à être sur la même longueur d’onde.
Cette section doit se terminer sur l’éloge d’une particularité que l’on trouve inestimable. On sait que
l’UQAC offre la possibilité à ses techniciens dédiés aux fins éducationnelles de suivre certains cours de la
formation académique de l’ingénieur. Ceci est un avantage considérable pour la qualité de l’éducation. Le
technicien connait ainsi le niveau d’enseignement et les méthodes de procéder. Il peut donc mieux
s’adapter à l’étudiant et l’aider à cheminer plus rapidement puisqu’il est en mesure de mieux définir les
capacités de l’étudiant futur ingénieur.
5.3 Respect de l’échéancier
L’échéancier global pour les parties importantes c’est-à-dire la conception, les preuves de concepts et la
validation du fonctionnement, a été respecté. Autrement dit, les tests faits ont démontrés que l’on était en
mesure de chronométrer de façon précise un objet effectuant un trajet rectiligne à travers un couloir de
capteurs placés à des points de mesures précis et que les différents modules développés étaient capables
d’interagir, entre autres grâce à la communication sans-fil. Le tout fut prouvé grâce à une simulation de
course. On affichait sur un afficheur à sept segments (contrôlé par un microcontrôleur), les paramètres
désirés grâce au traitement fait préalablement par la puce centrale constituée de la puce à logique
programmable (FPGA). Le tout était fait à distance grâce au module de communication sans-fil Xbee. Il
reste maintenant à superviser l’installation.
39
5.4 Analyse et discussion
Le bilan du projet se juge par le fonctionnement de l’installation. Le tout a été réalisé dans un des locaux
de laboratoires de l’université. Les capteurs ont été disposés de part et d’autre d’un couloir et une
simulation a été faite en les coupant à tour de rôle pour voir que l’on retirait bel et bien les informations. La
vidéo de la simulation fut présentée lors de la soutenance publique.
Réglons le cas des parties dont la validité de conception est prouvée par la réussite de la simulation. La
puce à logique programmable vient en tête de liste. Elle constitue la partie centrale du système. La
programmation qu’on a effectuée permet la gestion de la séquence d’allumage à partir des informations
provenant des capteurs qui indiquent quand les voitures sont prêtes à prendre le départ. Un module
chronomètre a également été programmé pour calculer de façon très exacte les temps de parcours. La
carte fille d’acquisition, a été conçue afin d’interfacer les capteurs pour être compatible avec le FPGA. Sur
cette carte on retrouvait également le module Xbee. Le fonctionnement de ces deux modules a été
éprouvé lors de la simulation. Cela vient confirmer que la conception fut faite de façon adéquate.
L’agencement des régulateurs, des transformateurs et des composantes électroniques permettent au final
d’alimenter les capteurs en 12V DC et d’avoir un signal de sortie de 3.3V pouvant être traité par la puce à
logique programmable. L’interfaçage pour le Xbee fut également bien conçu puisque la communication
sans-fil est fonctionnelle.
Pour ce qui est du module d’affichage, programmé à l’aide d’un microcontrôleur, il fut lié à la carte centrale
grâce à un module Xbee. La programmation fut validée par des essais avec un logiciel de communication
série (HyperTerminal). Les données affichées concordaient avec celles qui étaient envoyées.
Concernant la carte fille Opto-isolatrice, nous avons effectué une erreur de conception lors de la première
version. Les TRIACS ne dissipaient pas assez de chaleur pour supporter l’alimentation de deux lampes de
100 W en parallèle. Malgré ce souci, on a pu tester le fonctionnement de l’agencement Opto-
isolateur/TRIACS pour une lampe et le tout fonctionnait. Cependant, il a été impossible de faire la
simulation avec cette carte, car trop de composantes étaient défectueuses. Ainsi, la simulation fut faite
avec une séquence d’allumage avec des LEDs. Cela vient démontrer, encore une fois, l’efficacité de la
programmation effectuée. Pour l’étage d’isolation (agencement optocoupleurs/TRIACS) les plans ont été
refaits afin de produire la carte Opto-isolatrice corrigée qui ne devrait pas causer de problème cette fois-ci,
puisque le problème était bien cerné.
L’ensemble du projet était costaud de part l’architecture diffusante du système. Le tout est centré autour de
la carte mère et gère les informations et les modules périphériques. Cette multiplicité a fait en sorte que le
projet a fait appel à des connaissances extrêmement variées et que l’on devait constamment se plonger
dans le vif du sujet pour en ressortir et tomber dans une partie de matière complètement différentes, alors
40
que les projets de fin d’études plus « standards » s’enfoncent plus dans un créneau particulier. Ces
derniers étant plus restreints en termes de champs technique, cela permet à l’étudiant de pousser
beaucoup plus loin le raisonnement et l’avancement, ce qui est avantageux lorsque vient le temps d’épater
la galerie et d’étaler ses accomplissements comparativement à un projet plus large dont le but est de
développer et associer plusieurs « petites » parties « plus simples ».
Pour continuer dans la même veine des projets « moins large » avec possibilité de pousser plus loin
comparativement aux projets « plus larges » et plus simples, il faudrait mentionner la contrainte de gestion
du temps. Quand on a plusieurs petits objectifs, il faut être en mesure de répartir efficacement son temps.
Il faut donc être capable d’établir une bonne liste de priorités et de s’y fier. Dans un projet « plus
circonscrit », cette contrainte reste importante mais moins « déterminante ».
41
6.0 Conclusion
En regard des objectifs énoncés en début de projet, on peut être satisfait des accomplissements. Le
modèle proposé est fonctionnel et des courses d’accélération pourront avoir lieu sur le site de l’Autodrome
Saguenay.
Mentionnons une particularité du projet qui a créé un blocage jusqu’à un certain niveau. Comme on ne
voulait pas décevoir le promoteur, et que le mandat consistait à livrer un produit fini, on a voulu recréer ce
qui se faisait sur le marché. C’était en effet le but au point de vue technique, mais pas au niveau de
l’enveloppe (du moins c’était secondaire, il fallait avant tout valider la partie technique). Cela a fait en sorte
que par moment on n’a pas nécessairement mis les priorités nécessairement à la bonne place. À titre
d’exemple, le promoteur faisait valoir que l’arbre de Noël était la pièce la plus importante que c’était la
première chose que les spectateurs remarqueraient. Ainsi, on a mis beaucoup plus de temps qu’il aurait
fallu en mettre sur cette partie. Elle ne correspondait pas nécessairement aux champs d’expertise pour
lesquels on avait été demandé. Il aurait fallu insister davantage sur le fait de livrer les composantes
électroniques fonctionnelles puisque personne d’autre que nous dans l’équipe de travail n’aurait été en
mesure de les faire.
Si on avait été capable de passer par-dessus cette « fixation », on aurait certes eu une meilleure
répartition du travail et les sous-parties des échéanciers auraient été mieux respectées, même si au bout
du compte tout fut fini dans les temps. Il faut quand même réaliser qu’une partie du temps a mal été utilisé
et distribué à travers les différentes tâches.
Pour finir, en tant qu’étudiants et futurs ingénieurs nous seront ravi d’assister et de participer à l’installation
du système de mesures de l’Autodrome Saguenay. Ceci constitue en fait un mini-chantier, puisque pour
l’instant tout est à refaire sur le terrain. On pourra également apprécier le travail de divers corps de métier
avec lesquels on aura à cohabiter en tant qu’ingénieur, par exemple, l’électricien qui raccordera le nouvel
autodrome au réseau d’électricité. On pourra alors voir sa manière de procéder et gagner une certaine
expérience de chantier simplement en étant observateur.
42
7.0 Annexes
7.1 Documentation
7.1.1 Caractéristiques critiques ayant menée au choix du capteur de la série S30 DC10
10 Pour la fiche technique complète, se référer à la section 2.1 Recherche bibliographique
43
7.1.2 Caractéristiques critiques ayant menée au choix du capteur QS30LLP11
11 Pour la fiche technique complète, se référer à la section 2.1 Recherche bibliographique
44
7.2 Schéma électriques
7.2.1 Carte optocoupleurs et alimentations
45
7.2.2 Carte d’acquisition des capteurs
46
7.2.3 Carte FPGA
47
7.2.4 Carte Télécommande
48
7.3 Programmation
7.3.1 Code Verilog - Module principal
module Projet( // Sortie vers arbre de Gauche oSTAGE_G, oPRESTAGE_G, oORANGE1_G, oORANGE2_G, oORANGE3_G, oVERT_G, oROUGE_G, // Sortie vers arbre de Droite oSTAGE_D, oPRESTAGE_D, oORANGE1_D, oORANGE2_D, oORANGE3_D, oVERT_D, oROUGE_D, //Entrée Sortie vers télécommande oLED_TELECOMMANDE, iRESET, //Entrée des capteurs de la piste de Gauche iCAPTEUR_STAGE_G, iCAPTEUR_PRESTAGE_G, iCAPTEUR_60_G, iCAPTEUR_FIN1_G, iCAPTEUR_FIN2_G, //Entrée des capteurs de la piste de Droite iCAPTEUR_STAGE_D, iCAPTEUR_PRESTAGE_D, iCAPTEUR_60_D, iCAPTEUR_FIN1_D, iCAPTEUR_FIN2_D, // Horloge du système iCLK_25Mhz, iSTART, // Uart oTx, //iRx ); // Entrée sortie du module output oSTAGE_G; output oPRESTAGE_G; output oORANGE1_G; output oORANGE2_G; output oORANGE3_G; output oVERT_G; output oROUGE_G; output oSTAGE_D; output oPRESTAGE_D; output oORANGE1_D; output oORANGE2_D; output oORANGE3_D;
49
output oVERT_D; output oROUGE_D; output oLED_TELECOMMANDE; output oTx; input iCAPTEUR_STAGE_G; input iCAPTEUR_PRESTAGE_G; input iCAPTEUR_60_G; input iCAPTEUR_FIN1_G; input iCAPTEUR_FIN2_G; input iCAPTEUR_STAGE_D; input iCAPTEUR_PRESTAGE_D; input iCAPTEUR_60_D; input iCAPTEUR_FIN1_D; input iCAPTEUR_FIN2_D; input iRESET; input iCLK_25Mhz; input iSTART; //input [7:0] iRx; wire STAGE_G; wire PRESTAGE_G; wire ORANGE1_G; wire ORANGE2_G; wire ORANGE3_G; wire VERT_G; wire ROUGE_G; wire LED_TELECOMMANDE; wire OK_COULOIR_G; wire OK_FIN_G; wire STAGE_D; wire PRESTAGE_D; wire ORANGE1_D; wire ORANGE2_D; wire ORANGE3_D; wire VERT_D; wire ROUGE_D; wire OK_COULOIR_D; wire OK_FIN_D; wire GO_DEPART_G; wire GO_DEPART_D; wire CLK_2Hz; wire [31:0] Temps_Reaction_Binaire_G; wire [31:0] Temps_60Pieds_Binaire_G; wire [31:0] Temps_Fin2_Binaire_G; wire [31:0] Vitesse_Fin_Binaire_G; wire [4:0] Tempo_Allum_Lumiere_G; wire [31:0] Temps_Reaction_Binaire_D; wire [31:0] Temps_60Pieds_Binaire_D; wire [31:0] Temps_Fin2_Binaire_D; wire [31:0] Vitesse_Fin_Binaire_D;
50
wire [4:0] Tempo_Allum_Lumiere_D; wire [27:0] Vitesse_Fin_BCD_G; wire oLed_Ok_Depart; wire [2:0] CST_TEMPO_ALEATOIRE_D; wire [2:0] CST_TEMPO_ALEATOIRE_G; wire [7:0] Tx; // modes de fonctionnement de l'arbre de noel // mode 1 - Essai seul à gauche // mode 2 - Essai seul à droite // mode 3 - Duel sans Dial in // mode 4 - Duel avec Dial in parameter [2:0] mode_depart = 1; // Informations venant de la télécommande // Numéro de la voiture du couloir de gauche parameter [7:0] Voiture_ID_G = 2; // Numéro de la voiture du couloir de droite parameter [7:0] Voiture_ID_D = 1; // Offset pour le Mode 4 parameter [15:0] offset_depart_G = 500; parameter [15:0] offset_depart_D = 0; assign oLED_TELECOMMANDE = oLed_Ok_Depart; assign oSTAGE_G = STAGE_G; assign oPRESTAGE_G = PRESTAGE_G; assign oORANGE1_G = ORANGE1_G; assign oORANGE2_G = ORANGE2_G; assign oORANGE3_G = ORANGE3_G; assign oVERT_G = VERT_G; assign oROUGE_G = ROUGE_G; assign oSTAGE_D = STAGE_D; assign oPRESTAGE_D = PRESTAGE_D; assign oORANGE1_D = ORANGE1_D; assign oORANGE2_D = ORANGE2_D; assign oORANGE3_D = ORANGE3_D; assign oVERT_D = VERT_D; assign oROUGE_D = ROUGE_D; assign oTx = Tx; // Couloir de gauche de la piste de DRAG Piste u1 ( .oSTAGE(STAGE_G), .oPRESTAGE(PRESTAGE_G), .oORANGE1(ORANGE1_G), .oORANGE2(ORANGE2_G), .oORANGE3(ORANGE3_G), .oVERT(VERT_G), .oROUGE(ROUGE_G), .oOK_COULOIR(OK_COULOIR_G), .oOK_FIN(OK_FIN_G),
51
.oTemps_Reaction_Binaire(Temps_Reaction_Binaire_G), .oTemps_60Pieds_Binaire(Temps_60Pieds_Binaire_G),
.oTemps_Fin2_Binaire(Temps_Fin2_Binaire_G), .oVitesse_Fin_Binaire(Vitesse_Fin_Binaire_G), .iGO_DEPART(GO_DEPART_G), .iCAPTEUR_STAGE(~iCAPTEUR_STAGE_G), .iCAPTEUR_PRESTAGE(~iCAPTEUR_PRESTAGE_G), .iCAPTEUR_60(~iCAPTEUR_60_G), .iCAPTEUR_FIN1(~iCAPTEUR_FIN1_G), .iCAPTEUR_FIN2(~iCAPTEUR_FIN2_G), .iRESET(iRESET), .iCLK_25Mhz(iCLK_25Mhz), .iCLK_2Hz(CLK_2Hz), .ioffset_depart(offset_depart_G), .iCST_TEMPO_ALEATOIRE(CST_TEMPO_ALEATOIRE_G) ); // Couloir de droite de la piste de DRAG Piste u2 ( .oSTAGE(STAGE_D), .oPRESTAGE(PRESTAGE_D), .oORANGE1(ORANGE1_D), .oORANGE2(ORANGE2_D), .oORANGE3(ORANGE3_D), .oVERT(VERT_D), .oROUGE(ROUGE_D), .oOK_COULOIR(OK_COULOIR_D), .oOK_FIN(OK_FIN_D), .oTemps_Reaction_Binaire(Temps_Reaction_Binaire_D), .oTemps_60Pieds_Binaire(Temps_60Pieds_Binaire_D), .oTemps_Fin2_Binaire(Temps_Fin2_Binaire_D), .oVitesse_Fin_Binaire(Vitesse_Fin_Binaire_D), .iGO_DEPART(GO_DEPART_D), .iCAPTEUR_STAGE(iCAPTEUR_STAGE_D), .iCAPTEUR_PRESTAGE(iCAPTEUR_PRESTAGE_D), .iCAPTEUR_60(iCAPTEUR_60_D), .iCAPTEUR_FIN1(iCAPTEUR_FIN1_D), .iCAPTEUR_FIN2(iCAPTEUR_FIN2_D), .iRESET(iRESET), .iCLK_25Mhz(iCLK_25Mhz), .iCLK_2Hz(CLK_2Hz), .ioffset_depart(offset_depart_D), .iCST_TEMPO_ALEATOIRE(CST_TEMPO_ALEATOIRE_D) );
52
c
// Gestion des informations provenant de la télécommande telecommande u3 ( .iCLK_25Mhz(iCLK_25Mhz),
.iCLK_2Hz(CLK_2Hz), .iRESET(iRESET), .iSTART_COURSE(iSTART), .iREADY_COULOIR_G(OK_COULOIR_G), .iREADY_COULOIR_D(OK_COULOIR_D), .iFINISH_COULOIR_G(OK_FIN_G), .iFINISH_COULOIR_D(OK_FIN_D), .iMODE_DEPART(mode_depart[2:0]), .oLed_Ok_Depart(oLed_Ok_Depart), .oGO_DEPART_G(GO_DEPART_G), .oGO_DEPART_D(GO_DEPART_D), .ioffset_depart_G(offset_depart_G), .ioffset_depart_D(offset_depart_D), .oCST_TEMPO_ALEATOIRE_D(CST_TEMPO_ALEATOIRE_D), .oCST_TEMPO_ALEATOIRE_G(CST_TEMPO_ALEATOIRE_G) ); // Horloge 2 kHz clk2Hz u4 ( .iCLK_25Mhz(iCLK_25Mhz), .iRESET(iRESET), .oCLK_2Hz(CLK_2Hz) ); // Traitement des données après arrivées des véhicules // à la ligne de départ traitementDonnees u5 ( .iCLK_25Mhz(iCLK_25Mhz), .iRESET(iRESET), .iMODE_DEPART(mode_depart[2:0]), .iVOITURE_ID_G(Voiture_ID_G), .iSTART_TRAITEMENT_G(OK_FIN_G), .iTemps_Reaction_Binaire_G(Temps_Reaction_Binaire_G), .iTemps_60Pieds_Binaire_G(Temps_60Pieds_Binaire_G), .iTemps_Fin2_Binaire_G(Temps_Fin2_Binaire_G), .iVitesse_Fin_Binaire_G(Vitesse_Fin_Binaire_G), .iFAUX_DEPART_G(ROUGE_G), .iVOITURE_ID_D(Voiture_ID_D), .iSTART_TRAITEMENT_D(OK_FIN_D), .iTemps_Reaction_Binaire_D(Temps_Reaction_Binaire_D), .iTemps_60Pieds_Binaire_D(Temps_60Pieds_Binaire_D), .iTemps_Fin2_Binaire_D(Temps_Fin2_Binaire_D), .iVitesse_Fin_Binaire_D(Vitesse_Fin_Binaire_D), .iFAUX_DEPART_D(ROUGE_D), .oTx(Tx) ); Endmodule
53
7.3.2 Code Verilog - Module Piste
module Piste( oSTAGE, oPRESTAGE, oORANGE1, oORANGE2, oORANGE3, oVERT, oROUGE, oOK_COULOIR, oOK_FIN, oTemps_Reaction_Binaire, oTemps_60Pieds_Binaire, oTemps_Fin2_Binaire, oVitesse_Fin_Binaire, iGO_DEPART, iCAPTEUR_STAGE, iCAPTEUR_PRESTAGE, iCAPTEUR_60, iCAPTEUR_FIN1, iCAPTEUR_FIN2, iRESET, iCLK_25Mhz, iCLK_2Hz, ioffset_depart, iCST_TEMPO_ALEATOIRE ); // Entrée sortie du module output oSTAGE; output oPRESTAGE; output oORANGE1; output oORANGE2; output oORANGE3; output oVERT; output oROUGE; output oOK_COULOIR; output oOK_FIN; output [31:0] oTemps_Reaction_Binaire; output [31:0] oTemps_60Pieds_Binaire; output [31:0] oTemps_Fin2_Binaire; output [19:0] oVitesse_Fin_Binaire; input iCAPTEUR_STAGE; input iCAPTEUR_PRESTAGE; input iCAPTEUR_60; input iCAPTEUR_FIN1; input iCAPTEUR_FIN2; input iRESET; input iCLK_25Mhz; input iCLK_2Hz; input iGO_DEPART; input [15:0] ioffset_depart; input [2:0] iCST_TEMPO_ALEATOIRE;
54
// Lien du module avec d'autres modules wire oSTAGE; wire oPRESTAGE; wire oORANGE1; wire oORANGE2; wire oORANGE3; // Variables interne au module reg Led_Ok_Depart; reg Ok_Stage; reg Ok_PreStage; reg Ok_Placement; reg Ok_Couloir; reg Run_Chronos; // 4bits poids faible = millisec -> 4bits poids fort = minute reg [23:0] Chronos; reg [31:0] Compteur_Delais250ms; reg clk_500ms; reg [4:0] tempoAllumLumiere; reg [2:0] Scan_tempo_aleatoire; reg [3:0] Chiffre_Aleatoire; reg On_Orange1; reg On_Orange2; reg On_Orange3; reg On_Vert; reg On_Rouge; reg Fin_Course; reg Ok_Calcul_Vitesse; reg [1:0] DetectFront_4Hz; reg Front_iCAPTEUR_STAGE; reg Front_4Hz; reg gardien_Rouge; //Registres du calcul de vitesse reg [19:0] Vitesse_Fin_Binaire; reg [31:0] Quotient; reg [31:0] Reste; reg [31:0] Numerateur; reg CalculVitesse; reg [31:0] CompteurVitesse; wire [31:0] Temps_Reaction_Binaire; wire [31:0] Temps_60Pieds_Binaire; wire [31:0] Temps_Fin1_Binaire; wire [31:0] Temps_Fin2_Binaire; wire [31:0] Temps_Binaire;
55
// Processus implicites du module assign oSTAGE = ~iCAPTEUR_STAGE; assign oPRESTAGE = ~iCAPTEUR_PRESTAGE; assign oORANGE1 = On_Orange1; assign oORANGE2 = On_Orange2; assign oORANGE3 = On_Orange3; assign oVERT = On_Vert; assign oROUGE = On_Rouge; assign oOK_COULOIR = Ok_Couloir; assign oOK_FIN = Fin_Course; assign
oTemps_Reaction_Binaire[31:0] = Temps_Reaction_Binaire[31:0]; assign
oTemps_60Pieds_Binaire[31:0] = Temps_60Pieds_Binaire[31:0]; assign oTemps_Fin2_Binaire[31:0] = Temps_Fin2_Binaire[31:0]; assign oVitesse_Fin_Binaire[19:0] = Vitesse_Fin_Binaire[19:0]; // Instanciation du chronomètre chromometre u1 ( .oTemps_Binaire(Temps_Binaire[31:0]), .iCLK_25Mhz(iCLK_25Mhz), .iRESET(iRESET), .iStart_Chronos(Run_Chronos) ); // Mesure de temps - Capteur Réaction Time capteursPiste u2 ( .iCAPTEUR(iCAPTEUR_STAGE), .iActivation(Run_Chronos), .iCLK_25Mhz(iCLK_25Mhz), .iRESET(iRESET), .iTemps_Binaire(Temps_Binaire[31:0]), .oTemps_Binaire(Temps_Reaction_Binaire[31:0]) ); // Mesure de temps - Capteur 60 pieds capteursPiste u3 ( .iCAPTEUR(!iCAPTEUR_60), .iActivation(Run_Chronos), .iCLK_25Mhz(iCLK_25Mhz), .iRESET(iRESET), .iTemps_Binaire(Temps_Binaire[31:0]), .oTemps_Binaire(Temps_60Pieds_Binaire[31:0]) ); // Mesure de temps - Capteur Fin 1 capteursPiste u4 ( .iCAPTEUR(!iCAPTEUR_FIN1), .iActivation(Run_Chronos), .iCLK_25Mhz(iCLK_25Mhz), .iRESET(iRESET), .iTemps_Binaire(Temps_Binaire[31:0]), .oTemps_Binaire(Temps_Fin1_Binaire[31:0]) );
56
// Mesure de temps - Capteur Fin 2 capteursPiste u5 ( .iCAPTEUR(!iCAPTEUR_FIN2), .iActivation(Run_Chronos), .iCLK_25Mhz(iCLK_25Mhz), .iRESET(iRESET), .iTemps_Binaire(Temps_Binaire[31:0]), .oTemps_Binaire(Temps_Fin2_Binaire[31:0]) ); // Processus explicites du module //#################################################################### //Activation du compteur pour calcul de la vitesse -Premier capteur de //fin always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) CalculVitesse<=0; else begin if(!iCAPTEUR_FIN1) CalculVitesse<=1; if(!iCAPTEUR_FIN2) begin CalculVitesse<=0; end end end //Compteur pour calcul de la vitesse always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) CompteurVitesse<=0; else begin if(CalculVitesse ==1) CompteurVitesse <= CompteurVitesse +1; end end //Calcul de la vitesse par division always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin Numerateur <= 32'hFFFFFFFF; Reste <= 32'hFFFFFFFF; Quotient <= 32'h00000000; Vitesse_Fin_Binaire <= 0; Ok_Calcul_Vitesse <= 0; end
57
else begin if((Fin_Course == 1) && (On_Rouge == 0)) begin if( Reste > 4500000) begin // En fin d'opération le numérateur contient le reste Numerateur <= Numerateur - 4500000; Reste <= Numerateur; // le résultat de la division est enregistré dans quotient Quotient <= Quotient + 1; End // Vitesse visible sur les 3 bits de poids fort Vitesse_Fin_Binaire <= Quotient*210; Ok_Calcul_Vitesse<=1; end if((Fin_Course == 1) && (On_Rouge == 1)) begin Vitesse_Fin_Binaire <= 0; Ok_Calcul_Vitesse<=1; end end end //#################################################################### // Gestion du placement de la voiture du couloir always@(iCAPTEUR_STAGE,iCAPTEUR_PRESTAGE) begin if((!iCAPTEUR_PRESTAGE & !iCAPTEUR_STAGE ) == 1 ) Ok_Placement <= 1; else Ok_Placement <= 0; End //################################################################### // Vérifie si le départ est possible dans le couloir always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin Ok_Couloir <= 0; end else begin if(Ok_Placement & !Run_Chronos) // Départ ok si voiture bien placée et fin du run des voitures précedentes Ok_Couloir <= 1; else Ok_Couloir <= 0; end end //####################################################################
58
// Décompte de l'arbre si départ donné par l'opérateur always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin On_Orange1 <= 0; On_Orange2 <= 0; On_Orange3 <= 0; On_Vert <= 0; Run_Chronos <= 0; Fin_Course <= 0; end else begin if(iGO_DEPART) begin // Séquence d'allumage de l'arbre if((On_Rouge == 0) && (Run_Chronos == 0)) begin if(tempoAllumLumiere == 1) On_Orange1 <= 1; if(tempoAllumLumiere == 2) begin On_Orange1 <= 0; On_Orange2 <= 1; end if(tempoAllumLumiere == 3) begin On_Orange2 <= 0; On_Orange3 <= 1; end if(tempoAllumLumiere == 4) begin On_Orange3 <= 0; On_Vert <= 1; // Démarrer le chronomètre Run_Chronos <= 1; end End // Éteindre les lumieres si faux départ if((On_Rouge == 1) && (Run_Chronos == 0)) begin On_Orange1 <= 0; On_Orange2 <= 0; On_Orange3 <= 0; On_Vert <= 0; Fin_Course <= 1; end end
59
// Gestion des événements lorsque le capteur de fin de course est coupé
if(Run_Chronos == 1) begin if(!iCAPTEUR_FIN2) begin // Fin de la course Fin_Course <= 1;
// Re initialisation de l'arbre de noël On_Orange1 <= 0; On_Orange2 <= 0; On_Orange3 <= 0; On_Vert <= 0; end if(Temps_Fin2_Binaire[31:0]>0) Run_Chronos <= 0; // Fin du chronomètre end end end //####################################################################//Gestion du faux départ always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin On_Rouge <= 0; gardien_Rouge<=0; end else begin if(gardien_Rouge < 1) begin if(iGO_DEPART & iCAPTEUR_STAGE & !Run_Chronos) begin On_Rouge <= 1; gardien_Rouge <=1; end if(Fin_Course) begin gardien_Rouge <=0; On_Rouge <= 0; end end end end //####################################################################
60
// Détection de front de l'horloge 4Hz always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) DetectFront_4Hz <= 0; else begin DetectFront_4Hz[0] <= iCLK_2Hz; DetectFront_4Hz[1] <= DetectFront_4Hz[0]; end end always@(DetectFront_4Hz) begin Front_4Hz <= !DetectFront_4Hz[1] & DetectFront_4Hz[0]; End //################################################################# //Temposrisateur 500 ms entre allumage des lumieres always @(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin tempoAllumLumiere <= 0; Scan_tempo_aleatoire <= 0; end else begin if(iGO_DEPART & !Run_Chronos) // si un départ est lancé begin if(Front_4Hz) begin if(Scan_tempo_aleatoire < iCST_TEMPO_ALEATOIRE) begin Scan_tempo_aleatoire<=Scan_tempo_aleatoire+1; tempoAllumLumiere <= 0; end if(Scan_tempo_aleatoire == iCST_TEMPO_ALEATOIRE) begin tempoAllumLumiere <= tempoAllumLumiere + 1; // début du cycle d'allumage des lumiere Scan_tempo_aleatoire <= iCST_TEMPO_ALEATOIRE; end end end end end endmodule
61
62
7.3.3 Code Verilog - Module Télécommande
module telecommande( iCLK_25Mhz, iCLK_2Hz, iRESET, iSTART_COURSE, iREADY_COULOIR_G, iREADY_COULOIR_D, iFINISH_COULOIR_G, iFINISH_COULOIR_D, iMODE_DEPART, oLed_Ok_Depart, oGO_DEPART_G, oGO_DEPART_D, ioffset_depart_G, ioffset_depart_D, oCST_TEMPO_ALEATOIRE_D, oCST_TEMPO_ALEATOIRE_G ); input iCLK_25Mhz; input iCLK_2Hz; input iRESET; input iSTART_COURSE; input iREADY_COULOIR_G; input iREADY_COULOIR_D; input iFINISH_COULOIR_G; input iFINISH_COULOIR_D; input [2:0] iMODE_DEPART; input [15:0] ioffset_depart_G; input [15:0] ioffset_depart_D; output oLed_Ok_Depart; output oGO_DEPART_G; output oGO_DEPART_D; output [2:0] oCST_TEMPO_ALEATOIRE_D; output [2:0] oCST_TEMPO_ALEATOIRE_G; reg Ok_Start_G; reg Ok_Start_D; reg Led_Ok_Depart; reg [15:0] offset_depart_G; reg [15:0] offset_depart_D; reg [15:0] Compteur_offset_G; reg [15:0] Compteur_offset_D; reg [15:0] Compteur_Delais500us; reg delais_1ms; reg Start_offset; reg Start_offset_G; reg Start_offset_D; reg Offset_G_OK; reg Offset_D_OK; reg [3:0] etat; reg [2:0] CST_TEMPO_ALEATOIRE_D; reg [2:0] CST_TEMPO_ALEATOIRE_G; reg [2:0] tempoAleatoire;
63
reg [1:0] DetectFront_GO_DEPART_G; reg Front_GO_DEPART_G; reg [1:0] DetectFront_GO_DEPART_D; reg Front_GO_DEPART_D; reg [1:0] DetectFront_1ms; reg Front_1ms; reg Mode4; reg Go_G; reg Go_D; assign oGO_DEPART_G = Mode4 ? Offset_G_OK:Ok_Start_G; assign oGO_DEPART_D = Mode4 ? Offset_D_OK:Ok_Start_D; assign oLed_Ok_Depart = Led_Ok_Depart; assign oCST_TEMPO_ALEATOIRE_D[2:0] = CST_TEMPO_ALEATOIRE_D[2:0]; assign oCST_TEMPO_ALEATOIRE_G[2:0] = CST_TEMPO_ALEATOIRE_G[2:0]; parameter [13:0] delais500us = 12500; //####################################################################### //Horloge 2kHz (500us) always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin Compteur_Delais500us <= 15'b0; delais_1ms <= 0; end else begin Compteur_Delais500us <= Compteur_Delais500us + 1; if(Compteur_Delais500us == delais500us) begin delais_1ms <= ~delais_1ms; Compteur_Delais500us <= 0; end end end // Détection de font montant sur le bit de depart de course always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) DetectFront_1ms <= 0; else begin DetectFront_1ms[0] <= Ok_Start_G; DetectFront_1ms[1] <= DetectFront_1ms[0]; end end always@(DetectFront_1ms) begin Front_1ms <= !DetectFront_1ms[1] & DetectFront_1ms[0]; end
64
//####################################################################### // Compteur miliseconde pour offset du couloir de gauche always@(posedge delais_1ms or negedge iRESET) begin if(!iRESET) begin Compteur_offset_G <= 16'b0; Compteur_offset_D <= 16'b0; offset_depart_G <=0; Offset_G_OK <= 0; Offset_D_OK <= 0; end else begin if(Start_offset) begin if(Start_offset_G) begin Compteur_offset_G <= Compteur_offset_G + 1; if(Compteur_offset_G >= ioffset_depart_G) Offset_G_OK <= 1; else Offset_G_OK <= 0; end else Offset_G_OK <= 1; if(Start_offset_D) begin Compteur_offset_D <= Compteur_offset_D + 1; if(Compteur_offset_D == ioffset_depart_D) Offset_D_OK <= 1; else Offset_D_OK <= 0; end else Offset_D_OK <= 1; end end end //####################################################################### //chiffre aléatoire sur 3 bits, chiffres de (0 à 7) always @(posedge iCLK_25Mhz) begin tempoAleatoire <= tempoAleatoire + 1; end
65
//###################################################################### // Détection de front pour le départ gauche always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) DetectFront_GO_DEPART_G <= 0; else begin DetectFront_GO_DEPART_G[0] <= Go_G; DetectFront_GO_DEPART_G[1] <= DetectFront_GO_DEPART_G[0]; end end always@(DetectFront_GO_DEPART_G) begin Front_GO_DEPART_G <= !DetectFront_GO_DEPART_G[1] & DetectFront_GO_DEPART_G[0]; end //####################################################################### // Détection de front pour le départ droit always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) DetectFront_GO_DEPART_D <= 0; else begin DetectFront_GO_DEPART_D[0] <= Go_D; DetectFront_GO_DEPART_D[1] <= DetectFront_GO_DEPART_D[0]; end end always@(DetectFront_GO_DEPART_D) begin Front_GO_DEPART_D <= !DetectFront_GO_DEPART_D[1] & DetectFront_GO_DEPART_D[0]; End //####################################################################### // Control si l'opérateur lance le départ always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin Ok_Start_G <= 0; Ok_Start_D <= 0; Led_Ok_Depart <=0; CST_TEMPO_ALEATOIRE_G <= 0; CST_TEMPO_ALEATOIRE_G <= 0;
66
Start_offset <= 0; Start_offset_G <= 0; Start_offset_D <= 0; etat <= 1; Mode4 <= 0; Go_G <= 0; Go_D <= 0; end else begin //####################################################################### // MODE 1 - Départ seul à gauche if(iMODE_DEPART == 1) begin Mode4 <=0; // Si la voiture n'est pas bien placée if(!iREADY_COULOIR_G & !Ok_Start_G) Led_Ok_Depart <= 0; // Si la voiture est bien placée et que l'opérateur n'a pas lancé le départ if(iREADY_COULOIR_G & !Ok_Start_G) Led_Ok_Depart <= 1; // Si la voiture est placée et que l'opérateur lance le départ if(!iSTART_COURSE & iREADY_COULOIR_G & !Ok_Start_G) // Si l'opérateur appuis sur le bouton de départ begin Go_G <=1; if(Front_GO_DEPART_G) begin CST_TEMPO_ALEATOIRE_G <= tempoAleatoire; Ok_Start_G <= 1; end end // Si la voiture fini la course if(iFINISH_COULOIR_G) begin Ok_Start_G <= 0; Led_Ok_Depart <= 0; end if(Ok_Start_G) Led_Ok_Depart <= iCLK_2Hz; end
67
//####################################################################### // Mode 2 - Départ seul à Droite if(iMODE_DEPART == 2) begin Mode4 <=0; // Si la voiture n'est pas bien placée if(!iREADY_COULOIR_D & !Ok_Start_D) Led_Ok_Depart <= 0; // Si la voiture est bien placée et que l'opérateur n'a pas lancé le départ if(iREADY_COULOIR_D & !Ok_Start_D) Led_Ok_Depart <= 1; // Si la voiture est placée et que l'opérateur lance le départ if(!iSTART_COURSE & iREADY_COULOIR_D & !Ok_Start_D) // Si l'opérateur appuis sur le bouton de départ begin Go_D <=1; if(Front_GO_DEPART_D) begin CST_TEMPO_ALEATOIRE_D <= tempoAleatoire; Ok_Start_D <= 1; end end // Si la voiture fini la course if(iFINISH_COULOIR_D) begin Ok_Start_D <= 0; Led_Ok_Depart <= 0; end if(Ok_Start_D) Led_Ok_Depart <= iCLK_2Hz; end //################################################################ // Mode 3 - Duel sans dial in / Mode 4 - Duel avec dial in if(iMODE_DEPART > 2) begin // Si les voitures ne sont pas bien placées if(!iREADY_COULOIR_D & !Ok_Start_D & !iREADY_COULOIR_G & !Ok_Start_G ) Led_Ok_Depart <= 0; // Si les voitures sont bien placées et que l'opérateur n'a pas lancé le départ
68
if(iREADY_COULOIR_D & iREADY_COULOIR_G & !Ok_Start_D & !Ok_Start_G) Led_Ok_Depart <= 1; if(iREADY_COULOIR_D & !iREADY_COULOIR_G & !Ok_Start_D & !Ok_Start_G) Led_Ok_Depart <= 0; if(!iREADY_COULOIR_D & iREADY_COULOIR_G & !Ok_Start_D & !Ok_Start_G) Led_Ok_Depart <= 0; // Si les voitures sont placées et que l'opérateur lance le départ if(!iSTART_COURSE & iREADY_COULOIR_D & iREADY_COULOIR_G & !Ok_Start_D & !Ok_Start_G) begin if(iMODE_DEPART == 3) begin Mode4 <=0; Go_G <=1; if(Front_GO_DEPART_G) begin CST_TEMPO_ALEATOIRE_D <= tempoAleatoire; CST_TEMPO_ALEATOIRE_G <= tempoAleatoire; Ok_Start_D <= 1; Ok_Start_G <= 1; end end if(iMODE_DEPART == 4) begin Mode4 <=1; if(etat == 1) begin // Si pas de valeur d'offset entrée ignorer l'offset if(ioffset_depart_G == 0) Start_offset_G <= 0; else // Sinon décompter l'offset Start_offset_G <= 1; if(ioffset_depart_D == 0) Start_offset_D <= 0; else Start_offset_D <= 1; etat <= 2; end if(etat == 2) begin Start_offset <= 1; // Démarrer l'offset
69
etat <= 3; end if(etat == 3) begin Go_G <=1; if(Front_GO_DEPART_G) begin CST_TEMPO_ALEATOIRE_D <= tempoAleatoire; CST_TEMPO_ALEATOIRE_G <= tempoAleatoire; Ok_Start_D <= Offset_G_OK; Ok_Start_G <= Offset_D_OK; end end end end // Si les voitures ont fini la course if(iFINISH_COULOIR_D & iFINISH_COULOIR_G) begin Ok_Start_D <= 0; Ok_Start_G <= 0; Led_Ok_Depart <= 0; end if(Ok_Start_D & Ok_Start_G) Led_Ok_Depart <= iCLK_2Hz; end //################################################################ end end endmodule
70
71
7.3.4 Code Verilog - Module Horloge 2 kHz
module clk2Hz( iCLK_25Mhz, iRESET, oCLK_2Hz ); input iCLK_25Mhz; input iRESET; output oCLK_2Hz; parameter [22:0] Delais_500ms = 6250000; reg [22:0] Compteur_Delais500ms; reg clk_500ms; assign oCLK_2Hz = clk_500ms; //#################################################################### //Horloge 4 Hz (500 ms) always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin Compteur_Delais500ms <= 23'b0; clk_500ms <= 0; end else begin Compteur_Delais500ms <= Compteur_Delais500ms + 1; if(Compteur_Delais500ms == Delais_500ms) begin clk_500ms <= ~clk_500ms; Compteur_Delais500ms <= 0; end end end endmodule
72
7.3.5 Code Verilog - Module Horloge 2 kHz
module traitementDonnees( iCLK_25Mhz, iRESET, iMODE_DEPART, iVOITURE_ID_G, iSTART_TRAITEMENT_G, iTemps_Reaction_Binaire_G, iTemps_60Pieds_Binaire_G, iTemps_Fin2_Binaire_G, iVitesse_Fin_Binaire_G, iFAUX_DEPART_G, iVOITURE_ID_D, iSTART_TRAITEMENT_D, iTemps_Reaction_Binaire_D, iTemps_60Pieds_Binaire_D, iTemps_Fin2_Binaire_D, iVitesse_Fin_Binaire_D, iFAUX_DEPART_D, oTx ); // Entrées input iCLK_25Mhz; input iRESET; input [2:0] iMODE_DEPART; input [7:0] iVOITURE_ID_G; input iSTART_TRAITEMENT_G; input [31:0] iTemps_Reaction_Binaire_G; input [31:0] iTemps_60Pieds_Binaire_G; input [31:0] iTemps_Fin2_Binaire_G; input [31:0] iVitesse_Fin_Binaire_G; input iFAUX_DEPART_G; input [7:0] iVOITURE_ID_D; input iSTART_TRAITEMENT_D; input [31:0] iTemps_Reaction_Binaire_D; input [31:0] iTemps_60Pieds_Binaire_D; input [31:0] iTemps_Fin2_Binaire_D; input [31:0] iVitesse_Fin_Binaire_D; input iFAUX_DEPART_D; // Sorties output [7:0] oTx; wire [9:0] addra; wire [31:0] dina; wire wea; wire [31:0] douta; wire Tx_empty; wire [7:0] Tx_out; // Registres de gestion du port série reg [31:0] Tx_data; reg [7:0] Tx_mask; reg Tx_en; reg [7:0] cnt_paquet;
73
reg Front_START_TRAITEMENT_G; reg [1:0] DetectFront_START_TRAITEMENT_G; reg Front_START_UART_empty; reg [1:0] DetectFront_UART_empty; reg [27:0] Temps_Reaction_BCD_G; reg [27:0] Temps_60Pieds_BCD_G; reg [27:0] Temps_Fin2_BCD_G; reg [27:0] Vitesse_Fin_BCD_G; wire [31:0] iBin2BCD; // Registres du couloir de gauche reg [2:0] Mode_Course; reg [7:0] Nb_Run_G; reg [7:0] Nb_Rouge_G; reg [7:0] Nb_Victoire_G; reg [7:0] Nb_Defaites_G; reg [31:0] Moy_React_Time_G; reg [31:0] Moy_60Pieds_G; reg [31:0] Moy_Fin2_G; reg [31:0] Moy_Vitesse_G; // Registres du couloir de droite reg [7:0] Nb_Run_D; reg [7:0] Nb_Rouge_D; reg [7:0] Nb_Victoire_D; reg [7:0] Nb_Defaites_D; reg [31:0] Moy_React_Time_D; reg [31:0] Moy_60Pieds_D; reg [31:0] Moy_Fin2_D; reg [31:0] Moy_Vitesse_D; // Adressage dynamique reg [7:0] addr_1_G; reg [7:0] addr_1_D; reg [7:0] addr_2_G; reg [7:0] addr_2_D; reg [7:0] addr_3_G; reg [7:0] addr_3_D; reg [7:0] addr_4_G; reg [7:0] addr_4_D; reg [7:0] addr_5_G; reg [7:0] addr_5_D; reg [7:0] mem_etat; reg mem_ok; reg wea_E; reg [9:0] addra_E; reg [31:0] dina_E; reg Traitement; reg [31:0] Bin2BCD; wire [31:0] oBin2BCD;
74
assign addra[9:0] = addra_E[9:0]; assign dina[31:0] = dina_E[31:0]; assign wea = wea_E; assign iBin2BCD = Bin2BCD; assign oTx = Tx_out; // Module de mémoire RAM ram u1 ( .clka(iCLK_25Mhz), .wea(wea), // Bus [0 : 0] .addra(addra), // Bus [9 : 0] .dina(dina), // Bus [31 : 0] .douta(douta)); // Bus [31 : 0] // Module de communication UART uart_module u2 ( .iCLK_25Mhz(iCLK_25Mhz), .iRESET(iRESET), .iTx_data(Tx_data), .iTx_mask(8'b00001001), .iTx_en(Tx_en), .oTx(Tx_out), .oTx_empty(Tx_empty) ); // Convertisseur Binaire vers BCD binary_to_BCD u3 ( .iA(iBin2BCD), .oChiffre1(oBin2BCD[3:0]), .oChiffre2(oBin2BCD[7:4]), .oChiffre3(oBin2BCD[11:8]), .oChiffre4(oBin2BCD[15:12]), .oChiffre5(oBin2BCD[19:16]), .oChiffre6(oBin2BCD[23:20]), .oChiffre7(oBin2BCD[27:24]) ); always @(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin Tx_en <= 0; mem_etat <= 1; cnt_paquet <= 0; Traitement <= 0; end else begin
75
if(iMODE_DEPART == 1) // Si course seul Gauche begin if(iSTART_TRAITEMENT_G) // Fin de course seul OK Traitement <= 1; end if(iMODE_DEPART == 2) // Si course seul Droite begin if(iSTART_TRAITEMENT_D) Traitement <= 1; end if(iMODE_DEPART > 2) // Si mode Duel begin if(iSTART_TRAITEMENT_D & iSTART_TRAITEMENT_G) Traitement <= 1; end if(Traitement) begin if(mem_etat == 1) // Création de l'adressage dynamique begin addr_1_G <= (iVOITURE_ID_G*5) - 4; addr_2_G <= (iVOITURE_ID_G*5) - 3; addr_3_G <= (iVOITURE_ID_G*5) - 2; addr_4_G <= (iVOITURE_ID_G*5) - 1; addr_5_G <= (iVOITURE_ID_G*5) - 0; addr_1_D <= (iVOITURE_ID_D*5) - 4; addr_2_D <= (iVOITURE_ID_D*5) - 3; addr_3_D <= (iVOITURE_ID_D*5) - 2; addr_4_D <= (iVOITURE_ID_D*5) - 1; addr_5_D <= (iVOITURE_ID_D*5) - 0; mem_etat <=2; end if(mem_etat == 2) // Lecture des données en RAM begin wea_E <= 0; addra_E <= 0; Mode_Course <= douta[7:0]; mem_etat <= 3; end if(mem_etat == 3) // Lecture des données en RAM begin wea_E <= 0;
addra_E <= addr_1_G; // Récupération du nombre de run
Nb_Run_G <= douta[7:0]; // Récupération du nombre de faux départ
Nb_Rouge_G <= douta[15:8]; // Récupération du nombre de victoire
Nb_Victoire_G <= douta[23:16]; // Récupération du nombre de défaites
Nb_Defaites_G <= douta[31:24];
mem_etat <= 4;
76
end if(mem_etat == 4) begin wea_E <= 0; addra_E <= addr_1_D;
// Récupération du nombre de run Nb_Run_D <= douta[7:0];
// Récupération du nombre de faux départ Nb_Rouge_D <= douta[15:8]; // Récupération du nombre de victoire
Nb_Victoire_D <= douta[23:16]; // Récupération du nombre de défaites Nb_Defaites_D <= douta[31:24]; mem_etat <= 5; end // Traitement des données et mise à jour if(mem_etat == 5) begin //################# MODE DEPART 1 ########################## // Nombre de course et de faux départ Couloir gauche if(iMODE_DEPART == 1) begin Nb_Run_G <= Nb_Run_G + 1; if(iFAUX_DEPART_G) Nb_Rouge_G <= Nb_Rouge_G + 1; end //################# MODE DEPART 2 ########################## // Nombre de course et de faux départ Couloir droit if(iMODE_DEPART == 2) begin Nb_Run_D <= Nb_Run_D + 10; if(iFAUX_DEPART_D) Nb_Rouge_D <= Nb_Rouge_D + 1; end //################# MODE DEPART 3 ########################## if(iMODE_DEPART == 3) begin if(iFAUX_DEPART_D) begin Nb_Victoire_G <= Nb_Victoire_G + 1; Nb_Defaites_D <= Nb_Defaites_D + 1; end
77
s
if(iFAUX_DEPART_G) begin Nb_Victoire_D <= Nb_Victoire_D + 1; Nb_Defaites_G <= Nb_Defaites_G + 1; end else begin if(iTemps_Reaction_Binaire_G > iTemps_Reaction_Binaire_D) begin Nb_Victoire_D <= Nb_Victoire_D + 1; Nb_Defaites_G <= Nb_Defaites_G + 1; end if(iTemps_Reaction_Binaire_D > iTemps_Reaction_Binaire_G) begin Nb_Victoire_G <= Nb_Victoire_G + 1; Nb_Defaites_D <= Nb_Defaites_D + 1; end end end //################# MODE DEPART 4 ########################## // Travail en cours mem_etat <= 6; end
// Écriture des données en RAM if(mem_etat == 6) begin // Écriture du mode de l'autodrome wea_E <= 1; addra_E <= 0; dina_E[7:0] <= iMODE_DEPART; mem_etat <= 7; end if(mem_etat == 7) // Écriture du nombre de course et de faux départs begin wea_E <= 1; addra_E <= addr_1_G; dina_E[7:0] <= Nb_Run_G; dina_E[15:8] <= Nb_Rouge_G; mem_etat <= 8; end
if(mem_etat == 8) // Écriture du nombre de course et de faux départs
begin wea_E <= 1; addra_E <= addr_1_D; dina_E[7:0] <= Nb_Run_D; dina_E[15:8] <= Nb_Rouge_D; mem_etat <= 9; end
78
if(mem_etat == 9) // Écriture du temps de réaction
begin wea_E <= 1; addra_E <= addr_2_G; dina_E <= iTemps_Reaction_Binaire_G; mem_etat <=10; end if(mem_etat == 10) // Écriture du temps de réaction begin wea_E <= 1; addra_E <= addr_2_D; dina_E <= iTemps_Reaction_Binaire_D; mem_etat <=11; end if(mem_etat == 11)
// Écriture du temps au 60 pieds begin wea_E <= 1; addra_E <= addr_3_G; dina_E <= iTemps_60Pieds_Binaire_G; mem_etat <=12; end if(mem_etat == 12)
// Écriture du temps au 60 pieds begin wea_E <= 1; addra_E <= addr_3_D; dina_E <= iTemps_60Pieds_Binaire_D; mem_etat <= 13; end if(mem_etat == 13)
// Écriture du temps de fin de parcourt begin wea_E <= 1; addra_E <= addr_4_G; dina_E <= iTemps_Fin2_Binaire_G; mem_etat <=14; end if(mem_etat == 14)
// Écriture du temps de fin de parcourt begin wea_E <= 1; addra_E <= addr_4_D; dina_E <= iTemps_Fin2_Binaire_D; mem_etat <=15; end
79
if(mem_etat == 15) // Écriture de la vitesse
begin wea_E <= 1; addra_E <= addr_5_G; dina_E <= iVitesse_Fin_Binaire_G; mem_etat <=16; end if(mem_etat == 16)
// Écriture de la vitesse begin wea_E <= 1; addra_E <= addr_5_D; dina_E <= iVitesse_Fin_Binaire_D; mem_etat <=17; end if(mem_etat == 17)
// Envoie des données par port série begin if(cnt_paquet < 7) begin Tx_en <= 1; if(cnt_paquet == 0) begin wea_E <= 0; addra_E <= 0;
// Mode autodrome Tx_data <= douta[7:0]; end if(cnt_paquet == 1) begin wea_E <= 0; addra_E <= addr_1_G; Tx_data <= {douta[7:0],douta[15:8]}; end if(cnt_paquet == 2) begin // Envoie du temps de réaction BCD
Tx_data <= oBin2BCD; Bin2BCD <= iTemps_Reaction_Binaire_G;
end if(cnt_paquet == 3) begin // Envoie du temps au 60 pieds BCD
Tx_data <= oBin2BCD; Bin2BCD <= iTemps_60Pieds_Binaire_G; end
80
if(cnt_paquet == 4) begin
// Envoie du temps final BCD Tx_data <= oBin2BCD;
Bin2BCD <= iTemps_Fin2_Binaire_G; end if(cnt_paquet == 5) begin
// Envoie de la vitesse de pointe Tx_data <= oBin2BCD;
Bin2BCD <= iVitesse_Fin_Binaire_G; end if(cnt_paquet == 6) Tx_en <= 0; if(Front_START_UART_empty) cnt_paquet <= cnt_paquet + 1; end end end end end //#######################################################################// Détection de front de fin UART empty always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) DetectFront_UART_empty <= 0; else begin DetectFront_UART_empty[0] <= Tx_empty; DetectFront_UART_empty[1] <= DetectFront_UART_empty[0]; end end always@(DetectFront_UART_empty) begin Front_START_UART_empty <= !DetectFront_UART_empty[1] & DetectFront_UART_empty[0]; end endmodule
81
7.3.6 Code Verilog - Module UART
module uart_module( iCLK_25Mhz, iRESET, iTx_data, iTx_mask, iTx_en, oTx, oTx_empty ); input iRESET; input [31:0] iTx_data; input iCLK_25Mhz; input iTx_en; input [7:0] iTx_mask; output oTx; output oTx_empty; reg [16:0] count5kHz; reg clk5kHz; reg [31:0] countFreqTx; reg Tx_clk; reg Tx_out; reg [3:0] Tx_cnt; reg [7:0] Tx_reg; reg [7:0] Tx_data; reg [3:0] cnt_data_bits; reg [3:0] cnt_data_bytes; reg Tx_empty; reg [7:0] data_buff; parameter VAL5kHz = 2500; // clk 5kHz parameter freqTx = 108; // clk 115 kHz Tx //parameter freqTx = 10417; // clk 1200 Hz Tx // Sorties du modules assign oTx = Tx_out; assign oTx_empty = Tx_empty; ///////////////////////////////////////////////////////////////////////// // Encapsulation des données always @(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin data_buff <=0; end else begin //if(cnt_data_bytes == 0) // data_buff <= iTx_mask[7:0]; if(cnt_data_bytes == 0) data_buff <= {0000,iTx_data[19:16]};
82
if(cnt_data_bytes == 1) data_buff <= {0000,iTx_data[15:12]}; if(cnt_data_bytes == 2) data_buff <= {0000,iTx_data[11:8]}; if(cnt_data_bytes == 3) data_buff <= {0000,iTx_data[7:4]}; if(cnt_data_bytes == 4) data_buff <= {0000,iTx_data[3:0]}; end end ///////////////////////////////////////////////////////////////////////// //CLK pour communication Tx always @(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin countFreqTx <=0; Tx_clk <= 0; end else begin countFreqTx <= countFreqTx + 1; if(countFreqTx == freqTx) begin Tx_clk <= ~Tx_clk; countFreqTx <= 0; end end end //////////////////////////////////////////////////////////////////////// //envoie RS232 Tx always@(posedge Tx_clk or negedge iRESET) begin if(!iRESET) begin Tx_out <= 1; Tx_cnt <= 0; Tx_reg <= 0; Tx_empty <= 1; cnt_data_bytes <=0; end
83
7.3.7 Code Verilog - Module Convertisseur Binaire BCD
module add3(in,out); input [3:0] in; output [3:0] out; reg [3:0] out; always @ (in) case (in) 4'b0000: out <= 4'b0000; 4'b0001: out <= 4'b0001; 4'b0010: out <= 4'b0010; 4'b0011: out <= 4'b0011; 4'b0100: out <= 4'b0100; 4'b0101: out <= 4'b1000; 4'b0110: out <= 4'b1001; 4'b0111: out <= 4'b1010; 4'b1000: out <= 4'b1011; 4'b1001: out <= 4'b1100; default: out <= 4'b0000; endcase endmodule module binary_to_BCD( iA, // Nombre binaire sur 20 bits oChiffre1, // BCD sortie Chiffre 1 oChiffre2, // BCD sortie Chiffre 2 oChiffre3, // BCD sortie Chiffre 3 oChiffre4, // BCD sortie Chiffre 4 oChiffre5, // BCD sortie Chiffre 5 oChiffre6, // BCD sortie Chiffre 6 oChiffre7 // BCD sortie Chiffre 7 ); input [19:0] iA; output [3:0] oChiffre1,oChiffre2,oChiffre3,oChiffre4,oChiffre5,oChiffre6,oChiffre7; wire [3:0] c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,c13,c14,c15,c16,c17,c18,c19,c20; wire [3:0] c21,c22,c23,c24,c25,c26,c27,c28,c29,c30,c31,c32,c33,c34,c35,c36,c37,c38,c39,c40; wire [3:0] c41,c42,c43,c44,c45,c46,c47,c48,c49,c50,c51,c52,c53,c54,c55,c56,c57,c58; wire [3:0] d1,d2,d3,d4,d5,d6,d7,d8,d9,d10,d11,d12,d13,d14,d15,d16,d17,d18,d19,d20; wire [3:0] d21,d22,d23,d24,d25,d26,d27,d28,d29,d30,d31,d32,d33,d34,d35,d36,d37,d38,d39,d40; wire [3:0] d41,d42,d43,d44,d45,d46,d47,d48,d49,d50,d51,d52,d53,d54,d55,d56,d57,d58;
84
assign d1 = {1'b0,iA[19:17]}; assign d2 = {c1[2:0],iA[16]}; assign d3 = {c2[2:0],iA[15]}; assign d4 = {c3[2:0],iA[14]}; assign d5 = {c4[2:0],iA[13]}; assign d6 = {c5[2:0],iA[12]}; assign d7 = {c6[2:0],iA[11]}; assign d8 = {c7[2:0],iA[10]}; assign d9 = {c8[2:0],iA[9]}; assign d10 = {c9[2:0],iA[8]}; assign d11 = {c10[2:0],iA[7]}; assign d12 = {c11[2:0],iA[6]}; assign d13 = {c12[2:0],iA[5]}; assign d14 = {c13[2:0],iA[4]}; assign d15 = {c14[2:0],iA[3]}; assign d16 = {c15[2:0],iA[2]}; assign d17 = {c16[2:0],iA[1]}; assign d18 = {1'b0,c1[3],c2[3],c3[3]}; assign d19 = {c18[2:0],c4[3]}; assign d20 = {c19[2:0],c5[3]}; assign d21 = {c20[2:0],c6[3]}; assign d22 = {c21[2:0],c7[3]}; assign d23 = {c22[2:0],c8[3]}; assign d24 = {c23[2:0],c9[3]}; assign d25 = {c24[2:0],c10[3]}; assign d26 = {c25[2:0],c11[3]}; assign d27 = {c26[2:0],c12[3]}; assign d28 = {c27[2:0],c13[3]}; assign d29 = {c28[2:0],c14[3]}; assign d30 = {c29[2:0],c15[3]}; assign d31 = {c30[2:0],c16[3]}; assign d32 = {1'b0,c18[3],c19[3],c20[3]}; assign d33 = {c32[2:0],c21[3]}; assign d34 = {c33[2:0],c22[3]}; assign d35 = {c34[2:0],c23[3]}; assign d36 = {c35[2:0],c24[3]}; assign d37 = {c36[2:0],c25[3]}; assign d38 = {c37[2:0],c26[3]}; assign d39 = {c38[2:0],c27[3]}; assign d40 = {c39[2:0],c28[3]}; assign d41 = {c40[2:0],c29[3]}; assign d42 = {c41[2:0],c30[3]}; assign d43 = {1'b0,c32[3],c33[3],c34[3]}; assign d44 = {c43[2:0],c35[3]}; assign d45 = {c44[2:0],c36[3]}; assign d46 = {c45[2:0],c37[3]}; assign d47 = {c46[2:0],c38[3]}; assign d48 = {c47[2:0],c39[3]}; assign d49 = {c48[2:0],c40[3]}; assign d50 = {c49[2:0],c41[3]};
85
assign d51 = {1'b0,c43[3],c44[3],c45[3]}; assign d52 = {c51[2:0],c46[3]}; assign d53 = {c52[2:0],c47[3]}; assign d54 = {c53[2:0],c48[3]}; assign d55 = {c54[2:0],c49[3]}; assign d56 = {1'b0,c51[3],c52[3],c53[3]}; assign d57 = {c56[2:0],c54[3]}; assign d58 = {3'b0,c56[3]}; add3 m1(d1,c1); add3 m2(d2,c2); add3 m3(d3,c3); add3 m4(d4,c4); add3 m5(d5,c5); add3 m6(d6,c6); add3 m7(d7,c7); add3 m8(d8,c8); add3 m9(d9,c9); add3 m10(d10,c10); add3 m11(d11,c11); add3 m12(d12,c12); add3 m13(d13,c13); add3 m14(d14,c14); add3 m15(d15,c15); add3 m16(d16,c16); add3 m17(d17,c17); add3 m18(d18,c18); add3 m19(d19,c19); add3 m20(d20,c20); add3 m21(d21,c21); add3 m22(d22,c22); add3 m23(d23,c23); add3 m24(d24,c24); add3 m25(d25,c25); add3 m26(d26,c26); add3 m27(d27,c27); add3 m28(d28,c28); add3 m29(d29,c29); add3 m30(d30,c30); add3 m31(d31,c31); add3 m32(d32,c32); add3 m33(d33,c33); add3 m34(d34,c34); add3 m35(d35,c35); add3 m36(d36,c36); add3 m37(d37,c37); add3 m38(d38,c38); add3 m39(d39,c39); add3 m40(d40,c40); add3 m41(d41,c41); add3 m42(d42,c42); add3 m43(d43,c43); add3 m44(d44,c44); add3 m45(d45,c45);
86
assign d51 = {1'b0,c43[3],c44[3],c45[3]}; assign d52 = {c51[2:0],c46[3]}; assign d53 = {c52[2:0],c47[3]}; assign d54 = {c53[2:0],c48[3]}; assign d55 = {c54[2:0],c49[3]}; assign d56 = {1'b0,c51[3],c52[3],c53[3]}; assign d57 = {c56[2:0],c54[3]}; assign d58 = {3'b0,c56[3]}; add3 m1(d1,c1); add3 m2(d2,c2); add3 m3(d3,c3); add3 m4(d4,c4); add3 m5(d5,c5); add3 m6(d6,c6); add3 m7(d7,c7); add3 m8(d8,c8); add3 m9(d9,c9); add3 m10(d10,c10); add3 m11(d11,c11); add3 m12(d12,c12); add3 m13(d13,c13); add3 m14(d14,c14); add3 m15(d15,c15); add3 m16(d16,c16); add3 m17(d17,c17); add3 m18(d18,c18); add3 m19(d19,c19); add3 m20(d20,c20); add3 m21(d21,c21); add3 m22(d22,c22); add3 m23(d23,c23); add3 m24(d24,c24); add3 m25(d25,c25); add3 m26(d26,c26); add3 m27(d27,c27); add3 m28(d28,c28); add3 m29(d29,c29); add3 m30(d30,c30); add3 m31(d31,c31); add3 m32(d32,c32); add3 m33(d33,c33); add3 m34(d34,c34); add3 m35(d35,c35); add3 m36(d36,c36); add3 m37(d37,c37); add3 m38(d38,c38); add3 m39(d39,c39); add3 m40(d40,c40); add3 m41(d41,c41); add3 m42(d42,c42); add3 m43(d43,c43); add3 m44(d44,c44); add3 m45(d45,c45);
87
add3 m46(d46,c46); add3 m47(d47,c47); add3 m48(d48,c48); add3 m49(d49,c49); add3 m50(d50,c50); add3 m51(d51,c51); add3 m52(d52,c52); add3 m53(d53,c53); add3 m54(d54,c54); add3 m55(d55,c55); add3 m56(d56,c56); add3 m57(d57,c57); add3 m58(d58,c58); assign oChiffre1 = {c17[2:0],iA[0]}; assign oChiffre2 = {c31[2:0],c17[3]}; assign oChiffre3 = {c42[2:0],c31[3]}; assign oChiffre4 = {c50[2:0],c42[3]}; assign oChiffre5 = {c55[2:0],c50[3]}; assign oChiffre6 = {c57[2:0],c55[3]}; assign oChiffre7 = {c56[3],c57[3]};
endmodule
88
7.3.8 Code Verilog - Module Chronomètre
module chromometre( oTemps_Binaire, iCLK_25Mhz, iRESET, iStart_Chronos ); // Entrée sortie du module output [32:0] oTemps_Binaire; input iCLK_25Mhz; input iRESET; input iStart_Chronos; // Variables internes au module reg delais_1ms; reg [13:0] Compteur_Delais500us; reg [3:0] Compte_1ms; reg [31:0] Temps_Binaire; // Lien du module avec d'autres modules assign oTemps_Binaire = Temps_Binaire[31:0]; // Parametres fixes du module parameter [13:0] delais500us = 12500; //####################################################################### //Horloge 2kHz (500us) always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin Compteur_Delais500us <= 13'b0; delais_1ms <= 0; end else begin if(iStart_Chronos == 1) begin Compteur_Delais500us <= Compteur_Delais500us + 1; if(Compteur_Delais500us == delais500us) begin delais_1ms <= ~delais_1ms; Compteur_Delais500us <= 0; end end end end
89
//####################################################################### //Compteur mili secondes Binaire always@(posedge delais_1ms or negedge iRESET) begin if(!iRESET) Temps_Binaire <= 0; else Temps_Binaire <= Temps_Binaire +1; end endmodule
90
module capteursPiste( iCAPTEUR, iActivation, iCLK_25Mhz, iRESET, iTemps_Binaire, oTemps_Binaire ); input iCAPTEUR; input iCLK_25Mhz; input iRESET; input iActivation; input [31:0] iTemps_Binaire; output [31:0] oTemps_Binaire; reg [1:0] DetectFront; reg Front_Capteur; reg [31:0] Sortie_Temps_Binaire; reg gardien; assign oTemps_Binaire = Sortie_Temps_Binaire[31:0]; //###################################################################### // Détection de front du capteur always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin DetectFront <= 0; end else begin DetectFront[0] <= iCAPTEUR; DetectFront[1] <= DetectFront[0]; end end always@(DetectFront) begin Front_Capteur <= !DetectFront[1] & DetectFront[0]; end
91
always@(posedge iCLK_25Mhz or negedge iRESET) begin if(!iRESET) begin Sortie_Temps_Binaire <= 0; gardien<=0; end else begin // Contrôle qu'il n'y ai qu'un seul passage devant le capteur
if(gardien <1) begin
if(Front_Capteur & iActivation) begin gardien <= 1; Sortie_Temps_Binaire[31:0] <= iTemps_Binaire[31:0]; end end if(!iActivation) gardien <= 0; end end endmodule
92
7.3.9 Code assembleur – Contrôle de l’affichage
93
94
95
96
97
98
99
100
101
102
103
[...] On branche par la suite C1,C2,C3,C4,C5,C6,C7,C8…
104
Le code est donc identiquement le même pour toutes ces parties sauf pour le C9 où à chaque sortie on active le compteur pour l’affichage
[...]
105
