(Écrans TFT et avionique DIY : Dernière mise à jour par Benjamin le 25/03/2026)
Le choix d’un écran TFT-LCD pour un projet d’avionique DIY dépend de nombreux facteurs. Le type d’écran, l’interface de connexion, la disponibilité et la qualité des bibliothèques, ainsi que la luminosité doivent être pris en compte. La taille et la résolution dépendront de l’application logicielle et de l’espace disponible sur le tableau de bord. Par exemple, pour un EFIS ou un EMS, afin d’assurer une excellente lisibilité en toutes circonstances, une taille de 4,3 à 5 pouces, une résolution de 480 × 272 pixels et une luminosité de 500 cd/m² sont les exigences minimales. La technologie IPS offre des angles de vue larges, très appréciables.
Tactile ou pas ? C’est une question de choix personnel : en cas de turbulence, sélectionner une petite zone d’écran ou une option de menu peut s’avérer difficile sur un écran de 5 pouces (ou moins). D’autres systèmes de contrôle doivent être envisagés, tels que boutons-poussoirs, encodeurs rotatifs ou joysticks, qui sont souvent plus précis que les écrans tactiles capacitifs. Ces derniers présentent aussi l’inconvénient d’être toujours brillants, sujets aux reflets, alors qu’un écran non tactile, mat, est beaucoup plus lisible en plein soleil.
Une fois le microcontrôleur ou microprocesseur (MCU/MPU) du projet choisi, l’interface entre le MCU/MPU et l’écran constitue la principale spécification technique à prendre en compte. Bien sûr, cela dépend du type d’écran et du MCU/MPU. Il existe plusieurs interfaces avec les écrans, notamment HDMI, série, et RGB-parallèle, pour ne citer que les plus courantes. Une fois le type d’écran et l’interface sélectionnés, tous les critères mentionnés ci-dessus doivent être pris en compte.
Comment fonctionnent les écrans ?
Il ne s’agit pas ici d’expliquer en détail la technologie des afficheurs LCD ou TFT, mais plutôt la manière dont ils s’interfacent avec nos MCUs. Dans les systèmes embarqués simples qui nous intéressent, la chaîne d’affichage comprend quatre éléments de base : l’afficheur TFT-LCD, le contrôleur graphique, la mémoire tampon d’affichage, et le MCU/MPU.
L’afficheur TFT-LCD
Son rôle est bien sûr d’afficher des graphismes ou des textes. En termes très simples, le panneau de l’afficheur se compose de pixels. Il reçoit des signaux électriques qui, après traitement approprié, peuvent allumer ou éteindre individuellement les pixels et déterminer leur couleur et leur luminosité. La figure 1 montre un afficheur TFT typique.
La connexion à l’afficheur utilise généralement un câble flexible en nappe (câble FFC), le plus souvent à 40 conducteurs. Alors que des dizaines ou des centaines de milliers de pixels doivent être pilotés, selon la taille et la résolution du panneau.
Les afficheurs TFT contiennent donc toujours un driver. Il s’agit d’un circuit intégré spécialisé qui reçoit les données numériques via le câble FFC et génère les tensions analogiques appropriées, avec une synchronisation précise, pour contrôler individuellement chaque pixel rouge, vert et bleu de l’écran. Par exemple, le ST7277 de Sitronix est conçu pour piloter des panneaux TFT 800×480 ; il en existe évidemment une multitude d’autres.
Le contrôleur graphique
Sa fonction est de lire en boucle continue la mémoire tampon et de transmettre les données des pixels, ainsi que les signaux de synchronisation et d’horloge, via le FFC, vers le driver de l’afficheur.
La mémoire tampon
C’est une zone mémoire qui stocke en temps réel les informations de couleur et de luminosité de chaque pixel. Par exemple, si l’afficheur supporte une profondeur de couleur de 16 bits (RGB 565, voir ci-dessous), alors 2 octets de mémoire tampon sont nécessaires par pixel. Si la résolution du panneau est de 800 x 480 pixels, la capacité minimale de mémoire tampon requise est de 800 x 480 x 2 = 768 kilo-octets.
Le MCU/MPU
Sa fonction est de calculer les images à afficher et d’alimenter la mémoire tampon en conséquence, avec les données appropriées. Il n’a pas besoin de mettre à jour l’intégralité de la mémoire tampon à chaque image. Il doit simplement mettre à jour dans la mémoire ce qui a changé par rapport à l’image précédente.
Les différents types d’écran
Les quatre éléments de base mentionnés ci-dessus peuvent être organisés de différentes manières. Les petits écrans à faible résolution ont tendance à disposer d’une mémoire tampon et d’un contrôleur graphique intégrés. Par exemple, le circuit ILITEK ILI9340 permet de piloter un afficheur TFT LCD couleur RGB 240×320, qui prend en charge des profondeurs de couleur de 16 ou 18 bits. Il regroupe sur une seule puce un driver, un contrôleur graphique, la mémoire tampon nécessaire et une interface SPI. Beaucoup de petits écrans utilisent ce circuit (Fig. 2).
Les afficheurs plus grands, comme celui illustré à la figure 1, peuvent être gérés soit par un microcontrôleur via une interface SPI et une carte spécialisée comprenant une mémoire tampon et un contrôleur graphique (un bon exemple est le RA8875, voir ci-dessous), soit par un microcontrôleur plus puissant intégrant la mémoire tampon et le contrôleur graphique, et via une interface RGB parallèle (voir ci-dessous les écrans ESP32).
L‘interface HDMI
Ordinateurs monocarte
Les cartes microcontrôleurs n’intègrent jamais de connecteur d’affichage de type HDMI. En revanche, les ordinateurs mono-carte (SBC, pour Single Board Computer), comme par exemple le Raspberry Pi sous Linux ou le LattePanda sous Windows, disposent d’une telle interface.
Cependant, les ordinateurs, et en particulier leurs systèmes d’exploitation, sont peu tolérants à la perte d’alimentation. Ils doivent être éteints correctement. Les systèmes embarqués doivent être conçus de manière à ce qu’une perte d’alimentation inattendue (comme la bascule du Master Switch dans un avion) ne provoque pas de corruption du système d’exploitation ni de perte de données dans le logiciel applicatif en cours d’exécution.
Pour fonctionner en toute sécurité dans une application embarquée, un ordinateur monocarte nécessite donc des dispositifs pour sécuriser son alimentation (comme celui-ci pour le Raspberry Pi, par exemple), qui donnent au système d’exploitation le temps de s’éteindre correctement. On parle d’UPS, pour Uninterruptible Power Supply. Dans le cadre d’un projet DIY, le système est donc plus complexe et plus sujet à des défaillances.
Microcontrôleurs
Ils sont beaucoup mieux adaptés aux tâches embarquées. Leur procédure standard d’arrêt consiste simplement à couper l’alimentation.
Par ailleurs, les écrans HDMI lisibles en plein soleil sont très rares et exceptionnellement utilisables aussi bien en mode portrait qu’en mode paysage. Pour ces raisons, les écrans HDMI ne conviennent guère, et ne seraient pas faciles à utiliser dans nos applications d’avionique. 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 surtout, on va voir qu’il existe d’excellentes alternatives.
MIPI-DSI
Comme le HDMI, il s’agit d’une autre interface de niveau industriel. Certaines cartes microcontrôleurs haut de gamme, volumineuses et coûteuses (STM32, Arduino Portenta, etc.) intègrent un contrôleur graphique haute performance et disposent d’un connecteur MIPI-DSI.
Mais la rareté des écrans MIPI-DSI (surtout avec la haute luminosité requise), combinée à la complexité de ces microcontrôleurs professionnels, et à l’absence de bibliothèque graphique adaptée et simple d’utilisation, rend leur emploi dans un projet d’avionique DIY pratiquement impossible pour un amateur. Ces cartes sont plutôt destinées à des applications industrielles et professionnelles, elles sortent du domaine de l’amateur auquel ce site est destiné.
Les interfaces série
C’est la catégorie d’interface la plus courante pour les microcontrôleurs. L’interface série peut utiliser le protocole I2C ou SPI.
I2C
Le protocole I2C peut contrôler un système quelconque grâce à seulement deux broches d’entrée/sortie (SDA et SCL). Plusieurs appareils peuvent coexister sur un bus I2C tant qu’ils ont des adresses différentes. Ce bus est relativement lent, idéal pour des capteurs, un peu moins pour des écrans. Certains écrans LCD monochromes alphanumériques, comme celui illustré à la figure 3, bien qu’ayant une interface parallèle, peuvent être connectés à un bus I2C à l’aide d’une petite carte d’interface parallèle-vers-I2C soudée au dos de l’écran.
Pour afficher quelques lignes de texte, le bus I2C est alors amplement suffisant. Un tel écran pourrait trouver sa place sur un tableau de bord, par exemple pour afficher certains paramètres du moteur, la position d’un trim, les réglages d’un pilote automatique, etc. Cependant, cette technologie bien éprouvée a une apparence quelque peu austère et rétro, et fonctionne sous 5 volts, alors que les microcontrôleurs récents utilisent une tension de 3,3 volts.
Il existe aussi des écrans de technologie OLED utilisant le bus I2C, souvent de petite taille et de faible résolution. Ils permettent d’afficher des textes courts ou des graphiques très simples. Ils peuvent être utilisés avec une tension de 3,3 volts.
SPI
En raison de la nature rudimentaire et de l’aspect archaïque des écrans LCD alphanumériques monochromes, les écrans graphiques couleur sont généralement préférés. La technologie TFT est de loin la plus répandue. La connexion SPI est la plus courante. Les écrans TFT avec une interface SPI utilisent divers contrôleurs, par exemple le ST7735, le HX8357, le RA8875, entre autres. Leur taille varie de moins de 2 pouces en diagonale, jusqu’à 7 pouces. Leur résolution va de 128 x 160 à 800 x 480 pixels, et certains modèles incluent une interface tactile.
L’interface SPI
Le bus SPI est nettement plus rapide que le bus I2C. Quatre fils sont nécessaires : MISO, MOSI, CLK et CS. Le SPI convient très bien aux besoins des écrans TFT des systèmes avioniques personnels. Ce bus présente cependant un inconvénient important par rapport aux interfaces parallèles : il n’est pas possible de synchroniser le microcontrôleur avec 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 des lignes ou des bandes sombres qui défilent verticalement. Les animations sont donc à utiliser avec parcimonie.
Comment éviter les clignotements ?
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 à les réduire au minimum.
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 à sa place un cercle identique, mais de la couleur du fond (ici le noir), puis affiché de nouveau à l’emplacement suivant : de forts scintillements sont alors 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 !
Heureusement, les affichages en avionique peuvent se passer de sprites. Néanmoins, l’affichage via SPI et sans scintillement de l’horizon artificiel d’un EFIS constitue un vrai défi. Il faut faire coexister sur l’écran de nombreux affichages textuels et graphiques qui varient rapidement, sur un fond lui-même mobile symbolisant le ciel en bleu et la terre en ocre.
Le contrôleur graphique RA8875
Pour notre projet d’EFIS Teensy, afin de surmonter cette difficulté, 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. 4). 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 du principe du double buffer. Ce contrôleur bénéficie en outre d’une bibliothèque particulièrement efficace et rapide, optimisée pour les cartes Teensy 4.x.
La bibliothèque RA8875
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 autorisées par la définition de l’écran. Il revient au programmeur soit de gérer ces dépassements, au prix d’un ralentissement lié à des calculs plus complexes, soit de les éviter, grâce à des calculs moins complexes.
C’est la deuxième solution qui a été choisie, ce qui a conduit à faire des concessions par rapport à 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, et l’arc des graduations d’angle de roulis est fixe (vidéo 2). Une solution plus élégante aurait certainement pu être envisagée, mais entre-temps, l’EFIS-EMS ESP32 (cf. plus bas) a changé la donne.
Quel contrôleur RA8875 utiliser ?
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 tendance certaine à 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). Les écrans noirs, aussi intempestifs qu’incompréhensibles, ne sont pas rares.
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 dalles 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 garantit 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. 5). 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 à celui des dalles de 4,3 pouces. Pour cette raison, il est nécessaire de souder ensemble les deux pads intitulés « +100mA » au dos du contrôleur RA8875 (fig. 6).
Interface parallèle
Avec les interfaces parallèles (ou RGB-parallèle), chaque bit de chaque couleur (Rouge, Vert, Bleu) est transmis sur une ligne distincte. Il faut donc 24 lignes si chaque couleur est codée sur 8 bits ; c’est ce qu’on appelle le mode RGB888. Seules 16 lignes sont nécessaires pour le mode RGB565, où le Rouge et le Bleu sont codés sur 5 bits et le Vert sur 6 bits.
Plusieurs autres lignes sont requises pour les synchronisations verticale et horizontale, pour le signal d’horloge, etc. Et une ligne correspond à une broche. Ainsi, de nombreuses cartes de microcontrôleurs manquent tout simplement de broches. Par ailleurs, une puissance de calcul élevée et une mémoire de grande capacité sont nécessaires pour gérer toutes ces broches et tous ces signaux.
L’avantage d’une telle interface graphique RGB parallèle, combinée à une double mémoire tampon (un bloc de données étant affiché pendant qu’un autre est en cours de calcul et de mise à jour), est de permettre des animations rapides, sans le moindre scintillement. Mais cela demande beaucoup de ressources, notamment en mémoire.
L’interface RGB parallèle est-elle compatible avec les microcontrôleurs ?
Jusqu’à récemment, ce type d’interface ne répondait pas aux principes essentiels décrits sur la page d’accueil du site AvionicsDuino : la simplicité et la maîtrise des coûts. Mais l’arrivée récente d’écrans ESP32 à faible coût, combinée à l’émergence de deux bibliothèques graphiques dédiées, de qualité exceptionnelle (TFT_eSPI et LovyanGFX), a radicalement changé la situation. La figure 7 montre l’un de ces écrans à contrôleur ESP32.
L’EFIS-EMS ESP32
Les capacités graphiques de ces écrans, associées à la bibliothèque LovyanGFX (que nous privilégions), sont exceptionnelles. L’utilisation intensive de sprites permet de réaliser des animations de qualité professionnelle, sans scintillement. Un horizon artificiel très réaliste devient possible grâce à de simples microcontrôleurs. La figure 8 montre l’aspect de l’écran du nouveau système AvionicsDuino ESP32 EFIS-EMS, doté d’un écran de 7 pouces.
La luminosité de la totalité des écrans ESP32 disponibles sur le marché est bien trop faible. De plus, leur écran tactile brillant est fortement sujet aux reflets, et est difficilement utilisable en cas de turbulence. Pour ces raisons, et pour le projet EFIS-EMS, une carte contrôleur ESP32-S3 personnalisée a été développée. Elle est associée à une dalle TFT mate non tactile de 1000 cd/m². Ce système d’affichage est contrôlé via six boutons-poussoirs en façade. Voir la page « ESP32 EFIS EMS ». Ce système utilise un autre microcontrôleur ESP32-S3 pour son module d’acquisition de données distantes (RDAM, pour Remote Data Acquisition Module).
Bonjour Benjamin,
Merci pour la précision.
Bien cordialement,
P.
Bonjour Pascal,
Merci pour votre commentaire. Il m’a permis de me rendre compte que la référence de l’écran 5″ de l’EMS n’était pas indiquée sur la page « EMS », mais uniquement sur la page « Ecrans ». La correction est faite.
Oui, pour l’EMS, la référence de l’écran 5″ 800×480 est bien Riverdi RVT50HQTFWN00. La référence de l’écran 4.3″ 480×272 de l’EFIS est Riverdi RVT43HLTFWN00. Ce sont deux dalles IPS non tactiles haute luminosité (1000 nits). Riverdi les vend en direct.
Bien cordialement,
Benjamin
Bonjour,
Merci beaucoup pour ces informations précieuses.
Juste une petite précision, serait il possible d’avoir la référence précise de l’écran de la marque Riverdi ?
Est ce bien RVT50HQTFWN00 ecran 5″ sans touchpad ?
Vous en remerciant par avance.
Cordialement
PV
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