TouchGFX 4.25 : le nouveau framebuffer émulé transforme le rêve d’un système « single chip » en une réalité

TouchGFX 4.25 inaugure le framebuffer émulé (en attente de brevet), qui prend beaucoup moins de place dans la mémoire en divisant l’image à afficher en morceaux et en utilisant une technique de mappage de la mémoire qui permet de s’abstenir de la RAM graphique sur l’écran lui-même. Par conséquent, les systèmes qui nécessitaient auparavant une mémoire vive externe peuvent désormais fonctionner sur une carte à processeur unique, ce qui réduit la nomenclature. De plus, comme ST a intégré la technologie au niveau du middleware, les développeurs peuvent en tirer parti en choisissant la bonne option dans TouchGFX Generator pour voir si elle convient à leur projet. Cela oblige également les ingénieurs à examiner de plus près leur stratégie en matière de framebuffer pour voir si elle est adaptée à leur application, ce que trop de gens ont tendance à négliger.

• Télécharger TouchGFX 4.25

Quelles sont les nouveautés de TouchGFX 4.25 ?

Stratégie du framebuffer

Double framebuffer

Trop souvent, les développeurs ne pensent pas vraiment à la manière dont l’image sera rendue sur leur écran. Or, cette erreur peut s’avérer coûteuse, car le type de framebuffer influencera fortement la configuration de la mémoire. Par exemple, un double framebuffer stocke deux framebuffers de taille normale dans la mémoire pour garantir une expérience fluide sans déchirure. Cependant, une image standard de 24 bits de 1024×600 pour un écran de 10 pouces nécessiterait près de quatre mégaoctets de mémoire, ce qui est normalement inconcevable pour un système aux ressources aussi limitées. C’est pourquoi un double framebuffer n’a de sens que pour les grands écrans et les interfaces graphiques haut de gamme où le système utilise beaucoup de RAM externe.

Framebuffer unique

Le compromis consisterait à n’utiliser qu’un seul framebuffer complet. L’avantage évident est qu’il réduit de moitié l’empreinte mémoire. Le risque de déchirure est plus élevé car l’écran peut se rafraîchir au milieu d’une mise à jour, mais il est également possible d’atténuer ce problème. Par exemple, les développeurs peuvent limiter la complexité des animations qu’ils créent ou s’assurer que l’affichage est rafraîchi moins fréquemment et utiliser l’accélération DMA2D (Chrom-ART sur STM32) pour optimiser le traitement des données. C’est ce que nous trouvons souvent dans les interfaces graphiques milieu de gamme des systèmes embarqués. L’écran est petit et les exigences de l’interface utilisateur ne sont pas aussi élevées, ce qui permet d’utiliser un seul tampon d’image sans risque de déchirement.

Framebuffer partielle

De même, une autre option est d’utiliser un framebuffer partiel, que nous avons introduit dans TouchGFX 4.12 (nous y reviendrons plus tard). Comme son nom l’indique, la mémoire ne contient que les parties du framebuffer qui doivent être mises à jour, ce qui réduit encore l’empreinte mémoire. Toutefois, cette technique exige que l’écran dispose d’une RAM graphique (ou GRAM) capable de stocker l’intégralité du framebuffer. En effet, au moment du rendu de l’image, l’écran aura besoin de l’intégralité du framebuffer. Par conséquent, bien qu’il soit possible de réduire la quantité de RAM intégrée en n’utilisant qu’un framebuffer partiel, il était impossible de contourner le fait que l’écran avait besoin de l’intégralité du framebuffer dans sa GRAM.

Framebuffer émulée

Aujourd’hui, TouchGFX 4.25 inaugure des framebuffers émulés qui fonctionnent de manière similaire aux framebuffers partiels mais ne nécessitent pas de GRAM. Le framework graphique de ST utilise le LTDC (contrôleur d’écran LCD-TFT) et l’unité de gestion de la mémoire graphique de Chrom-GRC que l’on trouve dans certains MCU, comme le STM32H7R/S, le STM332H7A/B, le STM32U5 et le tout nouveau STM32N6. Les framebuffers émulés sont donc possibles parce qu’ils tirent parti des derniers accélérateurs trouvés sur les microcontrolleurs STM32. De plus, TouchGFX gère les framebuffers émulés au niveau du middleware sans que les utilisateurs n’aient à intervenir. Ils doivent simplement choisir de les utiliser ou non dans TouchGFX Generator.

Un nouveau système de gestion de la mémoire

En résumé, TouchGFX utilise une unité de gestion de la mémoire (MMU ou Memory Management Unit) pour émuler un framebuffer entier sans avoir à en stocker un en mémoire, en mappant les adresses de la mémoire. Ainsi, lorsque le système recherche le framebuffer, le MMU sait ce qu’il doit envoyer. Et parce que cela rappelle un framebuffer partiel, les développeurs découpent leur affichage en sections égales, en quatre ou en huit, par exemple, afin d’optimiser la mise à jour de leur interface. Plus la section est petite, plus les équipes de développement bénéficient d’un plus grand contrôle, mais plus l’opération est gourmande en ressources. Les programmeurs devront donc trouver le juste milieu en fonction de la partie de l’écran qu’ils mettent à jour.

Parler à l’écran et écouter ce qu’il a à dire

Du côté de l’écran, le LTDC de ST lit en permanence les données de pixels écrites par le MMU et envoie le framebuffer émulé à l’écran à l’aide d’interfaces telles que Parallel RGB ou MIPI DSI. Par conséquent, si le système ne parvient pas à rafraîchir l’ensemble de l’écran toutes les 16 millisecondes, l’image présentera des déchirures importantes. Il est toutefois essentiel de considérer ce phénomène comme un avantage. Les framebuffers émulés sont réservés aux interfaces utilisateur plus statiques. Le cas échéant, cette stratégie permet d’économiser suffisamment de mémoire pour se passer de RAM externe et utiliser uniquement la mémoire de l’unité centrale. Par exemple, les écrans 720p ou 1080p avec des interfaces riches qui nécessiteraient traditionnellement un microprocesseur peuvent maintenant facilement fonctionner sur un microcontrolleur grâce à notre framebuffer émulé.

En effet, s’il y a peu d’animations, comme c’est le cas pour les applications qui se concentrent sur des informations rapides, telles que les mises à jour d’une donnée précise, il n’y a aucune raison d’avoir un framebuffer entier en mémoire en permanence. Dans ces cas, le framebuffer émulé offre une utilisation beaucoup plus intéressante de la mémoire, ce qui permet d’utiliser un MCU et beaucoup moins de RAM. Par conséquent, si les développeurs rencontrent un problème de déchirement, ils doivent le considérer comme un message du framework leur indiquant de supprimer les animations ou d’utiliser un autre type de framebuffer (voir notre documentation sur les stratégies de framebuffer). Et puisque tous les types de framebuffer sont disponibles sous la forme d’une option dans TouchGFX Generator, il est très facile de passer de l’un à l’autre.

Applications dans le monde réel

Un peu plus de cinq ans après le lancement des framebuffers partiels par TouchGFX 4.12, nos équipes remettent le couvert avec les framebuffers émulés, une option encore plus optimisée qui ouvre la porte aux conceptions mono-processeur. Cette solution reflète la façon dont TouchGFX utilise les accélérateurs présentes dans les microcontrolleurs STM32 afin d’optimiser l’utilisation de la mémoire et d’avoir un impact direct sur la nomenclature. Cela signifie également que les interfaces graphique deviennent de plus en plus accessibles, car les projets qui ne pouvaient pas les adopter en raison du coût d’un module de RAM externe peuvent désormais en proposer une. La meilleure façon de voir quelle stratégie de framebuffer fonctionne est de lancer des tests en utilisant des framebuffers émulés sur une plateforme de développement compatible, comme le STM32H7S78-DK, et de voir si une application fonctionne sans problème.

Lors de nos tests internes, nous avons effectué une démonstration de faisabilité sur la carte ci-dessus en utilisant uniquement la RAM interne et nous avons obtenu d’excellents résultats en 800×400. La seule fois où nous avons rencontré des problèmes de déchirure d’écran, c’est lorsque nous avons exécuté des représentations statistiques en direct. Nous partageons cette information pour aider notre communauté à comprendre que toutes les démos ne fonctionneront pas correctement sur un framebuffer émulé. Cependant, celles qui fonctionneront bien ouvriront la voie à des systèmes embarqués plus efficaces et plus abordables. Par exemple, la capture d’écran de droite montre l’interface utilisateur d’un ascenseur fonctionnant sur un écran 720p et un STM32H7, en utilisant uniquement la mémoire vive intégrée, ce qui aurait été impossible avant les framebuffers émulés.

Nouvelle compression et soutien

TouchGFX 4.25 introduit également la compression des polices bitmap pour réduire l’empreinte mémoire de l’interface utilisateur. Cette fonction sert d’alternative aux polices vectorielles lorsqu’un système doit utiliser des bitmaps pour des raisons de performance. Dans les applications réelles, la nouvelle compression réduit la taille de la police bitmap de 20 à 80 %. Par exemple, une police contenant de nombreux caractères chinois peut voir sa taille diminuer de 40 %, et une très grande police, telle que Verdana en 110 points, mais avec un petit nombre de caractères, peut passer d’environ 40 Ko à seulement 8 Ko en mémoire.

La nouvelle version de TouchGFX prend également en charge CMake et iAR 9 afin d’améliorer la productivité. CMake est une suite d’outils open-source qui permet aux développeurs de construire, tester et empaqueter leurs logiciels. Il aidera donc les ingénieurs à porter leurs projets sur plusieurs plateformes et à les partager avec les membres de leur équipe afin d’optimiser les opérations de développement.

Qu’est-ce que TouchGFX ?

Le framework

TouchGFX est un framework ST gratuit qui permet de créer des interfaces utilisateur graphiques sur les microcontrôleurs STM32. Écrit en C++, le moteur graphique tire parti des optimisations sur les microcontrolleurs ST. TouchGFX part du principe que les interfaces graphiques sont constituées d’écrans sur lesquels les utilisateurs naviguent. Le cadre est donc intuitif et reflète les expériences de chacun. Il est également très complet puisqu’il gère les objets 2D et 3D, les vidéos, les animations, les transitions, etc. En outre, la possibilité d’accéder au code généré permet aux ingénieurs de l’optimiser. Pour les aider dans ce processus, la documentation de TouchGFX fournit des informations sur les API du framework ou les outils de développement disponibles.

TouchGFX Designer

TouchGFX Designer est souvent le premier outil que les développeurs utilisent lorsqu’ils entament leur interface graphique. Il s’agit d’un utilitaire avec une approche WYSIWYG où les concepteurs créent ce que leurs utilisateurs verront et avec quoi ils interagiront. Les développeurs peuvent commencer par des exemples de projets, tels qu’une horloge, une jauge ou une image animée. Il existe également des démonstrations plus complètes, comme une animation de dés, des transitions de scène ou un système de surveillance. Un écran permet de choisir la démo, une carte de développement ST, puis de tout configurer. Ainsi, l’exécution des codes d’exemple et des démos ne prend que quelques minutes, ce qui permet de créer des concepts plus rapidement. Les éléments de l’interface utilisateur dans TouchGFX Designer prennent souvent la forme de widgets que l’on ajoute et configure par le biais de l’interface de l’utilitaire.

TouchGFX Designer fait partie intégrante de l’écosystème TouchGFX. Par exemple, tant que les utilisateurs choisissent un modèle 3.0, il est possible de commencer le projet dans Designer, puis de le transférer dans STM32CubeMX, de configurer la carte Discovery Kit ou le MCU, et de laisser TouchGFX Generator (voir ci-dessous) mettre à jour le fichier .IOC pour appliquer immédiatement les nouveaux paramètres. De même, un développeur peut commencer par TouchGFX Generator, passer à TouchGFX Designer, puis revenir à STM32CubeMX pour modifier la résolution de l’écran. Le système mettra automatiquement à jour TouchGFX Designer sans qu’il soit nécessaire de fermer l’application.

TouchGFX Simulator

TouchGFX Simulator aide les développeurs à prévisualiser leur interface utilisateur graphique avant de l’exécuter sur leur MCU. Une partie de son attrait réside dans le fait qu’il offre des raccourcis clavier pour optimiser la productivité. Par exemple, il est plus facile de prendre diverses captures d’écran et d’étudier les animations image par image. De même, en appuyant sur F2, l’utilisateur met en évidence les zones invalidées, c’est-à-dire les sections de l’image que le système doit mettre à jour. Les développeurs peuvent ainsi vérifier si leurs animations gaspillent les ressources du MCU en invalidant inutilement des ressources.

TouchGFX Generator

TouchGFX Generator fonctionne avec STM32CubeMX pour générer une partie importante de la couche d’abstraction TouchGFX. Nous sommes compatibles avec presque tous les Discovery Kit STM32 avec un écran, et le nouveau plugin fonctionne avec n’importe quel MCU STM32 avec un Cortex-M0+, M4, ou M7. Les développeurs doivent encore fournir quelques détails avec leur code utilisateur et effectuer des optimisations, mais ce nouveau plugin simplifie les premières étapes d’un projet. En effet, Generator crée des fonctions vides pour guider les développeurs et faciliter l’initialisation de la carte. Il existe également des configurations par défaut pour les cartes de développement ST afin d’accélérer les développements et de servir d’exemples.

Quelles sont les caractéristiques déjà présentes dans TouchGFX ?

Optimisations vectorielles

La plupart des interfaces statiques sur les microcontrôleurs utilisent des bitmap parce qu’elles nécessitent peu de calcul. En comparaison, les images vectorielles sont moins courantes car elles nécessitent beaucoup plus de calcul. Le problème est que les vecteurs sont essentiels pour les animations. Par conséquent, les développeurs peuvent choisir d’utiliser plus de ressources pour obtenir un plus grand nombre d’images par seconde ou d’utiliser moins de puissance et d’avoir une animation moins fluide. Pour résoudre ce problème, TouchGFX offre des optimisations significatives lors du traitement des graphiques vectoriels, avec une amélioration du rendement allant jusqu’à 70 % dans certains cas. Les développeurs peuvent ainsi proposer des animations plus fluides sur des MCU plus petits ou utiliser plus d’éléments vectoriels. Toutefois, les développeurs constateront que les gains de performance les plus significatifs surviennent lors d’animations conséquentes.

La nouvelle optimisation utilise Chrom-ART pour décharger le microcontrôleur lors de certaines opérations telles que les remplissages de couleur. ST a également mis à jour la façon dont le framework calcule les contours d’une forme. De plus, comme les mises à jour concernent la gestion des graphiques vectoriels par le framework, les utilisateurs en bénéficient automatiquement. Les développeurs verront donc immédiatement les performances s’améliorer et pourront planifier en conséquence. Certains pourront réduire les besoins en mémoire de leur application ou ajouter de nouvelles animations à leur interface. Les équipes peuvent également être amenées à revoir leur interface utilisateur, car certains éléments peuvent s’exécuter plus rapidement que prévu.

Polices vectorielles

Il est paradoxal de constater que si le texte est un élément important de la plupart des interfaces utilisateur, il peut être l’un de ses aspects les plus négligés. Par exemple, nombreux sont ceux qui ne connaissent même pas la différence entre une police de caractères et une fonte, alors que, comme nous le montrerons, cette différence est importante. L’Helvetica ou l’Avenir sont souvent appelées des fontes, mais ce sont des polices de caractères. En bref, une fonte est le langage de conception qui façonne un ensemble de lettres, de chiffres et d’icônes. Une police de caractères est le sous-ensemble d’une police caractérisé, entre autres, par son poids et sa taille. Ainsi, si l’Helvetica est une police de caractères, l’Helvetica 12 points est une fonte. De même, l’Helvetica Bold 12 points est une fonte distincte de l’Helvetica Light 12 points.

En quoi cela est-il important ? Parce que les systèmes embarqués doivent rendre de nouvelles images bitmap pour chaque fonte au moment de la compilation. Contrairement aux PC qui utilisent des polices polices vectorielles contenant des instructions sur la manière de les dessiner, les systèmes embarqués utilisent des polices matricielles ou bitmaps. Les polices vectorielles nécessitent beaucoup de calculs, ce qui n’est pas un problème sur un PC mais peut ralentir les interfaces utilisateur sur un microcontrôleur. À l’inverse, les bitmaps ne nécessitent aucun calcul puisqu’ils sont déjà rendus, mais occupent beaucoup plus d’espace en mémoire puisque chaque fonte doit être rendue séparément. Par exemple, les bitmaps de trois polices (une police de caractères dans trois tailles différentes) occuperaient près de 800 octets en mémoire, alors qu’un fichier vectoriel nécessiterait moins de 200 octets.

Le fait que TouchGFX Designer soit devenu le premier kit de développement pour interface graphique pour MCU à prendre en charge les polices vectorielles est donc un grand pas en avant pour les ingénieurs qui cherchent à réduire l’utIlisation de leur flash. Grâce à cette fonctionnalité, un client de ST a pu se contenter de la seule mémoire flash interne du MCU, réduisant ainsi de manière significative sa nomenclature. C’est encore plus impressionnant pour les systèmes d’écriture logographique qui nécessitent souvent plus de bitmaps que les systèmes alphabétiques. Bien que les gains varient considérablement en fonction de l’application, les aléas du marché de la mémoire signifie que de nombreux développeurs cherchent toujours à réduire leur dépendance aux modules flash externes.

La prise en charge des polices vectorielles a été un projet de longue haleine. Par exemple, bien que beaucoup de nos MCU STM32 les supportent techniquement, la capacité d’accélérer le calcul vectoriel avec notre GPU NeoChrom signifie que le STM32U5 et le nouveau STM32H7R/S ouvrent la porte à des performances vraiment intéréssantes. Par exemple, alors qu’un STM32F7 peut prendre jusqu’à 2,88 ms pour rendre une police vectorielle, un STM32U5F9 n’a besoin que de 0,80 ms. De même, les récentes optimisations vectorielles dans les versions précédentes de TouchGFX ont également allégé le rendement. Cependant, nous savons également que toutes les interfaces graphiques ne bénéficient pas des polices vectorielles, comme les systèmes avec beaucoup d’animations. Cette fonctionnalité n’est donc qu’un outil de plus dans l’arsenal d’une équipe.

Pour aider les utilisateurs à déterminer si les polices vectorielles leur conviennent, nous avons publié la démo ci-dessus combinant des vecteurs et des bitmaps et avons partagé son code source. En effet, les polices vectorielles ne sont pas la seule option pour économiser de la mémoire. Par exemple, notre système de compression L8 peut également réduire les bitmap. Chaque projet aura des exigences différentes en matière de flash, et chaque interface utilisateur aura des besoins particuliers en matière de rendu. Certains projets doivent composer avec une flash externe limitée, tandis que d’autres essaient de n’utiliser que la flash interne, et d’autres encore veulent simplement réduire les temps de rendement. Cependant, les clients demandent de plus en plus des interfaces graphiques utilisant moins de flash. Par conséquent, les polices vectorielles ouvrent potentiellement la porte à des interfaces qui n’auraient pas été possibles autrement.

Optimisation de la mémoire

TouchGFX 4.24 apporte une série d’optimisations à ses algorithmes de compression et à ses opérations vectorielles afin d’économiser plus de flash. Depuis la version précédente, ST a publié la démo eBike présentée dans la vidéo ci-dessus, qui n’utilise que 355 Ko de mémoire au lieu de bitmaps totalisant 10,5 Mo. Concrètement, nous avons travaillé à l’optimisation de notre format de compression L8 et nous donnons des conseils pour aider les développeurs à tirer le meilleur parti de leurs interfaces graphique tout en utilisant moins de flash. Par exemple, les équipes obtiennent une meilleure compression sur les images utilisant des couleurs encodées en 8 bits ou moins. En outre, TouchGFX peut dessiner certaines ressources directement depuis la flash grâce à ChromART, réduisant ainsi les besoins en RAM.

Le framework de ST a également apporté de nouvelles optimisations à son implémentation de l’algorithme de compression QuiteOK Image (QOI), qui permet de réduire la taille des ressources graphiques. Le taux de compression dépend d’une myriade de facteurs. Dans des circonstances optimales, nous pouvons réduire, sans perte, la taille d’un fichier de 95 %. Toutefois, comme les opérations de décompression peuvent être coûteuses sur les processeurs les moins puissants, certains privilégieront l’utilisation de bitmaps optimisés et d’astuces telles que les images en mosaïque (une image complète constituée de copies d’une petite mosaïque) afin de limiter l’utilisation de la mémoire flash. Les ingénieurs savent qu’il n’existe pas de solution unique pour les interfaces graphiques pour les systèmes embarqués. Cependant, TouchGFX 4.24 ouvre davantage la porte à la possibilité de créer des interfaces sans utiliser de flash externe.

Format de compression L8

Les éléments graphiques occupent beaucoup d’espace dans la mémoire et la réduction de leur qualité se traduit par une dégradation de l’interface utilisateur. Le L8 est donc un format d’image incontournable car il permet de compresser un fichier jusqu’à 75 % sans dégradation, grâce à l’accélérateur Chrom-ART des microcontrôleurs STM32. Tant qu’une ressource utilise un maximum de 256 couleurs, ce qui est souvent le cas sur les petits systèmes embarqués, les développeurs peuvent compresser une ressource en utilisant le format L8 en cochant simplement une case dans TouchGFX Designer. La décompression est également optimisée, car elle utilise le moteur Chrom-ART pour rechercher les couleurs dans une table afin de rendre la ressource sans perte de qualité.

Compression supplémentaire des images L8

TouchGFX Designer 4.22 a introduit une fonctionnalité essentielle : la compression des images L8. En cliquant sur « Images » dans la colonne de gauche, vous obtenez la liste des ressources graphiques chargés. Pour toutes les images L8, un nouveau menu déroulant « Compression » est disponible, permettant aux utilisateurs de choisir entre trois méthodes : L4, LZW9 (Lempel-Ziv-Welch) et Run Length Encoding (RLE). Les trois sont sans perte, L4 et LZW9 créant des tables de compression qui attribuent une couleur à une entrée, tandis que RLE factorise simplement les séquences répétées. C’est pourquoi nous proposons également une option « Auto » qui permet au compilateur de choisir la méthode de compression la plus optimisée en fonction de la nouvelle taille du fichier et de son temps de rendu.

En moyenne, les utilisateurs peuvent s’attendre à une réduction de la taille des fichiers de 20 à 80 %. Les chiffres varient, mais il est facile de comprendre pourquoi tant d’utilisateurs ont demandé une telle fonctionnalité. Dans la plupart des cas, le rendu de l’image prend deux fois plus de temps. Toutefois, comme les développeurs utilisent cette fonctionnalité pour des interfaces statiques, des icônes ou des éléments plus petits, l’impact n’est pas perceptible puisque le rendu ne prend que quelques millisecondes. En outre, dans de nombreux cas, la taille de fichier considérablement réduite signifie un temps d’accès plus court dans la mémoire, ce qui compense le temps de rendu plus long. En d’autres termes, l’optimisation du stockage compense la pénalité de décompression, offrant ainsi des performances identiques ou presque identiques à celles d’un fichier L8 non compressé tout en utilisant moins de mémoire.

Si les utilisateurs utIlisaient une version de TouchGFX Designer antérieure à 4.22, ils doivent sélectionner manuellement leur méthode de compression. Nos équipes ont conservé le format non compressé comme comportement par défaut, car nous ne voulions pas que les développeurs constatent un changement radical dans la manière dont le framework gérait leurs images L8 sans en comprendre la raison. Néanmoins, nous pensons que cette fonctionnalité est hautement symbolique car elle communique explicitement notre désir d’optimiser l’utIlisation de mémoire, en particulier de la mémoire flash, tout en maintenant les mêmes performances ou presque.

Générateur de code QR

Les codes QR sont de plus en plus populaires. Par exemple, ils permettent à un consommateur de scanner un code et de voir apparaître automatiquement un numéro de série, ce qui facilite grandement le processus d’enregistrement. De même, envoyer quelqu’un vers un soutien technique sur le site web d’une entreprise devient beaucoup plus facile si personne n’a à taper une URL. Cela permet également aux fabricants de mettre à jour leur site web sans craindre que les utilisateurs ne trouvent pas la bonne page. La difficulté réside dans le fait que la génération d’un code QR peut nécessiter de grandes bibliothèques externes mal optimisées pour les microcontrôleurs. En outre, le passage d’arguments pour créer dynamiquement un code et le dessiner ensuite dans le framebuffer est extrêmement complexe à mettre en œuvre à partir de rien.

C’est pourquoi TouchGFX introduit un générateur de code QR. Il peut générer dynamiquement un code QR de niveau 40 (177 modules x 177 modules) à la volée et le dessiner dans le framebuffer. Au lieu d’afficher un code d’erreur, les développeurs peuvent générer un code QR qui renvoie l’utilisateur au soutien technique pertinent. Nous prenons même en charge la correction des erreurs pour garantir l’intégrité des données représentées, ce qui peut être un problème important si l’interface utilisateur transmet un numéro de série, par exemple. Le code QR facilite également l’envoi de symboles au lieu de simples caractères alphanumériques, ce qui est utile pour certaines régions.

Appels en direct

La compression des images L8 est aussi un exemple de la nécessité de mieux communiquer avec nos utilisateurs pour les informer des nouvelles possibilités. TouchGFX fait l’objet de mises à jour fréquentes. Cependant, les designers ne sont pas toujours au courant de ce qui se passe. Nous avons déjà des campagnes de courriels, ce blogue et le site ST.com, entre autres, mais plusieurs nous demandent encore d’établir une ligne de communication plus directe. Pour répondre à leur demande, nous avons lancé les appels en direct, qui sont de petites boîtes apparaissant uniquement au bas de l’écran d’accueil pour diriger les utilisateurs vers des fonctionnalités, des événements ou une solution d’un partenaire. En cliquant sur un appel en direct, vous obtiendrez une fenêtre contextuelle contenant plus de détails ou vous ouvrirez une fenêtre de navigation vers ST.com.

Comme leur nom l’indique, les Live Callouts attirent l’attention des utilisateurs sur des fonctionnalités ou des opportunités spécifiques. Ils n’existent que dans la page d’acceuil pour éviter de distraire les développeurs pendant qu’ils travaillent sur leur interface. Les appels en direct sont également différents des notifications qui ne font qu’avertir les utilisateurs d’une nouvelle version du cadre ou d’un message important. Ils sont moins critiques par nature, ce qui signifie que les développeurs ne seront pas gênés s’ils ne les voient pas tout de suite. Nous accordons également la priorité à la protection de la vie privée de nos utilisateurs. Nous personnalisons les appels en direct pour chaque région, mais nous ne recueillons pas de données privées sur les utilisateurs. Les données de localisation restent sur les machines locales, et TouchGFX Designer décide de ce qui doit être affiché en fonction de la localisation du système.

Mode hors ligne

TouchGFX 4.22 a introduit un nouveau mode hors ligne, qui permet aux utilisateurs de télécharger des démonstrations et des exemples à exécuter sans connexion Internet. Nous livrons également un outil de configuration de proxy plus puissant pour satisfaire les configurations complexes. Dans de nombreux cas, une connexion en ligne est impossible ou difficile à obtenir. Certains utilisateurs sont confrontés à des problèmes qui entravent leur travail, que ce soit dans un avion ou en raison de restrictions de bande passante ou de pare-feu. Grâce au nouveau mode hors ligne et à l’outil de configuration du proxy, il est plus facile et plus pratique d’utiliser TouchGFX Designer et d’être plus productif.

Programmation flash plus rapide

TouchGFX Designer 4.23 a acquis la capacité de flasher le code destiné uniquement à la mémoire flash interne, réduisant ainsi considérablement le temps de programmation. En effet, auparavant, lors de la compilation d’une interface, TouchGFX chargeait tous les actifs, y compris ceux stockés dans la mémoire externe, même s’ils étaient inchangés. Par conséquent, les opérations de compilation pouvaient parfois prendre près de 10 minutes, même si les développeurs n’avaient mis à jour aucune de leurs ressources stockées sur la mémoire externe. Pour accroître la productivité, TouchGFX Designer 4.23 comprend une option permettant de programmer uniquement la mémoire flash interne, réduisant ainsi les opérations de compilation à quelques secondes seulement. Toutefois, les développeurs doivent se méfier du fait qu’oublier de flasher la mémoire externe après avoir modifié certaines des données qu’elle contient peut casser une application.

Prise en charge de X-NUCLEO-GFX01M2 et X-NUCLEO-GFX02Z1

Lorsque les ingénieurs décident d’avoir une interface utilisateur graphique, l’écran devient souvent le composant le plus coûteux de leur nomenclature. Un simple écran de 2 pouces sans couche tactile améliorera considérablement l’expérience de l’utilisateur, mais il reste plus coûteux que tout le reste. Il est donc difficile de trouver un écran abordable lorsque l’on vise une nomenclature de cinq dollars ou moins. Par conséquent, ST offre des cartes avec écran pour aider les ingénieurs à trouver des pièces rentables, et nous assurons la compatibilité de TouchGFX Designer avec ces composants. Les utilisateurs choisissent la configuration de l’écran et peuvent commencer à travailler sur une interface qui correspond à ses caractéristiques.

La première carte que les ingénieurs peuvent choisir est la X-NUCLEO-GFX01M2. Elle utilise un écran SPI 2,2 pouces QVGA (320 x 240) qui prend en charge le SPI flash. Le X-NUCLEO-GFX01M2 est compatible avec une large gamme de cartes NUCLEO à 64 broches, ce qui correspond à une nomenclature d’environ cinq dollars pour un système embarqué typique avec une mémoire flash externe et un circuit imprimé à deux couches. Le X-NUCLEO-GFX01M2 est compatible avec une large gamme de cartes NUCLEO à 64 broches. Par exemple, les ingénieurs peuvent l’utiliser sur le NUCLEO-WB55RG pour rendre les applications Bluetooth plus accessibles.

De même, la X-NUCLEO-GFX02Z1 est notre première carte d’extension d’écran à prendre en charge une interface parallèle, une mémoire flash QSPI et des cartes Nucleo à 144 broches. La plate-forme cible les microcontrôleurs plus puissants, ce qui explique la compatibilité avec les interfaces offrant des bandes passantes plus élevées. Les développeurs peuvent utiliser le X-NUCLEO-GFX02Z1 avec le NUCLEO-U575ZI-Q sorti avec les premiers STM32U5. Les ingénieurs peuvent ainsi tirer parti du meilleur rapport performance par watt du nouveau MCU pour créer des interfaces utilisateur qui n’étaient pas possibles sur les générations précédentes de STM32.

Intégration de vidéos dans les interfaces graphiques

Le désir d’intégrer des vidéos dans un plus grand nombre d’interfaces utilisateur est une conséquence naturelle de la popularité croissante des écrans sur les systèmes embarqués. Malheureusement, la diffusion d’une vidéo sur un système embarqué doté d’un microcontrôleur est un véritable défi. Il n’y a pas de système d’exploitation avec un lecteur multimédia et des codecs par défaut. De même, il est impossible d’écrire une page web affichant une vidéo YouTube. Les développeurs doivent effectuer toutes les tâches lourdes, telles que l’implémentation d’une mémoire tampon vidéo, la détermination du format qui fonctionnera le mieux sur leur microcontrôleur et la détermination de la manière de tirer parti de l’accélération matérielle, si elle est disponible. TouchGFX Designer propose un widget vidéo pour résoudre ce problème. Ainsi, l’ajout d’une vidéo ne nécessite plus que trois étapes simples.

Vidéos directement dans le framebuffer

Une autre caractéristique de TouchGFX 4.23 visant à réduire l’utilisation de la mémoire par une application est la possibilité de configurer automatiquement un système pour écrire directement dans le framebuffer. Traditionnellement, lors de l’affichage d’une vidéo, les images sont d’abord stockées dans un tampon vidéo avant d’être transférées dans le framebuffer qui alimentera l’écran. Cette étape intermédiaire permet de s’assurer que toutes les ressources sont disponibles pour garantir une animation fluide. Le problème est qu’elle nécessite beaucoup plus de mémoire puisque les images vidéo doivent résider dans ce cache avant d’être transférées dans le framebuffer.

TouchGFX prend en charge l’écriture d’images vidéo directement dans le framebuffer au niveau logiciel depuis un certain temps. Cependant, essayer d’utiliser le décodeur MJPEG matériel et l’accélérateur Chrom-ART nécessitait une implémentation manuelle et extrêmement complexe parce qu’elle exigeait que les développeurs modifient les synchronisations et les pilotes de bas niveau. Par conséquent, cette fonctionnalité était hors de portée de beaucoup en raison de l’expertise requise pour la mettre en œuvre. TouchGFX 4.23 résout ce problème en offrant la possibilité d’initialiser automatiquement un microcontrôleur pour écrire des images vidéo directement dans le framebuffer tout en utilisant le moteur MJPEG et Chrom-ART. À partir de TouchGFX 4.23, ce comportement est devenu le nouveau comportement par défaut, garantissant ainsi que le widget vidéo nécessite beaucoup moins de mémoire pour fonctionner.

Exportation de conteneurs personnalisés

Dans sa forme la plus simple, TouchGFX Designer s’appuie sur des widgets, une représentation d’un élément dessiné à l’écran. Le logiciel est livré avec de nombreux widgets prédéfinis, tels qu’une jauge, une horloge ou un graphique, et les développeurs peuvent également concevoir des widgets personnalisés. Pour rendre les widgets plus simples, les designeurs peuvent les regrouper à l’intérieur d’un conteneur. Les conteneurs sont souvent les éléments constitutifs d’une interface. Ils permettent aux programmeurs de réutiliser un ensemble de widgets sur plusieurs écrans sans avoir à les reconfigurer à chaque fois. En outre, la modification d’un conteneur a un impact sur tous les écrans qui l’utilisent, ce qui simplifie grandement les développements. TouchGFX dispose également de conteneurs prédéfinis pour accélérer les opérations de conception les plus courantes, et les développeurs peuvent créer des conteneurs personnalisés.

Les conteneurs personnalisés sont très populaires car ils permettent aux développeurs de peaufiner leur interface et de donner corps à une vision précise. Cependant, le défi inhérent à tout outil de conception est que le travail effectué sur un projet peut rarement être exporté vers une autre interface utilisateur. En effet, un conteneur personnalisé comprend du code, des ressources graphiques, des textes, des dépendances et bien d’autres choses encore qui le lient à son projet existant. Depuis la version 4.20, TouchGFX Designer a résolu ce problème en offrant une fonction d’exportation qui crée un bundle (fichier .tpkg) réutilisable sur d’autres projets. L’utilitaire ajoutera toutes les ressources, y compris les polices, à l’ensemble, et un fichier XML en énumérera le contenu. Les développeurs peuvent donc vérifier et modifier ce fichier pour sélectionner ce qu’ils souhaitent exporter.

Importation de conteneurs personnalisés

Pour importer un conteneur personnalisé, les utilisateurs sélectionnent Edit -> Import -> Custom Container. TouchGFX inclut un nouvel utilitaire d’importation qui guide les utilisateurs tout au long du processus. Par exemple, le logiciel détecte les langues définies par le conteneur personnalisé et les fait correspondre à celles disponibles dans le nouveau projet ou les ignore. Le système interrompt également le processus d’importation en cas de conflit entre des noms génériques ou si un conflit risque de poser des problèmes dans la nouvelle interface. TouchGFX Designer oblige les utilisateurs à résoudre les problèmes sur le conteneur personnalisé original, au lieu de créer des solutions de contournement pendant le processus d’importation. L’objectif de cette fonctionnalité étant de préserver le design des interfaces entre les produits, le fait de forcer les changements dans le projet d’origine garantissant la cohérence entre les interfaces graphiques.

Conteneurs tampons

Comme son nom l’indique, un conteneur tampon utilise un tampon bitmap pour accélérer les performances graphiques et permettre un nombre d’images par seconde plus élevée pour des transitions plus fluides. La démo ci-dessous fonctionne sur un STM32F429I Discovery Kit. Sans conteneur tampon,, la simple animation de diapositives en plein écran (240 × 320) s’exécute à neuf images par seconde. Avec la technologie TouchGFX, le système atteint 60 images par seconde. Certaines smartwatches utilisent cette fonctionnalité pour garantir une expérience fluide malgré les limitations matérielles importantes inhérentes à petit système embarqué et la nécessité d’une plus grande autonomie de la batterie. Au-delà des animations, les conteneurs tampon peuvent optimiser les widgets complexes, tels que les mappeurs de textures ou les petits éléments dynamiques affichés devant un arrière-plan statique.

Sans conteneur tampon, une animation doit être redessinée à chaque image, ce qui peut s’avérer coûteux en termes de calcul. Le conteneur tampon contourne ce problème en stockant la première et la dernière image dans un conteneur séparé sous la forme d’une image bitmap que le système conserve dans la mémoire vive. Au lieu de rendre l’animation, le système récupère les deux images de la mémoire à l’aide du DMA et les affiche à des endroits différents grâce à une simple méthode de DynamicBitmap. Le MCU ne génère plus chaque image, ce qui optimise considérablement les performances. Les développeurs n’ont qu’à cocher la case « Cacheable » dans TouchGFX Designer, sélectionner l’emplacement en mémoire des conteneurs qu’ils veulent mettre dans la mémoire tampon, et les appeler lorsque c’est nécessaire. Cette technique permet de passer d’un temps de rendu de 100 ms à 5 ms.

Framebuffer partielle

Un framebuffer est un espace mémoire contigu qui stocke une représentation de chaque pixel qui apparaîtra à l’écran. Par exemple, une image standard de 24 bits de 390 x 390 pour l’affichage d’une smartwatch nécessite un framebuffer de 3 650 400 bits ou 456,3 Ko(latex\div8[/latex]), ce qui représente plus de 70 % de la SRAM disponible sur le STM32L4+ qui excelle sur les smartwatches et les technologies portables. Et ce chiffre peut exploser si une application nécessite plus d’un framebuffer. Au-delà des limites de capacité, un grand framebuffer prend plus de temps à extraire car plus de données doivent voyager de la mémoire à l’écran, ce qui ralentit les performances.

Comme son nom l’indique, le Framebuffer partiel ne stocke qu’une partie du framebuffer, réduisant ainsi son empreinte mémoire par 10. Les développeurs peuvent configurer sa taille en fonction de la section de l’écran qui changera, puis stocker plusieurs tampons partiels. Le framework choisira alors le tampon approprié et l’enverra à l’écran. Cette technologie fonctionne mieux avec des animations courtes, comme des horloges, des barres de chargement ou un graphique qui se construit au fil du temps. Elle exige également que l’écran utilise un contrôleur intégré, car il recevra directement le framebuffer partiel de la RAM du MCU, contournant ainsi la flash pour plus de performance. Cette technologie fonctionne sur les écrans parallèles / 8080, DSI et SPI.

TouchGFX optimise également le framebuffer partiel pour apporter des interfaces graphiques aux microcontrôleurs à ressources limitées. Traditionnellement, une interface graphique minimale nécessite un framebuffer d’environ 200 Ko. Cependant, lorsqu’un microcontrôleur comme le STM32G071 ne dispose que de 36 Ko de RAM, cela peut constituer un véritable problème. TouchGFX résout ce problème en optimisant le framebuffer partiel pour qu’il ne demande que six kilo-octets. En tenant compte des données d’application du framework, une interface graphique d’entrée de gamme n’aurait besoin que de 16 Ko de RAM pour fonctionner. TouchGFX utilise également des mises à jour partielles intelligentes de l’écran. Cette fonctionnalité s’ajoute au framebuffering partiel pour optimiser l’ordre des mises à jour sur l’écran. Le processus économise les ressources, ce qui permet d’effectuer plus de mises à jour au cours d’une même période.

Prise en charge des graphiques vectoriels (SVG)

TouchGFX 4.21 a inauguré la prise en charge du SVG. Traditionnellement, le framework stocke des images matricielles, telles que des fichiers PNG, parce qu’elles sont faciles à accéder et à afficher. À l’inverse, les fichiers SVG n’incluent pas de rendu mais des instructions sur la manière de les dessiner. Ils sont donc très évolutifs, mais nettement plus exigeants. Et si ce n’est pas un problème sur un ordinateur portable ou de bureau, c’est une toute autre histoire sur un microcontrôleur de faible puissance. Le problème est que les concepteurs créent de plus en plus d’interfaces animées et cherchent à adapter une interface utilisateur à différentes tailles d’écran. Par conséquent, les équipes souhaitent utiliser des fichiers SVG pour économiser des ressources, car un fichier peut être dessiné de différentes manières et occupe moins d’espace en mémoire.

ST utilise son nouvel accélérateur NeoChrom 2.5D disponible sur certains STM32U5 pour relever ce nouveau défi. Le hardware optimisant les animations de dessin décharge une partie des calculs associés aux fichiers SVG, ce qui résout le problème de performance. L’unité s’appuie également sur des interfaces mémoire plus rapides, ce qui accélère les opérations d’extraction, et le fichier est souvent plus petit. Par conséquent, le stockage de fichiers dans la mémoire externe est moins pénalisant. En fin de compte, cette annonce est hautement symbolique car SVG ne figurait pas sur la liste des fonctionnalités lorsque nous avons présenté NeoChrom en mai 2022. Cependant, TouchGFX montre que cette unité a un potentiel énorme, et ST continuera à publier de nouvelles fonctionnalités exploitant ses capacités.

Fichier XML pour le texte

Les équipes de conception stockent souvent du texte dans un fichier Excel pour travailler avec différents traducteurs dans le monde entier. Cependant, au lieu d’utiliser des systèmes de contrôle de version tels que Git, les éditeurs doivent gérer manuellement les modifications et s’assurer que personne n’écrase par inadvertance le travail de quelqu’un d’autre, ce qui peut s’avérer fastidieux. Pour résoudre ce problème, TouchGFX stocke tout le texte d’une interface dans un fichier XML. Ce format simplifie considérablement les opérations de fusion et la résolution des conflits. TouchGFX comprend également un convertisseur XML vers Excel pour s’adapter aux processus existants. Les développeurs peuvent exporter vers Excel, puis réimporter leur fichier Excel dans TouchGFX et son format XML.

Fichiers de projet optimisés

TouchGFX favorise également la collaboration grâce à des fichiers de projet de petite taille. Leur taille les rend plus faciles à fusionner et à partager. Auparavant, les fichiers de projet stockaient tous les paramètres dans un format JSON. Le problème est qu’un tel fichier peut devenir très volumineux. ST a donc décidé d’optimiser les fichiers de projet en ne stockant que les paramètres personnalisés. Par conséquent, tout ce qui n’est pas dans le fichier est considéré comme utilisant une valeur par défaut. Par conséquent, le fichier est beaucoup plus petit, ce qui rend les opérations de fusion sur Git beaucoup plus simples et rapides.

Texte à usage unique et son identification aléatoire

Les développeurs qui souhaitent utiliser du texte doivent créer une ressource dans le panneau de texte de TouchGFX Designer, puis utiliser l’ID du texte dans l’interface utilisateur. Cependant, TouchGFX permet également d’utiliser du « texte à usage unique », qui n’apparaît pas comme une ressource textuelle typique. Les développeurs l’utilisent pendant les tests ou si un texte n’est pas important. Cela évite de remplir la base de données avec des textes non pertinents et permet de créer des prototypes plus rapidement. En effet, la fonction de texte à usage unique génère automatiquement un identifiant et efface la ressource de la base de données si elle est supprimée de l’interface utilisateur, contrairement aux ressources textuelles ordinaires. TouchGFX utilise également un générateur de chaînes de caractères aléatoires pour la création des identifiants. Par conséquent, il est pratiquement impossible que deux identifiants de texte à usage unique soient identiques dans le même projet.

TouchGFX Stock

Bibliothèque d’images gratuite

TouchGFX Stock est la plus grande bibliothèque de ressources graphiques gratuites pour les interfaces utilisateur fournies par un framework destiné aux microcontrôleurs. Elle comprend des icônes, des éléments graphique, des thèmes, des images, etc. Étant donné que les icônes proviennent de la bibliothèque gratuite de Google et que ST détient les droits de toutes les autres ressources, TouchGFX Stock dispose d’une licence généreuse qui permet aux équipes d’utiliser les ressources gratuitement, même pour des projets commerciaux, à condition qu’elles fonctionnent sur des MCU STM32. Les utilisateurs peuvent s’emparer des ressources pour les ajuster à leurs besoins spécifiques. La licence couvre même l’utilisation de ces ressources avec un autre framework graphique tant que le programme fonctionne sur un microcontrôleur ST.

Récemment, de nombreuses startups ont réutilisé les paramètres fictifs de TouchGFX ou nos ressources exemples dans leur design. Cette nouvelle tendance découle de la prolifération de petites équipes qui n’ont pas les ressources nécessaires pour investir dans des concepteurs. Par conséquent, lorsqu’ils adoptent TouchGFX, certains développeurs trouvent les paramètres fictifs élégants et les ajoutent à leurs interfaces finales. C’est la raison pour laquelle nous avons décidé d’investir dans TouchGFX Stock et sommes devenus le fournisseur de MCU disposant de la plus vaste bibliothèque de ressources graphiques libres de droits. Cela explique également notre approche en matière de licences. Au fil des ans, nous nous sommes efforcés de rendre les interfaces graphiques des MCU plus accessibles. Il s’agit d’une nouvelle pierre à l’édifice, et nous nous engageons à enrichir cette bibliothèque au fil du temps avec de nouveaux thèmes, de nouvelles images, etc.

Un designer gratuit à votre service

En attendant, TouchGFX Stock est livré avec des éléments d’interface utilisateur, comme des barres, des popups, des horloges, des jauges, et bien plus encore. Nous fournissons également des versions claires et foncées de certains éléments. En fin de compte, TouchGFX est devenu une leçon de design. Les ingénieurs n’ont pas à s’inquiéter de l’incompatibilité des palettes de couleurs ni à s’appuyer sur des notions de conception dépassées. Nous fournissons des ensembles pour assurer la cohérence et la modernité des interfaces graphiques. Nous offrons également différentes tailles pour s’adapter à la plupart des écrans, de sorte que beaucoup n’auront même pas besoin de faire le redimensionnement eux-mêmes. TouchGFX Stock est livré avec cinq thèmes au lancement. Cependant, le passage d’un thème à l’autre n’est pas automatique en raison de la nature des interfaces graphiques sur les MCU. Comme il n’y a pas de relation univoque avec toutes les ressources, les utilisateurs doivent les remplacer manuellement.

Animations et widgets

Transitions par glissement et graphiques dynamiques

Le défi pour les développeurs est de tirer parti de toutes les fonctionnalités que nous continuons à ajouter à TouchGFX. C’est pourquoi nous proposons des animations optimisées qui utilisent déjà les fonctionnalités ci-dessus. Par exemple, alors qu’une transition traditionnelle nécessite un rafraîchissement complet de l’écran, l’animation de déplacement de texte de TouchGFX utilise beaucoup moins de ressources. De même, le widget graphique dynamique affiche mieux les données séquentielles avec moins d’impact sur la RAM et le microcontrôleur.

Graphiques statiques

Lorsque les technologies portables enregistrent des données environnementales ou physiques, les utilisateurs veulent voir les progrès accomplis. Les graphiques peuvent suivre les fréquences cardiaques, les températures, les pas parcourus, et plus encore. Les développeurs de TouchGFX ont d’abord demandé des graphiques dynamiques, car ils peuvent être difficiles à mettre en œuvre, et la fonctionnalité est disponible depuis TouchGFX 4.15. Maintenant, nos équipes publient des graphiques statiques pour répondre aux nouvelles applications. En effet, les données qui n’ont pas besoin d’évoluer constamment ou qui ne connaissent que de légères variations dans le temps conviennent mieux à une représentation statique. Les nouveaux graphiques fonctionnent légèrement différemment. Les développeurs n’ont besoin d’envoyer qu’un seul point de données pour un graphique dynamique, puisque l’intervalle de temps est constant. En revanche, pour les graphiques statiques, les programmeurs doivent saisir des informations pour les axes X et Y.

Horloges et mappeur de textures

TouchGFX propose également des widgets qui imitent des applications, telles que des horloges analogiques et numériques. Il y a également un mappeur de texture, ce qui signifie que les développeurs peuvent commencer à créer leur programme de mappage par un simple glisser-déposer. Ils devront toujours entrer leur code C++, mais cela rendra le processus beaucoup plus fluide. Texture Mapper est également un excellent exemple des optimisations de TouchGFX sur les MCU à ressources limitées. Il peut aider à animer des objets et fonctionne même sur un STM32G0 tant que les ressources graphiques se trouvent dans la RAM et non dans la flash.

Jauge

Le modèle de jauge dessine une aiguille et un arc pour aider les utilisateurs à surveiller les valeurs. Les développeurs peuvent également modifier l’arrière-plan, l’orientation de l’aiguille, la plage de valeurs, etc. La démo ci-dessous montre comment les programmeurs peuvent basculer entre leur IDE et TouchGFX Designer pour un flux de travail plus fluide. Les équipes peuvent vérifier la jauge rapidement, la modifier à la volée et tester leur code instantanément. Par exemple, la vidéo montre comment la fonction handleTickEvent() contrôle le comportement de la jauge. Avec très peu de lignes de code, les développeurs peuvent modifier la plage de valeurs et la fréquence de mise à jour de l’indicateur, entre autres. De telles optimisations permettent d’économiser beaucoup de ressources dans les applications qui n’ont pas besoin de renouveler constamment la valeur affichée.

Gestion avancée du texte

Le texte est essentiel à la plupart des interfaces graphiques, ce qui explique pourquoi les concepteurs y travaillent autant. Ils le personnalisent, le traduisent et le façonnent. Certaines applications créées sur TouchGFX Designers peuvent comporter des milliers de ressources textuelles, chacune traduite dans de nombreuses langues. Le problème est que le travail avec le texte peut être lourd. Ainsi, pour réduire les frictions, TouchGFX propose désormais des groupes que les développeurs peuvent définir en fonction d’une section ou d’une caractéristique de leurs applications. Cette nouvelle fonctionnalité simplifie l’affichage des textes traduits côte à côte dans TouchGFX Designer. Elle permet également de regrouper les informations pertinentes afin d’en vérifier la cohérence et l’exactitude. Enfin, les groupes permettent de rechercher et de trouver plus rapidement des ressources spécifiques.

TouchGFX Designer comprend également une option Typographies permettant de définir des paramètres par défaut au sein des groupes. Cette section permet aux utilisateurs de choisir les spécifications des polices, les caractères de remplacement, les caractères génériques, l’alignement, etc. Auparavant, les développeurs devaient écraser les paramètres pour chaque ressource textuelle, ce qui pouvait représenter un travail considérable. Grâce aux groupes, il est possible de paramétrer simultanément de nombreuses ressources, ce qui permet d’optimiser considérablement les développements. Les projets existants comportant des typographies personnalisées verront leurs paramètres transférés dans la nouvelle section. La nouvelle interface de texte affiche également les textes à usage unique et permet leur promotion vers une ressource si nécessaire.

• Télécharger TouchGFX 4.25