TouchGFX est un framework de développement d'interface graphique (GUI) fourni par STMicroelectronics, conçu pour le développement de systèmes embarqués ciblant les microcontrôleurs STM32 (MCU). Il permet de concevoir des affichages contextuels d’objets, aidant les utilisateurs de STM MCU à construire des pages d'interface fluides, esthétiques et variées.

L'exemple suivant utilise la version 4.23.2 de TouchGFX comme référence :

Figure 1 : Écran de démarrage de TouchGFX montrant des options telles que Example, Demo, Create Board chip, etc.

Aperçu de la structure de TouchGFX

L'architecture du programme TouchGFX adopte le modèle MVP (Model-View-Presenter), comme illustré dans la Figure 2, avec les avantages suivants :

Séparation des préoccupations (Separation of Concerns) : La maintenance du code varie selon les différentes étapes, ce qui facilite l'écriture des interfaces et la communication avec les couches inférieures, offrant une structure claire et compréhensible avec une grande réutilisabilité.

Tests unitaires (Unit Testing): La vue de niveau supérieur peut interagir directement avec le code généré par GFX, ce qui facilite la validation indépendante des résultats.

Figure 2 : Diagramme de relation des composants TouchGFX (MVP)

View : Page principale générée par GFX, conçue pour la représentation de l'interface. Elle agit généralement comme l'extrémité passive de la couche supérieure du modèle MVP, gérant toutes les informations de conception de l'interface utilisateur et affichant les écrans correspondants en fonction des propriétés des objets utilisés.

Model : Sert de cœur au traitement et à l'envoi des données. Certains paquets de communication sont traités ou analysés, puis envoyés à la vue via le Presenter afin de modifier le contenu affiché et l’état des objets.

Presenter : Sert de canal de communication entre la View et le Model, permettant des requêtes de données depuis le Model afin de réutiliser les fonctions.

En raison de la philosophie de conception du firmware, qui met l'accent sur le Model comme centre de traitement des commandes, un schéma peut être illustré (Figure 3).

Grâce au traitement de bas niveau de différentes interfaces (par exemple, bus CAN, RS485, UART, Bluetooth, Wi-Fi), les données sont transmises au Model pour communication, puis relayées à la View via le Presenter, permettant ainsi le changement d'état des objets.

Figure 3 : Communication entre plusieurs interfaces et l’architecture MVP

Deux exemples peuvent illustrer la méthode d'échange de données :

Exemple 1 : Supposons que l'hôte envoie une commande CANopen au dispositif (Figure 4).

CANopen reçoit les paquets via le port IF, déchiffre éventuellement les données via la tâche CAN, puis transmet le contenu au Model. Après mise à jour de la base de données et exécution de la commande correspondante, le Model envoie le résultat à la View via le Presenter pour actualiser la page.

Figure 4 : Exemple d’envoi de commande par l'hôte

Exemple 2 : Si un utilisateur touche un objet de l'interface sur le dispositif, un paquet d'événement tactile est renvoyé à l'hôte (Figure 5).

Lorsqu'un utilisateur clique sur un objet interactif, la View génère un événement de clic, qui est ensuite transmis au Model via un événement utilisateur à travers le Presenter. Le Model réagit en fonction de l'interface actuellement utilisée, en renvoyant le code à la tâche CAN, qui envoie finalement un paquet TX pour notifier l'hôte.

Figure 5 : Événement tactile de l’utilisateur renvoyé à l'hôte

Aperçu des connaissances sur les pages View

Dans l'interface logicielle TouchGFX, la conception de N pages génère N ensembles correspondants View et Presenter, mais un seul Model contrôlera toutes les pages View.

Lorsqu’un utilisateur conçoit un scénario UI, incluant graphiques, apparence, coordonnées et affichage de texte, appuyer sur « Générer le code » produira le code dans la page View nommée correspondante.

Les dossiers générés sont divisés en ..\generated\ et ..\gui\, où ..\generated\ contient le code de base pour l’affichage des pages conçues, et ..\gui\ contient la logique des interactions entre objets.

Nous pouvons utiliser ces informations pour placer les objets sur leurs pages respectives et référencer le code utilisable.

Voici une explication simple, étape par étape, de cette procédure :

Par exemple :

1. Ouvrez un projet vierge et appuyez sur « Créer nouveau » pour établir un projet (Figure 6).

Figure 6 : Écran d’ouverture d’un projet TouchGFX

2. Dans TouchGFX, un Screen1 par défaut sera disponible. Nous ajoutons un nouvel objet bouton, sélectionnons l’image souhaitée, puis exécutons « Générer le code » (Figure 7).

Figure 7 : Démonstration de création de bouton

3. Ensuite, en passant au chemin du projet, deux nouveaux dossiers apparaîtront : gui et generated (Figure 8) :

Figure 8 : Contenu du dossier du projet

Le dossier generated contient le code de base relatif aux composants de Screen1, généré automatiquement par TouchGFX et non modifiable directement. Si l’état des objets sur la page change et que le code est reconstruit, le contenu du dossier generated sera mis à jour.

De même, après l’exécution de « Générer le code », GFX créera le fichier Screen1ViewBase.cpp dans ..\generated\gui_generated\src\screen1_screen (Figure 9).

Figure 9 : Emplacement de Screen1ViewBase.cpp

Si nous ouvrons Screen1ViewBase.cpp avec Notepad++ (Figure 10), nous voyons les propriétés et contenus relatifs à la page Screen1 et aux données du bouton :

- Définir les coordonnées du bouton :
button1.setXY(63, 109);

- Définir l’ID de l’image du bouton :
button1.setBitmaps(TouchGfx::Bitmap(BITMAP_BUTTON_00_00_ID),TouchGfx::Bitmap(BITMAP_BUTTON_00_00_ID));

- Ajouter l’objet bouton à la page :
Add(button1);

Figure 10 : Contenu de Screen1ViewBase.cpp

Le code nommé XXXBase.cpp sera reconstruit lors de chaque « Générer le code », et toute modification des données d’attribut y sera reflétée. Ainsi, si nous ajustons la position ou l’image du bouton, les fonctions peuvent également changer.

Quant au dossier gui, c’est là que TouchGFX permet à l’utilisateur d’écrire la logique du programme (Figure 8). Ainsi, l’architecture MVP y est également construite (Figures 11 et 12), nous permettant de concevoir nos propres méthodes de communication dans le code pour réaliser les directions de conception UI.

Figure 11 : Chemin du Model

Figure 12 : Chemins du Presenter et de la View

4. Conception d’un scénario simple pour l’explication du design généré/UI

- Écrire une logique de contrôle pour l’interaction entre un bouton et du texte.
- Quand le bouton est cliqué une fois, la valeur du texte augmente.

Voici comment mettre en œuvre cette fonctionnalité :

Étape 1 :

Glissez deux objets : un bouton (button1) et une zone de texte (textArea1) (Figure 13).

Figure 13 : Projet UI avec contrôle Button

Étape 2 :

Sélectionnez l’action d’interaction sur la droite, ajoutez un événement de clic sur le bouton, et choisissez d’appeler la fonction add_number lorsque cet événement est déclenché (Figure 14).

Figure 14 : Ajout de l’événement Interaction1

Étape 3 :

Consultez Screen1ViewBase.cpp (Figure 15) pour trouver le code des propriétés créant button1 et textArea1.

En raison des interactions ajoutées, un buttonCallbackHandler est généré pour gérer l’événement tactile du bouton1. Lors du clic, il appellera la fonction add_number via le callback approprié.

Figure 15 : Screen1ViewBase.cpp

Contenu de Screen1ViewBase.hpp (Figure 16).

Figure 16 : Contenu de Screen1ViewBase.hpp

Étape 4 :

Dans la section gui, ajoutez Screen1View.cpp et Screen1View.hpp.
Ajoutez le programme add_number pour utiliser le paramètre count comme compteur (Figures 17 et 18).

Utilisez Unicode : snprintf(textArea1Buffer, TEXTAREA1_SIZE, "%02d", count) pour actualiser count dans textArea1.

Puis appelez textArea1.invalidate() pour rafraîchir l’affichage.

Figure 17 : Contenu de Screen1View.cpp

Figure 18 : Contenu de Screen1View.hpp

Après lancement du simulateur, on constate que chaque fois que button1 est touché, textArea1 (valeur de count) s’incrémente à partir de 0 (Figure 19).

Figure 19 : Affichage du résultat du simulateur

Cela confirme que la définition des propriétés des objets est généralement établie dans le dossier généré, tandis que l’utilisateur écrit la logique d’exécution dans la section gui.

Exemples de propriétés d’objet dans TouchGFX et Builder

Le Smart Display GUI Builder fourni par Winstar est un outil de conception d'interface pour UI/UX avec une fonctionnalité de glisser-déposer, offrant aux clients un service de développement sans code, adapté au développement rapide et à la conception de produits basés sur les MCU ST. Construit comme une extension du framework TouchGFX, le GUI Builder intègre les fonctionnalités originales des widgets de TouchGFX, avec pour principale différence la prise en charge de plusieurs interfaces système et protocoles de communication. Cela permet aux utilisateurs d'observer directement comment les commandes affectent le contrôle et les changements des widgets.

Voici l'introduction au Builder :
https://www.winstar.com.tw/fr/video/play/142.html

La philosophie de conception de Smartdisplay est liée à la fonctionnalité des paramètres TouchGFX, y compris le firmware écrit en utilisant le STM32 MCU comme base pour MVP. Les objets à l'intérieur sont conçus en utilisant des éléments existants combinés avec de la logique.

Par conséquent, parmi les objets ouverts par le GUI Builder, certains peuvent être implémentés en utilisant les composants UI existants de TouchGFX pour obtenir les résultats d'affichage correspondants.

*Segment d’explication complémentaire

Voici un exemple simple utilisant le curseur du Builder (Figure 20) :

Figure 20 : Page des propriétés du curseur dans Builder

Les propriétés du curseur Builder sont les suivantes :

Size:
- Width: 618
- Height: 20

Positions:
- Background Position (X): 0
- Background Position (Y): 4

Indicator Position:
- Min: 0
- Max: 580
- Pos: 0

 

Ces paramètres correspondent aux réglages du composant Slider dans TouchGFX (Figure 21).

Figure 21 : Propriétés du curseur dans TouchGFX

Les propriétés du curseur TouchGFX sont les suivantes :

Location:
- Width: 618
- Height: 20

Positions:
- Background Position (X): 0
- Background Position (Y): 4

Indicator Position:
- Min: 0
- Max: 580
- Y: 0

Les utilisateurs peuvent ajuster la valeur de départ dans GFX pour simuler les résultats dans Builder (Figure 22).
Si la valeur est définie sur 100, cela peut simuler le même résultat que dans Builder (Figure 23).

Figure 22 : Réglage de Start = 100 dans TouchGFX

Figure 23 : Réglage de la valeur de test = 100 dans Builder

Si nous regardons le fichier Screen1ViewBase.cpp généré par GFX (Figure 24) :

Figure 24 : Fonction dans Screen1ViewBase.cpp

Nous pouvons comprendre comment les paramètres mentionnés ci-dessus sont utilisés et modifiés dans le code. Ces valeurs sont directement liées à la conception du projet GFX. Lorsque Builder télécharge le projet, il réinitialise les paramètres initiaux du curseur de l’appareil.

Si l’hôte envoie une commande pour changer la valeur du curseur, il exécutera slider1.setValue() dans la vue pour modifier l’objet (Figure 25).

Figure 25 : L’hôte envoie une commande au curseur

Voici une explication simple de la relation entre les objets Builder et TouchGFX.

Perspectives d’évolution et évaluation du développement des objets Builder

Avec la mise à jour récente de TouchGFX vers la version 4.24.0, de nouveaux objets et fonctionnalités sont disponibles. Pour évaluer leur intégration potentielle dans Builder, nous pouvons d’abord tester les exemples par défaut dans GFX à des fins de démonstration et de recherche (Figure 26) :

Figure 26 : Divers projets exemples

 

La version 4.24.0 introduit des objets tels que le code QR. Nous pouvons donc évaluer les paramètres et fonctions pouvant être intégrés à Builder.

Exemple d’utilisation du code QR :

1. Sélectionner BlankUI.
2. Glisser-déposer le conteneur de code QR.
3. Observer les propriétés configurables (Figure 27) :
Emplacement : (X, Y)
Location: (X, Y)
Configuration:
- QRVersion
- Scale
- Text
- Error Correction Code…

Figure 27 : Écran des propriétés du code QR

Ces paramètres concernant le code QR peuvent être consultés sur le site officiel (Figure 28).

Figure 28 : Explication sur le site officiel

Dans la fonction générée de Screen1ViewBase.cpp, on peut vérifier les paramètres disponibles (Figure 29) :

1. Définir les coordonnées : qrCode1.setXY(208, 224);
2. Définir la version du QR code : qrCode1.setQRCodeVersion(3);
3. Définir l’échelle du QR : qrCode1.setScale(5);
4. Saisir le texte pour générer le QR code :
qrCode1.convertStringToQRCode("https://www.winstar.com.tw/zh-tw/");

Figure 29 : Code généré dans Screen1ViewBase.cpp

Si la fonction de code QR est intégrée dans Builder à l’avenir, les utilisateurs pourront configurer ces paramètres personnalisables.

Références :

https://support.touchgfx.com/docs/category/introduction
https://www.eettaiwan.com/20200203np21/
https://en.wikipedia.org/wiki/STMicroelectronics
https://www.winstar.com.tw/fr/video/smartdisplay.html