Projet Stage Erasmus

Transcription

PROJET STAGE ERASMUS
Diplôme : Enginyeria Tècnica Aeronàutica, especialitat Aeronavegació
AUTEUR : Iván Prados Camargo
DIRECTEUR : Denis Michaud
SUPERVISEUR : Jordi Berengeur i Sau
DATE : 7 mai 2012
Titre : Projet Stage Erasmus
Auteur: Iván Prados Camargo
Directeur: Denis Michaud
Superviseur: Jordi Berengeur i Sau
Date: 7 mai 2012
Résumé
Le déroulement de ce projet a été réalisé dans le cadre Erasmus entre l’Ecole d’Ingénierie
de Télécommunication et Aérospatial de Castelldefels et le Centre de Ressources
d’Ingénierie et Maintenance Aéronautique.
On a participé dans le Projet DR-400 dont objectif est de construire une reproduction d’un
cockpit de l’avion de tourisme Robin DR400 afin d’être utilisé pour les Travaux Pratiques
des étudiants.
Le projet est constitué par deux parties coordonnées :
• La transmission d’une trame ARINC 429 de données d’altitude acquises de la maquette, au travers d’un microcontrôleur et son affichage sur l’oscilloscope.
• La création d’un système générateur de pressions anémo-barométriques, à partir de l’adaptation d’une pousse-seringue, qui sont normalement utilisées dans les
hôpitaux, afin de substituer la valise de test anémo-barométrique employée actuellement.
Mots clés : maquette cockpit DR-400, spécification ARINC 429, microcontrôleur,
pressions anémo-barométriques, pousse seringue, rapport cyclique, logiciels LabVIEW et C.
Title : Projet Stage Erasmus
Author: Iván Prados Camargo
Director: Denis Michaud
Supervisor: Jordi Berengeur i Sau
Date: May 7, 2012
Overview
This project has been fulfilled within the Erasmus program in collaboration with the School
of Telecommunications and Spatial Engineering in Castelldefels and the Center of Resources and Aeronautical Maintenance.
We have participated in the Project DR-400 whose objective is to build a replica of the
cockpit of the recreational plane Robin DR400. Once it should be completed, its mission
would be to serve as training material for the students.
The project consists of two interconnected parts:
• Transmission of the altitude data as registered from the model using the ARINC 429
syntax through a micro-controller and an oscilloscope.
• Creation of a system for generating anemo-barometric pressures from a common
syringe in order to replace the current test pack.
Keywords: scale model cockpit DR-400, ARINC 429 specification, microcontroller,
anemo-barometric pressure, pushed syringe, duty cycle, programming LabVIEW &
C.
Nous tenons à remercier dans un premier temps toute l’équipe du CR-IMA, pour avoir
assuré la réalisation de notre stage ; en bref Mr. Michaud et Renaud pour sa confiance et
ses conseils.
Nous remercions également Alain et Babeth pour sa patience et bon humeur.
Finalement nous n’oublions pas nos familles et amis de Barcelone à qui nous remercions
pour son soutien.
TABLE DES MATIÈRES
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PARTIE I
1
Transmission d’une trame Arinc 429 de données d’altitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1. Spécification ARINC 429 . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.1. Caractéristiques
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.1. Physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.2. Électriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.3. Trasmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.2. Composition d’un mot ARINC 429 . . . . . . . . . . . . . . . . . . . . . . .
11
1.3. Encodage des données
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.3.1. Binaire - BNR . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.3.2. Binary Coded Decimal - BCD . . . . . . . . . . . . . . . . . . . . .
14
1.3.3. Données discrètes . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3.4. AIM (Acknowledgement, ISO Alphabet No 5 and Maintenance Data)
15
1.3.5. Williamsburg/Buckhorn Protocol . . . . . . . . . . . . . . . . . . . .
15
1.4. Mot ARINC 429 d’altitude . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.4.1. Décodage du mot . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2. Description du système . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1. Description des blocs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.1.1. Bloc 1 : Maquette . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.1.2. Blocs 2 et 3 : LabVIEW et NI USB-6008
. . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . . . .
22
2.1.3. Bloc 4 : Starter Kit PK-HCS12C32
2.1.4. Bloc 5 : Oscilloscope LeCroy WaveSurfer 44Xs-A
2.2. Résultats
PARTIE II
. . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Planning et diagramme de Gantt . . . . . . . . . . . . . . 39
3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
PARTIE III
La suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
ANNEXE A. Logiciels LabVIEW . . . . . . . . . . . . . . . . . . . . . . . 53
ANNEXE B. Analyse du programme C . . . . . . . . . . . . . . . . . . . 55
TABLE DES ACRONYMES
ARINC Aeronautical Radio Incorporated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
AEEC Airlines Electronic Engineering Committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
AMC
Avionics Maintenance Conference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
FSEMC Flight Simulator Engineering & Maintenance Conference . . . . . . . . . . . . . . . . . . . . . . 5
LRU
Line Replaceable Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
MSB
Most Significant Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
PWM Pulse-Width Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
RZ
Retour à Zéro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
ULDF User Label Description File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
TABLE DES FIGURES
1
2
Image de la maquette avec la valise anémo-barométrique. . . . . . . . . . . .
Parties du Projet DR400. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Topologies ; étoile et bus-cascade . . . . . . . . . . .
1.2 Plusieurs communications entre LRU’s . . . . . . . . .
1.3 Paire de câbles torsadés et blindés. . . . . . . . . . .
1.4 Encodage Bipolaire RZ . . . . . . . . . . . . . . . . .
1.5 Paramètres de l’encodage . . . . . . . . . . . . . . .
1.6 Circuit standard Tx et Rx . . . . . . . . . . . . . . . .
1.7 Composition d’un mot ARINC 429 . . . . . . . . . . .
1.8 Label en détail . . . . . . . . . . . . . . . . . . . . .
1.9 Ordre de transmission . . . . . . . . . . . . . . . . .
1.10Exemple des différents formats de données ARINC 429
1.11Label d’altitude . . . . . . . . . . . . . . . . . . . . .
1.12Exemple d’un mot d’altitude . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
9
10
10
11
13
13
15
16
17
2.1 Blocs du système. . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Mot de 32 bits divisé en 4 octets. . . . . . . . . . . . . . . . . . . . .
2.3 Interaction entre le altitude sub dm2.vi et Tx 11 bits.vi et Conv8bits.vi.
2.4 Bits - strobes de synchronisation. . . . . . . . . . . . . . . . . . . .
2.5 Connecteur 1 du Starter Kit PK-HSC12C32. . . . . . . . . . . . . . .
2.6 Branchement USB6008-Microcontrôleur. . . . . . . . . . . . . . . . .
2.7 Organigramme de syncrhonisation et le codage C associé. . . . . . .
2.8 Signaux des deux vitesses ARINC 429. . . . . . . . . . . . . . . . .
2.9 Signal d’horloge et des clocks de buses. . . . . . . . . . . . . . . . .
2.10Signaux ARINC 429 traduites en cycles d’horloge. . . . . . . . . . . .
2.11Cycles de CPU entre les deux instructions qui écrivent sur le Port B. .
2.12Affichage sur LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . .
2.13Première capture sur l’oscilloscope avec le label inversé. . . . . . . .
2.14Label sans inverser. . . . . . . . . . . . . . . . . . . . . . . . . . .
2.15Maquette avec une indication de 700ft. . . . . . . . . . . . . . . . . .
2.16Indication LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . .
2.17Mot émis à 13,5 kbps. . . . . . . . . . . . . . . . . . . . . . . . . .
2.18Mot émis à 100 kbps. . . . . . . . . . . . . . . . . . . . . . . . . . .
2.19Diagramme de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . .
2.20Exemple d’un test réalisé avec des LED’s. . . . . . . . . . . . . . . .
2.21Measure de la fréquence pour bien déterminer la vitesse de 12,5 kbps
2.22Images de la maquette des instruments gyroscopiques. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
21
21
22
24
24
26
27
28
28
30
31
32
34
35
36
37
38
40
41
42
43
A.1 Bloc Diagram Tx 11bits.vi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Bloc Diagram Conv8bits.vi . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Front panel altitude sub dm2.vi, indication en rouge sur le bouton qu’on a ajouté
et qui permet de choisir la vitesse . . . . . . . . . . . . . . . . . . . . . . . .
53
53
54
B.1 Exemple grapique du placement du bit 4 de l’octet #2 . . . . . . . . . . . . . .
B.2 Représentation d’un exemple graphique des tableaux motA, motB et motEmis .
56
58
LISTE DES TABLEAUX
1.1
1.2
1.3
1.4
1.5
1.6
ARINC Standards . . . . . . . . . . . . . . . . . .
Niveaux de tension . . . . . . . . . . . . . . . . .
Tolérances. Tb = Temps de bit et rb = vitesse de bit.
Signification du bit 29 en données BNR . . . . . .
Signification des bits SSM en données BNR . . . .
Interprétation du label d’un mot ARINC 429 . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
9
9
14
14
17
1
INTRODUCTION
En Catalogne, pour finir les études d’Enginyeria Tècnica Aeronàutica Especialitat en Aeronavegació, équivalents à une licence 3 en France, on demande le développement d’un
projet pendant au moins quatre mois mis en relation avec les études. Afin d’obtenir une
expérience différente et découvrir plusieurs façons de faire, nous avons envisagé de réaliser
notre projet à l’étranger.
Cette opportunité nous a été donnée par l’Institut de Maintenance Aéronautique à travers l’Université Bordeaux 1, et le projet a été développé dans un cadre Erasmus avec
un accord bilatéral entre l’Université Bordeaux 1 et l’Universitat Politècnica de Catalunya
en bref notre école EETAC (Escola d’Enginyeria de Telecomunicacions i Aeroespacial de
Castelldefels).
Le Centre de Ressources en Ingénierie et Maintenance Aéronautique (CR-IMA) appartient
au département Mécanique, Aéronautique et Ingénierie (MAI) de l’UFR de physique dédié
à l’Aéronautique de l’Université Bordeaux 1. Cet Institut crée en 1992 est situé à Mérignac,
dans une zone proche de l’aéroport et offre aux étudiants les diplômes de :
• Licence Professionnelle en Maintenance Aéronautique (Bac+3) ;
• Licence 3 en Maintenance Aéronautique qui à son tour donne accès au Master
Génie des Systèmes Aéronautiques et des Transports (GSAT) (Bac+5) avec trois
spécialités d’ingénierie :
– Maintenance Aéronautique (IMA) ;
– Systèmes Electroniques Embarqués (ISEE) ;
– Structures Composites (ISC).
La durée totale du stage à l’IMA a été d’environ cinq mois. Nous avons commencé vers
la mi-novembre 2011 et nous allons finir le 11 avril 2012, mais dans cette période là il
faut considérer les vacances de Noël et de Février ainsi que la rédaction du rapport en
français.
Nous avons travaillé sur le développement d’une maquette didactique qui représente le
cockpit d’un avion de tourisme Robin DR400. Cette maquette est utilisée par les élèves de
l’IMA dans ses Travaux Pratiques pour comprendre les variations des paramètres de vol
en fonction de l’altitude et leur permet aussi de visualiser le codage des données d’altitude
transmises à l’station sol.
Le déroulement de cette maquette est réalisé en différentes étapes par plusieurs étudiants
en License 3, Master 1 et 2.
2
F IGURE 1 – Image de la maquette avec la valise anémo-barométrique.
Le projet a été divisé en deux parties (indiquées sur la figure 2) :
1. La transmission d’une trame Arinc 429 contenant les données d’altitude issues de la
maquette DR400 qui sont récupérées et décodées par l’oscilloscope LeCroy WaveSurfer 44Xs-A, et qui offre la possibilité d’acquérir la trame sous le logiciel LabVIEW
et sur Internet au travers d’une adresse IP.
2. Le développement d’un système capable de générer des pressions anémo-barométriques
avec une pousse seringue, afin de substituer la valise de Test Pitot-Statique.
F IGURE 2 – Parties du Projet DR400.
Première partie
Transmission d’une trame Arinc 429 de
données d’altitude
4
Aujourd’hui l’avionique est devenue une composante essentielle des aéronefs. Les ARINC
Standards décrivent l’avionique, les systèmes du cockpit et les protocoles de communications à employer, entre autres. Ils sont utilisés par la majorité des fabricants, des lignes
aériennes et d’autres entreprises vinculées à l’aviation du monde. Il y a trois types d’ARINC
Standards :
• ARINC Caracteristics
• ARINC Specifications
• ARINC Reports
Chaque type est mise en relation avec unes séries ARINC. Concrètement, ARINC 429
correspond à une Spécification pour les bus avioniques, et est utilisée en avions come
le A-320 ou le B-767, en autres. On a développé un système pour émettre une trame
en respectant cette spécification pour les données d’altitude qu’on obtien de décoder le
codage Gillham, que l’alticodeur transmit au transpondeur de la maquette DR400.
Spécification ARINC 429
5
CHAPITRE 1. SPÉCIFICATION ARINC 429
Aeronautical Radio Incorporated (ARINC) est une société mondiale fondé en 1929 par la
Federal Radio Commission 1 , et dirigée par les quatre plus grandes lignes aériennes du
moment. Le but était créer, coordonner et regrouper les spécifications et standards des
systèmes électroniques et de télécommunications dans la industrie de l’aviation, hors le
cadre légal des gouvernements. Actuellement ARINC appartient à Carlyle Group et est
intégrée par différentes associations des lignes aériennes ainsi que des sociétés unies à
l’aviation. Aujourd’hui est le plus grand fournisseur de solutions, standards et spécifications
de systèmes de télécommunications aéronautiques et de systèmes embarqués.
• Airlines Electronic Engineering Committee (AEEC), créé en 1949. Sa fonction
est faire des standards et des solutions techniques pour l’équipement du cockpit et
l’avionique. Il est intégré par représentants des lignes aériennes, comme KLM, et
par fabricants d’aéronefs comme Airbus ou Boeing.
• Avionics Maintenance Conference (AMC), créé en 1949, contribue à incrémenter
la fiabilité et améliorer la maintenance pour réduire les coûts d’opération des systèmes
embarqués. Elle est intégrée par plus de 750 experts de la maintenance d’avionique
du monde.
• Flight Simulator Engineering & Maintenance Conference (FSEMC), créé en
1994, est l’entité responsable de fournir des solutions pour l’opération et la maintenance des simulateurs de vol. En plus, ils font des standards techniques pour
incrémenter la qualité des simulateurs de vol et réduire son coût opérationnel. Il est
intégrée par plus de 300 experts des simulateurs de vol du monde.
Les standards techniques adoptés par les trois comités sont publiés comme ARINC Standards par la société ARINC. Par conséquent, ils décrivent l’avionique, les systèmes du
cockpit et les protocoles de communications, entre d’autres. Ils sont utilisés par la majorité
des fabricants, des lignes aériennes et des entreprises vinculées à l’aviation du monde.
Il y a trois types d’ARINC Standards :
• ARINC Characteristics, qui définissent la forme, le branchement, la fonction et la
interface de l’avionique, systèmes du cockpit et bus de communication aéronautique.
Sont documents spécifiques et définissent chaque équipement individuellement.
• ARINC Specifications, qui déterminent les paramètres physiques et d’assemblage
de l’équipement avionique et du cockpit, les standards de communications des
données et de sécurité ainsi que les langages de programmation d’haut niveau.
• ARINC Reports, qui servent comme guide et information sur les bonnes practices
dans l’industrie de l’aviation. Normalement ils mettent en relation avec la maintenance et l’ingénierie des équipements avioniques ainsi que des simulateurs de vol.
Chaque type d’ARINC Standards est mis en relation avec une série ARINC :
1
Aujourd’hui conue comme Federal Communications Commission
6
ARINC Standards by Aircraft Generation
Networked Aircraft
Digital Aircraft &
Flight Simulators
Analog Aircraft &
Flight Simulators
Characteristics
ARINC 700-Series
ARINC 700-Series
ARINC 500-Series
Specifications
ARINC 800-Series
ARINC 600-Series
ARINC 400-Series
ARINC 400-Series
Reports
ARINC 800-Series
ARINC 600-Series
ARINC 400-Series
ARINC 400-Series
TABLE 1.1 – ARINC Standards
D’un côté, on peut voir dans le tableau 1.1 que la série ARINC 400 a Rapports et Spécifications
qui donnent les directives de développement pour l’équipement spécifié par les séries
ARINC 500 et 700. En plus, ces spécifications ont les guides pour l’installation, le câblage,
les bus et bases de données, et information générale.
D’un autre côté, on peut voir aussi dans le tableau 1.1 que les séries 500 et 700 définissent
caractéristiques. Dans le cas de la série 500 on trouve des références à l’équipement de
l’avionique analogique utilisé aux anciennes aéronefs comme le B-747, le DC-9 ou l’A-300,
entre d’autres. Dans le cas de la série 700 on trouve le même mais dirigé à l’avionique
digitale, qui est incluse dans les aéronefs plus modernes.
En résumé, la spécification ARINC 429 définit un standard pour le transfert de données
digitales qui a été créé par ARINC en 1978, et développé par rapport la spécification
ARINC 419 créé en 1966 dont la dernière révision a été en 1983.
L’ARINC 429 a trois parties :
• ARINC Specification, Part 1 : A les paramètres physiques ainsi que les électriques,
l’attribution du label et les formats du mot.
• ARINC Specification, Part 2 : A les standards pour des données discrètes.
• ARINC Specification, Part 3 : A les techniques pour le transfert des données.
À chaqu’une lui corresponde un document différent. On peut les obtenir au travers de la
page web de l’AEEC en format papier ou pdf. Aujourd’hui, les révisions de chaque partie
en vigueur sont la 17, la 16 et la 19 respectivement.
Ensuite on montre un résumé de la Spécification ARINC 429 avec des paramètres les plus
importants.
1.1.
7
Caractéristiques
Un bus de communications selon la spécification ARINC 429 doit être bifilaire, torsadé
et blindé. En plus, la communication est basé sur le Mark 33 Digital Information Transfer
System, qui établit une transmission des données série et unidirectionelle. Il y a deux types
de débit, 12-14,5 kbps et 100 kbps. Les données sont transférées sur mots de 32 bits.
1.1.1.
Physiques
Chaque émetteur peut être connecté au plusieurs récepteurs (20 au maximum). La topologie peut être en étoile ou en bus cascade, voir la figure 1.1. Pour avoir une communication
bidirectionnelle entre Line Replaceable Unit (LRU)2 on doit utiliser deux bus ARINC 429
distincts, voir la figure 1.2.
F IGURE 1.1 – Topologies ; étoile et bus-cascade
F IGURE 1.2 – Plusieurs communications entre LRU’s
1.1.2. Électriques
Le moyen de transmission spécifié par l’ARINC 429 doit être un paire de câbles torsadés
et blindés, avec une impédance de 78 Ω, voir la figure 1.3. Le blindé doit être connecté à la
2
Un LRU est un composante modulaire d’un système qu’on peut le remplacé facilement et rapidement
sens avoir besoin de démonter d’autres composantes du système.
8
masse des dispositifs aussi que les connecteurs pendant la largueur du bus. La longueur
maximale établi est de 100m par raisons d’atténuation, mais selon le dessin l’on la peut
allonger tant comme sait opportun. En plus, il faut éviter que les terminassions des lignes
soit en curt circuit ou circuit ouvert , puisque on peut affaiblir la immunité au bruit et l’on
peut susciter à un fonctionnement discontinu de la communication entre les LRU.
F IGURE 1.3 – Paire de câbles torsadés et blindés.
1.1.3.
Trasmission
L’émetteur transfert un signal différentiel entre les lignes A et B. Il y a deux débits spécifiés :
12-14,5 kbps et 100 kbps ±1%. La vitesse la plus utilisée est la lente. Sur le bus ne peut
pas avoir qu’un émetteur, la reste doit être récepteurs. La communication entre l’émetteur
et les récepteurs est unidirectionnelle, par conséquent est open loop, les dernières n’ont
pas besoin d’informer aux fonts que la information est bien arrivé. Dans le cas que l’on
veut un dialogue entre deux LRU on doit utiliser deux bus ARINC 429 distincts.
1.1.3.1.
Encodage
On fait servir un encodage Bipolaire Retour à Zéro (RZ). Comme ça, on a trois états :
HIGH, NULL et LOW. Dans le tableau 1.2 l’on peut voir les différents niveaux de tension
sait pour l’émission ou la réception. Les valeurs d’émission sont nominaux, sens charge
sur l’émetteur. D’un autre côté, les valeurs de réception ont dépendance de la longueur du
câblage, le nombre de LRU branchés à la ligne et la qualité du blindé, entre d’autres. Dans
le tableau 1.2 on spécifique les niveaux idéales (sens bruit), et les obtenus normalement
aux récepteurs réels (avec bruit).
Dans un codage Bipolaire RZ, la transmission d’un 1 logique on le fait en changer l’état
NULL au HIGH dans la première moitié de la période, dans la deuxième moitié on retour
à l’état NULL. Pour la transmission d’un 0 logique, on le fait comme l’on a expliqué avant,
mais à la place de l’état HIGH on met un état LOW. On peut observer qu’on a un signal
d’horloge implicit sur la transmission. Les mots de 32 bits doivent être séparés par 4 bitstime NULL au minimum, et que le récepteur les utilise comme synchronisation entre les
différentes mots.
9
F IGURE 1.4 – Encodage Bipolaire RZ
Voie
HIGH
NULL
LOW
Sortie de l’émetteur
A↔B
+10V ± 1
0V ± 0, 5
−10V ± 1
A ↔ GND
+5V ± 0.5
0V ± 0, 25
−5V ± 0.5
B ↔ GND
−5V ± 0.5
0V ± 0, 25
+5V ± 0.5
Entrée au récepteur sens bruit
A↔B
+7, 25V → +11V
+0, 5 → −0, 5
−7, 25V → −11V
Entrée au récepteur avec bruit
A↔B
+6V → +13V
+2, 5 → −2, 5
−6V → −13V
TABLE 1.2 – Niveaux de tension
Paramètres de l’encodage
Dans la figure 1.5 et le tableau 1.3 on montre les définitions, paramètres et tolérances de
temps du signal. On peu contrôler ces temps avec des dessins des circuits RC, selon le
fabricant.
Paramètre
Rapide (100 kbps ±1%)
Lente (12 - 14,5 kbps ±1%)
Tb
10µsec ± 2, 5%
1
2 Tb
5µsec ± 5%
1
rb µsec ± 2, 5%
Tb
2 ± 5%
Flanco de subida
1, 5µsec ± 0, 5µsec
10µsec ± 5µsec
Flanco de bajada
1, 5µsec ± 0, 5µsec
10µsec ± 5µsec
TABLE 1.3 – Tolérances. Tb = Temps de bit et rb = vitesse de bit.
10
F IGURE 1.5 – Paramètres de l’encodage
1.1.3.2. Équipement émetteur et récepteur
L’impédance de l’émetteur doit être de 75 ± 5 Ω divisée de manière égale entre les deux
lignes, voir la figure 1.6. On aura l’émetteur adapté en impédance avec la ligne qui permet
éviter pertes de puissance dans la transmission.
Le récepteur doit avoir une impédance d’entrée mesuré entre les deux lignes et chaque
ligne et masse de 12 kΩ au minimum pour éviter des effets de charge, Rin >> Rbus .
En plus, la résistance totale d’entrée de chaque récepteur, avec RI, RH et RG, doit être
supérieur à 8 kΩ, qui deviens 400 Ω quand les 20 récepteurs maximales spécifiés par
ARINC 429 sont branchés en parallèle au bus . Cette charge serait la minimale du bus et
par conséquent la maximale que doit avoir l’émetteur.
On peut voir les schèmes de base d’un émetteur et d’un récepteur et les valeurs des
composants.
F IGURE 1.6 – Circuit standard Tx et Rx
• Résistance d’entrée différentielle, RI ≥ 12kΩ
• Capacitance d’entrée différentielle, CI ≤ 50pF
• Résistance de la ligne par rapport à la masse, RH y RG ≥ 12kΩ
• Capacitance de la ligne par rapport à la masse , CG et CH ≤ 50pF
11
• Resistance totale, RI k RH k RG ≥ 8kΩ
1.2.
Composition d’un mot ARINC 429
Chaque émetteur est en transmission continue, soit mots ou états NULL. Normalement
chaque mot correspond à une donnée, mais il y a de fois que l’on a besoin de plus d’un
mot pour transmettre le donnée. Dans la section 1.3. l’on explique les formats d’encodage
de données les plus utilisées et qui sont définis par la spécification.
Le mot ARINC 429 est codé en 32 bits. Chaque mot est composé par cinq champs primaires :
F IGURE 1.7 – Composition d’un mot ARINC 429
• Parité impaire (1 bit).
• Sign/Status Matrix (SSM) (2 bits).
• Données (19 bits).
• Source/Destination Identifier (SDI) (2 bits).
• Label (8 bits).
Les champs les plus indispensables sont le label et la parité. Par conséquent, dans certains cases, l’on peut faire servir les champs SSM et SDI pour augmenter les champ des
données.
Partié
On peut détecter un nombre impair de bits erronés de la transmission, mais l’on peut
pas les corriger. Le bits le plus fort toujours est le bit de parité dans un mot ARINC 429.
Normalement, on fixe la parité impair excepte pour des cases concrets. Parité impaire veut
à dire qu’il doit avoir un nombre impair de bits avec la valeur 1 dans le mot. Pour y arriver,
l’émetteur fixe soit un 0, soit un 1 sur le champ de parité. Comme ça, le récepteur sait le
nombre de 1 que doit avoir dans le mot. Par exemple, si les bits 1-31 ont un nombre paire
de 1, le bit de parité on le fixe à 1, pour avoir un nombre de 1 impaire. Au contraire, si les
bits 1-31 ont un nombre impaire de 1, le bit de parité on le met à 0.
12
SSM
Assignée au bits 31 et 30 du mot ARINC 429. Ce champ définit l’état du hardware et
des équipements, le mode opératif ou la validité des données. En résumé, indiquer des
problèmes dans la partie de l’émetteur. Selon le format des données, la valeur du SSM
ont une signification différente.
Donées
Des 32 bits du mot au moins 19 sont destinés aux données, du bit 29 jusqu’a le bit 11. Ils
peuvent être codées en différents formats. Il y a aussi formats qui ne sont pas normalisées
implémentées par des fabricants. Les bits non utilisées dans le champs des données on
les met à 0, et l’on les appelle PAD bits.
SDI
Assigné au bits 9 et 10. Ce champ est utilisé quand il y a plusieurs récepteurs branchés à
l’émetteur. Il indique la source ou la destination du mot. Le récepteur sait son identifiant et
il le compare avec le mot et savoir ainsi qu’il est destiné à lui. Si les deux bits sont à zéro
le mot est destiné à tous les récepteurs du bus.
On ne peut avoir que quatre combinaisons, trois si on reste la ’00’, et identifier 20 récepteur
n’est pas possible. Mais normalement il n’y a pas de branchement entre les systèmes qui
traitent différents types de données. On peut faire servir ce champ comme une extension
du champ des données ou du label.
Label
Est un des champs le plus importants du mot car il s’utilise pour indiquer le format du
champs des données ainsi que pour identifier des paramètres associés. Selon le label, le
récepteur sait le décodage à appliquer sur les données. Tous les LRU ont une mémoire
ROM avec le label correspondante à ses opérations, et les instructions pour traiter les
données.
Il est codé en trois chiffres octaux. Il y a 28-1 labels différents, mais la ”000” ne se fait pas
servir. Le bit le plus faible du mot est le bit le plus fort du label, mais on transmis
le label en sens inverse, le bit le plus faible en premier, par conséquent le sens de
lecture doit être inverse aussi, voir figure la 1.8. Le LRU récepteur est le responsable de
lire le label dans le bon sens, et par rapport au label il est responsable aussi de faire un
bon décodage des données.
13
F IGURE 1.8 – Label en détail
Ordre de transmission
Le bit de poids faible du mot (Least Significant Bit en Anglais) est transmis en premier
temps , voir la figure 1.9.
F IGURE 1.9 – Ordre de transmission
1.3.
Encodage des données
Les données peuvent être codées en différents formats :
• Binaire - BNR
• Binary Coded Décimal - BCD
• Données discrètes
• AIM (Acknowledgement, ISO Alphabet No 5 and Maintenance Data)
• Williamsburg/Buckhorn Protocol
Ensuit on explique chaque format mais l’on ne détaille que le format BNR, qui est le
spécifié pour les données d’altitude.
1.3.1.
Binaire - BNR
Ce format est un des plus utilisés. La donnée est écrite comme un nombre binaire, c’est le
même format que sur les ordinateurs modernes. Le bit 29 indique le signe de la donnée,
voir table 1.4. La interprétation est associée au label. Par exemple, si le label indique une
donnée de latitude, le récepteur interprétera le bit 29 comme Nord ou Sur, selon si il y a
un 0 ou un 1.
Le bit 28 est le plus fort des données et représente la moitié du facteur d’échelle. Le bit 27
représente 1/4 du facteur d’échelle, etc. C facteur d’échelle est associé au label et on le
14
Bit 29
Signification
0
Positif : Plus, Nord, Est, Droite, Vers, au-Dessus
1
Négatif : Moins, Sud, Ouest, Gauche, De o Sous
TABLE 1.4 – Signification du bit 29 en données BNR
peut trouver dans l’Attachment 2 : Data Standards du Partie 1 de la Spécification ARINC
429.
Dans la figure 1.10 on peut voir un exemple qui correspond à un mot de vitesse.
Le système d’altitude est un des plusieurs qui utilise ce type d’encodage. Alors, les données
d’altitude sont codées en BNR. Plus bas, on explique un exemple de décodage d’une
donnée d’altitude comme les traités dans ce projet.
Dans ce cas, le champ SSM on l’utilise pour informer de l’état de fonctionnement du
récepteur, voire table 1.5.
Bit
Signification
30
31
0
0
Failure Warning
0
1
No Computed Data
1
0
Functional Test
1
1
Normal Operation
TABLE 1.5 – Signification des bits SSM en données BNR
1.3.2.
Binary Coded Decimal - BCD
Ce format est très commun aussi. La donnée est écrite en groups de 4 bits et que l’on
interprète comme une chiffre décimale. Il y a jusqu’à cinq niveaux qu’on peut utiliser en
fonction du label associé. Le sub-champ 29-27 représente la chiffre la plus forte, mais la
valeur décimale ne peut pas être plus que 7. Si la valeur es plus grande que 7, la chiffre la
plus forte serait le sub-champ 26-23 et on remplit les trois bits du digit 1 avec des 0 (PAD).
On peut faire servir dans ce cas les bits du SDI, comme par exemple pour l’indication
du cap qu’on a besoin de 6 chiffres (000°00,0’). La place de la virgule pour indiquer les
décimaux et le facteur d’échelle sont associés au label. Dans la figure 1.10 on peir voir un
exemple qui correspond à un mot de de distance au DME.
1.3.3.
15
Données discrètes
Dans ce format chaque bit du mot es relié à un paramètre d’un système concrète, et selon
si il y a un 1 ou un 0 le significat sera différent. Par exemple, dans un mot avec label
005 (Donnés du moteur) peut avoir un bit associé à un paramètre qui indique si il y a un
erreur sur le microprocesseur, si on envoie un 0, il y a un erreur (fail), si on envoie un 1 est
correcte (pass). Dans la figure 1.10 on peir voir un exemple.
Ce format est détaille dans la Partie 2 de la Spécification ARINC 429.
En plus, dans le mot de 32 bits on peut envoyer aussi données discrètes mélangées soit
en format BNR ou BCD. On utilise les bits de remplissage (PAD) en débutant du bit 11
jusqu’à le data pour envoyer ces données discrètes. Si non, on envoie ces bits fixés à 0
(PAD).
F IGURE 1.10 – Exemple des différents formats de données ARINC 429
1.3.4.
AIM (Acknowledgement, ISO Alphabet No 5 and Maintenance
Data)
Dans l’ARINC 429 il y a aussi la possibilité de traite des données reliées à la maintenance
et au messages alphanumériques. Dans ce type de données on un échange une séquence
de messages entre l’émetteur et le récepteur. Les messages alphanumériques sont codés
en ISO Alphabet No 5 (ASCII). Actuellement, ce format est en train d’être substitué par le
Williambsburg/Buckhorn protocol.
1.3.5.
Williamsburg/Buckhorn Protocol
C’est un système pour transférer fichiers entre deux équipements ARINC 429. Est un bit
oriented Protocol et a besoin d’accuses de reçoit et, par conséquent, d’une communication
bidirectionnelle entre les deux sources. On l’utilise surtout pour des communications entre
16
une source de la ligne aérienne et son aéronef. Dans la Partie 3 de la Spécification ARINC
429 il y a une explication plus détaillé du bit oriented Protocol Williamsburg/Buckhorn.
1.4.
Mot ARINC 429 d’altitude
Les données d’altitude sont encodées en BNR. Le label qui corresponds à l’altitude, selon la Spécification ARINC 429 Partie 1, Attachment 1-1, est la 203, voir figure 1.11. On
peut observer qu’il y a d’autres systèmes associés à ce label, comme la température du
réservoir de combustible ou la pression statique, entre d’autres. Cela est parce que dans
un aéronef il y a plus de 255 paramètres à échanger entre plus de 255 systèmes, et avec
8 bits de label n’est pas possible couvrir cette demande. La solution est ajouter un identificateur d’équipement et que chaqu’un sait le sien. Mais, normalement, ces identificateurs
ne sont pas exploités par les fabricants car ils ne branchent que les équipes qui traitent
les mêmes types de données entre eux. Il n’y aura pas une connexion entre un émetteur
du système de combustible et un récepteur du système d’altitude.
F IGURE 1.11 – Label d’altitude
1.4.1.
17
Décodage du mot
On va décoder à mode d’exemple un mot d’altitude extrait de la Spécification ARINC 429
Partie 1, Attachment 6 :
F IGURE 1.12 – Exemple d’un mot d’altitude
Décodage
• Label : 8 premiers bits. L’ordre de réception est : 8, 7, 6,. . ., 1. On les regroupe de
trois en trois en ordre de réception et on fait la conversion en format octal, voir la
table 1.6.
Bit
1
2
3
4
5
6
7
8
1
1
Valeur binaire
1
0
0
0
0
0
Binaire =⇒ Octal
2
0
3
TABLE 1.6 – Interprétation du label d’un mot ARINC 429
18
• Bits 9 et 10 : Normalement correspondent au champ SDI. Dans cette exemple ils
l’ont mis comme bits de remplissage (PAD en Anglais).
• Bit 11 : On l’utilise pour définir la résolution d’altitude (ratio indiqué par chaque bit
successif). Un 1 indique une résolution de 100ft et un 0 de 1 f t . Dans ce cas, on a
une résolution de 1 f t .
• Bits 12-28 : Dans ces bits il y a les données (encodage BNR). Pour les décoder il
fout suivi le processus suivant :
1. Dans un premier temps il faut obtenir le facteur d’échelle, qui est déterminé par
le type de donnée associée au label. Dans ce cas serait 217 = 131072 f t .
2. Le bit 28 est le MSB et est la moitié du facteur d’échelle et les bits successifs
décrémentent son poids en puissance de 2 jusqu’a le bit 12 qui est le LSB. On
peut faire la conversion comme suivi :
Altitude = F.échellemax.
1
1
1
1
Bit28
+
Bit27
+
Bit26
+
·
·
·
+
Bit12
21
22
23
217
(1.1)
Si on substitue les valeurs :
1
1
1
1
1
1 Altitude = 131072 3 + 5 + 8 + 11 + 16 + 17 = 21059 f t
2
2
2
2
2
2
On obtiens une altitude décode de 21059 f t .
• Bit 29 : Bit de signe. Dans ce cas indique une valeur positif.
• Bits 30 et 31 : SSM. Dans ce cas (11) il indique une opération normale.
• Bit 32 : Le bit de parité. Dans ce cas est rempli avec un 0, puisque le nombre de 1
dans le mot es déjà impair, concrètement il y a 11 bits fixés à 1.
Le récepteur doit être préparé pour mener à bien tout ce processus et décoder les données
du mot ARINC 429. En plus, il est le responsable de décoder dans le bon sens le label.
Description du système
19
CHAPITRE 2. DESCRIPTION DU SYSTÈME
Le système conçu pour faire une transmission et une acquisition d’une trame de données
ARINC 429 est composé par les cinq blocs que l’on peut voir ci-dessous :
F IGURE 2.1 – Blocs du système.
1. Maquette d’un tableau de bord d’une Robin DR400 qu’est le point de départ de ce
projet. Il y avait beaucoup de projets déjà faits sur celle-ci.
2. Logiciel développé sous LabVIEW.
3. NI USB-6008.
4. Starter Kit PK-HCS12C32 de Softec Microsystems pour le microcontrôleur Motorola
MC9S12C32.
5. Oscilloscope LeCroy WaveSurfer 44Xs-A.
2.1.
Description des blocs
2.1.1.
Bloc 1 : Maquette
Le bloc maquette est le point de départ de ce projet. Celle-là est composé par :
• Un altimètre modèle ALT20IMF-3 du fabricant Falcon Gauge.
• Un anémomètre modèle ASI 220N-3 du même fabricant.
• Un transpondeur modèle GARMIN GTX330.
• Un alticodeur modèle ACK A-30 Digitizer.
• Un ensemble de tuyaux qui interconnectent les instruments qui ont besoin de pression statique comme l’altimètre, l’anémomètre et l’alticodeur.
• Un NI USB-6008, différent de celui que l’on a nommé dans le diagramme de blocs.
On utilise cet interface USB pour l’acquisition par LabVIEW des données que l’alticodeur envoie au transpondeur.
• Une prise de pression statique.
20
• Une prise de pression totale.
D’autre côté, il y a un logiciel LabVIEW associé qui s’appelle ProjetDR400.vi que l’on
utilise pour visualiser les données que l’alticodeur envoie au transpondeur en temps réel.
Ces données sont acquises par le logiciel ProjetDR400.vi au travers du NI USB-6008 situé
dans la maquette. On peut décoder ces données (codage Gillham), et connaitre l’altitude
du porteur par rapport au niveau de la mer (niveau de vol). Une fois que l’on a acquis
l’altitude, ce programme fait la conversion en binaire et on construit le champ des données
ARINC 429 (bits 13-28) dans un tableau de 32 éléments. Cette dernière opération est faite
par un subvi intégré au programme principal appelé altitude sub dm2.vi. En plus, dans le
logiciel de ce subvi on peut choisir la valeur des champs restants : le label, le SDI, le signe,
la résolution et le SSM, voir la figure A.3 de le Chapitre 1 (Spécification ARINC 429). Si
l’on veut avoir un vrai mot ARINC 429 de données d’altitude, il faut que le label reste tout le
temps fixe à 203, comme défini dans la spécification ARINC 429 pour ce type de données.
Pour finir, ce tableau de 32 éléments est divisé en 4 octets prêts a être émis.
2.1.2.
Blocs 2 et 3 : LabVIEW et NI USB-6008
Le but de ces deux blocs est de traiter ces données d’altitude acquises par la maquette
dans le logiciel ProjetDR400.vi pour les transmettre au travers de l’interface NI USB-6008
(Bloc 3).
LabVIEW est un logiciel de programmation graphique qui à été publié par National Instruments en 1986 et aujourd’hui, grâce à sa programmation rapide et intuitive, c’est un
des software les plus utilisés dans l’ingénierie pour le développement de mesures, test et
contrôle de systèmes sophistiqués.
D’un autre côté, dans cette section on inclut aussi l’interface NI USB-6008 (Bloc 3) puisque
on commande ce dispositif avec LabVIEW. Celui-ci est un dispositif qui permet une acquisition Entrées/Sorties fonctionnelle de données. On peut le commander moyennant LabVIEW ou avec d’autres programmes codés en langage C, .NET, Visual Studio, etc. Le NI
USB-6008 est très utilisé dans les cadres académiques et universitaires. C’est idéal pour
les projets low cost, mais on peut l’utiliser aussi pour des applications plus sophistiquées.
La famille NI USB-6000 a dispositifs supérieurs comme le NI USB-6010 ou le NI USB6011, entre d’autres. Pour ce projet, les performances du NI USB-6008 sont suffisantes.
Le contrôle du NI USB-6008 est fait au travers du driver NI-DAQmx. Dans l’Annexe C on
peut voir ses spécifications.
2.1.2.1.
Logiciel développé
Comme on a déjà dit dans la section (bloc 1), le tableau de 32 éléments est créé et
divisé en 4 octets par le subvi altitude sub dm2.vi contenu dans le logiciel principal ProjetDR400.vi. On le divise pour utiliser la capacité du NI USB-6008, qui a douze Entrées/Sorties
digitales partagées en deux ports, le Port 0 (P0.0 à P0.7) et le Port 1 (P1.0 à P1.3).
Etant donné qu’on ne peut transmettre les 32 bits d’une trame ARINC simultanément, on
a décidé de faire 4 chargements successifs de mots de 8 bits sur le port P0. La mise
21
en forme de ces 4 paquets (4 submots) sera réalisée par le microcontrôleur (Bloc 4) de
manière à générer une trame qui respecte la spécification ARINC 429.
Selon la spécification du NI USB-6008, les Entrées sont de type TTL (0-5V) et les sorties
sont de type collecteur ouvert (0-5V) avec un courant nominal sur chaque sortie de 8.5mA
et un courant maximale sur toutes les sorties de 102mA. Il n’y a pas de limitation dans la
vitesse d’émission ou de réception numérique.
LabVIEW est basé sur une exécution par flots de données qui avance de gauche à droite
et de l’extérieur à l’intérieur des structures de contrôle. Pour commencer à exécuter un
subvi ou une structure de contrôle il faudrait avoir tous les données d’entrée disponibles.
Si ces données ont une dépendance à d’autres subvi et/ou structures de contrôle, le flux
attend que toutes les données soient disponibles avant d’exécuter la structure ou le subvi.
Cette exécution par flots de données implique que les traitements qui n’échangent pas de
données sont libres de s’exécuter en parallèle.
Alors, on peut considérer que la limitation de vitesse est associée au système : l’ordinateur,
l’opérating système, le langage de programmation utilisé, etc. Dans ce projet on a utilisé la
version 2011 de LabVIEW et Microsoft Windows 7 comme système opératif sur l’ordinateur
avec un processeur Intel core i5 avec 4 Gb de RAM appartenant à l’IMA.
Donc, on démarre avec un mot de 32 bits divisé en 4 octets, voir la figure 2.2.
F IGURE 2.2 – Mot de 32 bits divisé en 4 octets.
Pour en arriver à ce résultat, on a développé deux subvi’s. Un pour convertir un octet
entrant en format booléen et l’autre pour transmettre les 4 octets :
F IGURE 2.3 – Interaction entre le altitude sub dm2.vi et Tx 11 bits.vi et Conv8bits.vi.
22
• Le Conv8bits.vi, qui est situé dans le Tx 11bits.vi. Celui-ci a pour rôle de convertir un tableau entrant de huit éléments de type entier en un autre sortant de type
booléen. Comme cela on a un tableau de huit bits.
• Le Tx 11bits.vi, qui se trouve dans le programme principal ProjetDR400.vi et est
relié avec le altitude sub dm2.vi. Ses fonctions sont dans l’ordre suivant :
– Prendre les octets sortants de altitude sub dm2.vi. Les données de ces octets
sont des tableaux à huit positions de type entier.
– Transmettre deux bits de synchronisation sur le port P1 du NI USB-6008, voir
la figure 2.4. Un des bits pour indiquer le début ou la fin d’un mot complet
(jaune), et l’autre pour indiquer qu’il y a un octet prêt a être lu (rouge). On les
appelle strobes de synchronisation. On transmet aussi un bit au début de la
transmission qui permet indiquer au prochain bloc (4) à quelle vitesse doit se
faire l’émission du mot.
F IGURE 2.4 – Bits - strobes de synchronisation.
– Envoyer l’octet qui doit être transmis au subvi Conv8bits.vi pour faire la conversion en booléen.
– Transmettre les huit bits de l’octet qui sont envoyés sur le Port P0 du NI USB6008.
– Retransmettre le strobe rouge pour indiquer au prochain bloc qu’on a envoyé
un octet.
– A la fin du quatrième octet, retransmettre les deux bits de synchronisation
forcés à 0 pour indiquer la fin du mot de 32 bits.
On peut voir le diagramme de blocs complète de chaque .vi dans l’Annexe A.
2.1.3.
Bloc 4 : Starter Kit PK-HCS12C32
Le but de ce bloc est de générer les deux lignes A et B, de la trame ARINC 429. Ces
lignes sont en opposition de phase et contiennent l’information à émettre. Plus tard il y
aura la possibilité de connecter ces 2 lignes vers un émetteur pour générer un signal
différentiel de ±10 V . Cet émetteur pourrait être composé normalement par des amplificateurs opérationnels ou par des commutateurs digitaux intégrés, comme un DG403DJ
qui est déjà utilisé dans un autre projet de l’IMA.
23
Pour générer les deux lignes on utilise le Starter Kit PK-HSC12C32 de SofTec Microsystems qui intègre le microcontrôleur MC9S12C32 appartenant à la famille 68HC12 du
fabricant Motorola, voir l’Annexe C (numèrique). C’est un kit destiné aux débutants dans la
programmation de microcontrôleurs. Il est très utilisé dans le domaine académique, avec
de bonnes performances qui sont très utiles pour beaucoup d’applications. On peut voir
les principales performances et une description dans l’Annexe C (numèrique).
2.1.3.1.
Ports Utilisés
Le microcontrôleur a 80 pins avec plusieurs ports. voir l’Annexe C (numèrique). Chaque
port peut être programmé soit en entrée ou sortie.
Pour réaliser la réception des données issues de LabVIEW on utilise le Port A :
• Celui-ci dispose de 8 broches, PA0, . . . , PA7. Dans notre cas on le programme en
entrée.
Pour réaliser l’émission du mot ARINC on utilise le Port B :
• Celui-ci dispose de 8 broches, PB0, . . . , PB7. Dans notre cas on le programme en
sortie. PB0 pour la ligne A et PB1 pour la ligne B. De plus, on utilise PB7 vers
une LED pour représenter le signal Strobe rouge. Dans la configuration de base du
kit, ce port B est relié physiquement vers des LED pour visualisation de la section
DEMO, mais seul PB0, PB1 et PB7 sont utilisés.
Pour la synchronisation avec la couple bloc 2 & 3 et la détermination de la vitesse d’émission
de la trame ARINC 429 on utilise le Port T :
• Celui-ci dispose de 8 broches, PT 0, . . . , PT 7. Ce port donne accès au Timer Module, et on peut ainsi réaliser différentes fonctions avec le registre de temporisation
du MC9S12C32, aussi bien sur les entrées que sur les sorties. Les cinq premières
broches on peut les utiliser comme sortie Pulse-Width Modulation (PWM), ceci est
très utile pour le contrôle des moteurs à DC1 . Dans notre cas on le programme en
entrée pour la réception des deux bits de synchronisation (strobe jaune PT0, strobe
rouge PT2), et le bit de vitesse (PT1).
On peut voir que les ports utilisés ne sont pas groupés sur le même connecteur, mais on
aurait pu tout regrouper sur un seul connecteur. On pourrait avoir utilisé le Port T pour la
réception des données issues de LabVIEW au lieu du Port A et le Port P pour la synchronisation au lieu du Port T, voir figure 2.5. Mais l’on veut qu’un seul kit pour gérer toutes les
requêtes du projet DR400.
Ce projet est coordonné à celui que l’on explique dans la deuxième partie du rapport, et
qui a besoin de quatre sorties PWM. Le PWM intégré au microcontrôleur est accessible
1
Courant Continu
24
F IGURE 2.5 – Connecteur 1 du Starter Kit PK-HSC12C32.
sur le Port P. Alors, on a substitué le Port P par le Port T pour la synchronisation avec
la couple bloc 2 & 3 et la détermination de la vitesse d’émission, et le Port T par le Port
A pour la réception des données issues de LabVIEW. Par conséquent, on a du fabriqué
deux bus indépendants. Chaque bus a un connecteur femelle de 20 broches d’un côté, et
de l’autre côté on a connecté les fils de notre intérêt au NI USB-6008, voir la figure 2.6.
F IGURE 2.6 – Branchement USB6008-Microcontrôleur.
2.1.3.2.
25
Synchronisation avec LabVIEW
En ce qui concerne la synchronisation entre les blocs 2 et 3 (LabVIEW-NI USB-6008) et le
bloc 4 (microcontrôleur) on a utilisé une communication unidirectionnelle c’est-à-dire sans
accusé de réception (acknowledge). Le but est que le bloc microcontrôleur doit savoir à
quel moment il y a des données sur le port A prêtes a être lues. Dans la figure 2.7 on peut
voir l’algorithme désigné pour réaliser cette synchronisation et les instructions en langage
C associées pour son implémentation sur le microcontrôleur. La structure de contrôle la
plus commune est do ; while, qui correspond aux attentes des différentes combinaisons
des bits de synchronisation. Cette instruction veut dire répéter ”quelque chose” tant que.
Dans ce cas on répète l’exécution de la boucle while tant que la condition est fausse. De
cette façon on attend que les bits de synchronisation du Port T (PT0 et PT2) indiquent
dans l’ordre :
1. qu’il n’y a pas des mots en cours de transmission : Jaune & Rouge = 0 ;
2. qu’il y a un mot qui commence à se transmettre : Jaune = 1 & Rouge = 0 ; et,
3. qu’il y a un octet prêt à être lu sur le Port A : Jaune = 1 & Rouge = 1.
On lit l’octet, on le met dans un tableau pour le traiter. Ensuite on attend que les bits de
synchronisation du Port T (PT0 et PT2) indiquent par ordre :
4. qu’il y a un changement d’octet : Jaune = 1 & Rouge = 0 ; et,
5. qu’il y a un nouveau octet prêt à être lu sur le Port A : Jaune & Rouge = 1.
Ces deux dernières opérations sont réalisées quatre fois, jusqu’à compléter les 32 bits du
mot ARINC 429. Le microcontrôleur est suffisamment rapide pour ne perdre aucun octet
pendant le traitement et arriver à lire le prochain octet sans problème. Il est plus rapide
que le couple LabVIEW - NI USB-6008 (blocs 2 & 3). Ensuite il faut attendre que les bits
de synchronisation indiquent la fin du mot de 32 bits :
6. Jaune & Rouge = 0.
26
do ; w h i l e ( ! ( PTT PTT0==FALSE && PTT PTT2==FALSE ) ) ;
do ; w h i l e ( ! ( PTT PTT0==TRUE && PTT PTT2==FALSE ) ) ;
do ; w h i l e ( ! ( PTT PTT0==TRUE && PTT PTT2==TRUE ) ) ;
f o r ( c o m p t e u r o c t e t =0 ; c o m p t e u r o c t e t < 4 ; c o m p t e u r o c t e t ++ )
{
submotarinc [ c o m p t e u r o c t e t ] =PORTA;
}
Nmotarinc ++;
F IGURE 2.7 – Organigramme de syncrhonisation et le codage C associé.
2.1.3.3.
Analyse du programme
Pour générer les deux lignes de la trame ARINC on a développé plusieurs fonctions et
un programme principal. On considère que le programme doit couvrir les cinq exigences
suivantes :
1. Faire une synchronisation correcte avec le bloc antérieur (Blocs 2 & 3), couple LabVIEW - NI USB-6008.
2. Lire l’octet quand il est disponible sur le Port A.
3. Mettre en place les quatre octets lus et créer un mot de 32 bits.
4. Générer les deux lignes, A et B, et vérifier la parité.
27
5. Émettre sur le Port B le mot ARINC 429 à la vitesse demandé par l’utilisateur.
Dans l’Annexe B il y a la traduction à langage C de ces cinq exigences avec une explication
plus détaillé.
2.1.3.4.
Détermination de la vitesse
Dans la spécification ARINC 429 il y a deux débits permis : 100 kbps (rapide) ou 12 - 14,5
kbps (lente), voir le Chapitre 1 (Spécification ARINC 429). Afin de pouvoir choisir la vitesse,
on a ajouté un interrupteur dans le logiciel Tx 11 bits.vi que l’utilisateur peut actionner, voir
figure A.3 de l’Annexe A. Cet interrupteur actionne un bit que l’on transmet sur le Port
P1.2 du NI USB-6008 à la broche PT1 du microcontrôleur. Si le microcontrôleur reçoit un
1 (interrupteur actionné) il fera l’émission du mot ARINC 429 en vitesse rapide. D’un autre
côté, si le microcontrôleur reçoit un 0 (interrupteur non actionné), il fera l’émission du mot
ARINC 429 à vitesse lente.
On a choisi une valeur de 13,5 kbps pour la vitesse lente car il est plus simple d’obtenir
cette vitesse avec le microcontrôleur par rapport à 12.5 kbps. On peut voir dans la figure
2.8 les signaux des deux vitesses ainsi que les périodes :
F IGURE 2.8 – Signaux des deux vitesses ARINC 429.
Pour réaliser l’émission à ces vitesses avec le microcontrôleur en respectant l’encodage
bipolaire RZ on a utilisé la technique qui est expliquée à l’Annexe B (fonction EmettreARINC). On maintiens un temps déterminé la valeur, NULL et après la valeur HIGH/LOW,
sur le Port B. Ce temps dépend de la vitesse sélectionnée par l’utilisateur. Mais, celui ci
n’est pas choisi par hasard. On sait que l’oscillateur du kit travaille à 16 MHz, mais par
défaut, le microcontrôleur divise cette fréquence par deux. Comme celà, on a deux horloges de 8 MHz chaqu’une (une interne dont on n’a pas d’accès et une autre que l’on peut
contrôler). De cette façon, le microcontrôleur utilise deux clocks, chaqu’un à 8 MHz, pour
gérer le temps d’exécution des instructions, voir la figure 2.9.
Donc, on a accès à un signal carré de 8 MHz, avec une période (T) de 125 ns, qui en
même temps est la durée d’un cycle. Avec cette donnée et une simple opération on peut
28
F IGURE 2.9 – Signal d’horloge et des clocks de buses.
calculer combien de cycles d’horloge il faut maintenir la valeur sur le Port B pour émettre
le mot ARINC 429 à la vitesse désirée :
cycles nécessaires =
Td ésirée
Tclock
(2.1)
Pour la vitesse rapide :
10µs
= 80 cycles
125 ns
74µs
= 592 cycles
125 ns
Pour la vitesse lente :
Dans la figure 2.10 on peut voir un échantillon du signal ARINC 429 transmis aux deux
vitesses stipulées et ses périodes traduites en cycles. Comme on fait l’émission avec un
encodage bipolaire RZ, on a deux pauses à faire pendant une période. Une pour le retour
à zéro et l’autre pour la valeur du bit, HIGH ou LOW. Est évident qu’à chaque pause lui
correspond la moitié des cycles d’une période. Dans le cas de la vitesse rapide, chaque
pause doit être de 40 cycles, et dans la vitesse lente doit être de 296 cycles.
F IGURE 2.10 – Signaux ARINC 429 traduites en cycles d’horloge.
29
Pour mener à bien le nombre de cycles associé à ces pauses on a utilisé le debugger du
Freescale Codewarrior, compris dans le kit HCS12C32.
On fixe un breakpoint à l’instruction PORT B = 0 (NULL) et un autre à l’instruction PORT B =
port &255 (HIGH/LOW). Comme cela, avec l’aide du debugger, on peut compter le nombre
de cycles entre chaque instruction. Grâce aux délais crées à partir des boucles for, quelques
fois complétées par des instructions asm nop, on a ajusté le nombre de cycles nécessaires
entre les deux instructions d’écriture sur le Port B afin de maintenir la valeur et faire les
pauses correspondantes à l’encodage bipolaire RZ selon la vitesse choisie.
Mais, le nombre d’instructions qu’il y a entre PORT B = 0 et PORT B = port &255 n’est
pas le même qu’il y a entre PORT B = port &255 et PORT B = 0. Par conséquent, le
nombre de cycles n’est pas identique, voire la figure 2.11. Par cette raison on a crée
différents délais pour attendre les mêmes cycles entre ces deux instructions.
Pour ajuster les cycles des délais, on a utilisé le debugger en mode Full Chip Simulation.
Ce programme C complet on le peut consulter dans l’Annexe B.
30
F IGURE 2.11 – Cycles de CPU entre les deux instructions qui écrivent sur le Port B.
2.1.4.
Bloc 5 : Oscilloscope LeCroy WaveSurfer 44Xs-A
Le but de ce dernier bloc est l’affichage de la trame ARINC 429 que l’on a généré. Pour
cela, on utilise un oscilloscope LeCroy WaveSurfer 44Xs-A.
Cet oscilloscope a un décodeur série qui permet d’analyser les données de plusieurs
standards de communication comme le bus CAN ou la spécification ARINC 429, entre
autres. Dans ce projet on n’utilise que l’option de décodage ARINC.
LeCroy WaveSurfer 44Xs-A présente l’avantage d’être basé en Windows XP et on peut
lui fixer une adresse IP pour y accéder au travers d’Internet et visualiser l’écran sur un
ordinateur, par exemple.
En plus, le fabricant LeCroy a prévu l’acquisition des données sur le logiciel LabVIEW
moyennant son adresse IP. On est arrivé à afficher sur LabVIEW les deux lignes, A et B,
31
de la trame ARINC 429 émise par le microcontrôleur (Bloc 4), figure 2.12, mais on n’est
pas arrivé à acquérir le signal différentiel (fonction math de l’oscilloscope) ni à le traiter.
F IGURE 2.12 – Affichage sur LabVIEW.
Dans la partie III, entre d’autres propositions pour la suite du projet, on propose le développement
d’un logiciel LabVIEW capable d’acquérir la trame ARINC 429 de l’oscilloscope et de la
décoder.
Les drivers qu’on a installés dans l’ordinateur pour acquérir le signal de l’oscilloscope sur
LabVIEW via TCP/IP sont :
• Drivers de LeCroy qu’on a pu trouver dans la page web :
– LeCroy VICP Passport.
– IVI Shared Components 2.2.1. ce serait recommandable avant, installer et
exécuter le IVI Clean Up Utility qui est dans le même endroit ;
– X-Stream DSOs qui est un driver de type IVI-C and IVI-COM. Le fichier s’appelle IVI Driver 3.2.2.0-x86.
• Drivers de LabVIEW qu’on les peut trouver dans la page web de National Instruments :
– LeCroy Wave Series Oscilloscope,Analyzer qui appartiens au Certified LabVIEW Plug and Play Instrument driver. En plus, ce driver a des exemples pour
l’acquisition et le traitement des signales.
32
En ce qui concerne le décodeur série ARINC 429, on peut lui indiquer comme faire le
décodage. Dans la configuration de base il a trois options :
• 8 + 24 : Il interprète les 8 bits du label et les 24 restants comme champ de données ;
• 8 + 2 + 19 + 2 + 1 : Il fait l’interprétation générale de la Spécification ARINC
429, dont il y a 8 bits qui appartiennent au label, 2 bits du SDI, 19 pour le champ
des données, 2 bits du SSM et 1 bit de parité, et ;
• User Defined : où l’on peut charger un fichier de type Comma Separated Values
(CSV) et que LeCroy appelle User Label Description File (ULDF). On peut l’édité et
personnalisé pour décoder les différents champs du mot. Ce fichier doit être composé de 12 à 14 ULDF Tokens (objets). Ces objets sont ; Label 1 , EquipmentID2 ,
Name3 ,Units1 , Min5 , Max6 , SigBits7 , PosSense8 , Resolution9 , MinTransit 10 ,
MaxTransit 11 , LabelType112 , O f f set 13 , DetailsList 14 .
Par exemple, on peut éditer ce fichier pour décoder un mot d’altitude (BNR), avec
label 2032 :
/ / Label , EqptID , Name, U n i t , Min , Max , S i g B i t s , PosSense , Resol , MinTr , MaxTr , LabelType , O f f s e t , D e t a i l L i s t
203 ,6 , A l t i t u d e , f e e t s ,0 ,131072 ,17 , PosSen , 1 , 1 1 1 , 2 2 2 , L a b e l B i n a r y , 1 1
Avec cette configuration on est arrivé à décoder le mot ARINC 429 comme ci-dessous :
F IGURE 2.13 – Première capture sur l’oscilloscope avec le label inversé.
Dans l’image, on voie comme le décodeur ne reconnait pas le champ des données,
puisque le label qui a été décodé est le 301 et dans le ULDF on n’a spécifié que le
décodage pour le 203.
Pourtant, on peut ajouter au User Label Description File tous les labels qu’on veut et ils
auront les paramètres associés qu’on lui spécifique.
Comme on a émis le mot avec un label 203, et l’oscilloscope a interprété le 301, il a fallu
faire plus d’attention au décodage du label réalisé par le décodeur série ARINC 429 de
l’oscilloscope.
2
On a demandé support technique à LeCroy pour éditer le fichier puisque il n’y avait pas d’exemples
dans l’aide de l’oscilloscope ni dans sa page web. Ils nous ont envoyé un fichier d’exemple et documentation
associée qui nous a permit de l’éditer à notre convenance et qu’on la peut consulter dans l’Annexe C (version
numérique associé au projet)
33
Pour essayer de comprendre l’origine de l’ambigüité, on a consulté la spécification ARINC
429 selon laquelle la transmission du label est réalisée en tête du mot et en ordre inverse :
bits 8, 7, 6, 5, 4, 3, 2, 1. Dont le bit le plus fort est le bit 1, et le bit le plus faible est le bit 8.
En plus, il faut que le décodeur du récepteur les regroupe de trois en trois, selon l’ordre de
réception et fasse la conversion en octal en considérant que le bit le plus fort est le bit 1.
D’un autre coté, on a parlé avec le support technique de LeCroy pour savoir comment
l’oscilloscope interprète le champ du label mais ils sont en train de réfléchir pour nous
donner une réponse.
En attendant une réponse de LeCroy, on a pensé trois hypothèses qui peuvent aider à
comprendre l’origine de cette ambigüité selon le problème :
• Problème 1 : L’interprétation de la position du bit le plus fort (Most Significant Bit
(MSB)).
– Hypothèses :
* Le LSB est le bit 8 et le MSB est le bit 1. Option que l’on croit correcte et
qu’on a verifié avec la Spécification ARINC 429 Part 1 qu’on peut trouver
à l’Annexe numèrique.
* Le LSB est le bit 1 et le MSB est le bit 8. Cela qui interprète l’oscilloscope
et quelques fabricants comme AIM ou CONDOR Engineering dans sa
documentation 3 .
• Problème 2 : Ordre de transmission du label. Dans ce cas toutes les spécifications
son d’accord et il présente moins d’ambigüités :
– Hypothèse :
* Le décodeur de l’oscilloscope LeCroy WaveSurfer 44Xs-A ne prends pas
en compte que le label est transmit en sens inverse, mais il considère, au
contraire que dans le cas antérieur, que le MSB corresponds au bit 1.
3
Cette documentation on la peut consulter sur l’Annexe C(support numérique), et dans AIM il y a aussi
des ambigüitées avec le label
34
On pense que cette dernière hypothèse est la plus correcte, puisque si on suppose vers
la figure 2.13 qu’on fait l’émission sans invertir le label et en considérant que le MSB est
le bit 1, le décodage devient 203, voir figure 2.144 .
F IGURE 2.14 – Label sans inverser.
En résumé, le décodeur série de l’oscilloscope attends le label sans inverser : 1, 2, 3, 4,
5, 6, 7, 8, et il ne serve que pour tester que la trame qu’on envoie est correcte (label pas
inversé). Une fois on vérifie cette procède on inverse le label et on émit le mot.
De cette façon, comment le récepteur va bien décoder la trame (il est programmé pour
lire le label dans le bon sens), on saura que les données qu’il va recevoir sont les qu’on a
envoyé.
Pour l’instant, pour résoudre cette situation, on a édité le fichier ULDF avec un label 301
pour pouvoir décoder les données du mot ARINC 429 qu’on émit. En plus, pour améliorer
l’adaptation du décodeur série de l’oscilloscope on a choisi un label type pour données
binaires discrètes et on a ajusté les champs des données aux bits 12 à 28.
Bien que le label 203 est associé à un encodage BNR, on a pris l’antérieur puisque on
a considéré que le label type pour données binaires n’était pas le plus adapté. Ce label type(binaire) prend les bits 11 à 29 comme champ de données, mais le bit 11 correspond à la resolution et le bit 29 au signe qu’on spécifique dans le fichier ULDF, avec les
objets PosSense et Resol.
Fichier ULDF édité avec label 301 et le label type configuré pour décoder données binaires
discrètes :
/ / Label , EqptID , Name, U n i t , Min , Max , S i g B i t s , PosSense , Resol , MinTr , MaxTr , LabelType , O f f s e t , D e t a i l L i s t
203 ,6 , A l t i t u d e , f e e t s ,0 ,131072 ,17 , PosSen , 1 , 1 1 1 , 2 2 2 , L a b e l D i s c r e t e , 1 1
4
Cette capture n’est pas réel, c’est un montage graphique pour démontrer que l’oscilloscope ne prends
pas en compte le label transmis en sens inverse.
2.2.
35
Résultats
L’implémentation des cinq blocs donne comme résultat une communication complète ARINC
429. Dans un premier temps, on fait monter l’altimètre, et le transpondeur reçoit de l’alticodeur l’altitude par rapport au niveau de la mer, voir la figure 2.15.
Ensuite, on acquit cette altitude au travers du logiciel LabVIEW ProjetDR400.vi qui fait le
décodage du code Ghillam en altitude et construit le mot ARINC 429, figure 2.16.
De plus, avec les subvi’s que l’on a développés (Conv8bits.vi et Tx 11bits.vi du bloc 2)
et au travers du NI USB-6008 (bloc 3), on transmit le mot de 32 bits qui est divisé en
4 submots, de 8 bits chaq’un, au microcontrôleur (bloc 4). Ce bloc, regroupe ces quatre
submots et reconstruit le mot de 32 bits. Il génère les deux lignes, A et B, et fait l’émission
du mot à la vitesse choisie par l’utilisateur sur LabVIEW, en respectant la spécification
ARINC 429, figure 2.17 (13.5 kbps) et figure 2.18 (100kbps).
Finalement, le bloc 5 (Oscilloscope LeCroy WaveSurfer Xs-A), avec son décodeur série
ARINC 429, devient le récepteur.
F IGURE 2.15 – Maquette avec une indication de 700ft.
36
F IGURE 2.16 – Indication LabVIEW.
37
F IGURE 2.17 – Mot émis à 13,5 kbps.
38
F IGURE 2.18 – Mot émis à 100 kbps.
Deuxième partie
Planning et diagramme de Gantt
40
Pendant la période du stage on a développé plusieurs activités. Le but principal dans ce
chapitre c’est d’expliquer les différentes étapes et difficultés que l’on a rencontrées.
L’image suivante montre la distribution du temps destiné à chaque tâche qu’on a réalisée :
F IGURE 2.19 – Diagramme de Gantt.
41
Dans un premier temps, on a fait une mise à jour pour connaı̂tre tout le développement du
projet réalisé antérieurement et se familiariser avec les boı̂tes de contrôle à utiliser. (Id.1)
Ensuite, on a commencé à travailler dans l’application des logiciels en LabVIEW pour
tester le fonctionnement du NI-6008. Les différents essais avaient comme but principal
d’allumer et d’éteindre plusieurs LED’s au travers de leur sélection dans le logiciel. (Id.2)
F IGURE 2.20 – Exemple d’un test réalisé avec des LED’s.
L’étape suivante a été le dessin de l’organigramme et le développement du logiciel en C
pour l’ARINC 429. (Id.3)
Après cette partie initiale on a commencé la réalisation des deux parties du projet en
parallèle :
• Phases principales de déroulement du système ARINC 429.
Dans une première phase, on a debuggé la fonction CalcParite, déjà faite, car il y avait une
erreur. Dans cette étape on est arrivé aussi à afficher sur l’oscilloscope la trame ARINC
429 envoyée à vitesse lente. (Id. 5)
Ensuite, on a travaillé pour déterminé les deux vitesses de transmission de l’ARINC 429
en deux programmes différents que l’on a ajusté aidés par l’oscilloscope YOKOGAWA
DLM2024, figure 2.21. (Id. 8)
Après, on a testé le fonctionnement d’une carte électronique avec des commutateurs
DG403DJ qui a été réalisé par d’autres étudiants Erasmus. Cette carte génère une signale
différentielle +/- 10V de la trame ARINC 429 avec deux lignes, A et B, comme entrées. Il
a fallu réviser la documentation que les élèves avait fait, mais on n’a pas trouvé le chemin
électrique de la carte ni la spécification de fonctionnement. Finalement le résultat obtenu
n’a pas été satisfaisant et on la pas utilisée. (Id. 9)
La prochaine phase que l’on a fait, c’est l’implémentation des deux vitesses de transmission sur le même programme en ajoutant un bit qui permet de choisir une des vitesses.
(Id.10)
Finalement on a traité d’ajuster l’oscilloscope LeCroy qui permet décoder une trame ARINC
429. (Id.14)
42
F IGURE 2.21 – Measure de la fréquence pour bien déterminer la vitesse de 12,5 kbps
• Phases principales de déroulement du système Pousse Seringue.
Les phases principales de déroulement du système Pousse Seringue sont expliquées
dans le projet Système de génération de pressions anémobarométriques qui est coordonné avec celui.
Mais, pendant cette partie on a développé ensemble aussi une Maquette d’instruments
gyroscopiques.
La durée du développement de cette maquette (Id.7) a été d’une semaine et la tâche principale que l’on a réalisée est l’installation et la connexion des éléments qui la composent :
• Un magnétomètre SP-6 de la marque MGL Avionics.
• Un capteur d’attitude SP-7 de MGL Avionics.
• Deux instruments passifs AV-1 et AV-2 de MGL Avionics - Stratomaster Infinity qui
peuvent afficher selon le choix du pilote :
– Horizon artificiel ;
– Bille ;
– Indicateur de virage ;
– Compas ;
– Conservateur de cap.
43
• Une sortie pour l’oscilloscope.
• Un interrupteur qui permet d’allumer et d’éteindre le système sans avoir besoin de
débrancher.
On a réalisé aussi un support en carton et PVC pour tenir les instruments et pouvoir les
manipuler.
F IGURE 2.22 – Images de la maquette des instruments gyroscopiques.
Finalement, le personnel de l’IMA a obtenu un avion Playmobil® et un trépied pour les
ajouter au système et améliorer sa manipulation.
En ce qui concerne la durée finale du stage, elle a été allongée puisque il a fallu refaire
toute la rédaction du rapport en français alors qu’on l’avait faite en espagnol/catalan dans
un premier temps. Au début, la soutenance devait être effectuée à Barcelone mais avec
Mr. Michaud et Mr. Jordi Berenguer on a décidé que ce serait mieux de la présenter à
l’IMA.
D’autre part, pendant toute l’évolution du projet on a eu besoin de faire des recherches
d’information pour rédiger le rapport.
44
Conclusions
45
CHAPITRE 3. CONCLUSIONS
Les principaux buts de notre stage à l’IMA ont été la transmission d’une trame ARINC 429
de données d’altitude et la fabrication d’un système générateur de pressions.
Dans le premier cas, on est bien arrivés à transmettre une trame en respectant la spécification
ARINC 429 vers le microcontrôleur. De plus, on a synchronisé une communication LabVIEW - Microcontrôleur. Ainsi on a pu ajuster les deux débits d’émission permis par
l’ARINC 429 en contrôlant les cycles d’horloge du microcontrôleur.
On a configuré aussi l’oscilloscope LeCroy WaveSurfer 44Xs et édité un fichier qui nous a
permit de décoder la trame ARINC correctement sauf pour le label. Mais on a fait des hypothèses qui peuvent aider à comprendre le fonctionnement du décodeur série ARINC429
de l’oscilloscope surtout pour le champ ”label” pendant qu’on attend une réponse des
ingénieurs de LeCroy. Par contre, on n’est pas arrivé à acquérir et décoder les données
des mots sur LabVIEW au travers de l’adresse IP de l’oscilloscope mais on est arrivé a
recopier l’image de l’écran sur une page web en temps réel.
Pendant cette formation, nous avons acquis et amélioré nos connaissances dans plusieurs
domaines théoriques comme la spécification ARINC 429, le code Gillham (SSR Mode C),
le code SQUAWK du transpondeur (SSR Mode A), le système Pitot-Static des avions, le
fonctionnement interne des instruments du cockpit mais aussi dans le langage de programmation C orienté aux microcontrôleurs et du logiciel LabVIEW.
Avis personnel
Nous apprécions bien l’opportunité qui nous a été donnée, et qui nous a permit d’acquerir
des connaissances à partir du projet DR-400, ainsi que dans le cadre du travail et de la
vie en France.
Enfin, nous tenons à exprimer notre satisfaction d’avoir travaillé dans un environnement
agréable et un matériel aussi spécifique lié à l’aéronautique.
46
Troisième partie
La suite
48
Enfin dans cette dernière partie, on présente quelques propositions pour la suite du projet.
En effet, nous finissons notre stage mais il est possible que d’autres étudiants suivent ce
projet.
On pense que ce serait intéressant de faire l’acquisition sous LabVIEW de la trame ARINC
429 qu’on affiche sur l’oscilloscope avec son adresse IP. Par exemple, on pourrait développer
un logiciel LabVIEW pour décoder la trame ARINC 429, comme le ferait un récepteur. De
cette façon, on fermerait une connexion émetteur-récepteur d’une trame ARINC 429. Dans
la section 2.1.4. de la Partie I, on a déterminé les drivers à utiliser pour l’acquisition d’un
signal de l’oscilloscope sous LabVIEW à partir de son adresse IP.
Finalement on propose aussi l’intégration du logiciel du système générateur de pressions
dans le ProjetDR400.vi, et de faire alterner les mots de 8 bits de la transmission ARINC
429 avec le mot de 8 bits du Système de génération de pressions anémobarométriques et
tout gérer à partir du même logiciel.
Bibliographie
[1] Way Huang, Han. HCS12/9S12 An Introduction to Software and Hardware Interfacing.
(Delmar. Minnesota, USA. 2010)
[2] Condor Engineering. ARINC Protocol Tutorial. (Condor Engineering, Inc. Santa Barbara, USA. 2004)
[3] AIM GmbH. ARINC 429 Specification Tutorial. (AIM GmbH. Freiburg, Germany. 2001)
[4] AIRLINES ELECTRONIC ENGINEERING COMMITTEE. ARINC Specification Part 1 17. (AERONAUTICAL RADIO, INC.. Maryland, USA. 2004)
[5] Federal Aviation Administration. Instrument Flying Handbook. (US Department of
Transportation. Washinton DC, USA. 2008)
49
ANNEXES
Logiciels LabVIEW
53
ANNEXE A. LOGICIELS LABVIEW
On montre les deux .vi qu’on a développé pour la transmission des bits au microcontrôleur.
On les peut trouver dans le support numérique associé au projet.
• Tx 11bits.vi
F IGURE A.1 – Bloc Diagram Tx 11bits.vi
• Conv8bits.vi
F IGURE A.2 – Bloc Diagram Conv8bits.vi
• altitude sub dm2.vi
F IGURE A.3 – Front panel altitude sub dm2.vi, indication en rouge sur le bouton qu’on a
ajouté et qui permet de choisir la vitesse
Analyse du programme C
55
ANNEXE B. ANALYSE DU PROGRAMME C
Traduction à langage C des cinq exigences du programme C qu’on a établi dans la section
2.1.3.3. de la première partie :
1. Expliqué dans la subsection 2.1.3.2. de la première partie.
2. Pour lire l’octet on a crée un tableau de quatre éléments qui s’appelle submotarinc.
Pour mettre chaque octet dans sa place correspondante du tableau on a utilisé le
compteur compreuroctet qui s’incrémente avec les itérations de la boucle for.
//
lire
l ’ o c t e t sur Port A
3. Pour mettre en place les 4 octets et créer un mot de 32 bits on a utilisé une boucle
for pour remplir le tableau motA de 32 éléments que l’on a créé pour celà.
for
( i =1 ; i < 9 ; i ++)
/ / Metre l ’ o c t e t s u r l a p l a c e q u i l e correspond
{
}
motA [ i −1 + c o m p t e u r o c t e t * 8]= ( submotarinc [ c o m p t e u r o c t e t ] & p u i s s 2 ( i −1) ) >> ( i − 1);
Le premier problème rencontré est d’isoler chaque bit des octets reçusen bits afin
de le diriger vers un tableau de 32 éléments. On le fait avec l’instruction :
( submotarinc [ c o m p t e u r o c t e t ] & p u i s s 2 ( i −1) ) >> ( i −1)
On explique ci dessous cette instruction avec un exemple :
• On suppose qu’on veut issoler le quatrième bit de l’octet #2, voir la figure B.11 .
Pour isoler le bit de l’octet, on a utilisé les opérateurs de traitements de bits
AND (&) et décalage à droite (valeur à d écaler >> nombre de d écalages).
De plus, la fonction puiss2 fait la puissance de 2 reçu par valeur. Alors, si
l’octet #2 = 10010001 et i=4, car on veut le bit 4 :
bit4 = 10010001 & 23 >> 3 = 10010001 & 00001000 >> 3
3 bits au droite
*
bit4 = 00000000 >> 3 = 00000
000
= 0
Si on change la valeur de l’octet #2 à 10011001 :
bit4 = 10011001 & 23 >> 3 = 10011001 & 00001000 >> 3
3 bits au droite
*
bit4 = 00001000 >> 3 = 00001
000
= 1
Le deuxième problème rencontré est de mettre le bit déjà isolé à sa place correspondante dans le motA de 32 éléments, mais c’est plus facile à résoudre. On le fait
avec la instruction :
( submotarinc [ c o m p t e u r o c t e t ] & p u i s s 2 ( i −1) ) >> ( i −1)
Si on continue l’exemple précédent, et on considère l’expression suivante :
Pos = i − 1 + compteuroctet × 8
1
Les bits de l’octet reçu sont séparés par lignes plus fines pour remarquer que l’octet est un nombre
entier
Pos = 4 − 1 + 1 × 8 = 11
On peut voir que au bit 4 de l’octet #2 lui correspond la position 11 du motA, qui
commence à 0.
F IGURE B.1 – Exemple grapique du placement du bit 4 de l’octet #2
4. On génère les deux lignes, A et B, et on vérifie la parité avec la fonction CalcParite,
qui reçoit en référence les tableaux de 32 éléments MotArincA et MotArincB.
v o i d C a l c P a r i t e ( s h o r t MotArincA [ s i z e A r i n c 4 2 9 ] , s h o r t MotArincB [ s i z e A r i n c 4 2 9 ] )
{
unsigned s h o r t j ;
unsigned s h o r t p a r i t e l u e ;
/ / MotArincA gere l e s 1 −−− MotArincB gere l e s 0
MotArincA [32 − 1]=1;
/ / i n i t p a r i t é i m p a i r e a 1
f o r ( j =0; j <32−1; j ++)
{
/ / CALCULER l a p a r i t é i m p a i r e en comptant des b i t s a 1 parmis l e s 31 p r e m i e r s
i f ( MotArincA [ j ] = = 1 )
{
MotArincA [ s i z e A r i n c 4 2 9 − 1]=˜ MotArincA [ s i z e A r i n c 4 2 9 − 1]&1;
}
MotArincB [ j ] = ˜ MotArincA [ j ] & 1 ; / / f a b r i q u e r l e s i g n a l i n v e r s é B
}
//
i f ( p a r i t e l u e == MotArincA [32 − 1]) ;
/ / A f f e c t a t i o n b i t p a r i t é s u r bus B
MotArincB [ s i z e A r i n c 4 2 9 − 1]=˜ MotArincA [ s i z e A r i n c 4 2 9 − 1]&1;
}
Le concept est que la ligne A soit à l’état HIGH quand la ligne B soit à l’état LOW.
En plus, on recalcule la parité impaire comme redondance du système. Ensuite, on
fait une description du conjoint d’instructions qui font le calcule de la parité impaire
et qui construisent le tableau MotArincB :
• Fixer à 1 le bit 31 du MotArincA, parité impaire au début.
• Parcourir le tableau MotArincA, qui correspond au motA du programme principal. Si dans une position on trouve un 1, on fait l’inversion du bit 31 avec
l’opérateur de traitement de bit complément à 1 (∼). Ensuite, avec l’opérateur
AND (&) on sélectionne le premier bit de la valeur qui va être mise dans le
champ de la parité (bit 31). Par exemple, si les premières cinq positions du
tableau MotArincA ont 1 | 0 | 1 | 0 | 1 , et on fixe la parité impaire au début :
bit31 =∼ bit31 &1
(B.1)
– Iteracion #1 ⇒ bit31 =∼ 1&1 = 0&1 = 0 ⇒ le nombre de 1’s est déjà
impair, la parité change à 0.
– Iteracion #2 ⇒ N’accomplit pas la condition du if ⇒ le nombre de 1’s
continue impair, la parité est maintenue à 0.
– Iteracion #3 ⇒ bit31 =∼ 0&1 = 1&1 = 1 ⇒ le nombre de 1’s est pair, la
parité change à 1.
– Iteracion #4 ⇒ N’accomplit pas la condition du if ⇒ le nombre de 1’s
continue pair, la parité est maintenue à 1.
– Iteracion #5 → bit31 =∼ 1&1 = 0&1 = 0 ⇒ le nombre de 1’s est déjà
impair, la parité change à 0.
La parité résultant après ces instructions est 0. Rappeler la spécification ARINC
429 : il faut fixer la parité pour avoir un nombre de 1 impair.
• Créer la signal LOW dans le tableau MotArincB, qui est l’inverse du tableau
MotArincA. On complète chaque élément indiqué par le compteur j avec le
résultat d’inverser l’élément équivalent du MotArincA. En plus, il y a l’operateur AND (&) que l’on l’utilise pour sélectionner le premier bit de la valeur du
résultat. On fait 31 itérations comme celle-là. Pour finir, quand on sort de la for,
on fixe la parité du MotArincB inverse à cela qu’il y a au tableau MotArincA.
5. Pour finaliser, on émet les deux lignes, A et B, sur le Port B avec la fonction EmettreARINC :
v o i d EmettreARINC ( )
{ unsigned s h o r t i ;
unsigned s h o r t p o r t ;
/ / s e r i e de mots ARINC a t r a n s m e t t r e v i t e s s e l e n t e
f o r ( i =0; i <s i z e A r i n c 4 2 9 ; i ++)
{
PORTB=0;
delay ( 1 ) ;
p o r t = ( motB [ i ]<<1) | motA [ i ] ;
motEmis [ i ] = p o r t
;
/ / delay ( 1 ) ;
PORTB= p o r t &255;
delay ( 1 ) ;
//
//
//
//
p r e m i e r mot pour 4 bus s u r p o r t B
ETAT NULL
Tx à 12 ,5 kbps ;
envoyer l e code s u r l e s LED 0 & 1
/ / B i t a 0 ou 1 pour codage RZ
/ / Tx à 12 ,5 kbps ;
}
PORTB=0;
/ / ETAT NULL du codage RZ
}
On parcourt les tableaux motA et motB et on génère un troisième tableau. Ce tableau, appelé motEmis, a les 1 du motA comme un 1 (01) et les 1 du motB comme
un 2 (10), voir figure B.22 . De cette façon, si on a un HIGH, on émet un 1 sur le PB0
et un 0 sur le PB1 et vice versa.
Selon la spécification ARINC 429, l’émission doit être avec un encodage bipolaire
RZ, qu’on réalise en maintenant un 0 sur le Port B (état NULL) la même quantité
de temps qu’on maintient les états HIGH/LOW. Ensuite on détaille la séquence appliquée pour émettre un bit :
• Port B à zéro, pour assurer l’état NULL au début de l’émission.
• On soutient le Port B à zéro le temps nécessaire pour accomplir avec la vitesse de transmission désirée par l’utilisateur et faire l’émission en respectant
l’encodage Bipolaire RZ. Le procédé pour obtenir la vitesse on l’explique plus
bas.
2
Les champs des tableaux ne sont pas d’accord avec la spécification ARINC 429, sont seulement des
exemples
• On met dans la variable locale port le résultat de l’opération OR OR(|) entre
l’élément du motB indiqué par le compteur i décalé à gauche, et l’élément
équivalent du motA.
• On remplit l’élément du motEmis indiqué par le compteur i avec la valeur du
port , voire la figure B.2.
• On écrit le bit correspondante sur le Port B.
• On soutient le bit sur le Port B autant de temps comme il faut pour accomplir avec la vitesse de transmission désirée par l’utilisateur et faire l’émission
en respectant l’encodage Bipolaire RZ. Le procédé pour obtenir la vitesse on
l’explique plus bas.
Ce procédé on le répète jusqu’à 32 fois, comme indiqué dans la spécification ARINC
429 (mot de 32 bits). Pour finir on écrit un zéro sur le Port B et on s’assure qu’il ne
reste plus de données.
F IGURE B.2 – Représentation d’un exemple graphique des tableaux motA, motB et motEmis
Programme développé
1
2
3
# i n c l u d e < s t d i o . h>
# i n c l u d e < h i d e f . h>
# i n c l u d e <mc9s12e128 . h>
/ * common d e f i n e s and macros * /
/* derivative information */
4
5
# d e f i n e s i z e A r i n c 4 2 9 32
6
7
8
9
10
11
12
i n t compteuroctet , Nmotarinc =0;
s h o r t submotarinc [ 4 ] = { 1 , 2 , 3 , 4 } ;
s h o r t motA [ s i z e A r i n c 4 2 9 ] ;
s h o r t motB [ s i z e A r i n c 4 2 9 ] ;
s h o r t motEmis [ s i z e A r i n c 4 2 9 ] ;
unsigned s h o r t p a r i t e l u e =255;
13
14
15
/* ************************************** Attente **************************************** */
/ * * * Delay pour a j u s t e r l a v i t e s s e d ’ emision e t l e s d i f f é r e n t e s etapes d ’ execucion (ms) * * * /
16
17
18
19
20
21
22
23
v o i d a t t e n t e ( i n t duree ms )
/ / a t t e n t e ( q u a r t z 16 MHz e t F c l o c k = 16/2 )
{
unsigned l o n g i , j ;
f o r ( j = 0 ; j < duree ms ; j ++)
{
f o r ( i = 0 ; i < 200; i ++)
;
/ / Ne r i e n f a i r e
/ / Software d e l a y
24
25
26
27
}
}
/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Delay1 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
/ * Delay pour a j u s t e r l a v i t e s s e d ’ emision e t l e s d i f f é r e n t e s etapes d ’ execucion ( c y c l e s ) * * /
28
29
30
v o i d delay1 ( i n t duree us )
PK−HCS12E128 : K i t SofTec
/ / ( q u a r t z 16 MHz e t F c l o c k = 16/2 )
31
unsigned l o n g j , i ;
asm nop ;
f o r ( j = 0 ; j < duree us ; j ++)
;
32
33
34
35
{ f o r ( i =0; i <4; i ++) {
}
36
}
37
38
/ / Temporisation
{
}
39
40
41
42
/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Delay2 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
/ * * Delay pour a j u s t e r l a v i t e s s e d ’ emision e t l e s d i f f é r e n t e s etapes d ’ execucion ( c y c l e s ) * /
43
44
45
v o i d delay2 ( i n t duree us )
{
/ / T e m p o r i s a t i o n PK−HCS12E128 : K i t SofTec
unsigned l o n g j , i ;
46
47
48
f o r ( j = 0 ; j < duree us ; j ++)
49
{
f o r ( i =0; i <5; i ++)
50
{
51
52
}
53
54
}
55
56
}
57
58
59
/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Delay4 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
/ * Delay pour a j u s t e r l a v i t e s s e d ’ emision e t l e s d i f f é r e n t e s etapes d ’ execucion ( c y c l e s ) * * /
60
61
62
v o i d delay4 ( )
{
/ / T e m p o r i s a t i o n PK−HCS12E128 : K i t SofTec
65
unsigned l o n g j ;
asm nop ; asm nop ; asm nop ; asm nop ; asm nop ; asm nop ; asm nop ; asm nop ; asm nop ;
f o r ( j = 0 ; j < 0 ; j ++)
66
{
63
64
;
67
}
68
69
}
70
71
72
73
74
/* *********************************** CalcParite ** *** *** *** **** *** *** *** *** *** *** **** *** */
v o i d C a l c P a r i t e ( s h o r t MotArincA [ s i z e A r i n c 4 2 9 ] , s h o r t MotArincB [ s i z e A r i n c 4 2 9 ] )
{ unsigned s h o r t j ;
/ / MotArincA gere l e s 1
−−− MotArincB gere l e s 0
unsigned s h o r t p a r i t e l u e ;
75
MotArincA [ s i z e A r i n c 4 2 9 − 1]=1;
/ / i n i t p a r i t é i m p a i r e a 1
f o r ( j =0; j <s i z e A r i n c 4 2 9 −1; j ++)
{ / / CALCULER l a p a r i t é i m p a i r e en comptant des b i t s a 1 parmis l e s 31 p r e m i e r s
i f ( MotArincA [ j ] = = 1 ) MotArincA [ s i z e A r i n c 4 2 9 − 1]=˜ MotArincA [ s i z e A r i n c 4 2 9 − 1]&1;
MotArincB [ j ] = ˜ MotArincA [ j ] & 1 ; / / f a b r i q u e r l e s i g n a l i n v e r s é B
76
77
78
79
80
}
81
82
/ / A f f e c t a t i o n b i t p a r i t é s u r bus B
MotArincB [ s i z e A r i n c 4 2 9 − 1]=˜ MotArincA [ s i z e A r i n c 4 2 9 − 1]&1;
83
84
85
}
86
87
88
89
90
91
92
/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Emetre ARINC * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
/ * Emetre l e mot complet ARINC 429 (32 b i t s ) s u r l e s LED 0 & 1 du PORT B . L ’ emission e s t en
codage RZ * /
/ / PTT PTT1== TURE −−> v i t e s s e r a p i d e .
v o i d EmettreARINC ( )
/ / s e r i e de mots ARINC a t r a n s m e t t r e
{ unsigned s h o r t i ;
unsigned s h o r t p o r t ;
93
94
95
96
i f ( PTT PTT1==TRUE)
{
/ / Demande de Tx à haute v i t e s s e ?
{
97
PORTB=0; / / ETAT NULL
asm nop ; asm nop ; asm nop ;
p o r t = ( motB [ i ]<<1) | motA [ i ] ;
motEmis [ i ] = p o r t ;
delay4 ( ) ;
98
99
100
101
102
103
/ / delay3 , Tx à 100 kbps ;
/ / envoyer l e code s u r l e s LED 0 & 1
/ / Tx à 100 kbps ;
}
104
105
PORTB=0;
106
}
107
108
109
else
110
{
/ / Demande de Tx à v i t e s s e l e n t e
111
112
{
PORTB=0;
delay1 ( 1 ) ;
p o r t = ( motB [ i ]<<1) | motA [ i ] ;
motEmis [ i ] = p o r t ;
delay2 ( 1 ) ;
113
114
115
116
117
118
/ / ETAT NULL
/ / Tx à 13 ,5 kbps ;
/ / envoyer l e code s u r l e s LED 0 & 1
/ / Tx à 13 ,5 kbps ;
}
119
120
PORTB=0;
121
}
122
123
124
}
125
126
128
/* ********************************** I n i c i a l i z e ports ************************************ */
void P e r i p h I n i t ( void )
129
{
127
PORTB = 0x00 ;
PTT= 0xFF ;
PORTA = 0x00 ;
DDRB= 0xFF ;
DDRT = 0x00 ;
DDRA= 0x00 ;
130
131
132
133
134
135
136
//
//
//
//
//
//
Port B i n i t i a l i z a t i o n
Port T i n i t i a l i z a t i o n
Port A i n i t i a l i z a t i o n
Configure Port B f o r
Configure Port T f o r
Configure Port A f o r
( LEDs connected t o PB [ 7 . . 0 ] )
output
input
input
}
137
138
139
140
/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Strobe * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
/ * * * * * * * * * * * * * * * * * I n d i c a t i o n s u r l e p o r t B en t r a i n de l i r e un o c t e t * * * * * * * * * * * * * * * * * * * * * /
void strobe ( void ) {
141
i f ( PTT PTT2 )
PORTB BIT7=0xFF ;
else
PORTB BIT7=0x00 ;
142
143
144
145
146
/ / Mot
/ / LED
/ / Fin
/ / PTM
8 b i t s p r ê t s u r PORTA.
Rouge , PORTB BIT7 LED on
de Tx sub−mot 8 b i t s .
LED o f f
}
147
150
/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Puissance * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
/ * * * * * * * * * * * * * * * * * * * * * * F a i r e l a puissance de 2 i n d i q u é par j * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
i n t p u i s s 2 ( i n t exposant )
151
{
148
149
i n t j , tmp =1;
f o r ( j =0 ; j <exposant ; j ++) tmp=tmp * 2
r e t u r n tmp ;
152
153
154
155
;
}
156
158
/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Main program * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
v o i d main ( v o i d )
159
{
157
160
161
162
163
164
int i ;
i n t tmp2 [ s i z e A r i n c 4 2 9 ] ;
PeriphInit ( ) ;
DisableInterrupts ;
165
166
167
/ / s t r o b e rouge=PTT PTT2 ;
/ / s t r o b e jaune=PTT PTT0 ;
168
169
for ( ; ; ) / * wait forever * /
170
{
171
172
do ; w h i l e ( ! ( ( PTT PTT0==FALSE ) && ( PTT PTT2==FALSE ) ) ) ; / / 0 0 ; A t t e n d r e f r o n t montant
173
174
175
176
/ / 1 0 ; D ébut du mot ARINC 429
/ / 1 1 ; I l y a un o c t e t s u r PORTA
177
f o r ( c o m p t e u r o c t e t =0 ; c o m p t e u r o c t e t < 4 ; c o m p t e u r o c t e t ++ )
{
strobe ( ) ;
// lire
178
179
180
l ’ octet
181
182
for
183
{
184
( i =1 ; i < 9 ; i ++)
motA [ i −1 + c o m p t e u r o c t e t * 8]= ( submotarinc [ c o m p t e u r o c t e t ] & p u i s s 2 ( i −1) ) >> ( i − 1);
185
}
186
strobe ( ) ; / / f i n strobe
187
188
/ / 1 0 ; I l n ’ y a pas d ’ o c t e t s u r PORTA
/ / 1 1 ; I l y a un o c t e t s u r PORTA
}
189
/ / c a l c u l bus B e t b i t 32 l a p a r i t é iMPAIRE
p a r i t e l u e = motA [ s i z e A r i n c 4 2 9 − 1];
C a l c P a r i t e (&motA [ 0 ] , & motB [ 0 ] ) ;
EmettreARINC ( ) ;
Nmotarinc ++;
attente (100);
190
191
192
193
194
195
196
/ / 0 0 ; F i n du mot ARINC 429
/ / Emettre l e mot ARINC 429
/ / I n c r e m e n t e r l e nombre de mots emis
/ / A t t e n d r e 100ms avant l e p r o c h a i n mot
}
197
198
199
}
200
/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * FIN main * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /

Projet Stage Erasmus

Transcription

Documents pareils

Institut de Maintenance Aéronautique Support de Mise à niveau

Liaison série RS232 entre le Pic et un PC

Téléchargez le format PDF

Exigences techniques pour la Salle de classe virtuelle de Berlitz

Fiche syst`eme d`assainissement 2014 St

TD5 : Décimal Codé Binaire (Binary Coded Decimal)

Trois questions à… Daniel Lenoir, Directeur général de la

Fiche Produit CANON LBP 6000 Noir Type Imprimante Monochrome

Webdom® Satellite Smart Power Analyzer