This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
SommaireI.Terminologie et sigles utilisés :...............................................................................................................6II.Architecture générale :...........................................................................................................................8
1.Principes de décomposition :.............................................................................................................8 1.1 Vue statique :.............................................................................................................................8
1.1.1 Vue générale des soussystèmes :......................................................................................8 1.1.2 Vue en coupe du système :................................................................................................9
III.Interface du système :.........................................................................................................................161.IHM :................................................................................................................................................162.Monde extérieur :.............................................................................................................................17
IV.Les soussystèmes :.............................................................................................................................18IV.I. Sous système : La platine ...............................................................................................................18
1.1 Architecture générale :.................................................................................................................18 1.2 Scénario : démarrage...................................................................................................................19 1.3 Scénario Arrêt: ............................................................................................................................20 1.4 Scénario Mise en veille :..............................................................................................................21 2 Interfaces du sous système avec les autres soussystèmes :...........................................................23 2.1 Scénario : services fournis au gestionnaire des médias..............................................................23 2.2 Scénario : services fournis au LCD.............................................................................................24 2.3 Scénario : services fournis au module Infrarouge.......................................................................25 3 Soussystème matériel :..................................................................................................................26 3.1 Décomposition.............................................................................................................................26
3.1.1 Vue statique...........................................................................................................................263.1.2 Nomenclature des composants :............................................................................................28 3.1.3 Interfaçage avec le soussystème logiciel Platine................................................................29
4 Sous système logiciel :........................................................................................................................29 4.1 Vue statique :................................................................................................................................29 4.2 Présentation de la base du système d'exploitation......................................................................30 4.3 Présentation du noyau / modules.................................................................................................30 4.4 Présentation du sous système graphique.....................................................................................31 4.5 Présentation du sous système Audio...........................................................................................32
5 Matrice de traçabilité :.........................................................................................................................32
IV.II. Sous système : Gestion de médias.................................................................................................331 Architecture générale.......................................................................................................................33
1.1 Principes de décomposition....................................................................................................33 1.1.1 Vue statique.................................................................................................................33 1.1.2 Vue dynamique................................................................................................................35
1.1.2.1 Scénario : « Lire un média » ...................................................................................35 1.1.2.2 Scénario : « Visionner une image » ........................................................................36 1.1.2.3 Scénario : « Changer de skin » ................................................................................371.1.2.4 Scénario : « Changer le volume » ............................................................................38
2 Interfaces du soussystème avec les autres soussystèmes..............................................................392.1 Module Infrarouge...................................................................................................................392.2 Module Platine.........................................................................................................................392.3 Module Affichage LCD...........................................................................................................402.4 Module Lecteur CD / DVD.....................................................................................................402.5 Module Stockages USB...........................................................................................................41
3 Soussystème matériel.....................................................................................................................423.1 Principes de décomposition.....................................................................................................42
3.1.1 Vue statique.....................................................................................................................42 3.1.1.1 Le lecteur CD / DVD..............................................................................................42 3.1.1.2 Les stockages USB...................................................................................................42
3.1.1 Vue dynamique.................................................................................................................443.1.1.1 Le lecteur CD / DVD................................................................................................443.1.1.2 Les stockages USB....................................................................................................44
3.2 Découpage en composants.......................................................................................................443.3 Nomenclature des composants................................................................................................443.4 Interfaces avec l'équipement logiciel Platine..........................................................................44
4.1.3 Processus et programmes exécutables.............................................................................594.4 Conception détaillée des éléments logiciels............................................................................60
IV.III. Sous système : Affichage LCD....................................................................................................68 1 Architecture générale :....................................................................................................................68 1.1 dynamique Principes de décomposition :....................................................................................68 1.1.1 Vue statique :.............................................................................................................................68 1.1.2 Vue dynamique :........................................................................................................................69 1.1.2.1 Scénario 1 : Scénario de démarrage :.....................................................................................69 1.1.2.2 Scénario 2 : Scénario de fonctionnement sans action :.........................................................70 1.1.2.3 Scénario 3 : Scénario de navigation dans les menus :...........................................................71 1.1.2.4 Scénario 4 : Scénario de lecture :...........................................................................................72 1.1.2.5 Scénario 5 : Scénario de mise en veille ou d'arrêt :...............................................................73 2 Interfaces du sous système avec les autres soussystèmes :...........................................................74 2.1 Interface 1 : Interface avec le noyau............................................................................................74 2.2 Test : Interface 2 : Interface avec l'application CinéDjX :..........................................................78 3 Soussystème matériel :..................................................................................................................78 3.1 Principes de décomposition :.......................................................................................................78 3.1.1 Vue statique :.............................................................................................................................78 3.1.2 Vue dynamique :.......................................................................................................................82 3.1.2.1 Scénario 1 : Scénario de programmation :............................................................................82 3.1.2.2 Scénario 2 : Scénario de test :................................................................................................83 3.1.2.3 Scénario 3 : Scénario de fonctionnement :............................................................................84 3.2 Découpage en composants:.........................................................................................................85 3.2.1 Le microcontrôleur :.................................................................................................................86 3.2.2 Le LCD :..................................................................................................................................95 3.2.3 Le contrôleur LCD : ................................................................................................................97
2.Soussystème matériel....................................................................................................................115 2.1 Découpage en composants....................................................................................................115 2.2 Nomenclature des composants..............................................................................................117 2.3 Interface avec soussystème logiciel.....................................................................................118
3.Soussystème logiciel....................................................................................................................120 3.1 Vue dynamique......................................................................................................................120 3.2 Découpage en éléments logiciels..........................................................................................120 3.3 Détails sur l'installation la configuration et les tests de LIRC.............................................122 3.4 Matrice de traçabilité :..........................................................................................................125
● Platine : est un appareil électronique destiné à la lecture d’outils multimédia.
● Visionneuse : est un logiciel qui permet d'afficher une image emmagasinée dans un fichier électronique. Souvent, elle reconnaît plusieurs formats graphiques. Ce logiciel affiche les images selon les divers paramètres graphiques de l'affichage, tels que le nombre de couleurs par pixel et la finesse d'affichage.
● Ecran : (ou moniteur), en informatique, le périphérique de sortie qui permettent la communication visuelle avec l'utilisateur (ex : télévision, écran d’ordinateur)
● Module Infrarouge : connexion reliant un émmèteur et un récepteur via un rayon infrarouge. L’infrarouge est Le rayonnement infrarouge (IR) est un rayonnement électromagnétique d'une longueur d'onde supérieure à celle de la lumière visible mais plus courte que celle des microondes. Le nom signifie « en deçà du rouge », le rouge étant la couleur de longueur d'onde la plus longue de la lumière visible. Cette longueur d'onde est comprise entre 700 nm et 1 mm.
● USB : l'Universal Serial Bus (USB) est un bus informatique plugandplay servant à brancher des périphériques informatiques à un ordinateur pour communiquer en série.
● Linux : système d'exploitation open source de type Unix. C'est le système que nous allons utiliser pour faire fonctionner la platine « CinéDJx ».
● Noyau Linux : partie du système d'exploitation Linux réduite au simple code exécutable permettant de faire fonctionner le hardware, de gérer et de fournir des services aux processus utilisateurs.
● Distribution Linux : ensemble complet composé d'un noyau Linux prêt à l'emploi et d'un grand ensemble de programmes de configuration ou d'utilisation du système.
● C++ : langage de programmation compilé orientéobjet. C'est le langage que nous allons utiliser pour développer la plus grande partie de nos applications utilisateurs.
● Bourne shell : environnement programmable d'exécution de commandes sous Linux. C'est l'environnement que nous allons utiliser pour automatiser le fonctionnement du système d'exploitation ainsi que le lancement des applications utilisateurs.
● Qt : bibliothèque logicielle permettant de réaliser des interfaces graphiques homme machine . Cette bibliothèque peut être interfacée avec le langage C++ pour la programmation.
● Bios : Le bios est un composant de la carte mère, il, est chargé de reconnaître les périphériques présents lors du démarrage.
● Thèmes / Skins : Ils déterminent l'apparence générale de l'application et de définir le style de couleur que l'utilisateur verra.
A noter que pour la compréhension de ce dossier, il est nécessaire d'avoir de bonne notion en système d'exploitation Linux et en électronique numérique.
Cette vue statique représente le système général avec les différents messages envoyés entre les soussystèmes.
Le soussystème platine permet d'initialiser le système, gère le noyau, le scripts de boot, les boutons de contrôle, la carte mère et l'affichage à l'écran. Ce soussystème fournit des services et une couche d'abstraction matérielle aux autres soussystème.
Le soussystème gestion de média permet la gestion des périphériques extérieurs et est constitué de l'application général de CineDjX. Il communique principalement avec l'écran LCD et l'infrarouge. Il fournit l'IHM sur la télévision de la platine CineDjX.Le soussystème Récepteur Infrarouge permet le contrôle de notre système par un télécommande. Il est constitué d'un démon logiciel et d'une partie hardware.Le soussystème écran LCD permet l'affichage d'informations utiles sur un petit écran en façade. Il est lui aussi constitué d'un démon logiciel et d'une partie hardware.
1.1.2 Vue en coupe du système :
Cette vue représente la vue de côté de notre système, nous pouvons noter les périphériques USB pour brancher des périphériques de stockage de masse.
Cette vue représente la vue de façade du système, nous pouvons noter le lecteur DVD, les boutons de contrôle, l'écran LCD, le bouton ON/OFF et le récepteur infrarouge.
Cette vue dynamique présente le processus de démarrage du CinéDjX. L'action de déclenchement est une pression sur le bouton « power », situé en façade du boîtier. Cette action, de la part de l'utilisateur, donne lieu à la mise en route de l'ensemble des soussystèmes du CinéDjX, mise en route coordonnée par le soussystème « Platine ».
1.2.2 Scénario 2 :
Cette vue dynamique montre comment l'utilisateur pilote le CinéDjX, à partir de la télécommande infrarouge. Cette télécommande communique avec le module infrarouge, par l'envoi de signaux, lesquels donnent lieu à la transmission (par l'intermédiaire de la platine) de caractères au soussystème gestionnaire de médias. Ce dernier est le « cerveau » du CinéDjX ; il fournit en retour les informations destinées à être affichées sur l'écran de télévision et l'afficheur LCD. Ces données passent par la platine et sont dispatchées vers les appareils de destination.
Cette vue dynamique montre comment un périphérique de stockage de masse USB (disque dur externe, clé USB) est pris en charge par le système. Le branchement d'un tel périphérique entraîne sa détection et sa reconnaissance par la platine, laquelle envoie ensuite une notification au soussystème gestionnaire de médias. L'utilisateur peut alors utiliser l'interface graphique télévisuelle pour explorer le contenu de son périphérique de stockage de masse et demander la lecture de tel ou tel média.
1.2.4 Scénario 4 :
Cette vue dynamique présente enfin le processus d'arrêt du CinéDjX. De façon analogue au démarrage, l'utilisateur presse le bouton « power », situé en façade du boîtier, et la platine coordonne alors l'arrêt de chacun des trois autres soussystèmes, avant de s'arrêter ellemême.
Cette capture d'écran de l'IHM du CinéDjX montre le point d'entrée pour l'utilisateur vers les vers les fonctionnalités du soussystème de gestion de médias.
Dans ce deuxième onglet, on peut voir le point d'entrée vers les possibilités de configuration du CinéDjX.
Il devra réaliser des actions pour piloter la platine. Ainsi, il sera le seul opérateur du système CinéDjX. Il pourra contrôler celuici via la télécommande ou directement avec les boutons sur la platine.
La télécommande réalisera le lien entre l'utilisateur et le récepteur infrarouge. Elle permettra d'interpréter les requêtes de l'utilisateur qui sont matérialisées par la pression sur un des boutons de celleci.
La prise de courant devra impérativement être branché pour que la platine fonctionne. Ainsi, elle permettra l'alimentation de la platine. Elle transitera la courant de la prise électrique de l'utilisateur jusqu'au système.
Le stockage de masse pourra constituer une extension de mémoire pour l'utilisateur. Ainsi, une fois branché sur d'un des port usb, l'utilisateur aura la possibilité de visionner un fichier personnel.
La télévision permettra à l'utilisateur de visionner ses demandes. Elle sera, pourlui, l'interface privilégier puisque elle sera pour lui le seul moyen de voir l'application CinéDjX ou encore les films qu'il demande.
Ici nous avons le démarrage du système. L'utilisateur appuiera sur le bouton ON/OFF du système, afin de demander la mise en route. Cela alimentera la carte mère, qui après le lancement du BIOS, démarrera le système à partir de la mémoire SD, accessible en USB.
Le système lancera d'abord le noyau, puis s'exécuteront les scripts des démarrage. Ceuxci initialiseront les éléments logiciels du système, jusqu'à lancer le Serveur Graphique et le gestionnaire de médias.
Comme précisé dans la STB, le démarrage jusqu'à l'affichage de l'IHM utilisateur ne prendra pas plus de 25 secondes.
Lorsque l'utilisateur voudra arrêter complètement le système, celuici appuiera directement sur le bouton en façade. Cela enverra un évènement ACPI au système d'exploitation, qui arrêtera ensuite l'ensemble des programmes qui tournent, à commencer par le gestionnaire de médias.
Une fois l'ensemble des programmes arrêtés, celui ci éteindra le matériel, en coupant l'alimentation grâce à une commande ACPI OFF.
télécommande, et de pouvoir la rallumer avec la télécommande.
Celle ci n'arrête pas complètement l'appareil, mais permet de fournir un service à l'utilisateur intéressant, dans la mesure où il n'a pas besoin de se déplacer.
Par contre, la mise en veille amène le système matériel à un niveau de consommation électrique relativement bas: 14Watts contre 40Watts en fonctionnement.
2 Interfaces du sous système avec les autres soussystèmes :
2.1 Scénario : services fournis au gestionnaire des médias
Dans ce scénario, on voit très bien l'ensemble des services que ce soussytème fournit au soussystème gestionnaire de médias: il le lance, il fournit les bibliothèques dynamiques nécessaires à son exécutions (fichiers .so, équivalents des DLL sous windows).
Il gère également les primitives graphiques, par le bias du serveur graphique, ou serveur X,
logiciel qui s'occupe de l'affichage fondamentale (tracer des points, des courbes, envoyer des données vidéos).
Enfin, il fournit tous les programmes esclaves ou utilitaires, qui assistent le gestionnaire de médias dans les tâches qu'il doit réaliser. C'est le cas de MPLAYER, le lecteur vidéo.
Ici, on voit les services fournis au soussystème LCD: essentiellement une connexion USB, avec les modules noyau qui en permettent le support et ajoute une couche d'abstraction. Ainsi il y ici également des bibliothèques nécessaires à la gestion de l'USB. De même, une partie de ce soussystème sera intégrée à l'OS (lcd4linux).
2.3 Scénario : services fournis au module Infrarouge
Ici, nous avons les services fournis au soussystème infrarouge: la gestion des pipes nommés, et la présence d'un port série avec sa gestion au niveau du noyau, au travers des périphériques /dev/ttySX.
La carte mère utilisée par la platine, est une VIA MiniITX EPIACN13000G, basé sur le processeur C7.
Ce processeur est compatible x86, et est cadencé à 1Ghz. Il a l'avantage de consommer très peu d'énergie, et s'intègre parfaitement dans l'architecture cidessus.
Cette carte mère dispose du chipset VGA CN700, avec accelerateur hardware pour le décodage MPEG2 (format DVD). Elle dispose donc de fonctions idéales pour le multimédia, avec une intégration forte (17x17cm) de l'ensemble des fonctionnalités nécessaires à la platine CineDJx.
L'alimentation utilisée, une FlexATX 120 Watts, ce qui est amplement suffisant, le système utilisant 40 watts en fonctionnement à pleine puissance (lecture d'un DVD, ou d'une vidéo sur CDRom).
3.1.3 Interfaçage avec le soussystème logiciel PlatineIci le système hardware est presque un PC standard: il ne sera pas utilisé comme tel, et il le seul périphérique d'entrée sera la télécommande.
Mais cela simplifie grandement l'interface avec le soussystème logiciel, puisque celuici est fait pour s'exécuter sur le matériel.
4.2 Présentation de la base du système d'exploitationLe système est une base Debian Etch. Debian est une distribution linux extrêmement modulaire, disposant d'un très puissant gestionnaire de paquet, apt, afin de gérer les programmes installés sur le système. Etch est la version qui a été choisir par DaneaCorp, et elle représente le meilleur compromis en terme de stabilité, de support matériel et d'efficacité.
Sa construction se fait sur la machine de développement, et l'image du système est ensuite copié sur le support de la cible (la platine): par le biais d'une carte SD.
À savoir que l'on peut utiliser la carte mère de la platine, associée à un disque dur standard, pour installer une distribution linux quelconque. Celle ci devient alors la plateforme de développement, avec l'avantage immense d'avoir exactement le même hardware que le système cible.
Pour construire ensuite le système, il suffit de crée une partition spéciale qui sera appelée « partition cible ». La partition cible est de taille sensiblement inférieur à la taille de la carte SD, en l'occurence 1Go. Sur cette partition cible, le système est installé grâce aux scripts debootstrap, à partir de la partition de développement. Le système est ensuite mis à jour, et les programmes fondamentaux peuvent être installés à partir d'internet. On peut ensuite démarrer sur cette partition cible, en modifiant les options de boot au niveau de GRUB.
On alors un système fondamental, mais il ne représente pas encore le système CineDJx final. Pour ce faire, il faudra effectuer une grande simplification dans les scripts de démarrage debian, et rajouter les scripts écrits par l'équipe DaneaCorp.
Le système de paquets est également à simplifier: alors que sur une station de travail linux, on a entre 500 et 1000 paquets debian, l'objectifs ici est d'avoir 280 paquets au maximum: cela sera fait en enlevant tout paquet qui n'est pas demandé par la platine.
Au final, lorsqu'il est nécessaire de déployer le système, on utilise la commande dd:
dd if=/dev/partiCible of=/dev/mmcblkp1
afin de créer une copie octets par octets de la partition cible, vers la carte SD.
On a alors le système final, prêt à démarrer en usb sur la carte SD.
4.3 Présentation du noyau / modulesLe matériel détecté par le noyau est le suivant:00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01)
Le noyau est un noyau linux 2.6.18 recompilé par l'équipe DaneaCorp, et ce afin d'alléger au maximum la taille du noyau. Les modules nécessaires au système sont les suivants:
Nous utilisons comme technologie de boot le logiciel yaird, un système de initramfs, qui permet de charger le noyau correctement jusqu'au lancement des scripts de démarrage du système.
4.4 Présentation du sous système graphiqueLe système graphique, est modélisé par le serveur X, accompagné du driver graphique via unichrome, qui supporte le chipset CN700 intégré à la carte mère.
Ce serveur s'occupe des primitives graphiques. Il est installé comme paquet de la distribution, paquet xserverxorg. La version utilisé est la 7.1.
Il est lancé au démarrage par le système de scripts d'initialisation, et immédiatement après est lancé par dessus l'application du Gestionnaire de Médias.
Le sous système audio, dont on peut voir un schéma cidessus se nomme ALSA(Advanced Linux Sound Architecture). ALSA est une architecture complète de gestion du son sous linux, composé d'une partie noyau, et de bibliothèques et outils en espace utilisateur.
5 Matrice de traçabilité :STB v2 DA v1
4.1.3 Démarrage du Système Scénario: Démarrage du Système, scripts de démarrage
4.1.6 Afficher à l'écran Serveur Graphique
4.1.4 Mise En Veille Scénario: Mise en veille, scripts de mise en veille
Voici le schéma représentant l'architecture matérielle du soussystème.
Figure IV.II.1.1.1.1
Les Matériaux Pipés sont des Modules Matériels avec lesquels nous communiquerons par l'intermédiaire de Pipe nommés (Tunnel d'échange direct d'information).
Les Matériaux Purs sont des éléments pour lesquels les échanges se font mécaniquement, et qui ne dépendent que du Hardware.
Les Logiciels Purs sont des éléments pour lesquels ont lance des processus qui se chargent d'afficher et de configurer les applications nécessaires. Ils ne dépendent que du Software.
M e d i a P l a y e rG e s t i o n n a i r e d e s M e d i a sM o d u l e I n f r a r o u g e L e c t e u r C D / D V D S t o c k a g e d e M a s s e
L i s t 1 = g e t M e d i a s ( )
L i s t 2 = g e t M e d i a s ( )
E c r a n T V M o d u l e L C D
S é l e c t i o n L e c t u r e M é d i a
A f f i c h a g e ( L i s t 1 , L i s t 2 )
c h o i x = g e t S e l e c t i o n ( )
i n f o E n C o u r s = L i r e ( c h o i x )
A f f i c h e ( i n f o E n C o u r s )
A f f i c h e ( i n f o E n C o u r s )
Figure IV.II.1.1.2.1
Notre gestionnaire de médias peut sur activation du module infrarouge, ou bien directement des boutons en façade de la platine, lancer la lecture d'un média. Ce scénario décrit la première solution d'activation par le module infrarouge (Pour les IHM, vous reporter au guide d'utilisation). L'utilisateur sélectionne donc le menu de lecture par le biais de la télécommande et valide son choix. Le module infrarouge sur réception du signal lance la procédure. Il interroge les différentes sources : lecteur CD/DVD et stockage de masse. Il affiche ensuite sur l'écran TV la liste des médias trouvés. L'utilisateur sélectionne le média qu'il désire et valide son choix. Le module infrarouge renvoie les données au gestionnaire qui lance la lecture sur Mplayer, dirige la sortie vidéo sur la TV , et affiche les données de lecture sur l'écran LCD.
Ex :
Sélection Lecture Sélection Média Source Visualisation du Film
I m a g e V i e w e rG e s t i o n n a i r e d e s M e d i a sM o d u l e I n f r a r o u g e L e c t e u r C D / D V D S t o c k a g e d e M a s s e
L i s t 1 = g e t M e d i a s ( )
L i s t 2 = g e t M e d i a s ( )
E c r a n T V
S é l e c t i o n V i s i o n n e r M é d i a
A f f i c h a g e ( L i s t 1 , L i s t 2 )
c h o i x = g e t S e l e c t i o n ( )
i n f o E n C o u r s = V i s i o n n e r ( c h o i x )
A f f i c h e ( i n f o E n C o u r s )
Figure IV.II.1.1.2.2
Notre gestionnaire de médias peut également permettre à l'utilisateur de visionner des images sur activation du module infrarouge, ou bien directement des boutons en façade de la platine. Ce scénario décrit la première solution d'activation par le module infrarouge. L'utilisateur sélectionne donc le menu de visionnement par le biais de la télécommande et valide son choix. Le module infrarouge sur réception du signal lance la procédure. Il interroge les différentes sources : lecteur CD/DVD et stockage de masse. Il affiche ensuite sur l'écran TV la liste des médias trouvés. L'utilisateur sélectionne le média qu'il désire et valide son choix. Le module infrarouge renvoie les données au gestionnaire qui lance la lecture sur Image Viewer, dirige la sortie vidéo sur la TV , et affiche les données relatives à l'image sur l'écran LCD.
Le rendu des interfaces est identique aux exemples précédents. Pour plus d'informations vous reporter au manuel d'utilisation.
L'utilisateur pourra décider de personnaliser sa platine en choisissant un modèle d'habillage parmi le large choix proposé par CinéDJx. L'utilisateur sélectionne donc le menu de changement de skins par le biais de la télécommande et valide son choix. Le module infrarouge sur réception du signal lance la procédure. Il interroge la mémoire flash pour connaître les différents habillages disponibles. Il affiche ensuite sur l'écran TV le résultat sous la forme d'une liste. L'utilisateur sélectionne son habillage et valide son choix. Le module infrarouge renvoie les données au gestionnaire qui réaffiche l'interface et demande une confirmation à l'utilisateur. Une fois les changements confirmés par l'utilisateur via la télécommande et le module infrarouge, l'application les sauvegarde sur la mémoire flash.
Pour finir, l'utilisateur aura la possibilité de modifier le volume audio. Pour cela il pourra directement presser sur les boutons correspondants de la télécommande. Le module infrarouge transmettra alors la demande au gestionnaire de média. Celuici appellera l'application Amixer avec les arguments correspondants et affichera sur l'écran de la TV la nouvelle valeur.
Pour finir, l'utilisateur aura la possibilité de modifier le volume audio. Pour cela il pourra directement presser sur les boutons correspondants de la télécommande. Le module infrarouge transmettra alors la demande au gestionnaire de média. Celuici appellera l'application Amixer avec les arguments correspondants et affichera sur l'écran de la TV la nouvelle valeur.
2 Interfaces du soussystème avec les autres soussystèmes
2.1 Module Infrarouge
Figure IV.II.2.1
Le module infrarouge pour interagir avec le gestionnaire de médias devra passer via un pipe nommé. Ainsi le module infrarouge, par le logiciel « Lirc », se chargera de transformer les signaux fréquentiels reçus en signaux de type évènements clavier. Ces évènements seront redirigés en entrée du pipe nommé. Enfin, la sortie du pipe sera redirigée sur l'entrée standard de la machine qui est le clavier. Cela revient à dire que la télécommande va émuler notre clavier.
2.2 Module Platine
Figure IV.II.2.2.1
Selon le même schéma que pour le module infrarouge, le module platine renvoie ses
informations traduites au format des évènements clavier dans le pipe nommé, qui redirige les informations sur l'entrée standard du gestionnaire de médias.
Figure IV.II.2.2.2
Le gestionnaire de média pourra afficher directement ses informations sur un écran, puisque la platine redirigera la sortie écran.
2.3 Module Affichage LCD
Figure IV.II.2.3
Le gestionnaire contrôlera l'affichage de l'écran LCD par l'intermédiaire des fonctions proposées par Lcd4Linux. On chargera donc les chaînes d'information dans les fonctions qui se chargeront de l'affichage.
2.4 Module Lecteur CD / DVDFigure IV.II.2.4
Ce module se caractérise par les propriétés suivantes :
● Transfert de données : 33 Mo/s
● Temps d'accès aléatoire : 140 ms (CDROM),
160 ms (DVDROM)
Les données sont échangée par le contrôleur IDE de la carte mère (cf. Platine).
Le principal élément de notre gestionnaire de médias sera le lecteur CD / DVD, qui sera compatible avec la plupart des formats existants actuellement sur le marché :
● DVDROM, DVD+R/RW, DVDR/RW , DVDRAM
● CDR, CDROM, CDRW
Dimensions / poids : 148x42x190 mm / 0.9 Kg
Capacité : 8.5 Go +R9, 4.7 Go DVD
3.1.1.2 Les stockages USB
Figure IV.II.3.1.1.2
La plupart des périphériques de stockage USB seront compatibles avec notre platine s'ils sont formatés en FAT ou FAT32. En effet, la station tournant sous Linux, le format de stockage NTFS de Microsoft ne sera pas reconnu. Ainsi, si le format est respecté nous pourrons accéder à des périphériques tels que des lecteurs de cartes mémoire USB, des clés USB, des appareils photos USB, ...
● cf. Scénario : « Visionner une image », IV.II.1.1.2.2
3.1.1.2 Les stockages USB
● cf. Scénario : « Changer de skin », IV.II.1.1.2.3
3.2 Découpage en composantsLes modules sont aussi considérés comme éléments.
3.3 Nomenclature des composantsPour obtenir la nomenclature des composants, veuillez vous référer à la documentation
constructeur.
3.4 Interfaces avec l'équipement logiciel Platine
3.4.1 Logiciel Mplayer
slave Demande l'utilisation de mplayer comme une interface de contrôle (GUI)
quiet Précise le taux de détails sur le média en cours à renvoyer à l'utilisateur
nomouseinput Précise l'absence de souris
wid Permet d'identifier la fenêtre d'affichage
vo xv Paramètres d'affichage vidéo
Le gestionnaire de médias transmet le fichier à lire et la configuration du mode de lecture de Mplayer. Le logiciel fournit en retour les informations sur la lecture en cours dont l'affichage sur l'écran LCD sera géré par le gestionnaire de médias.
Le gestionnaire de médias transmet le fichier photo à visualiser et la configuration du mode de lecture du logiciel. Celuici fournit en retour les informations sur l'image en cours dont l'affichage sur l'écran LCD sera géré par le gestionnaire de médias.
3.4.3 Logiciel Amixer
Amixer set PCM 10+ Augmente le volume de 10
Amixer set PCM 10 Diminue le volume de 10
Amixer set PCM mute Rend la sortie audio muette
Amixer set PCM unmute Rétablit la sortie audio
Le gestionnaire de médias transmet la configuration du volume désiré. Le logiciel fournit en retour les informations sur l'état du contrôleur audio dont l'affichage sur l'écran TV sera géré par le gestionnaire de médias.
La vue statique de notre système logiciel est donnée par le diagramme de classes cidessus. Les éléments logiciels sont donc les différents objets du diagramme.
L'application principale reçoit des évènements provenant du module infrarouge. Ces évènements vont permettre de se déplacer dans le menu et lancer les différents objets : CinedjxMplayerGUI pour la vidéo, CinedjxImageViewerGUI pour afficher des images, CinedjxGameLauncherGUI pour lancer des jeux, CinedjxVolumeControllerGUI pour contrôler le volume et CinedjxSkinSelectorGUI pour changer l'apparence de l'IHM. Ces objets sont indépendants les uns des autres. Ils ne dépendent que de l'objet parent qui est MainApplication.
L'objet MainApplication reçoit l'évènement keyOK qui va lui permettre de lancer l'application sélectionnée : le lecteur multimédia représenté par l'objet CinedjxMplayerGUI. CinedjxMplayerGUI représentant l'interface, a un objet CinedjxMplayer qui contient l'implémentation. CinedjxMplayerGUI va recevoir des évènements du module infrarouge. Selon l'évènement reçu, il
lance la lecture (« play »), la pause (« pause ») ou l'arrêt (« stop ») d'un fichier audio/vidéo sélectionné au préalable grâce à l'explorateur de fichiers (« fileDialog »). L'évenement (« quit ») entraîne la destruction de l'objet CinedjxMplayerGUI et donc le retour à l'objet parent MainApplication.
sélectionnée : la visionneuse d'images représentée par l'objet CinedjxImageViewerGUI. CinedjxImageViewerGUI représentant l'interface, a un objet CinedjxImageViewer qui contient l'implémentation. CinedjxImageViewerGUI va recevoir des évènements du module infrarouge. Selon l'évènement reçu, il lance l'affichage (« display »), le zoom (« zoom ») ou le mode diaporama (« diaporama ») à partir d'un fichier image sélectionné au préalable grâce à l'explorateur de fichiers (« fileDialog »). L'évenement (« quit ») entraîne la destruction de l'objet CinedjxImageViewerGUI et donc le retour à l'objet parent MainApplication.
L'objet MainApplication reçoit l'évènement keyOK qui va lui permettre de lancer l'application sélectionnée : le lanceur de jeux représenté par l'objet CinedjxGameLauncherGUI.
CinedjxGameLauncherGUI représentant l'interface, a un objet CinedjxGameLauncher qui contient l'implémentation. CinedjxGameLauncherGUI va d'abord afficher la liste des jeux disponibles. Selon l'évènement reçu, il lance le jeu sélectionné (« run(jeu) ») et peut effectuer d'autres contrôles sur le jeu.L'évènement (« quit ») entraîne la destruction de l'objet CinedjxGameLauncherGUI et donc le retour à l'objet parent MainApplication.
L'objet MainApplication reçoit l'évènement keyOK qui va lui permettre de lancer l'application sélectionnée : le contrôleur de volume représenté par l'objet CinedjxVolumeControllerGUI.
CinedjxVolumeControllerGUI représentant l'interface, a un objet CinedjxVolumeController qui contient l'implémentation. CinedjxVolumeControllerGUI va d'abord afficher le volume courant et permettre de l'augmenter, de le diminuer ou de couper le son selon les évènements reçus.L'évènement (« quit ») entraîne la destruction de l'objet CinedjxVolumeControllerGUI et donc le retour à l'objet parent MainApplication.
L'objet MainApplication reçoit l'évènement keyOK qui va lui permettre de lancer l'application sélectionnée : le changeur d'apparence représenté par l'objet CinedjxSkinSelectorGUI. CinedjxSkinSelectorGUI représentant l'interface, a un objet CinedjxSkinSelectorGUI qui contient l'implémentation. CinedjxSkinSelectorGUI va d'abord afficher la liste des apparences disponibles et permettre la modification de l'apparence de l'IHM en fonction du skin choisi. Le contôle se fait grâce aux évènements reçus.L'évènement (« quit ») entraîne la destruction de l'objet CinedjxSkinSelectorGUI et donc le retour à l'objet parent MainApplication.
L'objet ou élément logiciel CinedjxMplayerGUI fait appel à un processus externe. Il s'agit de l'application libre mplayer qui permet de lire tout format vidéo.
Le lancement de l'application principale qui constitue l'IHM de la platine se fait à partir d'un seul fichier binaire nommé cinedjx.
4.2 Découpage en éléments logiciels
On utilise un langage orienté objet donc les différents élements logiciels sont les objets de notre système (logiciel).
4.3 Interfaces
L'interface principale est MainApplication et représent l'IHM de la platine multimédia.Cette dernière permet de lancer à partir d'un menu d'autres interfaces :
● CinedjxMplayerGUI pour la vidéo● CinedjxImageViewerGUI pour les images ● CinedjxGameLauncherGUI pour les jeux● CinedjxSkinSelectorGUI pour modifier l'apparence de l'IHM● CinedjxVolumeControllerGUI pour contrôler le volume
Chaque interface a comme parent MainApplication.Elles ont également chacunes leur implémentation. L'interface est en effet toujours séparée de l'implémentation afin des respecter les normes de développement objet.
Cette vue représente les actions nécessaires pour démarrer le système au niveau du soussystème LCD.Ainsi, l'utilisateur après avoir fait une demande de mise en route, la platine met sous tension le microcontrôleur par l'intermédiaire de port USB. Le microcontrôleur fait alors une demande d'affichage de message de bienvenue au LCD. L'écran LCD affiche alors le message et l'utilisateur peut le visualiser.
1.1.2.2 Scénario 2 : Scénario de fonctionnement sans action :
Le vue du fonctionnement sans action est en fait le fonctionnement standard quand l'utilisateur ne fait aucune demande particulière.
Même si l'utilisateur ne fait pas demande, il faut savoir que notre platine fonctionne toujours et doit afficher l'heure sur l'écran LCD. En effet, il est plus agréable pour l'utilisateur de pouvoir lire l'heure
Pour cet affichage, l'utilisateur n'a pas besoin de réaliser d'action, la platine envoie une demande d'affichage de l'heure au microcontrôleur qui luimême demande à l'écran LCD d'afficher l'heure à l'écran. Ces actions se répète alors toutes les secondes.L'utilisateur peut donc lire l'heure sans aucun problème en temps réel.Attention, l'heure affichée sera l'heure hardware de la carte mère.
1.1.2.3 Scénario 3 : Scénario de navigation dans les menus :
A chaque déplacement dans le menu, l'utilisateur aura la possibilité de voir où il se situe. L'utilisateur a besoin de choisir un menu. La platine envoie alors le nom du menu au microncontrôleur qui luimême demande l'affichage de ce menu.Une fois le menu affiché, l'utilisateur peut voir où il se situe.
Durant la lecture, le platine affichera le nom de la lecture en cours et le temps restant de lecture.
L'utilisateur n'a pas besoin d'action particulière à partir du moment où une lecture est en cours. La platine toutes les secondes envoie des informations sur la lecture en cours et le temps restant. Dans le cas où la lecture est une image, la platine n'enverra pas la durée mais seulement le nom de l'image. Le microcontrôleur effectue la demande d'affichage à l'écran LCD et celuici affiche le message.
1.1.2.5 Scénario 5 : Scénario de mise en veille ou d'arrêt :
Pour la mise en veille ou l'arrêt du système, le principe de fonctionne est légèrement différent. L'utilisateur doit faire une demande de mise en veille ou d'arrêt, ensuite la platine envoie le message correspond (ex : « A bientôt sur CineDjX ») au microcontrôleur et celuici dans transiter les informations jusqu'à l'écran LCD via un bus 16 pins. L'écran affiche le message et l'utilisateur pourra le visualiser.
2 Interfaces du sous système avec les autres soussystèmes :
Le soussystème est connecté directement par port USB à la platine. Ainsi il interagi directement avec le noyau Linux sur la carte mère avec un système de module noyau. De plus, l'application général Qt devra communiquer avec l'écran pour afficher les informations courantes.
2.1 Interface 1 : Interface avec le noyau
Description physique de l'USB :
Le bus USB utilise 4 fils, ainsi que des connecteurs particuliers. Deux des fils permettent d'acheminer l'alimentation électrique du périphérique (une souris USB par exemple), et deux véhiculent les données ellesmêmes.
Connecteur de type B
La spécification USB impose une tension maximale de 5V sur les fils et un courant de 500 mA au plus.
Il est évident que les fils d'alimentation sont toujours au même potentiel (tension de 5V si le périphérique est connecté, 0 sinon). Quant aux fils de données, la tension différentielle entre les deux peut valoir 0, 3,3 ou 5V. (cf spécification USB 1.1 (zip) pour plus de détails).
Protocole de communication USB :
La spécification USB impose un protocole de communication en plusieurs couches superposées ; ce qui permet à l'utilisateur de ne manipuler que la ou les couches supérieures.
Les transactions USB se font par l'intermédiaire de l'émission de plusieurs paquets dont le format obéit à un standard.Chaque transaction consiste en la succession d'un paquet Jeton (Token) d'un paquet de données (DATA) d'un paquet d'état (HandShake) Décrivons rapidement le schéma type d'une communication USB :Comme nous l'avons déjà vu, tout le bus est géré par l'hôte, ce qui signifie que c'est lui qui initie toutes les transactions en envoyant un paquet Jeton dans lequel figurent le type de transaction (lecture ou écriture), l'adresse du périphérique de destination, et la terminaison désignée (nous reviendrons sur ce terme plus loin).Suit le paquet DATA qui contient les informations réellement utiles dans la transaction, puis le paquet d'état qui indique si l'échange s'est correctement déroulé. Pour plus de détails sur le contenu de chaque paquet, se reporter à la spécification USB 1.1.
b) Les terminaisons
Nous avons déjà mentionné cette terminologie audessus. En fait, comme l'indique le schéma cidessous, chaque périphérique USB est décomposé en plusieurs sous blocs, possédant chacun un rôle différent dans la communication. Il s'agit ici de décrire de manière générale cette architecture, et non de développer complètement le fonctionnement précis de chaque étage ; pour cela, comme d'habitude, il conviendra de se reporter à la spécification USB 1.1 (zip).
Nous pouvons distinguer 3 sous blocs principaux : La partie qui décode l'adresse émise par l'hôte dans le paquet Jeton. Cette entité permet au périphérique de savoir que c'est bien à lui que l'hôte s'adresse, La partie terminaison, La partie réalisant la fonction USB proprement dit. Les terminaisons peuvent être vues comme des intermédiaires, des tampons entre le bus et la fonction USB. En effet, il n'est pas possible pour le bus d'écrire directement dans la fonction, et pour la fonction d'écrire directement sur le bus. Les données sont donc stockées temporairement (jusqu'à ce que l'hôte ou le périphérique les lisent) dans les terminaisons. C'est donc pour cette raison que dans le paquet Jeton, l'hôte précise la terminaison à laquelle il veut s'adresser. On peut remarquer qu'une même fonction USB peut utiliser plusieurs terminaisons. Dans la spécification USB 1.1 (zip), le nombre de paires de terminaisons est limité à 2, c'estàdire que les communications peuvent se faire via EP0 In, EP0 Out, EP1 In et EP1 Out. La paire de terminaisons utilisée par défaut par l'hôte pour dialoguer avec le périphérique est EP0.
c) Les types de transfert
La spécification de l'USB définit 4 types de transferts entre l'hôte et les périphériques.
Les transferts de commande
Ce sont les transferts qui sont généralement utilisés pour les opérations de commande et d'état. L'énumération du périphérique par exemple, que nous détaillerons plus loin, se fait en mode transfert
de commande.Ces transferts surviennent généralement en paquets directs et par rafales initiés par l'hôte, de manière à utiliser le meilleur rendement de livraison.Le transfert de commande est fiable : en cas d'erreur sur un paquet, il est répété.Plus de détails sur le type de transfert. Les transferts d'interruption Ce type de transfert est très utilisé, puisque c'est celui qui est mis en oeuvre pour les souris, les claviers,… En fait, quand le périphérique a une donnée à transférer à l'hôte, il lui faut attendre que l'hôte l'interroge pour lui signaler qu'il a une information urgente à transférer. En fait, ce n'est pas réellement un système d'interruption au sens informatique du terme. L'hôte n'interrompt pas le transfert en cours avec un autre périphérique pour se précipiter vers le périphérique nécessitant un transfert urgent. Les transferts isochrones
C'est certainement le mode de transfert le plus efficace en matière de débit, de disponibilité de la bande passante et du délai d'attente. Mais c'est aussi le plus complexe. Il est utilisé principalement pour des données ayant des durées de vie critiques tels que les trames audio ou vidéo. Ce type de transfert assure un débit minimum, mais il y peut arriver que certains paquets soient erronnés.
Les transferts en Bloc
Ce type de transfert est utilisé quand il faut transférer une grande quantité d'information pendant en temps relativement court. Par exemple, un appareil photo ou un caméscope utilise ce type de transfert pendant lequel 90% de la bande passante du bus est attribué au périphérique et les paquets erronnés sont répétés.
Notre système utilisera les transfert de commande car il n'est pas trop compliqué à gérer mais aussi parce que nous n'avons pas de grosse quantité de donnée à transférer. Interprétation avec le noyau :
Les modules noyau sont des parties de code qui peuvent être pris en compte par le noyau linux et qui permettent la gestion de certains périphériques. Ainsi, pour la gestion USB de type générique, il faut rajouter des modules comme le module « usbcore ».
Pour notre système, nous aurons besoin de charger deux modules : usbcore et usbuhci. Une fois ces deux modules chargés dans le noya, toute application pourra communiquer avec l'écran LCD.
2.2 Test : Interface 2 : Interface avec l'application CinéDjX :
Notre application n'a d'apparence aucune possibilité pour communiquer avec l'écran LCD puisqu'elle n'a pas de droit privilégié. Elle ne pourra pas écrire sur le périphérique LCD.
Nous avons donc choisi d'utiliser une autre application, en l'occurrence un démon, nommée lcd4linux qui sera chargé en super utilisateur et qui aura donc les droits nécessaires pour écrire sur les périphériques. Le fait que celleci soit un démon, elle pourra écrire à tout instant sur l'écran et sera constamment actif. Lcd4linux relira toutes les secondes les informations sur la platine par l'intermédiaire d'un fonction de notre application qui renverra un chaîne de caractères.
L'alimentation arrive directement par le port USB. Elle dépend donc du protocole USB décrit dans la partie « interfaces avec les autres soussystèmes ».
Microcontrôleur :
Ce microcontrôleur est fabriqué par Atmel. Il est constitué d'une architecture AVR très répandu pour des utilisations dans les logiciels libres. En effet, beaucoup d'outils libres sont disponibles pour programmer ce type d'architecture. La version utilisé sera une PDIP (boîtier DIL) pour des facilité de manipulation sur le circuit.
Il fonctionne sur un bus de 8 bits et réalise 16 Millions d'instructions par seconde.Il est aussi constitué de :– 8K octets de ROM– 512 octets de EEPROM– 1024 octets de RAM
LCD :
L'écran LCD est constitué de deux polariseurs dont les directions de polarisation forment un angle de 90°, de chaque côté d'un sandwich formé de deux plaques de verre enserrant des cristaux liquides. À chacune des interfaces avec les cristaux liquides, une couche de polymère, généralement un polyimide, rainurée assure l'ancrage des molécules au repos.
Les deux faces internes des plaques de verres comportent une matrice d'électrodes transparentes, une (noir et blanc) ou trois (couleur) par pixel. L'épaisseur du dispositif et la nature des cristaux liquides sont choisis de manière à obtenir la rotation désirée du plan de polarisation en l'absence de tension électrique (90° dans les écrans TN). Dans les écrans de grande dimension, on ajoute des espaceurs, petites billes transparentes, dans l'espace rempli de cristaux liquides pour maintenir la très faible épaisseur (20 µm) constante et précise. L'application d'une différence de potentiel plus ou moins élevée entre les deux électrodes d'un pixel entraîne un changement d'orientation des molécules, une variation du plan de polarisation et donc une variation de la transparence de l'ensemble du dispositif.
Cette variation de transparence est exploitée par un rétroéclairage, par réflexion de la lumière incidente ou par projection.
Affichage par segments et par pixels
Les électrodes des pixels ne sont accessibles que par ligne ou colonne entières et la commande d'allumage ou d'extinction doit se faire par un balayage régulier des lignes de points. Les petits afficheurs LCD monochromes reposent sur le même principe mais utilisent souvent des électrodes avant en forme de segments de caractère de façon à simplifier l'électronique (commande directe en tout ou rien) tout en obtenant une très bonne lisibilité (pas de balayage).
Un faisceau lumineux, émis par la lampe du projecteur, passe à travers 3 matrices à cristaux liquides (pour le tri LCD). Devant chacune d'elles se trouve un filtre de couleur : un Rouge, un Vert, un Bleu. En fonction du signal envoyé, les cristaux liquides vont plus ou moins laisser passer la lumière. Celleci est alors concentrée sur un prisme central qui diffusera vers l'objectif un seul faisceau lumineux et ainsi formera une image.
Lors du chargement du programme sur le microcontrôleur, nous utiliserons le programmateur. Le reste du temps le programmateur ne sera pas branché pour des raisons de place.Celuici sera relié à un pc par l'intermédiaire d'un port parallèle et sera relié avec un bus 5x2 (10 connecteurs) à la carte de l'écran LCD. La conception du programmateur a été réalisé selon l'architecture AVR du microncontroleur que nous utilisons.
Ce scénario est très important, il permet la programmation du microcontrôleur ATMEL directement sur la cible. Il faut que l'utilisateur branche le bus du programmateur sur la carte cible (carte du LCD). Le microcontrôleur est alors mis en mode reset, nous pouvons alors envoyer le code sur le Atmega816. Le code est alors chargé à la bonne adresse pour qu'il soit exécuté quand le microcontrôleur sortira du mode reset.
Ce scénario montre comment tester la carte et le microcontrôleur. L'utilisateur doit charger le code qui aura pour but de faire clignoter une LED. La led passera de l'état allumé à l'état éteint toutes les secondes.
Si l'utilisateur visionne le clignotement, cela veut dire la carte est bien alimenté, que le programmateur fonctionne et que le microcontrôleur n'est pas détérioré.
3.1.2.3 Scénario 3 : Scénario de fonctionnement :
Le scénario de fonctionnement représente le fonctionnement de l'affichage LCD en faisant totale abstraction de l'utilisateur. Ainsi la déclencheur devient le périphérique USB qui envoie une information au microcontrôleur. Ensuite, il demande l'affichage à l'écran LCD via un bus 16 pins. Le LCD exécute alors la demande en affichant à l'écran.
3.2 Découpage en composants:Dans cette partie, nous allons présenter les schémas structurels d'ensemble de tous les modules. Nous allons aussi présenter les interactions des signaux électriques échangés entre les différents modules dans le but de comprendre les signaux.
Les AVR (Advanced Virtual RISC ) d’Atmel sont de la famille des microcontrôleurs RISC. L’architecture a été conçu par deux étudiants de l’institut de technologie de Norvège (NTH : Norges Tekniske Høgskole).
Les AVR sont basés sur une architecture CPU Harvard. Ils disposent de 32 registres de travail de 8 bits. Ils permettent d’approcher les 1 million d’instructions par Mhz soit une instruction par cycle d’horloge.
Les ports d'entrée / sortie
DDRx : Registre qui impose la direction des ports. ex: DDRA=0b11110000 ; les bits 0 à 3 du portA sont configurés en entrée et de 4 à 7 en sortie.
PORTx : Registre d’écriture des niveaux logiques sur le port x ex: PORTA=0b11110000 ; Si le port est sotie (voir DDRx), les bits 0 à 3 du portA passent à l’état bas et de 4 à 7 à l’état haut.
Pour notre système, nous utiliserons le port C pour l'alimentation USB et pour le bus de contrôle de l'écran LCD, le port D pour les données USB et pour le BUS de data LCD, le port B pour la programmation du microcontrôleur.
PINx : Registre de lecture des niveaux logiques sur le port x
Résistance de tirage
Chaque pin de chaque port possède une résistance de tirage activable en mettant la pin en question en entrée (Registre DDRx) et en mettant le niveau logique à 1 (PORTx)ex : DDRA=0b10101010 et PORTA=0b11111111 ; Les résistances de tirage sont actives sur les pins 0,2,4,6 du port A. les autres pins sont en sortie et au niveau haut. Le bit PUD (Pullup disable) du registre SFIOR permet de désactiver toutes les résistances de tirage sur tous les ports. La résistance de tirage est comprise entre 20 et 50kΩ
DDRx PORTx Entrée/Sortie Résistance de tirage Description
0 0 Entrée Non La pin est en entrée en haute impédance
0 1 Entrée Oui La pin est en entrée avec résistance de tirage
1 0 Sortie Non La pin est en sortie et au niveau bas
1 1 Sortie Non La pin est en sortie et au niveau haut
Lecture d'une pin
Entre la mise en entrée d’une pin et sa lecture il faut qu’au moins 1 cycle d’horloge s’écoule. Si vous souhaitez lire immédiatement la pin après l’avoir mise en entrée intercalez un nop entre la configuration de DDRx et la lecture de PINx. Voir l'exemple en C.
Pin non connecté
Il est recommandé d’activer la résistance interne, pour fixer un niveau logique à l’entrée, si elle n’est pas utilisée. Ca ne coûte rien et ça réduit la consommation. Ne la connectez pas à VCC ou GND en cas d’erreur de config vous risquez de courtcircuiter la pin.
Interruptions externes
Les interruptions externes sont déclenchées sur un changement d’état des pins INT0, INT1 ou INT2.Les interruptions peuvent être déclenchées sur un front descendant, montant ou un niveau bas. (INT2 ne peut être déclanchée que sur des fronts) Le niveau apres un front doit être maintenu au moins pendant la durée d’un cycle d’horloge.
Bit 1 et 0 ICS01 et ICS00 servent à configurer INT0.Bit 3 et 2 ICS11 et ICS10 servent à configurer INT1. ISC11 ISC10
ISC01 ISC00 Description
0 0 Interruption sur niveau bas
0 1 Interruption sur front montant ET descendant
1 0 Interruption sur front descendant
1 1 Interruption sur front montant
MCUCSR :
bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
JTD ISC2 JTRF WDRF BORF EXTRF PORF
Bit 6 ISC2
ISC2 Description
0 Interruption sur front descendant
1 Interruption sur front montant
Choix de l'interruption
GICR :
bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
INT1 INT0 INT2 IVSEL IVCE
L’interruption de INT1 est activée si INT1 (bit 7) est à 1L’interruption de INT0 est activée si INT0 (bit 6) est à 1L’interruption de INT2 est activée si INT2 (bit 5) est à 1
L’interruption n’est activée que si le bit I (Interruption globale) du registre SREG est activé.La moyen le plus simple de l’activer est d’utiliser la fonction sei
Timer
Introduction
Un timer est un compteur cadencé par une horloge.
L’horloge peut :
• être l’horloge système (quartz, oscillateur interne etc ...)
• être un signal arrivant sur une pin du microcontrôleur.
• être divisée en fréquence
Le timer peut :
• déclancher une interruption arrivé à son maximum
• déclancher une interruption arrivé à une certaine valeur
• faire changer d’état une sortie du microcontrôleur
• être préchargé à une certaine valeur
Les applications possibles sont :
• la mesure de temps entre 2 évènements
• la génération de signaux, signal carré, PWM etc
• le déclanchement des évènements périodiques
Timer 0 (8 bit)
Source de l'horloge
Le timer peut être cadencé par un signal appliqué sur la pin T0 ou par l’horloge système.
T0
Le signal appliqué sur T0 doit avoir une fréquence inférieur à la fréquence système / 2.5 et un rapport cyclique de 1/2.
1 1 0 Incrémentation du timer sur front descendant de T0
1 1 1 Incrémentation du timer sur front montant de T0
Horloge système
L’horloge système (quartz, oscillateur RC interne etc) passe par un diviseur de fréquence appelé “prescaler”. Ce prescaler permet de diviser la fréquence appliqué au compteur (timer) par 8,64,256 ou 1024.
Le compteur va s’incrémenter jusqu’à sa valeur max, soit en 8 bit 0xFF.Arrivé à 0xFF, il recommencera à partir de 0×00 jusqu’à 0xFF et ainsi de suite. TCCR0 :
bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
FOC0 WGM00 COM01 COM00 WGM01 CS02 CS01 CS00
WGM01 WGM00 Description
0 0 Timer en mode normal
CTC (Clear time on compare match)
Le compteur va s’incrémenter jusqu’à la valeur du registre OCR0.Arrivé à la valeur de OCR0, il recommencera à partir de 0×00 jusqu’à la valeur de OCR0 et ainsi de suite. OCR0 définit donc la valeur max du compteur. OCR0 doit être inférieur à 0xFF.
Comme nous pouvons le voir, l'afficheur LCD ne fonctionne pas tout seul. Quand nous achetons un écran LCD, il est toujours fournni avec son contrôleur. Ici, pour cet écran LCD le driver est un driver KS0070B de type COM16/ SEG80. Il permet d'interpréter les signaux envoyés sur le bus d'entrée. En réalité, la matrice d'affichage est beaucoup plus grande, elle est constitué de 16 lignes et 80 colonnes. En entrée, il est possible de le connecter sur un bus de données de 4 ou 8 bitq et il y a 4 bits de contrôle.
16 Caractères
16 Caractères
1 16
Vss Vdd Vee Rs R/W E DB0 DB1 DB2 DB3 DB4 DB5 DB6 DB7 A+ A
Le programmateur est basé sur le un port parralèle. Il fonctionne sur tout type de microcontrôleur avec une architecture AVR, c'est à dire la presque totalité des microcontrôleur ATMEL.
Nous avons décidé de poser un connecteur 5x2 sur le circuit imprimé de l'écran LCD. Ainsi, nous pourrons brancher et débrancher à volonté notre programmateur. Le but étant d'aller le plus vite possible, le circuit du Lcd sera un peu plus gros mais nous pourrons charger notre code sur la carte en très peu de temps.
De plus, ce type de programmateur est très bien addapté au PC de développement Linux et beaucoup d'outils Linux sont disponibles pour charger le programme sur le microcontrôleur. Ainsi, avrgcc a retenu notre attention.
Nous avons tout d'abord besion du programme « uisp » ( Micro InSystem Programmer for Atmel's AVR MCUs) pour detecter le microcontrôleur et pour pouvoir faire la communication avec celuici. Ensuite après l'installation de avrgcc, nous pouvons commencé les tests. Sur un pc Linux, il faudra veillé à ce que le module « parport » (gestion du port parralèle) soit chargé.
La commande suite testera si le microcontrôleur est présent sur le port parrallèle :
# uisp dprog=dapaAtmel AVR ATmega16 is found.
Nous devons ensuite compiler le programme à l'aide d'un Makefile particulier qui enverra le code sur le Atmega816.
# erase the AVR before it is programmedload: avrledtest.hex uisp dlpt=/dev/parport0 erase dprog=dapa uisp dlpt=/dev/parport0 upload if=avrledtest.hex dprog=dapa v=3 hash=32
clean: rm f *.o *.map *.out
Nous avons créer un programme de test qui fait clignoter un led sur le PIN 5 du port D à la période de 500ms :
#include <avr/io.h>
void delay_ms(unsigned short ms)/* attente pendant un temps ms en milisecond */{ unsigned short outer1, outer2; outer1 = 200;
while (outer1) { outer2 = 1000; while (outer2) { while ( ms ) ms; outer2; } outer1; }}
int main(void){ /* PD5 comme sortie */ sbi(DDRD,PD5); /*Boucle infinie */ while (1) { /* lED ON, pin=0 */ cbi(PORTD,PD5); delay_ms(500);
/* mettre la sortie à 5V, LED ON*/ sbi(PORTD,PD5); delay_ms(500); } return 0;}
La première ligne permet de récupérer les information sur le microcontrôleur comme par exemple les noms des ports et pour permettre la compilation au niveau assembleur. Après exécution du makefile, si la LED clignote cela veut dire que notre programmateur fonctionne correctement et par déduction le microcontrôleur aussi.
3.3 Nomenclature des composants :
3.3.1 L'alimentation :Celleci n'a pas besoin de composants particulier, il faudra récupérer simplement le 5V et le ground du port USB, ceuxci seront ainsi diffusé sur tout le circuit car il faudra une masse commune et l'alimentation 5V de l'USB suffit pour aliementer tout le circuit.
Il faut rajouter à cela u cable parrallèle communication entre le PC et la carte de programmation et un bus entre la carte de programmation et la carte LCD.
3.4 Interfaces avec le soussystème logiciel Affichage LCD:Notre circuit imprimé n'interagit pas avec les autres soussystèmes logiciel mais seulement avec la couche logiciel du même soussystème.
Ainsi nous pouvons résumer les interactions de la carte avec le schéma si dessous :
3.5 Matrice de traçabilité :
STB v2 DA v1
4.1.2 Affichage frontal LCD Scénario: Affichage sur l'écran
4.1.3 Démarrage du système Initialisation du l'écran LCD
Le soussystème logiciel est décomposé en 2 composants principaux. Il y a tout d'abord Lcd4Linux puis les modules noyaux.Nous n'avons bien évidemment pas programmé ces parties logiciels car nous avons utilisé les outils libres existants. Ainsi, dans cette partie nous ne pourrons que détailler les configurations possibles et les sorties qui en découlent.
A la suite d'une demande de démarrage faite par l'utilisateur, la platine reçoit cette requête et initialise de démon Lcd4Linux. Lors de l'initialisation de ce démon, il fait la demande de chargement des modules noyau. Une fois initialisé et les modules chargés, lcd4linux fait la demande d'affichage du message de bienvenue. L'écran affiche alors le message (ex: bienvenue sur CineDjX) et l'utilisateur peut visualiser le message.
L'attente d'information est en fait le moment où le système est en attente. Il est démarré mais aucune action n'est demandé.
La platine ne fait rien mais le démon Lcd4Linux tourne toujours. Comme rien ne lui est demandé, il demande alors à la platine d'afficher l'heure. L'utilisateur peut alors lire l'heure.
Le scénario « demande d'affichage » est valable pour tout type d'affichage, celuici peut marcher pour l'affichage du menu en cours mais aussi pour l'affichage de la lecture.
La platine envoie une demande d'affichage. Lcd4Linux reçoit cette demande et l'envoie au noyau sous forme de signaux. Le noyau transmet alors la requête à l'écran LCD en écrivant sur le port USB. L'écran affiche alors le message et l'utilisateur peut le visualiser.
Le seul processus persistant dans ce soussystème est le démon LCD4Linux. Il sera en permanence en exécution et sera lancé au démarrage du système. Le module USB du noyau n'est pas considéré comme un processus car il ne s'exécute pas mais il permet simplement d'échanger les informations sur le bon port de la carte mère. Le module reste chargé dans le le noyau à partir du moment ou la commande modprobe « Nom du module » est exécuté.
4.2 Découpage en éléments logiciels :Nous ne pouvons découper les modules noyau en éléments logiciel car un module représente un élément à part entière, nous avons d'ailleurs pas regardé le code source des modules du fait de leur complexité.
En revanche, l'application Lcd4Linux se décompose en 3 éléments de configuration.
Display :Cette classe défini le type d'écran LCD utilisé, le driver à utiliser, le nombre de ligne et de colonne, le port utilisé ....
Exemple de configuration possible :Display HD4478016x2 { Driver 'HD44780' Model 'generic' UseBusy 1 Port '/dev/LCD0' Size '16x2' Wire { RW 'AUTOFD' RS 'INIT' ENABLE 'STROBE' ENABLE2 'GND' GPO 'GND' }}
Widget :Le widget permet de définir les informations que l'on veut afficher. Par exemple, le programme Lcd4Linux permet d'afficher les informations sur le CPU ou la mémoire RAM disponible mais ce
type de configuration ne nous intéresse pas. Nous utiliserons cette classe pour faire une demande à l'application CinéDjX.
Exemple de configuration possible :Widget lectureFichier { class 'Text' expression file::readline('/home/cinedjx/file', 1) width 20 align 'M' update 1000}
La configuration cidessus permet de lire un la première ligne d'un fichier toutes les 1 secondes. Elle permet de lire au maximum 80 caractères.
Layout : Les Layouts servent quand nous avons défini plusieurs widgets ce qui serra notre cas puisse qu'on aura un widget pour le nom de la lecture en cours et un widget pour le temps restant. Avec cette option, nous pouvons créer un tableau virtuel qui délimite chaque widget à une place bien définie.
Étant donné que nous n'avons pas programmé les modules noyaux pour la gestion de l'USB et du fait de leur complexité, nous n'avons pu découpé ce composant en élément logiciel. Nous pouvons quand même noter qu'il y a deux modules à charger qui sont usbcore et usbuhci.
Le sous système logiciel interagit avec le soussystème matériel LCD par le biais d'une interface USB. De plus, il existe une deuxième interface avec le soussystème « gestion de médias » qui permet la
récupération d'information sur la lecture en courant, le temps restant de lecture, la position de navigation ou sur l'heure. Cette deuxième interface se fera par le biais d'appel de fonction qui renverra une chaîne de caractères.
4.4 Conception détaillée des éléments logiciels:
Pour les raisons évoquées tout au long de cette description du soussystème logiciel, nous avons pu faire la conception détaillée des éléments logiciels. En effet, nous n'avons pas assez d'élément en notre possession sur le design des deux composants pour vous exposer de façon exacte leur conception.
L'alimentation de ce circuit vient de la ligne RTS du port série. D1 protège le circuit d'une tension négative qui se trouve habituellement sur la broche RTS. Le driver du programme LIRC va changer la
configuration du port série a l'initialisation pour que le circuit reçoive la tension positive nécessaire. Sur la plupart des ports série de PC, ce sera approximativement 10V. IC2 va convertir la tension en entrée en exactement 5V. Comme la tension d'entrée pour les régulateurs du type 78Lxx doit être au moins 2V de plus que la tension de sortie pour fonctionner correctement, ce circuit ne marchera probablement pas sur certain portables. Il faudra s'assurer que le port série délivre au moins une tension de 8V en sortie.R1 est un "pullup" pour être sûr que la ligne DCD a un niveau de tension valide si le récepteur ne reçoit rien.
Quand un signal infrarouge est détecté IC1 met la broche DCD du port série à la terre, ce qui est interprété par un "1" (DCD=0) logique par le port série. Donc en fait les données à ce stade se présentent sous la forme de trames carrées où les informations binaires 1 et 0 correspondent respectivement à 0V et 5V.
2.2 Nomenclature des composantsListe des composants:
• C1 Condensateur de 4,7 µF• D1 – Diode 1N4148• R1 – Résistance de 4,7 KΩ• IC2 – Régulateur de tension KA7805A
2.3 Interface avec soussystème logicielL'interface avec le soussystème logiciel peut être détaillée de façon exhaustive en parlant de la connexion du module infrarouge sur la carte mère de la platine et du type de données transférées par le port série.
Port série 9 broches:
Détail des broches:
Format des trames:Le bit de "start" apparaît en premier dans la trame puis les données (poids faible en premier), la parité éventuelle et le (les) bit(s) de stop.
Exemple :Si on veut transmettre en parité paire, avec 2 bits de stop, les bits qui suivent 1000010(2) la trame sera la suivante :
3.2 Découpage en éléments logiciels• LIRC (Linux Infrared Remote Control):
LIRC inclut des drivers pour le port série et sert à décrypter les signaux qui arriveront du circuit par la broche DCD du port série. Il interprétera ces signaux en tant que commandes linux qu'il relayera dans le "pipe".
• Pipe nommé:Il s'agit d'un buffer linux à travers lequel les différents processus peuvent se passer des données. Ainsi LIRC écrira des commandes dedans qui seront lues et exécutées par le gestionnaire de média.
• créez un fichier appelé ~/.lircrc (ce fichier configure ce que fait chaque touche).Voici un fichier ~/.lircrc pour contrôler mplayer, beepmediaplayer et le volume, il faut bien sûr l'adapter selon votre matériel et vos besoins, comme suit :
#Mplayer buttons begin button = VOL+ prog = mplayer config = volume 1 repeat = 1 end begin button = VOL prog = mplayer config = volume 1 repeat = 1 end begin button = || prog = mplayer config = pause endbegin button = Prog+ prog = mplayer config = pt_step 1 end begin button = Prog prog = mplayer config = pt_step 1 end begin button = MENU prog = mplayer
3.4 Matrice de traçabilité :La fonction intrinsèque de ce module infrarouge est de donner accès à la majorité des fonctions de la platine et ce, par le biais d'une télécommande. Le module ne possède pas de fonction propre autre que celle d'intermédiaire. Donc il n'y a pas de matrice de traçabilité.