Le contrôle du rétroéclairage et la rotation de l’écran sont des opérations d’affichage essentielles qui ont un impact direct sur le comportement du système dans les conceptions basées sur le STM32. Elles sont indépendantes de la logique de l’application, mais étroitement liées à la configuration du matériel et aux capacités du cadre graphique.
Dans cet article, nous expliquons comment les modules d’affichage Riverdi STM32 mettent en œuvre le contrôle du rétroéclairage basé sur le PWM en utilisant le TIM15 et un pilote de LED dédié, et comment la rotation de l’écran est gérée différemment dans les projets LVGL et TouchGFX. L’accent est mis sur les détails pratiques de la mise en œuvre et sur la séparation architecturale.
Contrôle du rétroéclairage des écrans Riverdi STM32
Le contrôle du rétroéclairage est l’une des opérations les plus fondamentales lorsque l’on travaille avec des écrans embarqués. Contrairement au rendu graphique ou à la gestion du toucher, le contrôle du rétroéclairage est indépendant du cadre de l’interface graphique et ne dépend pas du fait que l’application utilise LVGL, TouchGFX ou une autre pile graphique.
Sur les modules d’affichage Riverdi basés sur le STM32, la luminosité du rétroéclairage est contrôlée à l’aide d’un signal PWM matériel, généré par un timer STM32.
Modules Riverdi STM32 pris en charge
La méthode décrite dans cet article s’applique aux modules d’affichage Riverdi STM32 tels que :
- RVT121
- RVT101
- RVT70
- RVT50
Le même principe peut être utilisé sur d’autres plateformes Riverdi STM32 qui exposent une entrée de rétroéclairage contrôlée par PWM.
Principe de contrôle du rétroéclairage
Dans les modules d’affichage Riverdi basés sur le STM32, le microcontrôleur ne pilote pas directement le rétroéclairage des LED. Au lieu de cela, le STM32 génère un signal de commande PWM, qui est envoyé dans un circuit de pilotage dédié au rétroéclairage des LED.
Le pilote de rétroéclairage est une source de courant constant, conçue pour réguler le courant circulant à travers les chaînes de LED. Le signal PWM ne module pas directement la tension des LED. Il contrôle plutôt le cycle de travail effectif du pilote, ce qui permet au courant moyen des DEL de varier entre 0 et 100 % de sa valeur nominale.
L’architecture peut être résumée comme suit :
- Le timer du STM32 (par exemple, TIM15) génère un signal PWM.
- Le signal PWM est acheminé vers l’entrée du pilote du rétroéclairage.
- Le pilote de rétroéclairage régule le courant des LED.
- e rapport cyclique du signal PWM détermine la luminosité effective.
Cela signifie que :
- La fréquence PWM est définie par la configuration du timer.
- La luminosité est proportionnelle au cycle de travail PWM.
- Le courant de la LED est toujours régulé par le pilote, et non par le GPIO du MCU.
Cycle d’utilisation plus élevé → courant moyen des LED plus élevé → écran plus lumineux
Cycle d’utilisation plus faible → courant moyen des LED plus faible → affichage moins lumineux
Les DEL sont alimentées par une source de courant régulée :
- le contrôle de la luminosité est linéaire et stable,
- La durée de vie des LED est protégée,
- le comportement thermique est prévisible,
- reste élevé sur toute la plage de fonctionnement.
Cette approche permet
- contrôle souple de la luminosité,
- faible perte de puissance,
- une régulation correcte du courant du rétroéclairage LED,
- une indépendance matérielle totale par rapport au cadre de l’interface graphique.
Exigences en matière de matériel et de logiciel
Avant de régler le niveau de rétroéclairage, assurez-vous que
- l’écran est correctement connecté au module STM32,
- la carte est connectée à un PC à l’aide de ST-Link,
- le projet est construit en utilisant un modèle logiciel supporté (LVGL ou TouchGFX).
Aucune modification de la configuration du cadre de l’interface graphique n’est nécessaire pour le contrôle du rétroéclairage.
Minuterie utilisée pour le contrôle du rétroéclairage
Sur les modules d’affichage Riverdi STM32, le rétroéclairage est contrôlé à l’aide de :
- TIM15 (sur les infrastructures U5 et H7)
- Sortie PWM matérielle
- Canal 1
La configuration PWM se trouve dans le fichier de projet tim.c, dans la fonction MX_TIM15_Init().
Exemple de configuration PWM
Le canal PWM est configuré à l’aide des structures HAL standard du STM32 :
sConfigOC.OCMode = TIM_OCMODE_PWM1 ;
sConfigOC.Pulse = 998 ;
sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH ;
sConfigOC.OCNPolarity = TIM_OCNPOLARITY_HIGH ;
sConfigOC.OCFastMode = TIM_OCFAST_DISABLE ;
sConfigOC.OCIdleState = TIM_OCIDLESTATE_RESET ;
sConfigOC.OCNIdleState = TIM_OCNIDLESTATE_RESET ;
if (HAL_TIM_PWM_ConfigChannel(&htim15, &sConfigOC, TIM_CHANNEL_1) !=
HAL_OK)
{
Error_Handler() ;
}Le paramètre le plus important est sConfigOC.Pulse.
Plage de luminosité et signification
La luminosité du rétroéclairage est contrôlée par le cycle de travail PWM :
- 0 → rétroéclairage OFF
- 998 → luminosité maximale
Toute valeur comprise entre 0 et 998 donne un niveau de luminosité proportionnel.
Réglage de la luminosité en cours de fonctionnement
Outre la configuration statique, le niveau de rétroéclairage peut également être modifié en cours d’exécution en écrivant directement dans le registre de la minuterie :
TIM15->CCR1 = votre_nouvelle_valeur_d'impulsion ;
Cela permet :
- contrôle dynamique de la luminosité,
- la gradation en fonction de la lumière ambiante,
- les modes d’économie d’énergie,
- effets de fondu en entrée et en sortie.
Aucune réinitialisation de l’affichage n’est nécessaire.
Rotation de l’écran sur les écrans STM32
Contrairement au contrôle du rétroéclairage, la rotation de l’écran n’est pas une opération purement matérielle sur le STM32.
Le périphérique du contrôleur d’écran LCD TFT (LTDC) ne prend pas en charge la rotation de l’image, ce qui signifie que la rotation doit être gérée au niveau du contrôleur d’écran LCD TFT (LTDC). au niveau du cadre graphique.
La mise en œuvre diffère sensiblement selon le cadre d’interface graphique choisi.
Cette section explique les deux approches utilisées sur les écrans Riverdi STM32 :
- Rotation basée sur LVGL
- Rotation basée sur TouchGFX
Rotation de l’écran avec LVGL
Lorsque vous utilisez des modules d’affichage Riverdi STM32 avec des panneaux RVB, le périphérique LTDC du STM32 transmet les pixels de la mémoire ligne par ligne. Comme le LTDC ne prend pas en charge la rotation matérielle, le seul moyen fiable de faire pivoter l’image est de le faire par logiciel avant que les pixels n’atteignent le framebuffer du LTDC.
LVGL supporte la rotation de l’affichage via :
lv_display_set_rotation(disp, LV_DISPLAY_ROTATION_xxx) ;
où xxx peut être 0, 90, 180, ou 270.
Cependant, cet appel met à jour le système de coordonnées interne de LVGL et la gestion de la disposition – il ne fait pas automatiquement pivoter les données des pixels pour les pipelines RVB basés sur LTDC. Pour cette raison, la rotation des pixels doit être gérée à l’intérieur du callback LVGL flush.
La place de la rotation dans le pipeline LVGL
Dans cette configuration :
- LVGL rend de petites « tuiles » dans un tampon de travail (px_map) en utilisant le mode de rendu PARTIEL.
- Le rappel de vidage (disp_flush) écrit les tuiles rendues dans le framebuffer du LTDC.
- Si la rotation est activée, le callback flush fait pivoter la tuile avant de l’écrire dans le framebuffer.
- Les coordonnées tactiles restent cohérentes car LVGL connaît la rotation actuelle de l’écran.
Initialisation LVGL (rendu PARTIEL + rotation)
L’affichage est créé et configuré dans le fichier lvgl_port_display.c :
void lvgl_display_init(void)
{
disp = lv_display_create(MY_DISP_HOR_RES, MY_DISP_VER_RES) ;
__attribut__((section(".my_ram_d2_data")))
statique uint8_t buf1[288 * 1024] ;
lv_display_set_buffers(disp, (void *)buf1, NULL, sizeof(buf1),
LV_DISPLAY_RENDER_MODE_PARTIAL) ;
/* Définir la rotation souhaitée */
lv_display_set_rotation(disp, LV_DISPLAY_ROTATION_90) ;
/* Enregistrer le callback de rinçage */
lv_display_set_flush_cb(disp, disp_flush) ;
}
Rappel de rinçage (rotation logicielle dans le framebuffer du LTDC)
Vous trouverez ci-dessous le rappel de rinçage utilisé pour les écrans Riverdi STM32 avec LTDC.
Il prend en charge la rotation par :
- Transformer la zone de destination via lv_display_rotate_area(), et
- Rotation des données de pixels via lv_draw_sw_rotate() avant de les écrire dans le framebuffer
.
static void disp_flush(lv_display_t * display,
const lv_area_t * area,
uint8_t * px_map)
{
lv_color_format_t cf = lv_display_get_color_format(display) ;
uint32_t px_size = lv_color_format_get_size(cf) ; /* RGB565 = 2 octets */
/* Calculer la zone de destination après la rotation */
lv_area_t rot_area = *area ;
lv_display_rotate_area(display, &rot_area) ;
int32_t src_w = lv_area_get_width(area) ;
int32_t src_h = lv_area_get_height(area) ;
uint32_t src_stride = lv_draw_buf_width_to_stride(src_w, cf) ;
uint32_t fb_stride = lv_draw_buf_width_to_stride(MY_DISP_HOR_RES, cf) ;
/* Adresse du framebuffer LTDC */
uint8_t * fb = (uint8_t *)hltdc.LayerCfg[0].FBStartAdress ;
fb += (rot_area.y1 * fb_stride) + (rot_area.x1 * px_size) ;
/* Maintenance du cache (nécessaire lorsque le framebuffer est dans une SDRAM externe) */
SCB_CleanInvalidateDCache() ;
lv_display_rotation_t r = lv_display_get_rotation(display) ;
if(r == LV_DISPLAY_ROTATION_0) {
/* Chemin rapide : pas de rotation */
for(int32_t y = 0 ; y < src_h ; y++) {
lv_memcpy(fb, px_map, src_stride) ;
px_map += src_stride ;
fb += fb_stride ;
}
} else {
/* Rotation de la tuile rendue directement dans le framebuffer */
lv_draw_sw_rotate(px_map, fb,
src_w, src_h,
src_stride, fb_stride,
r, cf) ;
}
/* Notifier à LVGL que la vidange est terminée */
lv_display_flush_ready(display) ;
}Résultat
Avec cette approche :
- l’image est physiquement tournée avant la sortie LTDC,
- La mise en page et le rendu LVGL restent cohérents,
- les coordonnées tactiles restent alignées avec l’interface utilisateur pivotée,
- aucune modification de la configuration de la synchronisation LTDC n’est nécessaire.
Rotation de l’écran sur STM32 avec TouchGFX
Contrairement à LVGL, TouchGFX gère la rotation de l’écran au niveau du cadre et de la configuration. Pour la plupart des projets d’affichage Riverdi basés sur le STM32, la rotation peut être activée sans modifier les pilotes d’affichage de bas niveau ou le code de gestion du tampon d’image.
TouchGFX est donc particulièrement pratique lorsque :
- l’orientation de l’affichage est connue au moment de la conception,
- n’a pas besoin d’être modifiée dynamiquement au moment de l’exécution,
- une approche basée sur la configuration, rapide et maintenable, est préférable.
Concept de rotation TouchGFX
TouchGFX fait abstraction du pipeline d’affichage et le gère :
- la disposition de la mémoire tampon,
- l’orientation du rendu,
- les transformations de coordonnées,
- le mappage de l’entrée tactile.
En conséquence :
- aucune rotation manuelle des pixels n’est nécessaire dans le chemin de rinçage du LTDC,
- aucune manipulation personnalisée du framebuffer n’est nécessaire,
- La rotation est appliquée de manière cohérente pour le rendu et la saisie tactile.
Activation de la rotation de l’écran dans TouchGFX designer
La rotation de l’écran est configurée directement dans TouchGFX Designer.
L’appellation exacte peut différer légèrement selon la version de TouchGFX, mais le flux de travail
est cohérent.
Étape 1 – Ouvrir la configuration de l’affichage
Dans TouchGFX Designer :
- Ouvrez votre projet.
- Naviguez jusqu’à la section Configuration de l’affichage / de la carte / de l’application.
- Localisez le paramètre Orientation de l’affichage ou Rotation de l’écran.
Résumé
Sur les modules STM32 Riverdi, la luminosité du rétroéclairage est contrôlée par un PWM matériel généré par le TIM15 et régulé par un pilote de LED à courant constant. Le cycle de travail définit la luminosité, indépendamment du cadre de l’interface graphique, ce qui permet un fonctionnement stable et prévisible.
La rotation de l’écran n’est pas supportée par le matériel LTDC et doit être gérée au niveau de la couche graphique. Dans LVGL, la rotation nécessite une transformation logicielle des pixels dans le callback flush. Dans TouchGFX, la rotation est configurée au niveau de la structure sans modifier les pilotes d’affichage de bas niveau.
La séparation du contrôle au niveau du matériel et des responsabilités de la couche graphique garantit une architecture propre et un comportement fiable dans les systèmes d’affichage basés sur le STM32.
DÉCOUVREZ NOTRE
Livre blanc
Réalisez l’interaction parfaite entre l’utilisateur et l’écran avec le bon circuit intégré pour capteur tactile. Vous avez déjà été confronté à des problèmes d’événements tactiles fantômes ou de certification ? Boostez votre R&D comme un pro grâce à notre livre blanc !
Consultez notre catalogue de produits et voyez comment vous pouvez économiser sur la qualité, et non sur la qualité.
