Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
i
Université du Québec à Chicoutimi
MODULE D’INGÉNIERIE
PROGRAMME (Génie informatique)
6GIN555 Projet de synthèse
Rapport final
Projet : 2012-316
Conception d’un détecteur de température
sans contact
Préparé par
Hechmi AYARI
Pour : Jean-Michel Néron
Président de la formule SAE
07 Décembre 2012
CONSEILLER : Hung Tien-Bui, ing, Ph.D.
COORDONNATEUR : Jacques Paradis, ing.
ii
Approbation du rapport d’étape pour diffusion
Nom du conseiller
Date
Signature
iii
Remerciements
Je tiens à remercier les personnes qui m’ont aidé à mener à terme ce projet.
Tout d’abord, je remercie mon conseiller, Monsieur Hung Tien Bui pour ses
conseils et son savoir faire pour m’aider à garder les objectifs du projet en vue, et
d’avoir su me motiver à les atteindre, aussi pour sa disponibilité dans les moments
difficiles du projet.
Je remercie Monsieur Jean-Michel Neron (Président de la formule SAE)
pour son aide dans la compréhension de certains phénomènes mécaniques liés de
près à la réalisation de ce projet, ainsi que sa disponibilité tout au long de la
réalisation.
Je remercie Monsieur Francis Deschênes (technicien au sein de l’université)
pour son soutien, son aide ainsi que ses conseils pour mener à bien la réalisation du
PCB, qui est une des parties maitresses de mon projet.
Aussi, je remercie mon épouse de m’avoir soutenu moralement dans la
réalisation de ce projet et qui a su m’encourager dans les moments difficiles.
Pour terminer, je tiens à remercier mes parents pour les différentes qualités qu’ils
m’ont inculquées et qui m’ont permis d’avancer dans la vie.
Hechmi Ayari
iv
Résumé
Les responsables de la Formule SAE cherchent toujours à améliorer les
performances de la voiture de course. Chaque année ils participent dans un
concours interuniversitaire. Le but de ce concours est de démontrer les bonnes
performances de la voiture et de remporter la compétition. Une solution
envisagée est d’améliorer la suspension des roues.
L’objectif principal est de pouvoir étudier les paramètres qui peuvent altérer la
suspension. Le paramètre principal est l’adhérence, la température des pneus
en est un bon indicateur.
Ainsi, le défi est de pouvoir faire la lecture de la température à différents
endroits de chaque pneu pour pouvoir déterminer la bonne adhérence à la piste
de course.
Parmi les contraintes à respecter; trouver des capteurs à infrarouges capables
de relever des températures pouvant aller jusqu’à 125 °C et un module GPS
ayant une fréquence de rafraîchissement qui tient compte de la vitesse du
véhicule.
Dans le but d’améliorer la suspension des pneus, nous avons étudié les
températures que peuvent atteindre les pneus. En se basant sur notre
étude, nous avons choisi les capteurs adéquats. Par la suite, nous avons
réalisé un circuit imprimé capable de collecter les données de
températures ainsi que la position de la voiture en temps réel. Une fois
collectées, les données sont envoyées via un module XBee vers un
ordinateur qui les affiche dans un fichier.
L'équipe a réussi à concevoir un système qui inclut trois capteurs de
températures et un module GPS.
Ce système est géré par un microcontrôleur ATMEGA328P sur une
plaquette de type Arduino. Des tests ont été effectués au laboratoire et
montrent que l’acquisition de la température se fait bien sur un capteur à la
fois.
Concernant les données GPS, l’acquisition des strings NMEA fonctionne et
les fonctions pour traiter ces données sont implémentées.
Rés
um
é d
e la
pro
blé
mat
iqu
e et
des
obje
ctif
s R
ésu
mé
du
tra
vai
l ré
alis
é
Rés
um
é d
es c
on
clusi
ons
v
Table des matières
Remerciements .......................................................................................................................... iii
Résumé ...................................................................................................................................... iv
Table des matières....................................................................................................................... v
Liste des figures ........................................................................................................................ vi
I. Introduction .......................................................................................................................... 1
II. Présentation du projet ......................................................................................................... 2
II.1. Description du club .................................................................................................................2
II.2. Description de l’équipe de travail .......................................................................................... 2
II.3. Problématique et état de l’art reliés au projet ............................................................... 3
II.4. Objectifs généraux et spécifiques du projet ................................................................ 4 III. Aspects techniques et éléments de conception relatifs au projet .................................. 6
III.1. Architecture du module ...........................................................................................................6
III.2. Choix des composantes ...........................................................................................................7 III.3. Conception .................................................................................................................. 13
III.3.1 présentation des protocoles. ........................................................................................14
III.3.2 Alimentation du circuit imprimé. ................................................................................16
III.3.3 Circuit imprimé. ..........................................................................................................17
III.4. Programmation et Test ..........................................................................................................20 III.5. Réalisations ................................................................................................................. 24
IV. Bilan des activités ............................................................................................................ 30
IV.1. Arrimage formation pratique/universitaire ............................................................... 30 IV.2. Travail d’équipe ....................................................................................................... 31
IV.3. Respect de l’échéancier ............................................................................................ 32
IV.4. Analyse et discussion ................................................................................................ 33 V.Conclusion et recommandations ........................................................................................ 35
Bibliographie............................................................................................................................. 37
Annexe... ................................................................................................................................... 38
vi
Liste des tableaux et figures
Figure II.1 : Architecture générale ............................................................................................. 4 Figure III.1 : Architecture du module ......................................................................................... 6
Figure III.2 : Rayon du capteur MLX90620 ............................................................................... 8
Figure III. 3 : Capteur de température infrarouge (MLX90614) .............................................. 9
Figure III.4 : Module GPS (LS20031) ...................................................................................... 10
Figure III.5 : Module XBee Pro série1 .................................................................................... 12
Figure III.6 : Clé XStick ........................................................................................................... 12
Figure III.7 : Microcontrôleur (PIC18F46K22) ........................................................................ 13
Figure III.8 : Structure d’une trame de lecture ....................................................................... 14
Figure III.9 : Structure d’une trame UART .............................................................................. 15
Figure III.10 : Batterie en lithium ............................................................................................ 16 Figure III.11 : Régulateur linéaire de tension (REG117A)....................................................... 16
Figure III.12 : Régulateur linéaire de tension (TPS73033) ..................................................... 17
Figure III.13 : Schématique du circuit imprimé........................................................................ 18
Figure III.14 : Boitier de fixation (RP1095) ............................................................................ 19 Figure III.15 : Circuit imprimé envoyé à la fabrication ............................................................ 19
Figure III.16 : Circuit imprimé final assemblé ....................................................................... 20
Figure III.17 : Plaquette de prototypage ................................................................................... 21
Figure III.18 : Diagramme de flux pour la lecture de la température ...................................... 22 Figure III.19 : Diagramme de flux de la communication GPS ................................................. 23
Figure III.20 : Circuit imprimé modifié .................................................................................... 24
Figure III.21 : Analogie connexion Pic et Arduino .................................................................. 25
Figure III.22 : Code Arduino utilisé ......................................................................................... 25
Figure III.23 : Lecture de la température sur les 3 capteurs ..................................................... 26
Figure III.24 : Données reçues par l’ordinateur ........................................................................ 27
Figure III.25 : Résultat final...................................................................................................... 27
Figure III.26 : Module assemblé sur la voiture ......................................................................... 28
Figure III.27 : Support des capteurs ........................................................................................ 29
Figure IV.1 : Échéancier initial du projet ................................................................................. 32
1
I Introduction
La Formule 1 consiste, de nos jours, un domaine où la technologie est omniprésente. Les voitures
sont de plus en plus perfectionnées afin d’atteindre un niveau inégalé, et cela en essayant de
maîtriser tous les paramètres qui contribueront à rendre cette dernière plus performante et ainsi
fournir le meilleur rendement sur le circuit.
Dans le cadre des courses automobiles F1, la formule SAE constitue une reproduction à l’échelle
universitaire de ce genre de course où les étudiants des différentes universités essaient de se
surpasser en reproduisant les mêmes performances. Ces performances reposent sur plusieurs
paramètres qu’il faut maîtriser. Parmi ces paramètres on cite : la suspension, la température de
l’huile, l’adhérence de la voiture à la piste,…
Dans le cadre de ce projet intitulé «CONCEPTION D’UN DÉTECTEUR DE
TEMPÉRATURE SANS CONTACT », le but était de traiter l’adhérence des pneus de la voiture
à la piste de course. Ainsi, le facteur qui pouvait nous indiquer des défaillances dans ce dernier
est la température à différents points de la surface de la roue.
Ce rapport contiendra une description de l’organisme pour lequel le projet est destiné, ensuite
une description de la problématique et des objectifs à réaliser, par la suite on présentera les
aspects techniques reliés à ce projet et enfin un bilan des activités sera fourni suivi des
recommandations.
2
II Présentation du projet
Le projet est le fruit de 4 mois de travail rigoureux au sein de l’UQAC. Il est réalisé suite à des
besoins exprimés par le club de course automobile « Formule SAE » de l’UQAC.
II.1 Description du club
Le club Formule SAE (Society of Automotive Engineers) de l’UQAC est constitué de différents
étudiants issus de plusieurs domaines d’études tels que : génie mécanique, génie électrique, génie
informatique, etc…). Leur but principal est de construire une voiture de course de type Formule
compétitive et capable de concurrencer les voitures des autres clubs de différentes universités
canadiennes et américaines.
Ainsi, chaque année une nouvelle voiture est construite avec le défi d’être meilleure que la
précédente, cela dans le but de mieux représenter l’UQAC dans les compétitions universitaires.
Ce désir d’amélioration a créé une opportunité de chercher de nouvelles idées réalisables dans le
cadre des projets universitaires.
II.2 Description de l’équipe de travail
Le projet est né suite à une rencontre avec Jean-Michel NERON (président de la formule SAE).
Le conseiller de ce projet est Monsieur Hung Tien-Bui a par la suite fixé l’idée principale du
projet.
Les étudiants qui ont contribué à la réalisation de ce projet sont Hechmi AYARI
(Étudiant finissant en baccalauréat génie informatique) dans le cadre du projet 5 crédits et Jean-
Rock DUCHESNE (Étudiant troisième année en Baccalauréat génie informatique) dans le cadre
du projet de conception.
3
II.3 Problématique et état de l’art reliés au projet
Dans le but d’optimiser la voiture de la formule SAE, un des aspects à améliorer est la
suspension. La problématique est qu’il est difficile d’ajuster la suspension vu le manque de
données. Un des indicateurs les plus révélateurs est l’adhésion des pneus. En effet, la bonne
distribution de la température sur la surface de la roue pendant une course constitue une
indication sur la bonne adhérence de la roue au sol. Ainsi, afin d’améliorer l’adhérence il faut
ajuster la suspension et c’est la distribution de température qui nous indiquera le bon réglage à
faire.
Ce projet vise donc à concevoir un système à capteurs infrarouges afin de calculer la température
des pneus. Ces données seront combinées aux données GPS de la voiture, elles permettront
d’analyser la suspension de la voiture et ainsi prévoir les améliorations à y apporter.
Cette problématique est née d’un besoin non traité à ce jour au sein de la formule SAE de
l’UQAC. Dans d’autres universités, ce dernier a été satisfait en achetant un module
commercialisé appelé « CompactRIO » qui permet de mesurer en temps réel plusieurs
paramètres. La spécificité de ce projet consiste dans le fait que les compétences acquises (tant
dans le domaine électrique qu’informatique) au cours du cursus universitaire ont permis de
réaliser un module satisfaisant ce besoin, et ainsi permettre de sauver de l’argent à la formule
SAE, développer les compétences des étudiants et rendre la voiture plus performante sur la piste
de course.
4
II.4 Objectifs généraux et spécifiques du projet
Les objectifs généraux de ce projet sont : le choix des capteurs à infrarouges, la réalisation d’un
module embarqué sur la voiture de la formule capable de transmettre à la fois les données de
températures des pneus et les données GPS et la réception des données émises par le module sur
un ordinateur distant.
Concernant les objectifs spécifiques au projet : il s’agit, en premier lieu, de bien choisir les
capteurs à infrarouges adéquats pour la température des pneus (en respectant le budget et les
contraintes techniques), en deuxième lieu de choisir un module de collecte de données GPS
(permettant de transmettre la position de la voiture en temps réel),
en troisième lieu de choisir un module d’émission de données sans fil (XBEE), en quatrième lieu
de concevoir une plaquette de circuit imprimé capable de regrouper les modules précédents et, en
dernier lieu, de recevoir les données en temps réel sur un ordinateur et les formater dans un
fichier Excel.
Figure II.1 : Architecture générale
5
La figure précédente représente bien l’objectif principal de ce projet qui est de fabriquer un
module embarqué sur la voiture qui sera capable de transmettre des données (de températures et
de position) par le sans fil à un ordinateur distant, dans le but de traiter la variation de
température des pneus à différents points de contact avec la piste.
On remarque aussi sur la figure (en bas à gauche) comment seront disposés les capteurs sur la
surface de la roue. En effet, l’objectif est de mettre trois capteurs pour chaque roue et ainsi avoir
trois valeurs de températures différentes.
6
III Aspects techniques et éléments de conception relatifs au projet
III.1 Architecture du module
Lors des premières étapes du projet, une architecture générale a été élaborée, dans le but de
définir le fonctionnement du module. La figure suivante montre cette architecture :
I²CMicrocontrôleur
GPS
XBEE
UART
UART XBEE
Capteurs infrarouges
Module à concevoir
Figure III.1 : Architecture du module
Ainsi, dans le but de réaliser l’objectif du projet il a été conclu que le module à concevoir devait
intégrer :
- Un microcontrôleur pour acquérir les données
- Un module GPS pour collecter les données de positionnement de la voiture sur la
piste de course.
- Un module XBee capable de transmettre les données sans fil vers un ordinateur
distant muni d’une clé Xstick pour les réceptionner.
Le choix de ces modules doit être fait en respectant certaines contraintes qui seront détaillées
dans la section qui suivra.
7
III.2 Choix des composantes
Le choix de chaque module doit respecter certaines contraintes pour mener à bien ce projet :
Choix des capteurs de températures
Le choix des capteurs a été une tâche assez délicate. Ces derniers sont la base de ce projet. Ainsi,
un soin particulier devait leur être attribué, vu que les valeurs de températures qu’on voulait
avoir devaient être assez précises pour détecter la bonne valeur et ne pas fausser les valeurs
réelles.
Le choix des capteurs se basait sur certains critères principaux, à savoir :
- Une bonne résolution de mesure (pour donner la mesure la plus précise de
température) exemple : 0.01°C.
- Une taille assez petite (afin que leur intégration sur la tige de fixation soit assez
facile) exemple : 2 centimètres de diamètres.
- Un poids peu élevé (afin de ne pas alourdir la tige de fixation, et réduire l’impact
des frottements sur ces derniers) de quelques dizaines de grammes.
- La capacité de mesurer des températures assez élevées (vu que la température des
pneus pendant une course F1 peut atteindre facilement les 120°).
- La capacité de supporter des températures assez élevées (vu que la température de
l’objet à mesurer peut influer sur le capteur, aussi la température de la tige à
laquelle seront fixés les trois capteurs et la température de la chaussée par temps
de chaleur constitueront des sources de chaleur pour les capteurs qu’il devra
supporter)
- Un coût pas trop élevé (afin de respecter le budget alloué au projet) exemple : 100
dollars l’unité.
Vu la nature du projet, les recherches ont été orientées vers des capteurs de températures distants
et non pas avec contact. Car la roue est en mouvement constant pendant la course et elle ne peut
être en contact avec aucun objet.
Par la suite, dans la famille des capteurs distants il existe deux sortes de capteurs : ceux à lasers
et d’autres à infrarouges.
8
Mais, en analysant les contraintes à respecter le prix constituait un obstacle pour les capteurs à
laser qui avoisinait les 200$. Ainsi, les capteurs à infrarouges ont été étudiés et les plus
conformes aux besoins ont été choisis.
Il s’agit de capteurs de la marque MELEXIS [1], car ils regroupaient la plupart de ces critères à
savoir le prix (15$ chacun), la taille, la résolution (0.02°C) ainsi que les températures à mesurer
(-70°C..+380°C) et à supporter (-40°C..+125°C).
Les capteurs MLX90620 ont été le premier choix, car ils allaient faciliter le travail en fournissant
un tableau de 16x4 mesures avec un angle de capture de 60°. Avec toutes ces valeurs relevées,
cela dispensait d’avoir trois capteurs. Mais plutôt un seul pour chaque pneu et ainsi gérer un seul
signal au lieu de trois.
Figure III.2: Rayon du capteur MLX90620
9
Le seul problème rencontré fut que ce dernier fournissait une précision peu élevée pour les
valeurs d’extrémité du tableau (colonne : 0, 1, 2, 13, 14, 15). La précision était bonne seulement
pour les 4 valeurs du milieu (colonne 7, 8 : ligne 1,2).
Ainsi, les recherches furent orientées vers d’autres capteurs plus conformément aux besoins du
projet.
Des capteurs de la même marque MELEXIS ont ainsi été choisis, les capteurs MLX90614.
Ces derniers respectaient tous les besoins vu qu’ils eussent une précision de 0.02°C, un poids
léger, une taille très petite, ils peuvent mesurer une température variant de -70 °C à + 380 °C et
supporter une température de -40 °C à + 125 °C.
Et voici une figure de ces capteurs :
Figure III. 3 : Capteur de température infrarouge (MLX90614) [2]
Il est à mentionner que le coût de ces capteurs est très réduit par rapport à ce qui a été prévu
comme budget. Ainsi, ce choix a permis de sauver de l’argent à ce niveau vu le nombre de
capteurs à utiliser (3 capteurs par roue, 16 $ chacun).
10
Choix du module GPS
Autre choix à faire est le capteur GPS. Ce dernier a comme contrainte une vitesse de
rafraîchissement assez élevée pour pouvoir fournir la position de la voiture pendant son
déplacement au cours d’une course.
La voiture se déplace, au cours d’une course, à une vitesse assez élevée. Ce paramètre a permis
de conclure qu’une vitesse de rafraichissement de 5Hz (5 échantillons par secondes) serait
adéquate aux besoins du projet. Par exemples si la voiture se déplace à une vitesse de 80Km/h,
Equivaut à 22 m/s. Donc, on obtient 5 positions de la voiture sur les 22 mètres parcourus (à
chaque 4.4m une position est obtenue). Cela permettra d’avoir une bonne approximation du
parcours de la voiture au cours de la course.
Après quelques recherches, le choix a été établi sur le GPS LS20031 de la marque « Locosys »
dont voici la photo.
Figure III.4 : Module GPS (LS20031)[3]
11
Autres points positifs que présente ce module, est qu’il est alimenté à 3.3V qui est une tension
assez commune qui peut être obtenue à l’aide de régulateur pas cher. Aussi ce module présente
une pile de recharge qui lui permet de sauvegarder ses données si le module n’est plus alimenté.
On remarque aussi sur la photo la présence d’une antenne incorporée, cela a permis de sauver du
temps au niveau de la conception, et permettrai de donner plus d’importance à la partie
programmation.
Il est à mentionner que ce module est la pièce la plus chère avec un tarif de 59.9 $.
Choix du module XBee
Il existe sur le marché plusieurs modules à transmission sans fil utilisant des technologies
différentes tels que des modules utilisant la technologie WIFI ou Bluetooth.
Concernant les modules utilisant la technologie Bluetooth, se sont des modules performants avec
une taille assez petite pouvant facilement être intégré à un circuit imprimé et ayant des débits de
communications assez intéressants. Mais, leur grand inconvénient est qu’ils ne couvrent pas une
grande distance pour transmettre les données sans fil (environ 20 mètres). Ils sont plus conçus
pour des communications à petites distances.
La technologie wifi quand à elle est plus développée. En effet, en utilisant un routeur directement
embarqué sur la voiture, on peut émettre jusqu’à 100 à 150 mètre. Mais, cela reste insuffisant
pour pouvoir émettre à une grande distance.
Néanmoins, il existe des modules utilisant la technologie WIFI qui peuvent transmettre à une
distance assez élevée de 800 mètre, mais leur coût reste exorbitant.
Dans le but de concilier la contrainte de la distance avec celle du prix. le module XBEE s’avère
être la solution adéquate dans ce projet.
Ainsi, le module XBEE choisi est un XBEE pro de série 1. Ce dernier couvre une distance de 1.6
km ce qui est largement suffisant dans le cadre du projet, car au maximum la distance de la
voiture par rapport aux stands ne dépasse pas 1km.
12
Figure III.5 : Module XBee Pro série1 [4]
Autre point positif de module, est que son antenne est intégrée et donc ne prend pas de place s’il
est amené à être mis dans un boitier.
Le coût de ce dernier est de l’ordre de 35 $.
Côté réception sur l’ordinateur, la communication sera assurée par une clé XStick qui a le même
rôle qu’un module XBee.
Figure III.6 : Clé XStick
La figure III.6 montre la clé Xstick qui a permis d’établir une communication avec le module
XBee de test. La configuration de cette communication sera assurée par le logiciel X-CTU qui
permettra de configurer le baud rate de chaque composant afin de les faire communiquer.
13
Choix du microcontrôleur
Pour le choix du microcontrôleur, les contraintes à considérer ont été principalement
les protocoles que peut gérer ce dernier. En effet les protocoles à gérer sur le module à concevoir
sont :
- Le protocole I²C (entre le microcontrôleur et les capteurs).
- Le protocole UART (entre microcontrôleur et GPS).
- Le protocole UART (entre microcontrôleur et XBee).
Ainsi, ce microcontrôleur devra avoir deux connexions UART à supporter et une communication
I²C.
Après quelques recherches, le choix a été fait pour le pic18F46K22, qui est un pic couramment
utilisé et qui regroupe les caractéristiques souhaitées.
Figure III.7 : Microcontrôleur (PIC18F46K22) [5]
III.3 Conception
Cette partie détaillera la conception du module incluant le circuit imprimé, le boitier auquel il
sera fixé, ainsi les connexions qui seront reliées au circuit imprimé. Mais avant ça une petite
introduction aux protocoles qui seront utilisés s’impose.
14
III.3. 1 présentation des protocoles
Les deux protocoles à utiliser dans ce projet sont le protocole I²C et l’UART.
I²C (Inter Integrated Circuit): une norme est mise au point par Philips pour les applications
de domotique et d’électronique domestique, il permet de relier facilement à
un microprocesseur différents circuits notamment ceux d’une télévision moderne (récepteur de la
télécommande, réglages des amplificateurs basses fréquences, tuner, horloge, gestion de la
prise péritel, etc.).
Il existe d’innombrables périphériques exploitant ce bus, il est même implémentable par logiciel
dans n’importe quel microcontrôleur. Le poids de l’industrie de l’électronique grand public a
permis des prix très bas grâce aux nombreux composants [6].
Ce protocole utilise seulement deux fils :
- SDA (Serial Data Line): bus des données bidirectionnelles.
- SCL (Serial Clock Line): bus d’horloge.
Vu que l’opération à effectuer sur les capteurs est une opération de lecture, voici à quoi
ressemble une trame de lecture véhiculant à travers le bus SDA.
Figure III.8 : Structure d’une trame de lecture
15
Ainsi, on remarque que la communication est initialisée par un start bit qui donne le signal de
début de communication. Par la suite, il s’agit d’un envoi de données, de la réception d’un accusé
de réception jusqu’à ce que le PEC soit reçu par celui qui a commencé la communication pour
vérifier la validité des données reçues et par la suite clore.
Il est à mentionner que ce type de communication a une topologie de maître à esclave ou bien
comme dans le cas de ce projet d’un maître (le microcontrôleur) à plusieurs esclaves (les
capteurs).
UART (Universal Asynchronous Receiver Transmitter) : protocole basé sur une émission et une
réception asynchrone, les données y circulent bit par bit de l’émetteur vers le récepteur.
Et voici la structure d’une trame UART :
Figure III.9 : Structure d’une trame UART
Ainsi, on remarque que l’état de repos est à 1 logique, dès que li signal tombe à 0 ce passage est
interprété comme un start bit. Cela indique au récepteur de se préparer à recevoir une trame.
Ensuite, il reçoit les bits de données suivies d’un bit de parité. Enfin, le passage du niveau
logique 0 à 1 est interprété comme bit stop pour conclure la communication.
Afin de pouvoir faire communiquer deux composants en utilisant le protocole UART il faut leur
spécifier dès le départ la vitesse avec laquelle ils doivent communiquer. Cette vitesse est appelée
Baud Rate, et elle peut être à des valeurs différentes dont les plus utilisées 9600 baud, 38400
baud ou 57600 baud.
16
III.3.2 Alimentation du circuit imprimé
Avant de commencer la conception du circuit imprimé, il fallait penser à l’alimentation de ce
dernier, ainsi qu’aux modules qui y seront intégrés.
Comme alimentation principale du circuit imprimé, la batterie de la voiture a été considérée
comme source principale. Il s’agit en fait d’une batterie G9 en lithium, cette dernière possède la
qualité d’être légère et ainsi ne surcharge pas trop la voiture de course.
Figure III.10 : Batterie en lithium
Cette batterie peut fournir une tension de 12V et une intensité de 6A/H ce qui est largement
suffisant pour le circuit imprimé.
Vu que les capteurs choisis et le microcontrôleur ont un VDD de 5V donc, il a fallu utiliser un
régulateur de tension de 12 V vers 5V.
Figure III.11 : Régulateur linéaire de tension (REG117A)[7]
17
Cette photo montre le régulateur utilisé à l’entrée de l’alimentation qui fournira une tension de
5V et un courant de 800 mA pour alimenter le pic, les capteurs et un autre régulateur de 5V vers
3.3V.
Ce dernier sera chargé d’alimenter le module GPS ainsi que le module Xbee.
Figure III.12 : Régulateur linéaire de tension (TPS73033)[8]
Le fait de lier ce régulateur à celui à 5V n’est pas dû au hasard, car si on devait le brancher
directement sur l’alimentation de la batterie on aurait eu une chute de tension plus importante et
ça aurait pu causer un dégagement thermique assez important qui aurait pu endommager le
circuit imprimé.
III.3.3 Circuit imprimé
La tâche de conception du circuit imprimé a été réalisée en utilisant le logiciel Altium, qui est
une référence dans le domaine de conception des circuits.
En premier lieu, il a fallu faire la schématique du circuit imprimé et cela inclut :
- Faire la schématique de chaque pièce à part.
- Faire le footprint de chaque module en se basant sur sa fiche technique.
- Prévoir le schéma de branchement de chaque module
- Prévoir les connecteurs externes pour : l’alimentation (12V), ICSP
(programmation du microcontrôleur), GPS, capteurs (embarqués sur la voiture).
18
- Prévoir l’adaptation de niveau entre les modules de voltage différents (exemple :
GPS et microcontrôleur, microcontrôleur et XBee).
Figure III.13 : Schématique du circuit imprimé.
La figure III.13 montre la schématique du circuit imprimé final incluant tous les modules choisis
au début de ce projet.
En deuxième lieu, il a fallu passer à l’étape de réalisation du circuit sur Altium. Cette tâche
consiste à utiliser les footprints de chaque pièce et de les interconnecter. Mais pour pouvoir
réaliser cette dernière, il a fallu préciser les dimensions réelles du circuit imprimé dans le but
qu’il soit embarqué dans un boitier.
Ainsi après quelques recherches le boitier choisi fut le RP1095 de hammond manufacturing.
19
Figure III.14 : Boitier de fixation (RP1095).[9]
La contrainte que devait respecter ce boitier est d’avoir une hauteur assez importante pour
pouvoir supporter le circuit imprimé avec le module GPS monté perpendiculairement.
Figure III.15 : Circuit imprimé envoyé à la fabrication
La figure III.15 montre le circuit imprimé qui a été envoyé à la fabrication avec les dimensions
conformes à celle du boitier choisi.
20
Ainsi, après fabrication et assemblage on a pu obtenir un circuit imprimé comme suit :
Figure III.16 : Circuit imprimé final assemblé.
La figure III.16 montre la disposition des modules sur le circuit imprimé.
Il est visible que la position du module GPS en perpendiculaire au circuit imprimé est due au fait
que ce module, pour avoir une bonne lecture des trames GPS, a besoin d’être orienté vers le ciel.
III.4 Programmation et Test
Après la réalisation du circuit imprimé, la tâche qui s’imposait était de pouvoir programmer le
microcontrôleur afin de pouvoir acquérir la température des capteurs ainsi que les données GPS
et de les envoyer vers le module XBee qui sera chargé de les transmettre à l'ordinateur distant.
Pendant que le circuit imprimé était en fabrication, on a dû utiliser la plaquette de prototypage
fournie par l’Université pour faire nos tests, et ainsi réaliser l’objectif du projet.
21
Figure III.17 : Plaquette de prototypage.
La Figure III.17 montre la maquette de prototypage de l’UQAC munie d’un module XBee, d’un
microcontrôleur et d’un protobobard où est monté un capteur de température.
Sur cette plaquette on remarque l’existence d’une connexion (fils jaune et bleu) entre le capteur
de température et le microcontrôleur dans le but d’acquérir les données du capteur. Ainsi qu’une
autre connexion (fils rouge et noir) entre le microcontrôleur et le module XBee afin d’assurer la
transmission des données.
Une fois la communication UART fonctionnelle, on a commencé à tester les capteurs de
températures. Dans un premier temps, il fallait attribuer une adresse différente à chaque capteur.
Cette adresse se trouve dans la mémoire EEPROM de chaque capteur dans le registre 00EH
(l’adresse par défaut étant 0x5A).
Dans un deuxième temps, il fallait lire la température de l’objet pointé par le capteur dans le
registre 0x07 de la mémoire RAM.
22
Une fois ses paramètres réglés voici le diagramme de flux du programme élaboré en assembleur :
Figure III.18 : Diagramme de flux pour la lecture de la température
La figure III.18 montre le diagramme de flux pour la réception des données de températures.
Ainsi, le maitre envoie un start bit à l’esclave pour commencer la communication accompagnée
de l’adresse de celui-ci et de l’opération à effectuer.
Suivant la réponse de l’esclave le maitre va soit continuer d’envoyer la commande soit reprendre
la communication dès le départ.
Après l’identification de l’esclave, le maître attend ses données et envois des accusés de
réception au fur et à mesure qu’il reçoit les données. Une fois le PEC (Packet Error Checking)
reçu, le maitre vérifie l’exactitude des données reçues si conforme à celles envoyées, envoyer un
accusé et arrêter si ce n’est pas le cas reprendre la transmission.
23
Concernant la programmation au niveau du module GPS voici le diagramme de flux associé :
Figure III.19 : Diagramme de flux de la communication GPS
Le principe de ce programme est qu’il reçoit une trame NMEA (National Marine Electronics
Association), et il la traite.
En parcourant la trame, il essaie de trouver les trames de type GGA ou RMC.
En effet, ces dernières sont très courantes, car elles font parties de celles qui sont utilisées pour
connaître la position courante du récepteur GPS [2].
Si la trame reçue contient l’une des deux chaines précédentes, on la prend sinon on passe à la
trame suivante.
Une fois que la trame est bonne on essai de connaître les champs longitude et latitude pour
pouvoir calculer la position exacte de la voiture. Aussi d’autres paramètres peuvent être lus dans
ces deux trames à savoir la date, l’heure, le nombre de satellites utilisés pour calculer la
position…
24
III.5 Réalisations
Au cours de la programmation du microcontrôleur, des difficultés ont été rencontrées.
En effet, il a fallu implémenter tout le protocole I²C mais cela ne donnait pas de résultats
satisfaisants. Le changement d’adresse se faisait très bien pour chaque capteur, mais l’opération
de lecture ne retournait rien.
Ainsi par manque de temps, on s’est orienté vers un microcontrôleur atmega328 sur une
plateforme ARDUINO.
La raison de ce changement est que sur ARDUINO le protocole I²C est implémenté et une
bibliothèque est fournie. Ce changement a facilité le travail, car l’utilisation des fonctions était
facile.
Ainsi, des modifications ont été apportées au circuit imprimé comme le montre la figure
suivante :
Figure III.20 : Circuit imprimé modifié.
25
On remarque d’après la figure qu’un microcontrôleur Atmega328 a été introduit à la place du
PIC18F46k22. Et cela a été effectué en respectant les branchements des autres modules.
Ainsi, la concordance des pins entre PIC et Atmega328 est la suivante :
Figure III.21 Analogie connexion Pic et Arduino
Voici un aperçu du code ARDUINO utilisé pour effectuer une opération de lecture sur les trois
capteurs :
Figure III.22 : Code ARDUINO utilisé
26
Ce code effectue une opération de lecture sur chacun des capteurs puis se charge d’établir une
connexion série avec le port COM adéquat pour la transmission via module XBEE vers
l’ordinateur.
Figure III.23 : Lecture de la température sur les 3 capteurs.
La figure précédente montre l’opération de lecture effectuée sur les capteurs de températures.
27
Et voici la figure qui montre les données réceptionnées par l’ordinateur :
Figure III.24 : Données reçues par l’ordinateur
On remarque que les données reçues par l’ordinateur sont sous forme hexadécimale, il a fallu
modifier leur structure en introduisant des points virgules entre chaque valeur pour faciliter leur
envoi à un fichier EXCEL où ils seront traités.
Figure III.25 : Résultat final.
28
D’après la figure précédente on remarque le résultat final obtenu.
En effet, on a pu recevoir les données hexadécimales (A : Capteur1 ; B : Capteur2; C :
Capteur3), puis une opération de conversion en données décimale a été effectuée pour enfin
fournir les graphiques montrant la variation de la température enregistrée sur les 3 capteurs.
Il est à mentionner que les valeurs de températures obtenues sont le résultat d’une expérience
faite en passant un objet avec une température différente.
Cela sera fonctionnel sur la voiture à partir du moment où cette dernière sera réassemblée.
Figure III.26 : Module assemblé sur la voiture.
Aussi, un support a été conçu par les membres de la formule SAE dans le but d’y fixer les
capteurs au dessus de la roue. Ce dernier a été soudé sur l’axe de la roue comme on peut le
remarquer sur la figure qui suit :
29
Figure III.27 : Support des capteurs.
30
IV Bilan des activités
IV.1 Arrimage formation pratique/universitaire
Les deux principaux domaines touchés par ce projet sont d’une part le domaine électrique à
travers l’étude des pièces électroniques utilisées (fiches techniques) ainsi que la conception du
circuit imprimé principal, qui constitue la pièce maîtresse de ce projet et d’autre part le domaine
informatique à travers la programmation du microcontrôleur et de la réception des données sur
l’ordinateur.
Les connaissances acquises tout au long de mon parcours universitaire m’ont permis de mener à
terme ce projet. Grâce à la qualité de l’enseignement des professeurs de l’Université, j’ai pu être
en mesure de réaliser le travail demandé.
Chaque cours que j’ai suivi, au cours de ma formation à l’UQAC, m’a été d’une grande utilité.
La formation des étudiants en Baccalauréat en génie informatique est très complète, en effet elle
met l’accent sur tous les aspects nécessaires à la réalisation d’un projet qui touche plusieurs
domaines à la fois.
Voici quelques cours qui ont permis de mener à bien le projet :
- 6GEN525 Architectures des ordinateurs : ce cours a contribué largement à
acquérir les connaissances nécessaires à la programmation du microcontrôleur.
- 6GEI542 Interfaces et instrumentations : ce cours a permis de savoir lire une fiche
technique d’un composant électronique et choisir l’information pertinente à
utiliser.
- 6GIN333 Conceptions ingénierie : ce cours m’a permis d’approfondir mes
connaissances en termes de conception de circuit imprimé en utilisant le logiciel
Altium, en effet c’est avec ce dernier que la conception du circuit imprimé a été
effectuée.
31
- 6GEI300 Électronique 1 : en effet les connaissances concernant les diodes
acquises durant ce cours m’ont permis de savoir les utiliser dans ma conception de
PCB.
Vu que l’enseignement reçu est diversifié, il ne faut pas se limiter à la formation universitaire : il
faudra toujours essayer de maintenir ses connaissances à jour.
IV.2 Travail d’équipe
Lors de ce projet, un travail d’équipe a été effectué en premier lieu avec les membres de la
formule SAE. En effet il a fallu comprendre différents aspects concernant la voiture telle que les
dimensions des pneus (pour espacer les capteurs), les caractéristiques de la batterie utilisée (pour
savoir la tension et le courant qui seront appliqués au circuit imprimé), et les températures que
peuvent atteindre les pneus. Tous ces aspects ont été abordés suite à des rencontres avec Jean-
Michel NERON (président de la formule SAE) et expliqués.
À un autre niveau, une collaboration avec Jean Rock Duchesne a eu lieu concernant tout d’abord
le choix du module de transmission GPS car il fallait que ce dernier soit compatible avec les
autres modules du circuit imprimé (en termes d’alimentation et de communication entre
modules).
Ensuite, une collaboration au niveau de l’intégration des codes (acquisition des données GPS et
données de températures) a permis de réaliser un code homogène capable de réaliser l’objectif
attendu.
Ainsi, ce projet a constitué une bonne expérience en termes de travail d’équipe, car malgré les
différences d’horaires de cours et le niveau de formation, un travail satisfaisant a été réalisé, et
cela a permis de surmonter les difficultés rencontrées.
32
IV.3 Respect de l’échéancier
Voici l’échéancier du projet :
Figure IV.1: Échéancier initial du projet
33
Il est à mentionner qu’au départ du projet les tâches ont été effectuées dans leurs délais, et ainsi
l’échéancier a été respecté. Mais arrivé au niveau de la tâche de conception du PCB on a constaté
du retard, vu la délicatesse de cette tâche. En effet cette tâche est considérée comme la plus
importante du projet, car elle se traduit en la conception de la pièce maitresse qui sera en charge
d’acquérir les données puis de les transmettre à l’ordinateur.
Par la suite, ce délai supplémentaire a entrainé un autre retard dans la réalisation de la tâche de
programmation du microcontrôleur. Ces retards accumulés ont empêché la réalisation du projet à
temps. Mais cela n’empêche pas qu’on soit arrivé à un résultat satisfaisant, concernant la lecture
des données de température, et avec un peu plus de temps l’objectif principal du projet sera
atteint.
IV.4 Analyse et discussion
L’une des premières tâches dans ce projet a été de mettre au point un échéancier. Ce dernier
devait s’étaler sur une période de 4 mois. Au départ, l’échéancier a été respecté sans aucun
problème, mais arrivé au niveau de la tâche de conception quelques retards ont eu lieu au niveau
de la fabrication.
En effet, il fallait synchroniser l’envoi des circuits imprimés de toutes les équipes en même
temps. Par la suite, au niveau du fabricant, il y’a eu des retards, car certains circuits imprimés
présentaient des problèmes au niveau du respect des règles de conception imposées par le
fabricant.
Ce retard n’a pas trop influencé l’avancement du projet, car d’autres tâches étaient effectuées
pendant la fabrication.
L’une de ces tâches est la programmation sur le microcontrôleur qui s’annonçait comme une
tâche facile et qui ne le fut pas. Car, en assembleur il a fallu implémenter la communication sur
un Bus I²C et il fallait prendre en considération tous les changements d’état sur le bus SDA.
Ainsi, un code, qui respecte le format des données, a été implémenté, mais qui n’arrivait pas à
réaliser la lecture adéquatement.
Dans le souci d’avoir un code fonctionnel, on s’est orienté vers la plateforme ARDUINO qui
fournissait une bibliothèque déjà implémentée, et le résultat fut satisfaisant.
Ainsi, le temps a joué un rôle important dans la réalisation de ce projet, car avec un peu plus de
temps le code assembleur aurait pu être débogué et l’erreur aurait pu être trouvée.
34
Mais cela n’empêche qu’avec l’ARDUINO on a obtenu un résultat satisfaisant.
Cela nous a appris la délicatesse de la tâche d’intégration et l’importance de l’opération du choix
des composantes qui doit être faite en prenant en considération le facteur temps.
35
VII Conclusion et recommandations
À travers ce rapport, on a pu démontrer que le projet s’est bien déroulé dans l’ensemble malgré
quelques retards. En effet, la tâche choix des composantes a été réalisée avec soin vu sa
délicatesse. Chaque composant à choisir devait satisfaire des contraintes imposées par la nature
du projet : les capteurs de température (à infrarouges, une bonne résolution, un faible coût,
détection des températures élevées), le module GPS (une bonne vitesse de rafraichissement), le
module XBee (couvrir une grande distance) et le microcontrôleur (supporter les protocoles de
communications à utiliser).
Par la suite, la tâche conception du circuit imprimé a été réalisée avec un grand soin vu tous les
aspects à prendre en considération. On cite, l’alimentation de chaque module (un régulateur de
12V 5V et un autre de 5V3.3V), les connexions entre les modules (sans oublier l’adaptation
de niveau entre deux modules de tensions d’alimentation différentes) et les dimensions du circuit
imprimé qui devait être embarqué dans un boitier pour sa protection une fois fixés sur la voiture
de course.
Ensuite, la tâche de programmation a été effectuée en premier lieu sur le microcontrôleur choisi
au départ de ce projet. Mais, vu que le résultat obtenu pour la température n’était pas assez
satisfaisant, on s’est orienté vers le module ARDUINO et ainsi de bons résultats ont été obtenus.
Mais cela n’empêche pas que la programmation en assembleur peut être améliorée et avec un peu
plus de temps on pourrait arriver au résultat voulu avec le microcontrôleur.
Ainsi, après les modifications apportées en utilisant l’ARDUINO, l’objectif principal du projet a
été atteint en réalisant un module fonctionnel capable de lire la température des pneus et de les
envoyer à un ordinateur distant dans le but de les analyser. Ce projet contribuera dorénavant à
calibrer la suspension de la voiture de course.
Dans le cadre des recommandations, on peut citer le fait qu’utiliser un module ARDUINO s’est
avéré une tâche assez facile, que si elle avait été faite comme choix principal aurait permis de
sauver beaucoup de temps en terme de programmation. Et cela a contribué à montrer
36
l’importance de la tâche de choix des composantes qui doit prendre en considération la difficulté
d’utiliser un module plutôt qu’un autre.
Mais cela n’empêche pas que le travail peut être fait avec le microcontrôleur en ayant bien sûr
plus de temps.
Autre point à améliorer est la réception des données à travers une interface. Dans un projet futur,
une interface logicielle pourrait être implémentée et ainsi permettrait d’interpréter ces résultats
différemment. Par exemple, une interface pourrait dessiner le parcours de la voiture lors de la
course et en pointant avec le curseur à un endroit bien précis la température à ce point sera
fournie. D’autres graphiques pourront être produits dans le but de mieux analyser le
comportement de la suspension lors d’une course.
Aussi, une amélioration au module pourra être effectuée en introduisant des données de vitesse et
d’accélération, ce qui permettra de mieux calibrer la suspension des pneus.
37
Bibliographie
[1] : www.Melexis.com
[2] :http://www.digikey.ca/product-detail/en/MLX90614ESF-BAA-000-TU/MLX90614ESF-
BAA-000-TU-ND/1647941
[3] : http://www.locosystech.com/
[4] : http://www.digikey.ca/product-detail/en/XBP24-AUI-001/XBP24-AUI-001-ND/935970
[5] : http://www.digikey.ca/product-detail/en/PIC18F46K22-I%2FPT/PIC18F46K22-I%2FPT-
ND/2480377
[6] : http://fr.wikipedia.org/wiki/I2C
[7] : http://www.digikey.ca/product-detail/en/REG1117A/REG1117A-ND/254749
[8] : http://www.digikey.ca/product-detail/en/TPS73033DBVR/296-17580-1-ND/705377
[9] : http://www.hammondmfg.com/pdf/RP1095.pdf
38
ANNEXES Code assembleur implémenté :
List p=18F46K22, R=DEC, F=INHX16
#include <P18F46K22.INC>
#include <boot.inc>
#include <config.inc>
#include <GPRs.inc>
#include <macros.inc>
UDATA 0XF0
SlaveAddress res 1
command res 1
DataH res 1
DataL res 1
RX_buffer res 1
TX_buffer res 1
counterU res 1 ;|
counterH res 1 ; > Registers used in delay subroutines
counterL res 1 ;|
Code
ORG 0x00
Goto MAIN
MAIN
CALL MCUinit
CALL Init_UART
clrf WREG
MOVLW SA<<1 ; Put SA in the upper 7 bits
MOVWF SlaveAddress ; Set SMBus Address
BSF SlaveAddress,0
39
MOVLW RAM_Tobj1|RAM_Access ; Form RAM access command + RAM address
MOVWF command ; Load the command register
CALL delay_200ms ; Wait after POR,Tvalid=0.15s
; See the datasheet of
MLX90614
ReadLoop
CALL MemRead ; Read RAM address
CALL delay_200ms ;|
CALL delay_200ms ; > Wait before next measurement
CALL delay_200ms ;|
; MOVFF SA,TXREG1
;CALL delay_200ms
;MOVFF SlaveAddress,TXREG1
;CALL delay_200ms
; MOVFF command,TXREG1
;CALL delay_200ms
;MOVFF SlaveAddress,TXREG1
; CALL delay_200ms
;CALL delay_200ms
movff DataH,TXREG1 ;get the data and transmit
movff PEC, TXREG1
infini
BRA infini
BRA ReadLoop ; Read again
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
MCUinit:
;Set all I/O as digital
MOVLW B'00001111'
MOVWF ADCON1 ; All channels are digital I/O
;----------------------------------------------------------------------------------------------
;SMBus_init
VddUON
_SCL_HIGH ; The bus is in idle state
_SDA_HIGH ; SDA and SCL are in high level from pull up resistors
;----------------------------------------------------------------------------------------------
40
RETURN
Init_UART:
bcf BAUDCON1,BRG16
BSF TRISC,7
BCF TRISC,6
;---Configure SPBRG for desired baud rate
movlw D'162' ;set baud rate 25 MHz
movwf SPBRG1
MOVLW B'10000000' ;Enable serial port
MOVWF RCSTA1 ;Receive status reg
;---Configure TXSTA
MOVLW B'00100100' ;Configure TXSTA as :
MOVWF TXSTA1 ;
;8 bit transmission - 6.bit
;Transmit enabled - 5.bit
;Asynchronous mode - 4.bit
;Enable high speed baud rate - 2.bit
return
;Name: delay
;Function: Produces time delay depending on the value in counterL
;Input: WREG
;Output: No
;Comments:
”
;************************************************************************************
************************
delay
MOVWF counterL ;WREG -> counterL
DECFSZ counterL,f ;If (counerL=counterL-1) =0 go out
BRA $-2 ;else decrement counterL again
RETURN ;End of “delay”
delay_200ms ;Fcpu=25.000MHz
MOVLW d'9'
MOVWF counterU
MOVLW d'10'
MOVWF counterH
MOVLW d'256'
MOVWF counterL
DECFSZ counterL,F
BRA $-2
DECFSZ counterH,F
41
BRA $-d'10'
DECFSZ counterU,F
BRA $-d'18'
RETURN
;Output: DataH:DataL
;Comments: Refer to AN "SMBus communication with MLX90614"
; If receiver doesn’t answer with ACK, the number of the attempts to be send will
be
; equal of the unsigned value in Nack_Counter-1
;************************************************************************************
**********
MemRead
LoadNACKcounter ; Set Nack_Counter
restart
CALL STOP_bit ; STOP SMBus communication
DECF Nack_Counter,F ; If((Nack_Counter-1) == 0) stop transmission
BNZ start ; Else start transmission
RETURN ; Go out
start
CALL START_bit ; Start SMBus comunication
MOVF SlaveAddress,W ;|
MOVWF TX_buffer ; > Send Slave address(Bit R/-W no meaning)
CALL TX_byte ;|
ANDLW 0x01 ; W & 0x01 -> W
BTFSS STATUS,Z ; If Slave acknowledge,continue
GOTO restart ; Else restart communication
; MOVLW 0x01
; MOVWF TXREG1
MOVF command,W ;|
MOVWF TX_buffer ; > Send Command
CALL TX_byte ;|
ANDLW 0x01 ; W & 0x01 -> W
BTFSS STATUS,Z ; If Slave acknowledge,continue
GOTO restart ; Else restart communication
; call delay_200ms
; MOVLW 0x02
; MOVWF TXREG1
CALL START_bit ; Send Repeated START bit
MOVF SlaveAddress,W ;|
42
MOVWF TX_buffer ; > Send Slave address again(Bit R/-W no
meaning)
CALL TX_byte ;|
ANDLW 0x01 ; W & 0x01 -> W
BTFSS STATUS,Z ; If Slave acknowledge,continue
GOTO restart ; Else restart communication
; MOVLW 0x03
; MOVWF TXREG1
; CALL delay_200ms
BCF bit_out ; Master must send acknowledge after this
received byte
CALL RX_byte ; Receive low data byte
MOVFF RX_buffer,DataL ; Save it in DataL
;MOVFF DataL, TXREG1
BCF bit_out ; Master must send acknowledge after this
received byte
CALL RX_byte ; Receive high data byte
MOVFF RX_buffer,DataH ; Save it in DataH
BSF bit_out ; Master not need to send acknowledge after this
received byte
CALL RX_byte ; Receive PEC byte
MOVFF RX_buffer,PecReg ; Save it in PecReg
; MOVFF PecReg,TXREG1
BSF bit_out ; Master not need to send acknowledge
CALL STOP_bit ; Stop SMBus comunication
MOVF SlaveAddress,W ;|
MOVWF PEC4 ;|
MOVFF command,PEC3 ;|
MOVF SlaveAddress,W ; > Load PEC3:PEC2:PEC1:PEC0:PEC
MOVWF PEC2 ;|
MOVFF DataL,PEC1 ;|
MOVFF DataH,PEC0 ;|
CLRF PEC ;|
CALL PEC_calculation ; Result is in PEC
MOVF PecReg,W ; PecReg -> WREG
XORWF PEC,W ; PEC xor WREG ->WREG
BTFSS STATUS,Z ; If PEC=PecReg go out
43
GOTO restart ; Else repeat all transmission
; call delay_200ms
; MOVLW 0x04
; MOVWF TXREG1
RETURN
;************************************************************************************
**********
;Name: START_bit
;Function: Generate START condition on SMBus
;Input: No
;Output: No
;Comments: Refer to "System Managment BUS(SMBus) specification Version 2.0" and
; AN "SMBus communication with MLX90614"
;************************************************************************************
**********
START_bit
_SDA_HIGH ;Set SDA line
MOVLW TBUF ;Wait a few us
CALL delay ;
_SCL_HIGH ;Set SCL line
MOVLW TBUF ;Generate bus free time between Stop
CALL delay ;and Start condition (Tbuf=4.7us min)
_SDA_LOW ;Clear SDA line
MOVLW TBUF ;Hold time after (Repeated) Start
CALL delay ;Condition. After this period, the first clock is generated.
;(Thd:sta=4.0us min)
_SCL_LOW ;Clear SCL line
MOVLW TBUF ;
CALL delay ;Wait
RETURN
;************************************************************************************
**********
; STOP CONDITION ON
SMBus
;************************************************************************************
**********
;Name: STOPbit
;Function: Generate STOP condition on SMBus
;Input: No
;Output: No
;Comments: Refer to "System Managment BUS(SMBus) specification Version 2.0" and
44
; AN "SMBus communication with MLX90614"
;************************************************************************************
**********
STOP_bit
_SCL_LOW ;Clear SCL line
MOVLW TBUF ;Wait a few microseconds
CALL delay ;
_SDA_LOW ;Clear SDA line
MOVLW TBUF ;
CALL delay ;Wait
_SCL_HIGH ;Set SCL line
MOVLW TBUF ;Stop condition setup time
CALL delay ;(Tsu:sto=4.0us min)
_SDA_HIGH ;Set SDA line
RETURN
;************************************************************************************
**********
; TRANSMIT DATA ON SMBus
;************************************************************************************
**********
;Name: TX_byte
;Function: Send a byte on SMBus
;Input: TX_buffer
;Output: WREG - contains acknowledge value, 0 for ACK and 1 for NACK
;Comments:
;************************************************************************************
**********
TX_byte
MOVWF TX_buffer
MOVLW D'8'
MOVWF Bit_counter ; Load Bit_counter
tx_loop
BCF bit_out ; 0 -> bit_out
RLCF TX_buffer,F ; Tx_buffer<MSb> -> C
BTFSC STATUS,C ; C is 0 or 1? If C=0 don’t set bit_out
BSF bit_out ; 1 -> bit_out
CALL Send_bit ; Send bit_out on SDA line
DECFSZ Bit_counter,F ; All 8th bits are sent? If not, send next bit ,else check for
; acknowledgement from the receiver
GOTO tx_loop ; Send next bit
CALL Receive_bit ; Check for acknowledgement from the receiver
BTFSS bit_in ; Receiver send ACK?
RETLW 0 ; Yes,return 0
RETLW 1 ; No ,return 1
;----------------------------------------------------------------------------------------------
Send_bit
45
BTFSC bit_out ;|
GOTO bit_high ;|
_SDA_LOW ;|
GOTO clock ; > Send bit on SDA line
bit_high ;|
_SDA_HIGH ;|
NOP ;|
clock
_SCL_HIGH ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ; > Send clock pulse
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
_SCL_LOW ;|
NOP ;|
NOP ;|
RETURN
;************************************************************************************
**********
;
;************************************************************************************
**********
;Name: RX_byte
;Function: Receive a byte on SMBus
;Input: No
;Output: RX_buffer(Received byte),bit_in(acknowledge bit)
;Comments:
;************************************************************************************
**********
RX_byte
CLRF RX_buffer ;Clear the receiving buffer
MOVLW D'8'
MOVWF Bit_counter ;Load Bit_counter
BCF STATUS,C ;C=0
RX_again
RLCF RX_buffer,F ;RX_buffer< MSb> -> C
CALL Receive_bit ;Check bit on SDA line
BTFSC bit_in ;If received bit is ‘1’ set RX_buffer<LSb>
BSF RX_buffer,0 ;Set RX_buffer<LSb>
DECFSZ Bit_counter,F ;ALL 8th bis are received? If no receive next bit
GOTO RX_again ;Receive next bit
CALL Send_bit ;Send NACK or ACK
RETURN ;End of “RX_byte”
;----------------------------------------------------------------------------------------------
46
Receive_bit
BSF bit_in ;Set bit_in
BSF _SDA_IO ;Make SDA-input
_SCL_HIGH ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ; > Send 9th clock and check for acknowledge
from Slave
NOP ;|
NOP ;|
NOP ;|
NOP ;|
NOP ;|
BTFSS _SDA ;|
BCF bit_in ;|
_SCL_LOW ;|
NOP ;|
NOP ;|
RETURN ;Bit is received
;----------------------------------------------------------------------------------------------
;************************************************************************************
**********
; CALCULATION PEC PACKET
;************************************************************************************
**********
;Name: PEC_calculation
;Function: Calculates the PEC of received bytes
;Input: PEC4:PEC3:PEC2:PEC1:PEC0:PEC- data registers
; CRC4:CRC3:CRC2:CRC1:CRC0:CRC- CRC value=00000107h
;Output: PEC
;************************************************************************************
**********
PEC_calculation
MOVLW 0x07 ;|
MOVWF CRC ;|
MOVLW 0x01 ;|
MOVWF CRC0 ;|
CLRF CRC1 ; > Load crc value 0x0107
CLRF CRC2 ;|
CLRF CRC3 ;|
CLRF CRC4 ;|
MOVLW d'47' ;
MOVWF BitPosition ; 6bytes*8bits=48bits(MSb=47)
;check PEC4 for '1'
47
BTFSC PEC4,7
BRA shift_CRC
DECF BitPosition
BTFSC PEC4,6
BRA shift_CRC
DECF BitPosition
BTFSC PEC4,5
BRA shift_CRC
DECF BitPosition
BTFSC PEC4,4
BRA shift_CRC
DECF BitPosition
BTFSC PEC4,3
BRA shift_CRC
DECF BitPosition
BTFSC PEC4,2
BRA shift_CRC
DECF BitPosition
BTFSC PEC4,1
BRA shift_CRC
DECF BitPosition
BTFSC PEC4,0
BRA shift_CRC
;check PEC3 for '1'
DECF BitPosition
BTFSC PEC3,7
BRA shift_CRC
DECF BitPosition
BTFSC PEC3,6
BRA shift_CRC
DECF BitPosition
BTFSC PEC3,5
BRA shift_CRC
DECF BitPosition
BTFSC PEC3,4
BRA shift_CRC
DECF BitPosition
BTFSC PEC3,3
BRA shift_CRC
DECF BitPosition
BTFSC PEC3,2
BRA shift_CRC
DECF BitPosition
BTFSC PEC3,1
BRA shift_CRC
DECF BitPosition
BTFSC PEC3,0
BRA shift_CRC
;check PEC2 for '1'
DECF BitPosition
BTFSC PEC2,7
48
BRA shift_CRC
DECF BitPosition
BTFSC PEC2,6
BRA shift_CRC
DECF BitPosition
BTFSC PEC2,5
BRA shift_CRC
DECF BitPosition
BTFSC PEC2,4
BRA shift_CRC
DECF BitPosition
BTFSC PEC2,3
BRA shift_CRC
DECF BitPosition
BTFSC PEC2,2
BRA shift_CRC
DECF BitPosition
BTFSC PEC2,1
BRA shift_CRC
DECF BitPosition
BTFSC PEC2,0
BRA shift_CRC
;check PEC1 for '1'
DECF BitPosition
BTFSC PEC1,7
BRA shift_CRC
DECF BitPosition
BTFSC PEC1,6
BRA shift_CRC
DECF BitPosition
BTFSC PEC1,5
BRA shift_CRC
DECF BitPosition
BTFSC PEC1,4
BRA shift_CRC
DECF BitPosition
BTFSC PEC1,3
BRA shift_CRC
DECF BitPosition
BTFSC PEC1,2
BRA shift_CRC
DECF BitPosition
BTFSC PEC1,1
BRA shift_CRC
DECF BitPosition
BTFSC PEC1,0
BRA shift_CRC
;check PEC0 for '1'
DECF BitPosition
BTFSC PEC0,7
49
BRA shift_CRC
DECF BitPosition
BTFSC PEC0,6
BRA shift_CRC
DECF BitPosition
BTFSC PEC0,5
BRA shift_CRC
DECF BitPosition
BTFSC PEC0,4
BRA shift_CRC
DECF BitPosition
BTFSC PEC0,3
BRA shift_CRC
DECF BitPosition
BTFSC PEC0,2
BRA shift_CRC
DECF BitPosition
BTFSC PEC0,1
BRA shift_CRC
DECF BitPosition
BTFSC PEC0,0
BRA shift_CRC
CLRF PEC4
CLRF PEC3
CLRF PEC2
CLRF PEC1
CLRF PEC0
RETURN
shift_CRC
MOVLW d'8'
SUBWF BitPosition,W ;BitPosition-8 ->W
MOVWF shift ;get shift value for CRC registers
BCF STATUS,C
shift_loop
MOVF shift,F ;read shift to force flag Z
BZ xor
RLCF CRC,F
RLCF CRC0,F
RLCF CRC1,F
RLCF CRC2,F
RLCF CRC3,F
RLCF CRC4,F
DECFSZ shift,F
BRA shift_loop
xor
MOVF CRC4,W
XORWF PEC4,F
MOVF CRC3,W
XORWF PEC3,F
50
MOVF CRC2,W
XORWF PEC2,F
MOVF CRC1,W
XORWF PEC1,F
MOVF CRC0,W
XORWF PEC0,F
MOVF CRC,W
XORWF PEC,F
BRA PEC_calculation
END