(Dernière mise à jour par Benjamin le 16/12/2022)
La sélection de l’écran à utiliser va dépendre de nombreux facteurs. L’interface de connexion est le premier à prendre en compte, suivi par la disponibilité et la qualité des bibliothèques, puis la luminosité. La taille et la définition vont dépendre de l’application utilisant l’écran et de la place disponible sur le tableau de bord. Pour un EFIS ou un EMS, et pour avoir un affichage graphique de bonne qualité, lisible en toutes circonstances sur un tableau de bord d’avion, une taille de 4.3 à 5 pouces, une définition de 480×272 pixels ou plus, et une luminosité minimale de 500 nits constituent un bon compromis. La technologie IPS offre des angles de vision nettement meilleurs que la technologie TFT. La présence d’une interface tactile est affaire de choix personnel : en vol, en cas de turbulences, et sur un écran de 7 pouces ou moins, même peu chargé, la sélection au doigt d’une petite zone d’écran ou d’une option de menu peut être difficile. D’autres systèmes de commandes peuvent être envisagés, comme des boutons poussoirs, des encodeurs rotatifs ou un joystick, souvent plus précis qu’un écran tactile capacitif. Ce dernier a en outre l’inconvénient d’être brillant, alors qu’un écran mat, anti reflet, est nettement plus lisible.
L’interface de connexion
Il existe plusieurs standards. Parmi les plus répandus, on peut citer HDMI, Parallèle, et Série.
HDMI
Les cartes microcontrôleur ne disposent jamais d’un connecteur d’écran de type HDMI. Les ordinateurs mono carte, comme par exemple le Raspberry Pi sous Linux ou le LattePanda sous Windows (il en existe bien d’autres), possèdent une telle interface. Mais les ordinateurs et leurs systèmes d’exploitation ne sont guère compatibles avec les coupures d’alimentation, il faut les arrêter “proprement”. Les systèmes embarqués doivent toujours être conçus de telle sorte qu’une perte de puissance inattendue (comme la coupure du contact général sur un avion) ne risque pas d’entraîner une corruption du système d’exploitation ou une perte de données des logiciels d’application. Pour être exploité en toute sécurité dans une application embarquée, un ordinateur mono carte nécessite donc des mesures de sécurisation de son alimentation (comme par exemple celle-ci, pour Raspberry), qui donnent le temps nécessaire au système d’exploitation pour s’arrêter correctement. Dans le cadre d’un développement personnel, de type “DIY” (pour Do It Yourself), ceci rend le système plus complexe, et à risque accru de panne.
Les microcontrôleurs sont mieux adaptés aux tâches embarquées, la coupure de l’alimentation est leur procédure normale d’extinction. Par ailleurs, les écrans HDMI, de 5 pouces ou moins, et lisibles au soleil, sont rares, et pas toujours orientables en mode portrait aussi bien qu’en mode paysage. Pour ces différentes raisons, les écrans HDMI ne sont donc pas toujours adaptés ni simples à utiliser de façon fiable dans nos applications d’avionique personnelle. La puissance graphique d’un ordinateur mono carte, associé à un logiciel graphique comme Processing, est pourtant bien supérieure à celle d’un microcontrôleur… Mais on va voir qu’il existes des alternatives.
Parallèle
Dans les interfaces parallèles, chaque bit de chaque couleur (rouge, vert, bleu) est transmis sur une ligne séparée. Ce qui fait 24 lignes si chaque couleur est codée sur 8 bits, auxquelles il faut rajouter plusieurs autres lignes, entre autres pour la synchronisation des balayages horizontal et vertical. Beaucoup de cartes microcontrôleur ne disposent tout simplement pas d’un nombre suffisant de broches. Il existe quelques rares (et coûteuses) cartes de prototypage exploitant un microcontrôleur haut de gamme incorporant lui même un contrôleur graphique très performant. Peu de ces cartes exposent une interface parallèle, via un port de sortie adapté, par exemple de type MIPI-DSI sur certaines cartes STM32 ou la carte Arduino Portenta. Mais ces cartes sont plutôt réservées à des applications industrielles et professionnelles, elles sortent un peu du domaine du “DIY”, c’est à dire du domaine de l’amateur auquel s’adresse ce site. Les écrans adaptés à ces cartes sont rares, souvent peu lumineux, et les bibliothèques quasiment introuvables…
L’avantage de tels contrôleurs graphiques parallèles RGB est lié d’une part à leur taux de rafraichissement élevé (50 images/seconde, voire beaucoup plus) et surtout au double ou triple buffer d’image qu’ils incorporent. Ces caractéristiques assurent une parfaite fluidité de l’affichage, sans clignotement ni scintillement pendant les transitions d’images. Le principe du double buffer est le suivant : l’image N, actuellement affichée, est stockée dans la mémoire vidéo de l’écran. Pendant ce temps, la prochaine image (N+1) est en cours de calcul et de stockage provisoire dans le buffer A. Au prochain signal de synchronisation verticale, l’image N+1 sera transférée depuis ce buffer A dans la mémoire vidéo, et donc affichée. Pendant cette transition, et pendant la durée d’affichage de l’image N+1, l’image N+2 commencera alors à être calculée et stockée dans le buffer B, et ainsi de suite. Ce type de contrôleur nécessite d’importantes ressources, en particulier au niveau de la mémoire, mais il permet des animations rapides, sans le moindre scintillement. Ce type d’interface ne répond donc malheureusement guère aux principes essentiels du cahier des charges qui figure en page d’accueil : simplicité et économie.
Série
C’est la catégorie d’interface la plus adapté à nos microcontrôleurs simples. Il en existe deux types, sur bus I2C et sur bus SPI.
I2C
Le bus I2C ne comporte que 2 fils, SDA et SCL. Plusieurs périphériques peuvent coexister sur le même bus, à condition d’avoir des adresses différentes. Ce bus est assez lent, parfaitement adapté aux capteurs, moins aux écrans. Certains écrans LCD monochromes alphanumériques, comme celui de la figure 1, bien qu’ayant de base une interface parallèle, peuvent être connectés à un bus I2C, grâce à une carte d’interface parrallèle-I2C, située au dos de l’écran. Pour afficher quelques lignes de texte, le bus I2C s’avère largement suffisant. Un écran de ce type pourrait avoir sa place en avionique, par exemple pour afficher quelques paramètres moteur, ou la position d’un trim, ou les réglages d’un pilote automatique…etc.
SPI
En raison de l’affichage rudimentaire et un peu désuet des écrans alphanumériques monochromes, les écrans graphiques en couleurs sont généralement préférés. D’autant plus que leur coût est souvent équivalent. La technologie TFT est de très loin la plus répandue. La connexion en SPI est la règle. Les écrans TFT à interface SPI ont des contrôleurs divers : ILI9341, ST7735, HX8357, RA8875… pour n’en citer que quelques uns. Leurs tailles sont très variées, de moins de 2 pouces de diagonale jusqu’à 7 pouces. Leurs définitions s’échelonnent de 128 x 160 à 800×480 pixels, parfois avec une interface tactile.
Le bus SPI est nettement plus rapide que le bus I2C, il utilise 4 fils : MISO, MOSI, CLK et CS. Il est parfaitement adapté à ces écran TFT et aux besoins des systèmes avioniques personnels. Ce bus a cependant un inconvénient important par rapport aux interfaces parallèles : il n’y a pas de possibilité de synchronisation entre le microcontrôleur, et le balayage de l’écran. Par ailleurs, les contrôleurs de ces écrans ne sont pas équipés de buffers multiples. Tout cela peut entraîner des phénomènes de scintillement (flickering) très gênants sur des animations rapides, se manifestant par des clignotements et/ou lignes ou des bandes sombres qui défilent verticalement. Les animations sont donc à utiliser avec parcimonie. D’une manière générale, la meilleure façon de supprimer les éventuels scintillements consiste à mettre à jour uniquement les zones de l’écran qui changent et de faire en sorte que ces zones soient les plus réduites possibles. Ces principes de prévention sont impossibles à appliquer dans l’exemple de la vidéo 1, où une grande surface circulaire se déplace. Le cercle est successivement affiché, puis effacé en traçant à la place un cercle identique, mais de la couleur du fond (ici le noir), puis affiché en vert à l’emplacement suivant : scintillements garantis ! Inutile de penser à programmer un jeu vidéo, avec des sprites mobiles, à l’aide d’un microcontrôleur et d’un écran TFT SPI !
Fort heureusement, les affichages en avionique peuvent se passer de sprites. Néanmoins, l’affichage de l’horizon artificiel d’un EFIS peut constituer une vraie difficulté. Il faut faire coexister sur l’écran de nombreux affichages textuels et graphiques qui varient rapidement, sur un fond lui même mobile, représentant le ciel en bleu et la terre en ocre. Pour surmonter cette difficulté, pour notre projet d’EFIS, nous avons choisi d’utiliser un écran équipé d’un contrôleur RA8875. Ce dernier sert d’interface entre le microcontrôleur, auquel il est connecté en SPI, et la dalle LCD-TFT auquel il est connecté via une interface parallèle (Fig. 2). Le RA8875 permet de gérer séparément deux couches différentes, chacune ayant sa propre mémoire dédiée, ce qui permet de se rapprocher un peu du principe du double buffer. Ce contrôleur bénéficie en outre d’un bibliothèque particulièrement efficace et rapide, optimisée pour les cartes Teensy.
L’inconvénient principal de la bibliothèque utilisée, mais c’est la rançon de sa rapidité, est qu’elle ne gère pas les tentatives d’affichage de pixels en dehors des coordonnées permises par la définition de l’écran. Il revient au programme soit de gérer ces dépassement, au prix d’un ralentissement des calculs, soit de les éviter. C’est la deuxième solution qui a été choisie, ce qui a conduit à faire une petite concession sur l’aspect habituel d’un horizon artificiel : les graduations de pitch se contentent de tourner avec l’horizon, mais ne se déplacent pas verticalement avec lui, voir la vidéo 2. Une meilleure solution sera peut-être adoptée ultérieurement…
Les écrans EastRising/BuyDisplay ont quelques fonctions annexes qui ne sont pas utiles pour nos projets : slot micro SD, emplacements SPI Flash et clavier. De plus, ils manifestent à l’usage une certaine tendance à dysfonctionner, par exemple si la connexion SPI dépasse quelques centimètres, ou si on utilise pour les essais une plaque de connexions sans soudure (breadboard). Pour ces raisons, nous préférons utiliser le contrôleur RA8875 Adafruit, plus fiable. Et une dalle séparée, comme celle-ci ou celle-là, qui ont en outre le gros avantage sur les dalle EastRising d’être de technologie IPS (angles de vision étendus). Ceci permet par ailleurs une plus grande flexibilité dans la disposition des éléments lors de l’installation sur le tableau de bord. En effet, la carte contrôleur RA8875 peut être intégrée sur le même circuit imprimé que la carte Teensy, ce qui garanti une connexion SPI la plus fiable et la plus courte possible. En outre, contrairement à la connexion SPI, la connexion parallèle (nappe à 40 conducteurs) peut être étendue sans inconvénient grâce à un prolongateur de 20 cm (Fig 3). Voir la page EFIS.
Les dalles LCD haute luminosité de 5 pouces de diagonale nécessitent un courant d’alimentation du rétroéclairage supérieur aux dalles 4.3 pouces. Pour cette raison, il est nécessaire les souder ensemble les deux pads intitulés “+100mA” au dos du contrôleur RA8875 (fig. 4).
N’hésitez pas à nous solliciter à nouveau !
Bonne réalisation !
Benjamin
Bonsoir la réponse me semble claire…je vais m’attaquer au projet…Merci et bravo pour ce travail
Bonjour Stephaner,
Un écran plus grand n’aurait pas d’intérêt ici, car la définition maximale de la carte graphique RA8875 est de 800 x 480, ce qui est adapté à un écran de 5″, voire au maximum 7″.
D’autre part, je pense qu’on aurait un peu de mal à “remplir” un écran de 10 ou 12″ juste avec un horizon artificiel et l’affichage des paramètres du moteur.
A supposer qu’il existe des écrans de 10 ou 12 pouces avec une définition de seulement 800 x 480, si on voulait afficher le contenu des 2 écrans actuels sur ce grand écran unique, il faudrait reconcevoir l’ensemble pratiquement de zéro, pour essayer de faire tenir les deux programmes (EFIS et EMS) sur un seul microcontrôleur. Il faudrait aussi beaucoup plus de broches disponibles…
Ou bien confier l’affichage sur grand écran à un Raspberry Pi qui recevrait toutes les données à afficher par le bus CAN. Vaste programme ! Mais on y pense et on a même déjà fait pas mal d’essais préliminaires. Tout est plus complexe avec un ordinateur mono-carte comme le R-Pi plutôt qu’avec un microcontrôleur, car il faut prévoir une alimentation sécurisée afin de ne pas risquer une extinction inopinée du système qui pourrait corrompre le système d’exploitation. Ce n’est pas un projet qui va voir le jour prochainement…
Les grands écrans de 10 ou 12 pouces sont bien adaptés aux glass-cockpits qu’on voit de plus en plus souvent sur nos petits avions et ULM, mais ils affichent (beaucoup) plus d’informations, notamment une carte défilante et mille autres choses.
Mais j’ai peut-être mal compris votre question.
Benjamin
Bonjour. Je suis très intéressé par votre réalisation.
Je suis loin de ma zone de confort en me lançant dans ce projet.
Est il possible par exemple de prendre un écran 10 voir 12 pouces de le partager en deux en 2 tiers 1 tiers.
Re bonjour Florent,
Cette question a été abordée dans la discussion de la page EFIS, plusieurs solutions y sont exposées.
Benjamin
Bonjour,
j’ai terminé le montage, j’ai un souci d’écran, il s’affiche dans le quart gauche en haut, comme si la résolution était mauvaise mais je trouve pas la solution, avez vous déjà eu le cas ?
merci de vos retours,
Florent
Bonjour Jean Claude,
Je me suis permis de déplacer ton commentaire de la page EFIS vers la page Ecrans.
Les modifications que tu projettes de faire sur la carte Adafruit RA8875 sont très intéressantes, tout comme tes essais d’écrans 7″.
Pourrais-tu partager tout cela ici quand tu auras testé le bon fonctionnement ?
Amicalement, et bonnes fêtes également,
Benjamin
Bonjour Benjamin,
Un break assez long en attendant mon afficheur Adafruit 7″. Je viens de le recevoir, surprise une taxe à la livraison plus le coût du transport ont doublé la valeur de celui-ci, un conseil, ne pas commander chez Adafruit directement. Bon, un constat, les programmes RA8875 pour UNO n’ont pas été testés chez Adafruit car ils ne fonctionnent pas.
L’important pour moi était le rétroéclairage de l’afficheur 7 ” haute intensité, celui ci fonctionne, mais je vais changer la valeur de la self du RA8875 pour mettre une 10µH car la 6,8 ne prend pas assez d’énergie; comme le TPS61165 de chez TI.
Bonnes fêtes de fin d’année à tous.
Amicalement
JCB
Pour répondre à une question de Jean Claude il y a quelques jours, voici une courte vidéo montrant le système de menus de l’EFIS en action.
Benjamin
Bonjour Jean Claude,
La bibliothèque RA8875 est peu documentée, mais il y a quand même un wiki qui mérite d’être consulté.
Sinon, les fichiers ra8875.h et ra8875.cpp contiennent pas mal de commentaires intéressants (les autres fichiers de cette librairie également), de même que la datasheet du RA8875.
Pour répondre plus précisément à ta question, la commande begin() peut contenir d’autres arguments que la définition de l’écran. Par exemple : tft.begin(Adafruit_480x272, 16); démarre l’écran en mode 480×272 et couleurs 16 bits, on pourra afficher jusqu’à 65535 couleurs simultanément. Si on remplace le 16 par un 8, on aura plus que 256 couleurs disponibles. Mais chacune de ces 256 couleurs est définie sur 16 bits selon le format RGB565.
En fait, on n’a pas vraiment besoin de ce 2ème paramètre de la fonction begin() : même si on précise 16, la bibliothèque va d’elle même réduire automatiquement la profondeur à 8 bits si la définition et l’utilisation des layers l’imposent. Le logiciel de l’EFIS est donc compatible 256 couleurs, ce qui est largement suffisant. Même si on souhaite personnaliser l’écran d’introduction avec une photo, 256 couleurs assurent un rendu parfait sur un petit écran.
Amicalement,
Benjamin
Bonjour Benjamin
J’ai terminé la partie matérielle, mes CI sont en commande chez Seeed, je me mets au logiciel, ce n’est pas le plus simple pour moi. Une question sur la gestion des couleurs de l’afficheur, utilises tu la profondeur 256 ou 65K ? Car pour gérer les “2 layers” en 800×480, je doit être en 256 couleurs seulement. Ou est située la commande permettant de définir ce paramètre, merci d’avance.
De façon plus générale, ton logiciel est il compatible 256 couleurs, ce qui me simplifierait la tâche.
Bien cordialement.
JCB
Bonjour Jean Claude,
J’ai effectivement souvenir d’avoir eu des difficultés de commande avec Analog Microsystems. J’ai cherché dans mes archives Outlook, j’avais en fait finalement commandé chez Amsys. Mais le circuit est le même qu’avec Analog Microsystems, ils ne cherchent manifestement pas à développer la vente en ligne. Je ne connais pas les liens qui unissent ces deux entités qui vendent les mêmes capteurs, avec des adresses postales quasiment identiques, mais les numéros de téléphone et adresses mail diffèrent.
Compte tenu de ces difficultés, si je devais commander à nouveau des capteurs de pression, je me demande si je ne chercherais pas du côté de Honeywell : très gros choix de capteurs, avec un circuit de vente “normal”, chez les grossistes habituels. Beaucoup de capteurs Honeywell disposent de bibliothèques dédiées Arduino/Teensy.
Benjamin
Bonjour Benjamin,
J’ai un problème pour commander les capteurs de pression chez Analog Microelectrinics Allemagne, j’ai fait ma demande sur leur site, j’ai eu en réponse un devis par email pour commander, mais je n’ai pas eu d’IBAN pour leur faire un versement comme indiqué dans leurs conditions de ventes. J’ai répondu à cet email pour demander leur IBAN, mais je n’ai pas de réponse depuis une semaine. Peux tu me dire comment tu as fait le versement de ta commande, stp. Pour info, c’est la première fois que je vois un modèle de vente comme le leur, pas de vente en ligne mais un retour par email; ça doit leur couter un max une personne pour répondre surtout pour des petites quantité ! Merci d’avance. JCB
Bonjour Jean Claude,
Je confirme que dans l’optique d’utiliser la bibliothèque “Hardware Quadrature Library for the Teensy 4.x” (elle est vraiment performante), la connexion des broches OUTPUT A et OUTPUT B sur les pins 30, 31 ou 33 de la Teensy 4.1 est parfaite. Tout comme l’utilisation des pins 36 et 37 comme dans la version 1 de l’EFIS. Dans la version 2, j’ai malencontreusement interverti des pistes sur le PCB, ce qui fait utiliser les pins 35 et 37 pour les phases A et B de l’encodeur, mais la pin 35 n’est pas supportée par le hardware… J’ai donc dû modifier le logiciel pour me passer de cette bibliothèque, et du coup, l’encodeur est moins réactif.
Je suis en train de compléter le logiciel de l’EMS pour lui “greffer” une partie “Menus”, ce qui va bien me remettre en mémoire l’algorithme des menus utilisé pour l’EFIS. Cet algorithme m’avait donné pas mal de fil à retordre. J’avais dû repartir de zéro pour écrire cet algorithme, n’ayant rien trouvé de satisfaisant et adapté aux besoins particuliers d’un EFIS.
Bon courage pour la réalisation matérielle.
Benjamin
Bonjour Benjamin
J’ai suivi ton conseil, pas de connecteur SPI mais j’ai ajouté 3 connecteurs 3 points mâles me servant d’aiguilleur avec un pontet pour soit avoir le câblage actuel du rotacteur optique, soit aller vers les points 30, 31 et 33 permettant d’utiliser la bibliothèque pour le GrayHill. J’ai recommandé un RA8875 sur eBay car le délais de Digikey est vers le 25 janvier 2023 ! Mon CI est prêt, je vais pouvoir me faire chauffer la tête avec la partie logicielle…
Je te tiens au courant de la réalisation matérielle lorsque j’aurai toute les pièces.
Très cordialement, JCB
Bonjour Jean Claude,
La carte RA8875 est effectivement en rupture chez Digikey, mais elle est en stock chez Mouser, et on la trouve aussi sur ebay.
Je n’ai malheureusement pas de vidéo du système de menus. En attendant que je trouve le temps d’écrire une page du site dédiée à ce système de menu, voici un lien vers un fichier contenant des fragments de code abondamment commentés, extraits du programme de l’EFIS.
On peut bien sûr rajouter un connecteur sur le PCB pour disposer d’un port SPI disponible pour une future évolution. Mais si l’idée germait à l’avenir d’une évolution nécessitant un port SPI supplémentaire, j’ai l’impression qu’il serait aussi simple de refaire un nouveau PCB propre et net pour y placer le composant qui nécessiterait une liaison SPI…
L’encodeur optique GrayHill tel qu’il est actuellement connecté ne tire pas profit des 4 “hardware quadrature encoder channels” disponibles sur les Teensy 4.1. Si je devais refaire mon PCB maintenant, c’est la première modification que je ferais. Voir ici. Mais je n’ai pas encore fait de tests en ce sens avec cette bibliothèque…
Benjamin
Bonjour Benjamin,
Oups, j’ai tout faut. Je viens de recevoir une grande partie de ma commande DigiKey, dont l’afficheur. Une pièce de belle facture mais que je ne peux pas tester car la carte RA8875 est en rupture de stock actuellement. La vidéo présentant l’initialisation de l’EFIS permet de voir ce qui se passe dans la partie Setup du programme. Pouvez vous mettre une vidéo sur la partie menu et sous menus permettant là aussi de mieux appréhender le programme. J’ai jeté un œil sur celui ci et je pense qu’il y a beaucoup de temps et de neurones à dépenser avant de le comprendre.
J’ai repris le circuit imprimé pour l’adapter à l’afficheur. Une question avant de lancer la fabrication, ne serait il pas judicieux de mettre un connecteur 6 points pour une liaison SPI supplémentaire avec celle qui reste disponible, en réserve pour une évolution future.
Merci encore pour cette belle réalisation. A bientôt pour les nouvelles.
JCB
Bonjour Jean Claude,
Nous sommes dans l’open source soft et hard, il est donc tout à fait possible de personnaliser comme on le souhaite.
L’affichage d’images fixes ou de photos stockées sur la microSD d’une carte Teensy 4.1 est possible. Je l’ai fait pour la séquence de démarrage de l’EFIS installé dans mon MCR.
Je suis dans le Var, le MCR est à LFTF, donc pas vraiment à côté de Chartres !
Amicalement,
Benjamin
Pour n’utiliser qu’un seul GPS, les modifications des programmes de l’AHRS et de l’EFIS sont très simples à faire si on en reste à la transmission série entre l’AHRS et l’EFIS, comme c’est le cas actuellement. En effet l’AHRS envoie 20 fois par seconde à l’EFIS une trame binaire de 74 octets, dont 38 seulement sont utilisés. Les 36 autres sont à zéro et sont donc disponibles, par exemple pour que le GPS associé à l’AHRS transmette d’autres paramètres à l’EFIS comme l’heure, l’altitude AMSL, la vitesse sol… etc. Le GPS contenu dans l’EFIS devient ainsi inutile. Je vais faire ces modifications sur les 2 programmes et vérifier le fonctionnement sur mon MCR, cela va peut-être prendre “un peu” de temps…
Si on souhaite exploiter l’AHRS sur le bus CAN et abandonner la transmission série, les modifications à faire sont un peu plus conséquentes. Matériellement, l’AHRS est déjà prêt pour le CAN bus.
Bonjour Jean Claude,
Il y avait une imbrication malencontreuse des commentaires qui n’apparaissaient donc pas forcément dans l’ordre chronologique. De ce fait, tu n’as pas dû voir ma réponse du 2/11 à 22h59 (voir ci-dessous). Ce que j’avais écrit répondait à ton commentaire d’aujourd’hui. J’ai modifié la configuration du site, les imbrications de commentaires ne sont plus possibles, et désormais l’ordre chronologique est respecté. Le commentaire le plus récent apparait en haut comme il se doit. C’est beaucoup plus clair ainsi.
Amicalement,
Benjamin
Benjamin,
Cet EFIS est une réalisation DIY, pourquoi ne pas lui ajouter une personnalisation comme je l’ai fait sur un altimètre que j’ai développé avec une Arduino Nano. Durant les 5 premières secondes, j’affiche le nom de la machine ainsi que le nom de son propriétaire. Mon objectif de départ était d’afficher une photo de la machine avec son propriétaire et d’ajouter son nom, malheureusement le Nano ne pouvait pas supporter tout le code, donc j’ai fait plus simple. Mais ici, on a tout ce qu’il faut : l’image à afficher est mise sur la carte µSD de la Teensy, c’est une image jpeg qui est créée avec Img2lcd pour être directement compatible avec le TFT; qu’en penses tu ?
Une question, où es tu basé ? Perso je suis à LFOR (Chartres), peut être es tu pas très loin, et si c’est le cas je serais ravi de te rencontrer.
Amicalement.
Jean-Claude
Bonjour Benjamin,
Je viens de recevoir mes 2 Teensy 4.1 de chez PJRC, les 4.0 sont en rupture de stock actuellement, donc commandé chez DigiKey.
La dalle 7″ que j’ai commandée chez DigiKey est la NHD-7.0-800480MB-ASXN-ND, elle coute 109,52 €, voici le lien : https://www.digikey.fr/fr/products/detail/newhaven-display-intl/NHD-7-0-800480MB-ASXN/8574360?s=N4IgTCBcDaIHIAkAiBaA7AOgAwoBxawBZ8BZAIRQEEBlADThTiRAF0BfIA
J’ai commandé un seul GPS, penses tu faire une évolution du programme sur l’AHRS et l’EFIS pour cette configuration simplifiée ?
Amicalement
Jean-Claude
Bonjour Benjamin,
Pour info, je viens de passer une commande chez DigiKey pour l’AFIS et l’AHRS. Question, y a t’il un GPS NEOM9N de connecté directement sur l’AFIS, versus V1 en plus de celui de l’AHRS ?
Il me reste à commander les capteurs de pressions, je n’ai pas trouvé où les acheter. Peux tu mettre le fournisseur que tu as pris, merci. Bien cordialement. Jean-Claude Buron
Bonjour Jean Claude,
Oui, je confirme que le système installé dans mon MCR comporte 2 GPS NeoM9N, un dans l’EFIS et un autre dans l’AHRS. Mais c’est pour les raisons historiques que j’ai expliquées dans mon message précédent. Un seul GPS est en fait suffisant, il me semble logique de le mettre dans l’AHRS, et donc géré par le microcontrôleur Teensy 4.0 de cet AHRS. Ce microcontrôleur surpuissant peut parfaitement gérer aussi l’envoi à l’EFIS de quelques paramètres supplémentaires, comme l’heure exacte, par exemple. Bien sûr, il faut pour cela modifier quelques lignes de code. Sinon la configuration à 2 GPS publiée sur le site fonctionne très bien, mais ce n’est pas très économique.
Pour les capteurs de pression, il faut les commander directement chez Analog Microelectronics en Allemagne. Il faut préciser à la commande que l’on souhaite des adresses I2C différentes pour les deux capteurs. Ce que j’avais omis de faire, c’est la raison pour laquelle j’ai dû les connecter sur des ports I2C différents. Ce qui n’était pas trop gênant.
Je serais très intéressé par la référence de la dalle LCD 7 pouces, et par les résultats des essais avec cet écran. Pour permettre à la carte RA8875 Adafruit de fournir plus de courant au rétroéclairage, il faut souder les 2 pads marqués +100 mA au dos de la carte.
Amicalement,
Benjamin
Bonjour Benjamin,
Je reviens l’afficheur 7″, j’ai trouvé un modèle avec languettes mécaniques pour le support mécanique, ainsi que des inserts pour vis de 3 permettant de supporter un circuit imprimé. D’autre part, il a une consommation pour le rétroéclairage plus raisonnable de 180 mA sous 9,3 V, ce qui le place en puissance consommée de backLight à 1,67 W, identique à la puissance du Reverdi RVT50HQTFWN00.
Pour info, je viens de passer une commande chez DigiKey pour l’AFIS et l’AHRS. Question, y a t’il un GPS NEOM9N de connecté directement sur l’AFIS, versus V1 en plus de celui de l’AHRS.
Reste les capteurs de pressions, peux tu mettre le fournisseur que tu as pris, merci.
Bien cordialement.
Jean-Claude Buron
J’ai rajouté la Bill of Materials sur la page en langue anglaise de l’EFIS.
Théoriquement, les pages en anglais et en français devraient être identiques… En pratique, il peut y avoir un petit délai entre les rédactions dans les deux langues, dans un sens ou dans l’autre…
Benjamin
Bonjour Benjamin,
Merci pour cette réponse rapide et détaillée. J’ai regardé les données techniques sur les datasheets, la consommation typique du premier écran 7″ est de 500 mA, le driver de la carte RA8875 est donné pour 1.1 A typique, 1.5 A max; donc aucun soucis pour piloter l’afficheur 7″.
Je n’ai pas encore regardé les pages en anglais, pensant qu’elles n’apportaient pas d’informations complémentaires aux pages françaises. Maintenant je vais consulter ces pages attentivement.
A bientôt.
Bonjour Jean Claude,
Pour mon MCR, l’écran de l’EFIS est un 4.3″, et celui de l’EMS est un 5″, tous deux de marque Riverdi et de technologie IPS.
Il existe des écrans 7″ avec une définition de 800×480 qui sont donc compatibles avec le contrôleur RA8875.
Celui ci est IPS, avec une luminosité de 1200 Nits. Il est disponible sur ce site
Celui-là a une luminosité de 1000 Nits, mais il n’est pas IPS. Disponible ici.
Le rétro-éclairage de ces écrans 7″ demande plus de puissance que les 5″. Le driver de LED choisi par Adafruit sur la carte RA8875 est celui-ci. Je ne suis pas un expert en interprétation de datasheets, je ne sais pas si ce driver est suffisant pour permettre 1000 nits avec un 7″. Pour info, le circuit de la carte Adafruit est ici.
Il y a d’autres choix possibles en 7″ (toujours avec cette même interrogation pour le rétro-éclairage) sur les sites comme Mouser et Digikey.
Concernant la BOM de l’EFIS, il faut que je la rédige, et que je mette à jour la page EFIS en français. La page en anglais est à jour, avec les fichiers Kicad de l’EFIS V2. Sur le schéma, il y a déjà pas mal d’indications.
Bien cordialement,
Benjamin
Bonjour,
Ravis de voir toutes ces évolutions, bravo à l’équipe. Une question sur la partie afficheur, quelle taille sera retenue pour le projet final ? Pour ma part, je pense qu’un écran de 5″ est trop petit, un 7″ serait parfait. En regardant chez Riverdi, je vois que l’écran 7″ n’est pas compatible avec la carte pilote Adafruit, trop de pixels. Il existe des cartes 7″ compatibles mais elles ont une luminosité de 250 cd/m², un peu faible lorsque le soleil donne sur le tdb.
Pouvez vous m’en dire plus, svp.
Question subsidiaire, quand pensez vous mettre sur votre site une nomenclature pour l’EFIS ?
Très cordialement.
JCB