Frequencies of Musical Notes

Best François
Bounaix François
Groupe C-3
Projet d’Atelier :
Inclinomètre à base d’accéléromètre
1
Encadrant : Lionel Bastard
Année : 2007-2008
Plan du compte rendu :
Introduction :
Rappel sur le cahier des charges
Principes physiques mis en oeuvres
I) Etude théorique détaillée
1) Partie analogique
a) L’alimentation
b) Le traitement analogique du signal
c) Le convertisseur Analogique/Numérique
d) Le bit de signe analogique
2) Partie numérique
a) La programmation du FPGA
b) L’affichage
II) Réalisation et mesure
1) Réalisation du PCB
2) Partie analogique
a) L’alimentation
b) Le traitement analogique du signal
c) L’influence de la température sur l’accéléromètre
d) Le convertisseur Analogique/Numérique
e) Le bit de signe analogique
3) Partie numérique
a) La programmation du FPGA
b) L’affichage
Conclusion :
Bilan sur les fonctions du cahier des charges et le prototype mis en place.
Les limites de notre inclinomètre.
2
Introduction :
Ce compte rendu à pour but d’expliquer la démarche mise en œuvre pour réaliser le système
choisis à partir de la documentation fournis et des connaissances personnelles.
Le sujet que nous avons choisi est l’inclinomètre à base d’accéléromètre et nous avons décidé
de prendre de la distance par rapport à la documentation fournie (Article paru dans Elektor en
novembre 1999). Ainsi le système en place est assez différent du système original de manière
à s’adapter au cahier des charges. Nous avons décidé de nous orienter vers un inclinomètre
mesurant les angles inférieurs à 5 ou 6 degrés qui sont difficiles à estimer à l’œil nu.
Dans cette partie introductive nous allons brièvement rappeler le cahier des charges, ainsi que
les principes physiques mis en jeux pour faire fonctionner notre inclinomètre.
Comment transformer un accéléromètre en inclinomètre ?
Le principe physique est assez simple ; comme le montre le schéma suivant, l’accéléromètre
ne peut mesurer une accélération que sur un axe de mesure, lorsque l’on incline le composant
celui-ci va donc mesurer la projection de l’accélération terrestre sur son axe de mesure et non
la pesanteur réelle. C’est ainsi qu’avec une formule assez simple nous pouvons retrouver
l’angle d’inclinaison du composant par rapport à la verticale :
sin ! = g / gprojeté
De plus pour des angles ! petits (! < 15 °) nous pouvons considérer l’approximation
sin ! " ! , ce qui simplifiera encore la relation.
Il reste maintenant à voir comment mettre en place ce principe pour notre système et c’est ce
que nous verrons dans la première partie.
Passons maintenant aux rappels concernant le cahier des charges.
Rappel du cahier des charges :
Grâce à une analyse fonctionnelle nous décomposons notre système en 7 sous systèmes dont
nous allons donner les attentes. Les 7 sous systèmes sont :
- l’accéléromètre
- le traitement du signal
- le convertisseur analogique numérique (CAN)
- la conversion Binaire pur en Binaire Codé Décimal (BCD)
- le traitement numérique et l’affichage (FPGA)
- l’affichage du bit de signe (entièrement analogique)
- l’alimentation
3
Le schéma suivant donne l’organisation de ces différents blocs :
On va donc maintenant donner les attentes pour chaque bloc fonctionnel en gardant en tête
que notre inclinomètre doit au final rester dans une mesure d’angles relativement petits.
Les attentes serons très concrètes et ont été définies par nos soins :
- Plage des angles de mesure : +/- 6,4 °
En effet à plus ou moins cinq degrés l’erreur d’angle est visible à l’œil nu et il n’est donc
pas nécessaire d’utiliser le niveau pour s’apercevoir du fait que l’objet à mesurer n’est pas
parfaitement à plat.
- Précision avec un convertisseur analogique/numérique (CAN) 8 bit : 0,05 ° soit 3’.
Nous fixons la précision à 3’ en compromis entre une plage de mesure suffisante et une
précision maximale. Mais aussi sachant que nous avons à notre disposition un CAN 8 bits
et donc pour que le pas du niveau tombe sur un chiffre « rond » pour facilité son utilisation.
- Alimentation 5V
Comme il est possible d’utiliser tous les composants avec une tension d’alimentation de 5V,
nous avons choisi pour plus de simplification d’alimenter tous les composant en 5V directement. De plus une version fonctionnant sur batterie rechargeable sera plus facile à concevoir. Il est bon de remarquer cependant la nécessité d’une référence VREF/2 (donc ici 2,5V)
pour le CAN.
- Affichage 3 digits plus un digit de signe (afficheur 4 digits) :
D’après la précision du CAN (8 bits soit 256 valeurs) nous somme en mesure d’afficher 3
digits dont le digit de poids faible à 0 ou a 5, la présentation ce fera sous la forme
|+|0|,|0|0| °
- Compensation en température (capteur interne + contre-réaction) :
Le capteur d’accélération étant très sensible à la température nous allons grâce au capteur
de température intégré de l’accéléromètre compenser les erreurs dues à la température.
4
- Mise en forme du signal et protection du CAN :
Amplification du signal fourni par l’accéléromètre (250mv/g) à l’aide de l’amplificateur
intégré mais aussi grâce à des amplificateurs opérationnels (AOP), compensation en température, réglage du zéro et protection du CAN en n’utilisant que des amplificateurs saturant à
5V.
- Gestion de l’affichage et données provenant du CAN par un FPGA.
- Une interface utilisateur simple comprenant un interrupteur de mise en route (type switch),
un bouton poussoir de test de l’afficheur (type momentary), un potentiomètre permettant
de faire le zéro et une LED indiquant que l’appareil est sous tension.
I) Etude théorique détaillée
Chaque grande partie sera divisée en deux sous partie. L’une traitant la partie analogique de
notre système et l’autre détaillant la partie numérique.
1) Partie Analogique
a) L’alimentation
Nous allons commencer par étudier le circuit d’alimentation qui est le plus simple. En considérant que nous avons une source 5V à notre disposition, nous avons le schéma suivant :
Les condensateurs C6 à C9 permettent de protéger les éléments alimentés de possibles ondulation du signal d’alimentation. Nous effectuons ensuite une conversion 5V / 2,5V grâce à un
pont diviseur de tension qui nous permet d’obtenir une tension de référence Vref/2. Le choix
de la méthode du diviseur de tension est justifié par le fait que la tension Vref/2 ne sera pas
une véritable alimentation mais une référence et il n’y aura donc pas passage d’un fort courant.
5
b) Traitement du signal analogique
Cette partie du montage permet d’avoir un signal en adéquation avec le cahier des charges à
l’entrée du CAN, pour ce faire nous allons définir la chaîne d’action donnée par le schéma
suivant puis voir sa réalisation :
- La préamplification : elle permet d’obtenir un signal d’accélération du même ordre de grandeur que les autre signaux arrivant dans le sommateur, elle est réalisée à partir de l’amplificateur intégré de l’accéléromètre, et sert aussi de filtre passe bas pour éliminer le bruit provenant de l’accéléromètre (Bande passante à -3 dB : 0 à 8Hz). Le schéma suivant donne sa réalisation pratique :
Nous avons alors la relation suivante : Vout= 4*Vin
A noter que le zéro correspond à une tension de 2,5V, ainsi nous assurons le bon fonctionnement de l’accéléromètre car nous ne pouvons pas l’alimenter en négatif. Nous utilisons donc
ici la méthode de masse fictive.
- Le traitement du signal sortant du capteur de température est à peu près identique à celui de
la préamplification nous utilisons un ampli opérationnel (AOP) avec un montage amplificateur non inverseur dont on peut ajuster le coefficient à l’aide d’une résistance variable.
6
La relation entrée/sortie sera donc :
Vs = ( 1 + k / 10^4 )*Ve
- Le montage permettant le réglage du zéro (situé tout en haut sur le schéma fonctionnel) est
réalisé avec un pont diviseur de tension dont une des résistances est variable.
Sa relation est donnée par : Vout = (k/k+10^4)*5
Il permet d'obtenir avec les résistances choisies, une tension allant de 0,09V à 4,55V.
La tension après le sommateur sera donc de 2,5 V lorsque le PCB est parfaitement à plat.
- Le sommateur/différentiateur est réalisé à partir d’un montage différentiateur avec un AOP,
le schéma d’un tel montage est le suivant :
Sa relation entrée/sortie est donnée par :
Vout = (Vacc-Vtemp/10-Voff)
Il est bon de noter que la température est divisée par dix alors qu’elle à subie une amplification précédente. Il s’agit là d’une méthode
pour réaliser une division à coefficient variable de la tension de température sans utiliser
de montage inverseur (car l’alimentation
n’est pas symétrique).
- Enfin le dernier amplificateur (non inverseur) lui aussi réalisé à l’aide d’un AOP et permet
de faire correspondre les 256 valeurs du CAN avec leurs tensions équivalentes. Le fait d’alimenter tout les amplificateur et surtout celui-ci qui est juste avant le CAN avec du 0/5V permet d’obtenir une saturation à 5V ou 0V et ainsi naturellement protéger le CAN.
Son équation est donnée par :
Vs = (1+k/10^4)*Ve
A noter que là aussi nous utilisons
la méthode de la masse fictive pour
avoir une amplification symétrique
des deux coté du 2,5V sans que celui-ci soit déplacé.
7
Pour réaliser les Quatre amplificateurs nous allons prendre un boîtier MC34084P contenant
quatre ampli-op compensés.
c) Le convertisseur Analogique/Numérique (CAN)
Le montage de celui-ci reste assez simple cependant il nécessite quelques éléments supplémentaires qui doivent être détaillés.
Premièrement nous allons protéger ses entrées grâce à des diodes puis nous allons lui fournir
une référence à 2,5V et une alimentation à 5V. Ensuite nous allons le faire fonctionner sans
commande de la part du FPGA pour simplifier au maximum le montage. Pour cela il faut
donner les bonnes consignes aux entrées/sortie de commande de celui-ci (INTR, WR, RD,
CS). D’après le manuel du CAN nous allons avoir RD = CS = 0 et INTR = WR (=0 pour
effectuer un reset du CAN). Le montage suivant donne les branchements généraux du CAN.
Nous utiliserons l’horloge interne du CAN pour donner à celui-ci les ordres d’échantillonnage
et de transmission. Pour ce faire on relie les entrées CLK IN et CLK R ensemble avec une
résistance puis on relie le tout à la masse à l’aide d’un condensateur. Le choix judicieux de la
valeur RC nous permet de contrôler les oscillation du trigger de Schmitt formant l’horloge
interne du CAN. Nous prendrons ici R = 10 k# et C = 150 pF soit une fréquence de 640 kHz.
Il ne faudra pas oublier après toute mise sous tension d’appuyer sur le bouton de remise à zéro
du CAN pour qu’il fonctionne correctement.
8
d) Le Bit de signe analogique
Le bit de signe peut être traité analogiquement à l’aide d’un comparateur LM311 monté selon
le schéma suivant en ce servant de la référence à 2,5V :
Dès que le signal est au dessus
de la référence (2,5V) le comparateur donne un nivaux logique
haut qui est puis affiché grâce à
une LED.
2)Partie numérique
a)Programmation du FPGA
Schéma général:
Le rôle de la partie FPGA est de traiter les 8 bits de sortie du CAN afin de l’afficher sur un
module d’affichage LCD 4 digits (un des digits servira uniquement à afficher le signe).
On pourra diviser cette partie en plusieurs sous-parties:
-Traitement du signe en complément à 1
-Conversion binaire / BCD
-Modules AHDL BCD / 7 segments
-Mode 42 (test de l’affichage)
Principe de fonctionnement:
On utilise le bit de poids fort pour traiter le signe, si le CAN sort un signal compris entre 0 et
127, le bit D7 vaut 0, et on inverse la valeur des 7 autres bits. Si le bit D7 vaut 1, on ne touche
pas à ces bits. Il s’agit la de la technique du complément à 1, on n’a pas besoin de complément à 2, sachant que l’on souhaite simplement inverser la progression. La position horizontale se trouve à la valeur 127, donc 0 une fois le complément effectué.
9
Le module de gestion du signe:
On va maintenant devoir traiter ces 7 bits. Une conversion en BCD s’avère nécessaire pour
séparer les digits. Pour afficher 2 digits BCD, on a besoin de 6 bits binaires en entrée, ce qui
fait qu’il nous reste le bit de poids faible D0. Ce bit servira directement à afficher un digit qui
prendra 2 valeurs, 0 ou 5.
Pour la conversion en BCD, on utilise un tableau AHDL, pour plus d’efficacité. On rentre les
7 bits restants du CAN, et on en sort 2 digits. Ce tableau fait 64 lignes de long, et évite l’utilisation de plusieurs dizaines de portes. (cf feuille annexe)
On a aussi inclus un module spécial
chargé de tester l’affichage, censé afficher “42”. Pourquoi 42? Parce que c’est
la Réponse à la Grande Question sur la
Vie, l’Univers et le Reste.
(H2G2, Le Guide du Voyageur Galactique)
Un module spécial est chargé de détecter si une entrée (nommée justement
42), est au niveau haut, auquel cas le
CAN est déconnecté de la chaîne d’affichage, en on rentre automatiquement
(par câblage) la valeur 42 en BCD.
C’est le module “dispatcher” qui gère le
routage entre le mode 42 et le mode
normal d’affichage.
10
Le dispatcher s’occupe de transformer les 7 bits binaires purs en BCD 2 digits, il contient le
module 42 (module câblé) et s’occupe du mode d’affichage (CAN ou 42)
Il en sort les 3 digits qui seront affichés.
do correspond au bit D0 du CAN, et ressort immédiatement pour le 3e digit (celui de fausse précision, qi n’affiche que 0
et 5), selon que le mode 42 soit actif ou
pas.
b) L’affichage
Une fois les digits extraits, on les envoie chacun dans un module VHDL chargé de transcrire
le BCD en langage 7 segments. Etant donné qu’on utilise un module d’affichage LCD, il est
nécessaire de rafraîchir les bits s’ils sont à 1, pour cela on utilise une horloge et des portes ET.
11
Les modules AHDL du signe et du digit de fausse précision sont un peu différent de ceux utilisés pour les afficheurs 7 segments classiques (censés afficher les digits de 0 à 9):
affich_ahdl: digit classique
signeahdl: digit de signe (- ou rien)
digit0ahdl: digit de fausse précision (0 ou 5
ou rien pour le mode 42)
II) Réalisation et mesures
1) Réalisation du PCB
Pour la conception du PCB nous avons utilisé Altium avec les règles de tracé suivantes :
- Largeur de piste de 1mm pour toutes les pistes (pas de fort courant donc pas largeurs spéciales pour les pistes d’alimentation)
- Espacement minimum de 0,3 mm
- Pas de plan de masse
Nous avons rajouté les composants suivants (inexistants dans les bibliothèques d’Altium) :
- L’accéléromètre : ADXL105
- Le convertisseur Binaire pur / BCD : DM74185A
12
On donne ci-dessous le PCB version 2 (après correction des erreurs sur le premier PCB) :
2) Partie analogique
a) L’alimentation
On mesure les tensions d’alimentation et Vref/2 pour voir si le circuit d’alimentation est correctement conçu :
On mesure Vref/2 = 2,25 V et Vcc = 5,01 V.
On observe que Vref est différent de la valeur prévu, ce qui peux s’expliquer par la précision
des résistances que nous avons utilisé pour l’obtenir. Il faudrait donc utiliser des résistances
plus précises ou ajouter un potentiomètre de réglage.
13
b) Traitement du signal analogique
Pour vérifier que ce bloc fonctionne correctement on va d’abord tester les étages un par un en
faisant varier l’inclinaison du support PCB et observer les variations de tensions à l’aide soit
de l’oscilloscope soit d’un voltmètre. Puis nous allons étalonner les différents étages en réglant : l’inclinaison 0° à 2,5V avec le potentiomètre d’offset puis on réglera le maximum 6,4°
à la tension maximum 5V avec le potentiomètre d’amplification et enfin on réglera la compensation en température.
Sur les photos ci-dessus on peut observer que lorsque le systeme est réglé nous obtenons un
signal pouvant aller de environs 0V à 5V. L'oscillogramme obtenu avec un défilement lent
(1s) montre des variations d'angles lorsque l'on déplace la plaque à la main. Sur la photo de
droite on peut voir que quand le PCB est incliné vers la droite le bit de signe indiqué par la
LED de gauche est éteint.
On condense les résultats des mesures du bon fonctionnement des différents étages dans un
tableau (étalonnage déjà effectué) :
Inclinaison (°)
Vacc
VOp1
Vsom
VOp2=VCAN
Bits CAN
6,4
5
2
-------2,971
2,958
-------0,946
0,955
-------2,405
2,429
-------1.705
1,969
1111 1111
0101 0101
0110 0101
0
2,949
1,038
2,475
2,475
0111 1111
-2
2,935
1,09
2,478
2,508
1000 0000
-5
2,935
1,137
2,504
2,794
1000 1111
-6,4
--------
--------
--------
--------
0000 0000
Vacc : tension en sortie de l'accéléromètre
Vop1 : tension Vacc amplifiée (x4) et filtrée
Vsom : tension Vop1 + Offset + correction en température
Vcan : tension Vsom amplifié (x11)
Les données en bleues sont des données non mesurées mais calculées à partir des mesures.
Les données rouges sont des valeurs limites non mesurées.
c) L'influence de la température sur l'accéléromètre
On va maintenant étudier l’influence de la température sur le capteur d’accélération. Pour cela
on met en place un dispositif de chauffage avec mesure de la température à l’aide d’un thermomètre comme le montre les photos ci-après :
14
On relève dans un tableau les différentes mesures effectuées:
Température (°C)
Vtemp
Vaccmax
43
2,689
1,045
42
2,683
1,048
39
2,661
1,048
37
2,655
1,045
36
2,648
1,046
34
2,644
1,045
31
28,5
26,5
25,5 (Tamb)
2,648
2,633
2,601
2,584
1,046
1,046
1,045
1,047
Vaccmin
1,044
1,045
1,046
1,045
1,045
1,043
1,044
1,044
1,044
1,047
Vtemp : la tension de sortie du capteur de température interne de l’accéléromètre
Vacc : la tension de sortie du capteur d’accélération ayant subi la première amplification /filtrage
température : la température mesuré par le thermomètre
On trace à partir de ces données deux graphes Vtemp=f(T) et Vacc=f(T) :
15
On remarque que le capteur de température a un gain de 5 mV/°C qui est différent de celui
donné dans la datasheet ( 8 mV/°C ). Ceci peux s'expliquer par les conditions de mesures difficiles : impossibilité de stabiliser le thermomètre et forte inertie du capteur de température
interne.
En conclusion il aurai fallu effectué des tests avec un temps d'attente plus long entre les mesures et surtout dans une boite isolée des variations thermiques extérieurs.
Le deuxième graphe montre les variations de l'accélération au moment de la mesure et à des
températures différentes. Globalement les variations ont lieux entre 1,043 et 1,048 volts ce qui
pourra être considéré comme négligeable puisqu'elles correspondent au maximum à une erreur de 0,05°.De plus il semble difficile de donner une relation entre la température et la variation de l'accélération. On pourra considérer dès lors que pour notre plage de mesure (25°C45°C), que la température n'a pas d'effet sur le capteur d'accélération.
d) Le convertisseur Analogique/Numérique
On commence par tester le bon fonctionnement de l'horloge du CAN. Elle fonctionne à l'aide
d'un trigger de Schmitt intégré et avec l'ajout d'une résistance et d'un condensateur pour obtenir la fréquence désirée.
On relève l'oscillogramme suivant :
Le signal possède la forme attendue :
un créneau assez grossier oscillant
entre 0 et 5V.
Par contre la fréquence (380 kHz) est
inférieure à celle attendue (606 kHz),
ce qui en soit n'est pas très gênant
pour notre application. On vérifie
ensuite que les pattes des communication du CAN sont bien reliées pour
fonctionner en mode autonome, ce
qui est le cas.
On peut maintenant tester les sortie à l'aide de LED que l'on ajoute en série avec une résistance sur toutes les sorties.
e) Le bit de signe analogique
Enfin nous testons le Bit de signe analogique en tournant la plaque dans un sens ou dans l'autre, celui-ci fonctionne correctement comme l'indique les deux photos ci-dessous :
On constate cependant un léger effet d'hystérésis venant du comparateur.
16
3)Partie numérique
a) Le FPGA
Solution de secours:
On utilise, à la place du FPGA, un microcontrôleur Arduino qui va lire l’information analogique censée rentrer dans le CAN (l’Arduino possédant un CAN 10 bits), et la transmettre via
MIDI vers un ordinateur chargé de l’affichage.
Du fait des 10 bits du CAN intégré, on peut penser qu’on aura une meilleure résolution, mais
le MIDI n’autorise le transport que de donnée de valeur inférieure à 128 (7 bits), donc on aura
au final une précision moindre, mais de vrais digits.
b) La structure des messages MIDI
On a donc choisi le message “Control Change numéro 11, sur canal 1”. Ceci peut paraître
assez obscur au premier abord, mais le langage MIDI est assez simple.
Un message en MIDI est constitué de 3 octets, le premier étant un octet de contrôle, les deux
autres étant des octets de données. C’est l’octet de contrôle qui va définir le type de message
qu’on envoie, ainsi que le canal (le MIDI est un langage permettant à plusieurs appareils de
communiquer en réseau, l’information de canal permet ainsi de restreindre certains messages
à certaines machines.)
Ce premier octet se présente sous la forme suivante: 10110001, que l’on peut décomposer en
1 011 0001
Le bit de poids fort à 1 signifie qu’il s’agit d’un octet de contrôle.
Les 3 bits suivants désignent le type de message (ici 3 correspond au type Control Change).
Les 4 derniers bits désignent le canal (ici 1).
Les deux octets suivants dans le message sont des données, et leur valeur dépend du type de
message qu’on envoie. (dans certains de ces types, un seul octet de données est nécessaire,
mais on ne s’attardera pas à décrire toute la syntaxe MIDI).
Dans le cas du Control Change, le premier octet de données correspond au numéro du Control
Change (ce qui fait 128 control changes différents au total. Nous avons choisi le numéro 11
par hasard pour tester la liaison entre l’Arduino et le patch Pure Data, et il est resté dans la
version finale).
17
Le premier octet de données s’écrit donc 0
0001011.
Le deuxième octet de données est le plus intéressant dans notre cas, car c’est lui qui contient
l’information à transmettre, la “valeur de control change”. Elle est codée sur 7 bits, et le CAN
de l’Arduino sort du 10 bits, donc une division par 8 entre les deux et tout rentre dans l’ordre.
c) Réception des messages et interprétation
Une fois le message MIDI transmis via le port série de l’Arduino, il passe à travers une
interface MIDI - USB qui se branche sur un ordinateur. On utilise un logiciel nommé
Pure Data pour lire la valeur du control change, puis on la traite de cette façon pour afficher
un angle en degrés:
L’entrée ctlin 11 1 lit les données MIDI correspondant au Control
Change numéro 11 sur le canal 1.
Elle donne des valeurs entre 0 et 127.
On divise ensuite le résultat par 64
pour avoir des valeurs entre 0 et 2
On retranche 1 pour avoir des valeurs
entre -1 et 1
Le dernier facteur multiplicatif doit
être étalonné au même titre que les
potentiomètres sur la carte, pour une
exactitude optimale, et une bonne
précision.
d) Pourquoi ces choix?
La pénurie de cartes de programmation de FPGA qui fonctionnent et le chaos constaté dans
l’afficheur LCD nous ont poussé à changer de méthode d’affichage. L’Aduino que nous avons
utilisé appartient à l’un de nous, la programmation en C facilitant grandement la transmission
de données en série. Nous avons choisi la transmission par MIDI car c’était également un
langage qui nous était connu, et que nous ignorions comment transmettre directement les
données à l’ordinateur en USB (ce qui aurait été plus pratique et nous aurait sûrement donné
une meilleure précision).
De plus, l’Arduino et Pure Data sont des projets libres, aussi bien au niveau logiciel que
matériel.
18
Conclusion
Nous avons donc pu fabriquer un inclinomètre selon la plupart des critères que nous
nous étions fixés au départ, bien que la compensation en température fut mesurée de manière
assez peu rigoureuse, au final elle s’avère presque inutile. Nous avons eu des soucis avec le
dernier étage d’amplification (juste avant d’entrer dans le CAN), ce qui ne nous a pas permis
d’avoir une précision maximale.
Les soucis avec les cartes FPGA nous ont forcé à changer de technologie, opération
faite en moins de 2 séances, ce qui pourrait laisser croire que le FPGA n’est pas du tout adapté
à la plupart des projets. Quoi qu’il en soit nous avons pu lire notre angle sur l’écran de
l’ordinateur, mais on aurait très bien pu utiliser Pure Data pour traiter autrement ce signal,
comme par exemple afficher une bulle se déplaçant comme dans un niveau à bulle réel.
Nous avons pu, en fin de dernière séance, coupler notre projet avec celui du Pong sur
oscilloscope (qui utilisait lui aussi un Arduino), pour contrôler la position d’une raquette avec
la carte de l’inclinomètre (pencher d’un côté fait monter la raquette, de l’autre la fait
descendre), ce qui fut un succès. Avec le projet de transmission sans fil, nous aurions pu
recréer une console Wii de base (jouant au pong avec une seule manette). Mais là n’était pas
le but.
Liens:
Le site du projet Arduino:
http://www.arduino.cc
Le site qui produit la version que nous avons utilisé (sur plaque de tests):
http://www.ladyada.net/make/boarduino/index.html
Le site de Pure Data:
http://www.puredata.org
19
SUBDESIGN affich_ahdl
(
f[5..0] : INPUT;
Y[6..0] : OUTPUT;
)
BEGIN
TABLE f[7..0] =>
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
Y6, Y5, Y4, Y3, Y2, Y1, Y0;
0, 0, 0, 0, 0, 0, 0;
0, 0, 0, 0, 0, 0, 1;
0, 0, 0, 0, 0, 1, 0;
0, 0, 0, 0, 0, 1, 1;
0, 0, 0, 0, 1, 0, 0;
0, 0, 0, 0, 1, 0, 1;
0, 0, 0, 0, 1, 1, 0;
0, 0, 0, 0, 1, 1, 1;
0, 0, 0, 1, 0, 0, 0;
0, 0, 0, 1, 0, 0, 1;
0, 0, 1, 0, 0, 0, 0;
0, 0, 1, 0, 0, 0, 1;
0, 0, 1, 0, 0, 1, 0;
0, 0, 1, 0, 0, 1, 1;
0, 0, 1, 0, 1, 0, 0;
0, 0, 1, 0, 1, 0, 1;
0, 0, 1, 0, 1, 1, 0;
0, 0, 1, 0, 1, 1, 1;
0, 0, 1, 1, 0, 0, 0;
0, 0, 1, 1, 0, 0, 1;
0, 1, 0, 0, 0, 0, 0;
0, 1, 0, 0, 0, 0, 1;
0, 1, 0, 0, 0, 1, 0;
0, 1, 0, 0, 0, 1, 1;
0, 1, 0, 0, 1, 0, 0;
0, 1, 0, 0, 1, 0, 1;
0, 1, 0, 0, 1, 1, 0;
0, 1, 0, 0, 1, 1, 1;
0, 1, 0, 1, 0, 0, 0;
0, 1, 0, 1, 0, 0, 1;
0, 1, 1, 0, 0, 0, 0;
0, 1, 1, 0, 0, 0, 1;
0, 1, 1, 0, 0, 1, 0;
0, 1, 1, 0, 0, 1, 1;
0, 1, 1, 0, 1, 0, 0;
0, 1, 1, 0, 1, 0, 1;
0, 1, 1, 0, 1, 1, 0;
0, 1, 1, 0, 1, 1, 1;
0, 1, 1, 1, 0, 0, 0;
0, 1, 1, 1, 0, 0, 1;
1, 0, 0, 0, 0, 0, 0;
1, 0, 0, 0, 0, 0, 1;
1, 0, 0, 0, 0, 1, 0;
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
END TABLE;
END;
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
1,
1,
1,
1,
0,
0,
0,
0,
0,
0,
0,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
0,
0,
0,
0,
0,
0,
0,
0,
0,
1,
1,
0,
0,
0,
0,
0,
0,
0,
0,
1,
1,
0,
0,
0,
0,
0,
1,
1,
1,
1,
0,
0,
0,
0,
0,
0,
1,
1,
1,
1,
0,
0,
0,
0,
0,
0,
1,
0,
0,
1,
1,
0,
0,
0,
0,
1,
1,
0,
0,
1,
1,
0,
0,
0,
0,
1,
1,
1;
0;
1;
0;
1;
0;
1;
0;
1;
0;
1;
0;
1;
0;
1;
0;
1;
0;
1;
0;
1;