Philosophie de la bibliothèque PecheuxGraph

D'abord, posons nous la question : qui va utiliser PecheuxGraph? Si c'est un particulier qui n'a qu'un seul afficheur et qui va faire un million d'essais dessus, ce n'est pas la peine de lui fournir un gros logiciel qui fonctionne avec tous les drivers qu'il n'a pas. Il va prendre une fois la bibliothèque et si elle est plus petite, elle se compilera plus vite. Si c'est pour une entreprise qui a des VMA412 avec tout plein de circuits pilotes différents et tout un tas d'autres afficheurs avec des résolutions différentes, le mieux c'est qu'elle me paie pour lui fournir ce dont elle a besoin.

Il faut aussi savoir :
- pour quel afficheur (par exemple VMA412, mais il y en a d'autres)
- pour quel driver (par exemple ST7781, ILI9341)
- pour quelle carte (Uno, Méga...)
- pour quel sens (portrait, paysage...)

Les afficheurs

En notant que je ne peux tester que sur le matériel que j'ai, et que je n'avais qu'un afficheur VMA412, le problème se pose assez peu. Je n'ai écrit pour l'instant que pour le VMA412.

Les drivers

C'est pareil pour le driver, je n'avais qu'un afficheur équipé d'un ST7781. Maintenant que www.vdram.com m'a donné un deuxième VMA412 basé sur le ILI9341, je peux écrire pour ces deux drivers. Ces deux drivers ne réagissent pas pareil le premier permet d'être utilisé dans les modes portrait ou paysage, inversé ou non, tandis que le second ne reconnaît qu'un mode portrait. Au début, je pensais faire des optimisations pour chaque driver, mais cela porte sur trop de choses. Les fonctions qui seraient différentes seraient les fonctions de base: points, droites horizontales, verticales et obliques, rectangles pleins. Le fait de pouvoir utiliser les 4 orientations complique le problème et augmenterait notamment le code. En optimisant un peu moins, cela simplifie la bibliothèque et par là, la mise au point, en particulier pour les modifications ultérieures.

Pour faire une bibliothèque qui fonctionne pour deux drivers, on peut faire des choix de gérer tout cela par le programme au moment de l'exécution. C'est ce que font les bibliothèques officielles. Cela implique d'avoir en mémoire une fonction d'initialisation par driver, puisqu'on choisira à l'exécution seulement. L'avantage est que cela fonctionne pour tout le monde. Mais sur ce principe, c'est comme si dans votre voiture vous aviez une roue de secours de chaque modèle. C'est sûr que si vous crevez, vous avez la bonne roue, mais que de poids inutile! Et il n'y a pas que l'initialisation qui risque d'être différente. Si on écrit pour tous les drivers, soit on écrit plusieurs fonctions différentes (augmentation du code), soit on cherche un dénominateur commun, et du coup les circuits performants sont pénalisés. Pour donner une image, certaines voitures ont une boîte 4 vitesses, d'autres en on 6, certaines peuvent passer en 4x4. En cherchant quelque chose qui marche pour tous, c'est empêcher les voitures d'utiliser plus de 4 vitesses, le 4x4, le régulateur de vitesse, la radio...

J'ai donc choisi, pour des questions de test et de remplissage mémoire de faire une bibliothèque par couple afficheur/driver. Chacun choisira ce dont il a besoin, une fois pour toutes.

Les cartes

Pour les cartes, l'afficheur VMA412 est 100% compatible avec la carte Uno, et à 90% avec la carte méga. J'utilise personnellement une carte dite "Vrillette" permettant de mettre un carte Méga, un afficheur, mais en plus d'autres circuits. Cette carte permet le dialogue entre ma carte Méga et l'afficheur sur un seul port, dans le bon ordre. Les lectures et les écritures sont plus rapides. Comme lorsque l'on compile, on donne le type de carte, la compilation permet de ne prendre que le code nécessaire. Et comme les changements pour une carte ou pour une autre n'est pas très important, le choix de la carte peut se mettre directement dans le code. Cela doit augmenter légèrement le temps de compilation, mais pas la taille du code. Et puis ce n'est pas rare d'avoir un seul afficheur, mais plusieurs cartes différentes.

Le nom de la librairie

J'ai longtemps pensé à prendre comme nom pour ma bibliothèque Pecheux_Graph_VMA412_ILI9341. Cela présente l'avantage de pouvoir avoir en même temps la bibliothèque Pecheux_Graph_VMA412_ST4481. Mais c'est un peu long à taper, et j'ai tendance à oublier le numéro du driver. J'ai finalement opté pour PecheuxGraph . Ainsi, les exemples étant indépendants du driver, je peux donner un code qui fonctionnera avec une ou l'autre bibliothèque. Celui qui n'a qu'un type d'afficheur ne sera pas gêné, mais celui qui a les deux types d'afficheur devra changer le nom des deux bibliothèques. Mais celui-ci est rare, et si il a plusieurs afficheurs, il doit être plus avancé, et changer le nom de quelques fichiers devrait être à sa portée.

Utiliser une bibliothèque standard ou se faire la sienne?

Au départ, je n'avais pas du tout l'intention d'écrire une bibliothèque graphique. Mais avec un circuit en 2020, j'ai chargé la bibliothèque officielle récupéré sur le site de Velleman. Les exemples sont en deux endroits. le premier paquet d'exemples ne se compile pas. Dans le deuxième, presque tout fonctionnait. J'ai eu une proposition automatique de mettre à jour mes bibliothèques, et depuis il y a plein d'exemples qui ne fonctionnent plus, et plus de la moitié de ceux qui se compilent ont des avertissement. Du coup, si je fais mes propres programmes et que j'ai un message d'avertissement, je ne saurais pas si c'est mon code qui est mal écrit ou si c'est la faute de la bibliothèque récupérée. Et faire des programmes avec des exemples qui ne fonctionnent pas est plus délicat.

La deuxième raison qui m'a fait choisir d'écrire ma bibliothèque, c'est le mode texte. Deux problèmes se posent :
- la fonte est matricielle et supporte assez peu les agrandissements
- il n'y a pas d'accents.
On peut théoriquement corriger ces problèmes, il suffit de redéfinir les fontes. Mais la documentation n'explique pas comment faire. On peut suivre le code, mais quand j'ai voulu savoir comment la bibliothèque officielle faisait pour lire une couleur, mais c'est une galère. A chaque remontée dans le code, on a de nouvelles bibliothèques, et beaucoup de code. Je crois plus rapide de repartir à zéro. Déjà que quand je relis mon code, j'ai des problèmes!

La troisième raison c'est la taille du code officiel. Voici trois exemples:
- une fonte de caractères "officielle" fait en moyenne 4000 octets, avec la seule possibilité de passer en italique et avec des agrandissement pas terrible; ma fonte fait 721 octets, avec la possibilité d'agrandir sans perte (fonte vectorielle), permet le gras, le jambage (serif in english), et surtout j'ai les lettres accentuées!
- si je veux stocker des images, je n'ai que le format bitmap. C'est bien gentil, mais l'afficheur est en 16 bits, le bitmap en 24. Pour passer d'une format à l'autre c'est long. J'ai choisi en plus du bitmap (presque obligatoire pour pouvoir mettre une image la première fois), d'avoir un format 16 bits adapté au VMA412. C'est plus rapide (gain de 50%), la taille aussi gagne 50%. Ce qui veut dire qu'on y gagne si on veut mettre des icône en mémoire programme.

Un peu aussi pour les mêmes raisons, je songe déjà à faire ma bibliothèque pour gérer la carte SD!


dansetrad.fr Contactez-moi