Rotation de l’écran sur l’écran 7″ du Riverdi STM32

Table des matières

Rotation de l'écran sur l'écran 7" du Riverdi STM32

La rotation de l’écran est une exigence courante dans les appareils basés sur le STM32, en particulier lorsque la conception mécanique impose une orientation portrait ou un montage inversé. Sur les systèmes utilisant le contrôleur d’écran LTDC, la rotation doit être gérée par logiciel, car le contrôleur lui-même ne fournit pas de rotation native du framebuffer.

Cet article explique une approche pratique et couramment utilisée pour la rotation de l’écran sur les systèmes STM32 en utilisant TouchGFX et l’alignement tactile, avec une correction optionnelle du côté du panneau lorsque l’installation physique l’exige.

Problèmes typiques

Les problèmes de rotation d’écran se présentent généralement sous l’une ou plusieurs des formes suivantes :

• l’interface utilisateur est affichée dans une mauvaise orientation par rapport à l’enceinte
• le contenu de l’écran n’est lisible que lorsque l’appareil est physiquement tourné
• la saisie tactile ne s’aligne pas sur les éléments visibles de l’interface utilisateur

Ces symptômes ne sont pas dus à des défauts du matériel d’affichage, mais à la manière dont l’orientation est gérée par le logiciel.

Hypothèses du système

Cette approche a été validée sur un écran TFT Riverdi de 7 pouces connecté à un microcontrôleur STM32 à l’aide de l’interface LTDC. Le comportement et la configuration décrits s’appliquent à cette catégorie d’écrans Riverdi STM32 et sont représentatifs de configurations similaires.

Comment l’orientation est gérée sur le STM32 LTDC

Le périphérique LTDC balaie la mémoire tampon dans un ordre fixe défini par la disposition de la mémoire. Il ne prend pas en charge la rotation du framebuffer de 90 ou 270 degrés au niveau matériel.

C’est pourquoi la rotation de l’écran sur les systèmes STM32 est généralement divisée en deux aspects indépendants : l’orientation visuelle de l’interface utilisateur et le mappage des coordonnées tactiles. Chacun de ces aspects doit être traité de manière explicite.

Stratégie de rotation recommandée

Une stratégie robuste et couramment utilisée consiste à gérer les changements d’orientation de 90 degrés au niveau du cadre de l’interface graphique et à appliquer une correction supplémentaire de 180 degrés uniquement si le montage mécanique l’exige. Cela permet d’éviter la rotation du framebuffer pendant l’exécution et de maintenir une utilisation prévisible de l’unité centrale et de la mémoire.

Gestion de l'orientation à 90 degrés dans TouchGFX

TouchGFX gère l’orientation en rendant l’interface utilisateur nativement pour les dimensions d’écran configurées. Un changement de 90 degrés entre le paysage et le portrait est réalisé en sélectionnant la largeur et la hauteur appropriées et en concevant l’interface utilisateur pour cette orientation.

Le framebuffer lui-même n’est pas tourné. Au lieu de cela, l’interface utilisateur est générée directement dans l’orientation requise.

TouchGFX Designer montrant un projet configuré pour l'orientation portrait ou paysage

Correction optionnelle de 180 degrés au niveau du panneau ou du logiciel

Dans certains cas, l’écran est monté à l’envers par rapport à l’orientation prévue de l’interface utilisateur. Dans ce cas, une correction supplémentaire de 180 degrés peut être nécessaire.

Cette correction n’est pas effectuée par le périphérique LTDC. Elle peut être appliquée au niveau de la configuration du panneau à l’aide des commandes de l’interface d’affichage, ou bien dans le logiciel en appliquant la logique d’inversion des coordonnées.

Dans l’approche côté panneau illustrée dans la capture d’écran, la rotation de 180 degrés est réalisée par un seul changement dans la séquence d’initialisation du panneau DSI.
Commentez cette commande DSI spécifique (dans cet exemple, la ligne 250) qui déverrouille les registres de contrôle du panneau:

Le panneau fonctionne alors avec un sens de balayage inversé, ce qui entraîne une rotation effective de 180 degrés de l’image affichée.

Aucune autre modification n’est nécessaire dans cette séquence pour appliquer la rotation.

Ce comportement est spécifique au panneau et dépend de la façon dont le contrôleur du panneau interprète ses commandes d’initialisation. Le changement n’ affecte que l’orientation du balayage côté panneau et fonctionne indépendamment du processus de balayage du framebuffer LTDC. Il n’implique aucune rotation matérielle du framebuffer du côté du STM32.

Lorsque cette méthode est utilisée, les coordonnées tactiles doivent toujours être alignées séparément, car le contrôleur tactile continue de transmettre des coordonnées brutes basées sur l’orientation physique du capteur.

Gestion tactile avec LITEK ILI2132A dans les écrans Riverdi IPS

Tous les écrans Riverdi IPS jusqu’à 10 pouces utilisent lecontrôleur tactile capacitif ILITEKILI2132A. Lorsque vous travaillez avec la rotation de l’écran sur des systèmes basés sur STM32, il est important de comprendre comment ce contrôleur rapporte les coordonnées tactiles et comment la rotation doit être gérée.

Correction du rapport sur les coordonnées brutes

L’ILI2132A transmet toujours des coordonnées tactiles brutes, non modifiées, qui sont directement liées à l’orientation physique du capteur tactile. Le contrôleur ne propose aucune option de configuration permettant de passer du mode portrait au mode paysage, et ne prend pas non plus en charge la rotation en cours d’exécution ou l’inversion à 180 degrés des coordonnées communiquées.

Il n’y a pas de registre d’orientation ou de rotation qui puisse être utilisé pour informer le contrôleur que l’écran a été tourné. Quelle que soit l’orientation de l’écran utilisée par le cadre GUI ou le contrôleur d’affichage, l’ILI2132A continue à émettre les mêmes valeurs X et Y brutes.

Ce comportement est le fruit d’une conception et doit être considéré comme une caractéristique fixe du contrôleur.

Rotation et alignement des touches par logiciel

Étant donné que l’ILI2132A transmet toujours des coordonnées brutes, l’alignement tactile doit être entièrement réalisé par logiciel. La rotation de l’écran et le mappage tactile sont deux étapes indépendantes qui doivent être traitées de manière cohérente.

L’approche recommandée consiste à transformer les coordonnées tactiles brutes en fonction de l’orientation finale de l’écran avant de les transmettre au cadre de l’interface graphique.

Tout d’abord, déterminez l’orientation finale de l’écran utilisée par le système, par exemple paysage natif, portrait, paysage inversé ou portrait inversé. Cette orientation est généralement définie par les paramètres du projet TouchGFX ou par la rotation de l’affichage LVGL.

Ensuite, lisez les coordonnées tactiles brutes transmises par l’ILI2132A. À ce stade, les coordonnées reflètent toujours l’orientation native du capteur tactile.

Appliquez ensuite une transformation de coordonnées basée sur l’orientation de l’écran sélectionnée. La transformation dépend de la largeur et de la hauteur de l’écran après la rotation et implique généralement une permutation des axes et une inversion de l’une ou des deux plages de coordonnées.

Par exemple :

• sans rotation, les coordonnées brutes peuvent être utilisées directement
• avec une rotation de 90 degrés, les axes X et Y sont intervertis et un axe est inversé
• avec une rotation de 180 degrés, les deux axes sont inversés
• avec une rotation de 270 degrés, X et Y sont échangés avec l’inversion opposée par rapport au cas de 90 degrés

Enfin, transmettez les coordonnées transformées au cadre de l’interface graphique. Dans TouchGFX, cela se fait à travers l’interface du contrôleur tactile. Dans LVGL, les coordonnées corrigées sont fournies via le rappel du pilote du périphérique d’entrée.

Le cadre de l’interface graphique lui-même ignore l’orientation du toucher physique et reçoit toujours des coordonnées déjà alignées.

Référence de la cartographie de rotation

Supposons :

• W est la largeur de l’écran après rotation
• H est la hauteur de l’écran après rotation
• (x, y) sont les coordonnées brutes du toucher
• (x’, y’) sont des coordonnées transformées transmises au cadre GUI

Ensuite :

Pas de rotation (0 degré)
Utilisez directement les coordonnées brutes :

• x’ = x
• y’ = y

Rotation de 90 degrés (portrait)
Permuter les axes et inverser un axe :

• x’ = y
• y’ = W – 1 – x

Rotation de 180 degrés (paysage inversé)
Inverser les deux axes :

• x’ = W – 1 – x
• y’ = H – 1 – y

Rotation de 270 degrés (portrait inversé)
Échangez les axes et inversez l’axe opposé :

• x’ = H – 1 – y
• y’ = x

Ces transformations sont appliquées dans la couche de traitement tactile et n’affectent pas le rendu de l’affichage.

Note sur les écrans Riverdi de plus grande taille

Pour les écrans Riverdi plus grands, un contrôleur tactile différent est utilisé. Les écrans IPS de taille supérieure utilisent généralement le contrôleur tactile ILITEK ILI2511. Bien que le principe général de séparation de la rotation de l’écran et du mappage tactile reste le même, les détails de mise en œuvre peuvent différer et doivent être vérifiés pour le contrôleur spécifique et la configuration de l’écran.

Vérification

Après avoir appliqué les étapes décrites ci-dessus, l’interface utilisateur devrait apparaître dans la bonne orientation et les données tactiles devraient s’aligner sur les éléments de l’interface utilisateur. Aucune rotation du framebuffer en cours d’exécution ne devrait être nécessaire. Si le comportement tactile reste incorrect, les paramètres d’inversion d’axe et de résolution doivent être revérifiés.

Pièges courants

Les problèmes les plus courants sont les suivants : supposer que le LTDC prend en charge la rotation matérielle, faire pivoter l’interface utilisateur sans corriger les coordonnées tactiles et mélanger l’inversion côté panneau avec les changements d’orientation au niveau de l’interface utilisateur graphique sans séparation claire.

Rotation de l'écran avec LVGL

LVGL supporte la rotation de l’écran par incréments de 90 degrés. L’orientation de l’écran peut être modifiée en utilisant
lv_display_set_rotation(disp, LV_DISPLAY_ROTATION_xxx), où xxx est soit 0, 90, 180 ou 270.

Lorsque la rotation est activée, LVGL met à jour son système de coordonnées interne et échange la résolution horizontale et verticale selon les besoins.

Sur les systèmes STM32 utilisant le LTDC, la rotation est entièrement gérée par le logiciel. LVGL ne s’appuie pas sur la rotation matérielle du framebuffer. En fonction du mode de rendu sélectionné, les données des pixels peuvent être pivotées dans le callback de rinçage avant d’être envoyées à l’écran. Pour les affichages avec rotation, LV_DISPLAY_RENDER_MODE_PARTIAL est généralement utilisé, car il permet de faire pivoter des zones de rendu individuelles avant de les envoyer à l’écran.

Cette approche a été testée sur des systèmes STM32 avec des écrans Riverdi utilisant LVGL version 9.1 et plus récente.

Même lorsque la rotation LVGL est activée, les contrôleurs tactiles continuent de rapporter des coordonnées brutes. Pour les écrans Riverdi IPS utilisant l’ILITEK ILI2132A, les coordonnées tactiles doivent toujours être transformées dans le logiciel pour correspondre à l’orientation de l’écran sélectionnée.

Pour plus de détails sur les modes de rotation LVGL, les API et les exemples, reportez-vous à la documentation LVGL officielle :
Rotation de l’écran LVGL

Résumé

Sur les systèmes STM32 utilisant le LTDC, la rotation de l’écran est entièrement gérée par le logiciel. TouchGFX est utilisé pour définir l’orientation primaire en rendant l’interface utilisateur pour les dimensions d’écran requises, tandis qu’une correction supplémentaire de 180 degrés peut être appliquée au niveau du panneau ou du logiciel si nécessaire.

Cette approche en couches fournit une solution fiable et facile à maintenir sans dépendre de la rotation des tampons de trame non pris en charge par le matériel et convient aux applications industrielles à long terme.