MicroPython - Polices Truetype

L’utilisation de pip au lieu de apt sur une distribution Debian est susceptible de provoquer des problèmes, notamment en raison d’une gestion différente des dépendances. Depuis Debian 12, l’installation d’une application Python doit donc se faire au sein d’un environnement virtuel. Si vous avez déjà utilisé un tel environnement, vous connaissez la procédure et vous installerez mpy-cross dans l’environnement virtuel que vous aurez créé pour, après l’avoir activé, en exécutant la ligne :

pip install mpy-cross

Si vous n’avez pas configuré d’environnement virtuel, l’installation n’aboutira pas. Pour faire simple, je vous conseille, dans ce cas, d’installer d’abord l’utilitaire pipx en exécutant :

sudo apt update && sudo apt install pipx
pipx ensurepath

Cet utilitaire se sert de pip pour l’installation proprement dite, mais crée au préalable un environnement virtuel spécifique à l’application qu’il va installer et à ses dépendances. Il s’utilise exactement comme pip:

pipx install mpy-cross

mpy-cross est installé dans le dossier /home/user/.local/bin. Si ce dossier n’existe pas, il sera créé et ajouté au path pour donner l’accès à l’utilitaire depuis un dossier quelconque de votre PC. Pour faire simple, ce dossier nous servira également à stocker font_to_py.py.

Ce fichier, comme tous les fichiers utilisés dans ce tutoriel, est contenu dans l’archive fournie à la fin du chapitre VIII. ApplicationApplication. Pour avoir une version plus récente, si elle existe, rendez-vous sur cette page puis cliquez sur Download raw file :

Dans ce cas, il sera peut-être nécessaire de s’adapter aux modifications apportées à cette nouvelle version.

Le fichier font_to_py.py est téléchargé dans un dossier qui dépend du paramétrage de votre navigateur, généralement le dossier Téléchargements. Déplacez-le dans le dossier /home/user/.local/bin que nous venons de voir pour le rendre accessible depuis n’importe quel emplacement de votre PC. Vous pouvez également, si vous préférez, créer un dossier spécifique et l’incorporer au path.

Comme vu plus haut, font_to_py.py requiert la bibliothèque freetype-py pour fonctionner. Cette bibliothèque se trouve dans les dépôts Debian et peut être déjà installée sur votre PC, mais ce n’est pas obligatoire. Avant de l’installer, on va vérifier cela. Exécutez l’une des deux lignes suivantes :

apt show python3-freetype

ou

pip show freetype-py

Si le retour indique qu’aucun paquet n’a été trouvé, il va falloir installer freetype-py. Vous avez deux possibilités :

apt install python3-freetype

ou

pip install freetype-py

Dans les deux cas, il s’agit bien de la même bibliothèque, à savoir freetype-py, mais installée par deux méthodes différentes.

Ce fichier, comme tous les fichiers utilisés dans ce tutoriel, est contenu dans l’archive fournie à la fin du chapitre VIII. ApplicationApplication. Pour avoir une version plus récente, s’il y en a une, rendez-vous sur cette page puis cliquez sur Download raw file :

Le fichier writer.py est téléchargé dans un dossier qui dépend du paramétrage de votre navigateur, généralement le dossier Téléchargements. Déplacez-le dans le dossier de votre choix.

Pour utiliser cette bibliothèque, il vous suffit de la téléverser telle quelle dans la mémoire flash du microcontrôleur puis de l’importer dans le script qui doit l’utiliser. Comme il s’agit d’une bibliothèque que vous n’avez pas à modifier, vous pouvez également la compiler avec mpy-cross (voir le chapitre VII. mpy-crossmpy-cross) avant de la téléverser avec les avantages suivants :

• fichier résultant plus petit, donc téléversement plus rapide et occupation mémoire flash plus faible ;
• importation plus rapide et RAM moins impactée.

Pour illustrer cet article et lui donner un fil directeur, on va partir sur un très classique affichage de mesures fournies par un capteur (voir chapitre VIII. ApplicationApplication ). Le choix des polices dépend à la fois du type d’application visé, de la place dont on dispose et des préférences esthétiques du concepteur. C’est toujours un compromis. Dans le contexte que je viens de fixer, par exemple, le choix d’une police cursive ou gothique n’a que peu d’intérêt. On a besoin d’une police plutôt technique avec un graphisme simple facile à lire : n’oublions pas que cette police va être affichée sous forme de bitmap sans antialiasing. Personnellement, j’utilise une police standard sans serif à chasse fixe.

En ce qui concerne la taille, ça dépend de ce que l’on doit afficher. Avec un afficheur à LED, l’affichage classique d’une mesure comprend :

• l’intitulé qui indique le type de mesure effectuée. Exemple : Température. Cette information est généralement sérigraphiée sur le boîtier qui supporte l’afficheur ;
• la valeur numérique de la mesure. Exemple : 18,5 ;
• l’unité dans laquelle la mesure est exprimée. Exemple : °C. Cette information est généralement sérigraphiée sur le boîtier qui supporte l’afficheur.

Ce type de présentation, efficace au demeurant, ne se prête pas à l’évolution. Les sérigraphies sont difficiles à modifier et l’afficheur en lui-même est limité à un certain nombre de digits.

Avec un afficheur matriciel, on peut aller plus loin :

• si on décide, pour des raisons de place et de lisibilité, de n’afficher que la donnée numérique, on ne se pose pas de question : on utilise une seule fonte dans la plus grande taille possible ;
• sinon, on peut bien entendu n’utiliser également qu’une seule fonte pour afficher le tout, mais dans ce cas, on sera obligé d’opter pour une taille relativement faible afin que tout tienne dans l’écran, au détriment de la lisibilité ;
• comme l’important reste malgré tout la valeur numérique affichée, on peut envisager une grande taille pour l’affichage de la mesure elle-même et une taille plus modeste pour l’intitulé et l’unité de mesure ;
• on peut également envisager de n’afficher que l’intitulé ou que l’unité, dans la mesure où il y a redondance d’information ;
• on peut également alterner l’affichage des différentes informations.

En tout état de cause, ça reste une affaire de choix, et chacun fera le sien. Pour le tutoriel, on va tout afficher, mais en privilégiant l’affichage de la mesure en elle-même.

Partant de là, il nous faut au moins une police dans au moins deux fontes de tailles différentes. Le plus simple consiste à utiliser l’une des polices installées sur votre ordinateur. Sous Debian, par exemple, elles se trouvent dans les dossiers /usr/share/fonts/truetype/ et /usr/share/fonts/opentype/. Elles sont toutes libres d’usage dans le cadre privé, mais en dehors de ce cadre, il est préférable de vérifier les licences qui les accompagnent. Vous pouvez également en télécharger depuis des sites web. Une fonte comme LiberationMono-Regular fera parfaitement l’affaire. Elle est mise à disposition sous licence GNU-GPLv2 modifiée pour les polices de caractères par cette exception. LiberationMono-Regular est installée d’origine sur Debian, mais comme ce n’est pas forcément le cas pour toutes les distributions, je vous ai mis un lien à tout hasard si vous voulez la télécharger. Elle est également fournie dans l’archive téléchargeable en fin de tutoriel. J’ai fait le choix d’une fonte à chasse fixe car cela permet de déterminer simplement la longueur d’un mot et donc, entre autres, de savoir au moment du codage s’il tiendra dans l’espace qui lui est attribué. Ça limite les modifications à posteriori.

Bien que cette police suffise à nos besoins, j’aime bien, pour la présentation, afficher les valeurs numériques avec une police de type 7 segments. Ça rappelle les afficheurs à LED qui ont eu leur heure de gloire, qui sont d’ailleurs toujours utilisés en raison de leur facilité de mise en œuvre et de leur lisibilité, mais qui n’offrent pas, bien entendu, la même souplesse d’affichage que les écrans matriciels comme je l’ai souligné plus haut.

Je n’ai pas trouvé, ce qui ne veut pas dire qu’il n’y en a pas, de police de ce type vraiment libre de droits : le plus simple a été d’en bricoler une que j’ai appelée led_7_digits.ttf. Vous la trouverez dans l’archive téléchargeable en fin de tutoriel. C’est une police TrueType sans baseline à chasse presque fixe (voir note ci-dessous) qui ne propose qu’une seule fonte (regular) et qui ne contient que les caractères nécessaires à l’affichage de données numériques. Si ce minimum syndical vous convient et que vous en avez l’utilité, vous pouvez bien entendu vous en servir gratuitement sans aucune restriction ni obligation dans vos applications, que ce soit sous sa forme vectorielle ou sous sa forme matricielle, sans garantie d’aucune sorte, bien entendu, comme d’habitude.

Puisqu’en France on ne peut rien placer de son propre chef dans le domaine public, j’ai opté pour ©naute 2024 sous licence CC0-1.0, assez proche de la licence GNU-GPLv3 modifiée et qui permet en gros de faire tout ce que l’on veut avec cette police sauf de la rendre non libre (c’est le but de la protection). À noter que le copyright n’a aucune valeur juridique en France où l’on utilise plutôt les notions de droit d’auteur ou de propriété intellectuelle. Voici un aperçu de son rendu :

font_to_py.py n’implémente qu’une fonction, qui accepte toutefois plusieurs paramètres. La ligne de commande minimale pour générer une fonte nécessite trois arguments : le fichier d’entrée, la hauteur souhaitée pour les caractères, en pixels, et le fichier de sortie. Elle est de la forme :

font_to_py.py fonte_1.ttf hauteur fonte_2.py

ou

font_to_py.py fonte_1.otf hauteur fonte_2.py

Cette ligne va générer le fichier fonte_2.py, et un résumé de l’opération va s’afficher. fonte_1 et fonte_2 représentent symboliquement le chemin vers le fichier orignal et le fichier généré et peuvent être identiques, mais les extensions doivent être respectées.

La fonte générée n’est plus vectorielle, mais matricielle, et l’utilisateur décide de la hauteur en pixels de la fonte qu’il veut créer. Un algorithme détermine alors, en plusieurs passes s’il le faut, la largeur permettant de respecter au mieux les proportions des caractères originaux et peut être amené, dans ce but, à modifier légèrement la hauteur demandée. D’après mes essais, cette modification semble ne pas excéder deux pixels. Si cette modification, occasionnelle, je le souligne, ne convient pas à votre projet, vous devrez répéter l’opération en modifiant les paramètres de votre demande, jusqu’à obtenir le résultat escompté, ou tout au moins un résultat satisfaisant.

Par exemple, la commande suivante va créer le fichier LiberationMono-Regular.py dans le répertoire courant à partir du fichier LiberationMono-Regular.ttf présent dans le même répertoire. L’afficheur utilisé ayant une définition verticale de 64 pixels, paramétrer 16 pixels pour la hauteur des caractères assurera l’affichage de 4 lignes avec une lisibilité convenable et un remplissage optimal :

font_to_py.py LiberationMono-Regular.ttf 16 LiberationMono-Regular.py

et en image :

Le résumé indique que tout s’est bien passé et que la fonte tient dans une matrice de 16✕10 px (la hauteur demandée a été respectée). Étant donné les 128 px de large de l’afficheur, on peut « caser » 12 caractères, ce qui autorise potentiellement l’affichage de 48 caractères. Si c’est insuffisant pour une liseuse, ça permet malgré tout de travailler. Dans l’histoire, 512 px seront « gâchés », soit 6,25 % de la surface d’affichage. Même si ce n’est pas parfait, cela reste acceptable.

En plus de la génération d’une fonte bitmap à partir d’une fonte vectorielle, font_to_py.py implémente neuf fonctions qui pourront être appelées lors de l’utilisation de writer.py. Parmi ces fonctions, cinq seront particulièrement utiles (voir la page de référence pour de plus amples informations) :

1. height() : retourne la hauteur des caractères en pixels. Quand on parle de la hauteur du caractère, on parle de la hauteur de la matrice qui contient le caractère. Cette hauteur est plus grande que la hauteur réelle du plus grand caractère pour éviter que les caractères de deux lignes successives ne se touchent ;
2. max_width() : retourne la largeur en pixels du caractère le plus large. Il s’agit ici aussi de la largeur de la matrice qui est plus grande que la largeur réelle du plus grand caractère pour éviter que deux caractères successifs ne se touchent. Dans le cas de chasse fixe, tous les caractères ont la même largeur, naturellement ;

3. baseline() : retourne la hauteur du caractère depuis sa ligne de base (baseline). Cette donnée est utile quand on veut aligner deux caractères de tailles différentes. Un petit dessin vaut mieux qu’un long discours :

   

4. monospaced() : retourne True si la police est à pas fixe. Utile pour la mise en page ;

5. get_ch(arg) : retourne un tupple de trois items dont width (largeur du caractère passé en argument). Utile pour la mise en page quand monospaced() retourne False.

L’utilisation de la ligne de commande minimale fonctionne parfaitement mais présente deux inconvénients :

• la police générée ne contient par défaut que les caractères dont les codes ASCII sont compris entre 32 et 126 inclus, codés sur 7 bits. Si c’est suffisant pour un anglo-saxon, c’est un peu juste pour nous autres Français qui utilisons des diacritiques ;
• pour les fontes dont on sait qu’on n’utilisera qu’un sous-ensemble réduit de caractères, il est inutile de s’encombrer de l’ensemble complet : n’oublions pas que la RAM est comptée sur les microcontrôleurs et qu’il est préférable de l’économiser.

Pas d’inquiétude : c’est prévu !

Outre les arguments obligatoires que nous venons de voir, la ligne de commande accepte des arguments optionnels qui vont permettre d’adapter au mieux le fichier de sortie à nos besoins. Tous les arguments optionnels ne seront pas traités ici, mais vous pouvez vous rendre sur la page de référence pour de plus amples informations.

1. -f ou --fixed : permet de générer une police à pas fixe à partir d’une police à pas variable. Si c’est utile quand la police à pas fixe n’existe pas, cette fonction donne malgré tout de moins bons résultats que quand on utilise directement une police à pas fixe. Il est donc préférable de ne l’utiliser que lorsque la police à pas fixe n’est pas disponible ;
2. -s ou --smallest : permet de fixer la valeur ordinale inférieure à partir de laquelle commencera la génération. Cette valeur, appartenant obligatoirement à l’intervalle [0..1114111] représentant l’ensemble des caractères Unicode codés sur 4, 5 ou 6 octets (codage UTF-8, intervalle [0000h..10FFFFh]), est fixée à 32 par défaut. Combinée à la valeur supérieure, elle doit déterminer un ensemble non vide de caractères : s ≤ l ;
3. -l ou --largest : permet de fixer la valeur ordinale supérieure à laquelle s’arrêtera la génération. Cette valeur, appartenant obligatoirement au même intervalle que ci-dessus, est fixée par défaut à 126. Combinée à la valeur inférieure, elle doit déterminer un ensemble non vide de caractères : l ≥ s ;
4. -e ou --errchar : fixe le caractère générique qui sera affiché en cas d’appel d’un caractère qui n’est pas contenu dans le set en cours. Le caractère générique par défaut est ? (point d’interrogation). Il faut bien entendu que le caractère générique choisi fasse partie du set en cours. Si, par exemple, vous utilisez le set ainsi que le caractère générique par défaut et que vous voulez afficher le mot « Température », le mot qui s'affichera sera Temp?rature ;
5. -c ou --charset : permet de limiter la génération de caractères à un ensemble saisi explicitement dans la ligne de commande. Si, par exemple, vous utilisez une fonte 7 segments pour n’afficher que des nombres, vous n’aurez besoin que des chiffres de 0 à 9 et, éventuellement, des caractères : ou . comme séparateurs horaire ou décimal. Toujours dans l’optique d’économiser la mémoire, il est inutile de générer tous les caractères ;
6. -k ou --carset_file : permet de fournir l’ensemble des caractères à générer sous la forme d’un fichier texte. Cet argument permet de faire la même chose que l’argument -c mais évite d’avoir à saisir à chaque fois la même séquence de caractères à générer. Si ce n’est pas gênant pour une dizaine de caractères, ça devient un problème s’il y en a une centaine, voire plus. On sauvegarde donc une fois pour toutes cette séquence dans un fichier et on donne ce fichier comme argument. On peut ainsi créer autant de fichiers que l’on veut pour couvrir des besoins différents.

Pour l’application proposée au chapitre VIII. ApplicationApplication, il va nous falloir trois fontes py : une basée sur la fonte led_7_digits.ttf et deux basées sur la fonte LiberationMono-Regular.ttf.

Pour la fonte led_7_digits.ttf, nous n’utiliserons que 12 caractères (de toute manière, elle n’en propose pas d’autres). L’option -c est suffisante dans ce cas, car la saisie explicite de ces 12 caractères est rapide et il y a peu de chance d’en oublier un. Voici la commande correspondante :

font_to_py.py led_7_digits.ttf 35 digits_35.py -c 0123456789.:

• le choix de la hauteur de la fonte créée, 35 ici, dépend uniquement du résultat que l’on veut obtenir au niveau de l’affichage et nécessite quelques essais pour arriver au bon compromis ;
• le nom de la fonte créée est libre, mais à l’usage, on s’aperçoit rapidement que le rappel de la fonte d’origine et de la taille choisie sont des renseignements utiles, d’où le choix digits_35.py ;
• l’option -c 0123456789.: indique explicitement les caractères qui vont être générés.

À partir de la fonte LiberationMono-Regular.ttf, nous allons créer deux fontes py : l’une dédiée à l’affichage du libellé du type de mesure effectué, l’autre dédiée à l’affichage de l’unité de mesure correspondante. Elles différeront par le set de caractères utilisé et la taille choisie pour ces caractères.

Contrairement au cas précédent, la saisie explicite des caractères n’est pas pratique : d’une part, elle prend du temps et expose à des oublis, et d’autre part elle n’est pas réutilisable. Si, par exemple, on veut créer plusieurs fontes avec le même set de caractères, il faudra tout ressaisir à chaque fois. On peut bien entendu faire un copier-coller, mais il y a une solution plus pérenne : elle consiste à créer deux fichiers « texte » contenant les caractères voulus.

Pour le libellé, il nous faut tous les caractères alphanumériques (pour être sûr) et le caractère – (tiret) pour les mots composés. Ces caractères seront regroupés dans le fichier alphanum.

alphanum

Sélectionnez

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzàâäçéèêëîïôöùûüÿæœÀÂÄÇÉÈÊËÎÏÔÖÙÛÜŸÆŒ-

Pour les unités de mesure, j’ai regroupé dans le fichier usysint (UnitésSYStèmeINTernational) les caractères utilisés dans le système international d’unités en vigueur sur (presque*) toute la planète (*exception faite des États-Unis, du Liberia et de la Birmanie : voir ici), en espérant ne pas en avoir oublié.

abcdfghklmnopqrstvxyz ABCFGHJKMNPSTVW/°Ωµ%

Nous pouvons maintenant créer nos deux polices :

font_to_py.py LiberationMono-Regular.ttf 16 liberation_alphanum_16.py -k alphanum

et

font_to_py.py LiberationMono-Regular.ttf 20 liberation_usysint_20.py -k usysint

Pour les raisons évoquées plus haut, le nom du fichier généré comporte le rappel du set de caractères utilisé pour sa création et la hauteur de caractère demandée.

Pour utiliser writer, vous devez l’importer dans votre script. Le fichier writer.py doit donc être présent dans le système de fichiers de votre microcontrôleur. Pour le téléverser, exécutez la ligne suivante (ou l’équivalent avec votre utilitaire de téléversement) en adaptant les chemins si besoin :

mpremote u0 cp writer.py :

ce qui nous donne :

Cette manipulation sera à effectuer pour tous les fichiers nécessaires, à savoir les pilotes et les fontes : comme la seule différence sera le nom du fichier, je ne détaillerai pas les autres téléversements.

Vous devez ensuite créer une instance de writer et, pour cela, vous devez fournir :

• une instance de l’afficheur utilisé : dans notre cas, le pilote ssd1306.py doit donc soit être présent dans votre version de MicroPython, soit avoir été préalablement téléversé dans le système de fichiers de votre microcontrôleur, pour pouvoir, après importation, créer cette instance :

   

  Sélectionnez

  from machine import Pin, SoftI2C
  from ssd1306 import SSD1306_I2C
  
  # Initialisation du bus I2C pour un ESP32
  i2c = SoftI2C(scl=Pin(22), sda=Pin(21))
  
  # Dimensions de l’afficheur stockées en mémoire flash
  WIDTH = const(128)
  HEIGHT = const(64)
  
  # Création d’une instance de l’afficheur
  oled = SSD1306_I2C(WIDTH, HEIGHT, i2c)

• une police bitmap, par exemple LiberationMono_Regular.py que nous avons créée plus haut avec l’outil font_to_py.py, et qui aura été téléversée dans le système de fichiers de votre microcontrôleur.

À une exception près, les méthodes fournies par writer nécessitent une instance de classe et nous avons donc besoin d’un constructeur. Il prend les arguments suivants :

• device : une instance de l'afficheur utilisé ;
• font : la police qui va être utilisée pour la prochaine écriture. Vous pouvez définir autant d’instances de writer que nécessaire avec des polices différentes pour les besoins de l'affichage, dans la limite de la mémoire disponible ;
• verbose : True par défaut. Affiche dans la console un résumé des arguments déjà définis.

Par exemple, maintenant que nous avons tous les éléments, à savoir un afficheur (oled) et une police (liberationMono_Regular.py), nous pouvons créer une instance de Writer :

import LiberationMono_Regular as lib
from writer import Writer

# Création d’une instance de "Writer"
w_lib = Writer(oled, lib, False)

Cette méthode est l’exception à laquelle j’ai fait allusion ci-dessus. Elle est statique et n’est donc pas liée à une instance de classe. Il faut par conséquent lui fournir en argument l’instance sur laquelle elle doit agir.

set_textpos(device, row=None, col=None) fixe le point d’insertion du prochain texte affiché quelle que soit l’instance utilisée, et donc, quelle que soit la police. Elle reçoit trois arguments :

• device : l’instance de l’afficheur utilisé ;
• row : position verticale en pixels, l’origine étant en haut de l’afficheur. La valeur par défaut est zéro (0). Si None est passé en argument, la valeur précédemment assignée reste inchangée ;
• col : position horizontale en pixels, l’origine étant à gauche de l’afficheur. La valeur par défaut est zéro (0). Si None est passé en argument, la valeur précédemment assignée reste inchangée.

Exemple :

# Affichage du prochain caractère aux coordonnées "(10,20)"
set_textpos(oled, 10, 20)

Quelques précisions :

• la méthode attend les paramètres de positionnement row et col dans cet ordre précis, ce qui revient à fournir les coordonnées (-y,x). Ceci peut sembler contre-intuitif dans un contexte orthonormé si on considère la matrice d’affichage de l’écran comme tel, mais ça devient cohérent si on considère l’affichage de caractères comme dans un traitement de texte. writer étant dédié à l’affichage de texte, ce choix est logique ;
• le point de référence pour le positionnement du caractère est le pixel supérieur gauche représenté en rouge dans le schéma suivant :

• une fois le caractère dessiné, le point d’insertion du caractère suivant est automatiquement réévalué en fonction de la place disponible sur la même ligne pour le nouveau caractère et des paramètres fournis à set_clip(). Avec les paramètres par défaut, si la place est suffisante, le nouveau point d’insertion se trouve sur la même ligne que l’ancien et décalé de la largeur du caractère précédent, ce qui fait que le nouveau caractère est dessiné à la suite du premier. S’il n’y a pas assez de place pour dessiner le nouveau caractère, le nouveau point d’insertion sera positionné en début de ligne (x=0 ou col=0), mais sera décalé de la hauteur du caractère précédent. Attention toutefois : si vous changez de police entre deux caractères, le résultat obtenu risque fort de ne pas vous convenir. Vous devrez alors soit gérer les alignements dans le code, en utilisant notamment height() et baseline(), si l’affichage est dynamique, soit déterminer « à la main » les valeurs à coder en dur si l’affichage est statique.

printstring(string, invert=False) affiche la chaîne fournie en argument à la position définie par set_textpos() :

• string : chaîne à afficher ;
• invert : False par défaut affiche les caractères en blanc sur fond noir. Si True, les caractères sont affichés en noir sur fond blanc.

Exemple :

# Affiche "Bonjour !" en blanc sur fond noir
w_lib.printstring('Bonjour !')

# Affiche "Bonjour !" en noir sur fond blanc
w_lib.printstring('Bonjour !', True)

height() retourne la hauteur des caractères de la police en cours. Peut servir à calculer une position verticale pour des besoins de mise en page.

Exemple :

# Dans notre contexte, l’instruction suivante stockera "16" dans la variable "hauteur_car"
hauteur_car = w_lib.height()

stringlen(string, oh=False) retourne la longueur de la chaîne en pixels si oh = False (valeur par défaut). À utiliser notamment pour centrer ou justifier du texte :

• string : chaîne dont on veut connaître la longueur ;

• oh : argument à usage interne. Quand oh = True, la méthode renvoie un booléen :

  • True dans le cas où la chaîne dépasserait la limite de l’afficheur si elle était positionnée au point d’insertion en cours,
  • False dans le cas contraire.

Exemple :

# Dans notre contexte, après exécution de l’instruction suivante,   vaudra .
longueur = w_lib.stringlen('Bonjour !')

set_clip(row_clip=None, col_clip=None, wrap=None) gère les débordements :

• row_clip (False par défaut) :

  • True : si un caractère empiète sur la limite inférieure de l’afficheur, il ne sera pas affiché,
  • False : si un caractère empiète sur la limite inférieure de l’afficheur, le texte déjà affiché défilera vers le haut du nombre de pixels nécessaires pour que ce caractère soit affiché entièrement,
  • None : pas de modification de la valeur précédemment attribuée ;

• col_clip (False par défaut) :

  • True : si un caractère empiète sur la limite droite de l’afficheur, il ne sera pas affiché,
  • False : si un caractère empiète sur la limite droite de l’afficheur, il sera affiché sur la ligne suivante,
  • None : pas de modification de la valeur précédemment attribuée ;

• wrap (True par défaut):

  • True : si un mot empiète sur la limite droite de l’afficheur, il sera affiché sur la ligne suivante,
  • False : si un mot empiète sur la limite droite de l’afficheur, il sera tronqué,
  • None : pas de modification de la valeur précédemment attribuée.

Exemple :

# L’instruction suivante active le retour à la ligne et le défilement vertical
w_lib.set_clip(False, False, True)

# L’instruction suivante affecte les paramètres actuels aux variables "a", "b" et "c" (tupple)
a, b, c = w_lib.set_clip()

tabsize(value=None) fixe la largeur de la tabulation en nombre d’espaces dans la police en cours. Si le paramètre saisi est un nombre entier, celui-ci représente le nombre d’espaces (4 par défaut). Si None ou pas d’argument, la méthode renvoie la valeur actuelle de la tabulation.

Exemple :

# La ligne suivante fixe la tabulation à deux espaces
w_lib.tabsize(2)

# Après exécution d’une des instructions suivantes, "tab" vaudra "2"
tab = w_lib.tabsize()
# ou
tab = w_lib.tabsize(None)

Cette fonction, bien qu’à priori de peu d’intérêt pratique sur notre petit écran, peut trouver à s’exprimer sur des écrans plus grands, notamment pour la réalisation de menus.

Je vous propose le code ci-dessous afin de vérifier que vos installations se sont bien passées.

Ce code fonctionnera indifféremment avec les microcontrôleurs ESP8266EX ou ESP32 en optant pour l’instanciation correspondant à votre matériel, c’est-à-dire en commentant la ligne inutile entre les deux lignes suivantes :

i2c = I2C(0, scl=Pin(22), sda=Pin(21), freq=400000) #ESP32
i2c = I2C(scl=Pin(5), sda=Pin(4)) # ESP8266EX

Le choix entre ces deux polices se fera en suivant la même méthode que ci-dessus, à savoir commenter l’une des deux lignes suivantes :

import digits_35 as dig35_50
import digits_50 as dig35_50

Les deux polices étant importées sous le même nom, dig35_50, il n’y aura pas d’autre modification à effectuer dans le code.

L’importation des polices sous le même nom permet, en basculant simplement de l’une à l’autre, de mettre en évidence l’intérêt de l’utilisation des fonctions max_width() et height() fournies par la police bitmap plutôt que de coder les valeurs correspondantes en dur. Quelle que soit la police utilisée, dans les limites permises par le matériel, l’affichage sera centré correctement sans qu’il y ait de modification à effectuer dans le code.

# Ce code est utilisable sur les microcontrôleurs de type ESP8266 et ESP32. 
# Seules les entrées/sorties GPIO diffèrent, et il vous suffira de commenter
# la ligne inutile. Vous pourrez également choisir la police à utiliser en
# commentant la ligne que vous n'utiliserez pas.

from machine import Pin, I2C
import time
from ssd1306 import SSD1306_I2C
from writer import Writer
#import digits_35 as dig35_50
import digits_50 as dig35_50

#i2c = I2C(0, scl=Pin(22), sda=Pin(21), freq=400000)
i2c = I2C(scl=Pin(5), sda=Pin(4))

WIDTH = const(128)
HEIGHT = const(64)
oled = SSD1306_I2C(WIDTH, HEIGHT, i2c)

w = Writer(oled, dig35_50)

largeur = dig35_50.max_width()  # Utilisation de deux des fonctions fournies par
hauteur = dig35_50.height()     # la police bitmap
ligne = (HEIGHT - hauteur) // 2
colonne = (WIDTH - largeur) // 2

for i in range(9, -1, -1):
    oled.fill(0)
    Writer.set_textpos(oled, ligne, colonne)
    w.printstring(str(i))
    oled.show()
    time.sleep(0.5)

while True:  # Clignotement
    oled.contrast(0)
    time.sleep(0.5)
    oled.contrast(255)
    time.sleep(0.5)

from writer import Writer

pyboard.PyboardError: exception
In file "", line 1, \r\nMemoryError: memory a\r\n')

Le fichier exemple.py ainsi que les polices digits_35 et digits_50 se trouvent dans l’archive proposée au téléchargement dans le chapitre VIII. ApplicationApplication.

mpy-cross est un utilitaire destiné à pré-compiler un fichier MicroPython avant de l’utiliser sur le microcontrôleur (ou ailleurs). L’intérêt de cette pratique est essentiellement de diminuer la charge de travail de l’interpréteur MicroPython, et, du même coup, d’économiser la RAM, limitée sur certains matériels. Si ce n’est pas crucial avec un ESP32, par exemple, ça l’est pour un ESP8266. Donc, en fonction du microcontrôleur que vous utilisez, et de votre application bien entendu, vous pourrez ou non vous passer de cet outil.

Un autre avantage du fichier mpy réside dans le fait qu’il est nettement plus petit que le fichier py dont il est issu. Compte tenu du type d’application développé pour les microcontrôleurs ciblés, la mémoire flash qui équipe ce type de matériel est généralement largement suffisante pour les scripts MicroPython, mais pour des applications susceptibles d’utiliser des images, par exemple, comme des serveurs web, ça peut être un plus. En outre, cette pratique permet de gagner du temps lors du téléversement. mpy-cross fonctionne à partir de Python v3.8 jusqu’à Python v4.0 (ce dernier n’étant pas inclus).

Les fichiers mpy n’ont malheureusement pas que des avantages et présentent deux inconvénients qu’il faut considérer :

1. Ce sont des fichiers binaires : en tant que tels, ils ne sont pas éditables ;
2. Ils doivent être compatibles avec la révision de Micropython installée sur le microcontrôleur, ce qui fait que je n’en fournis pas dans l’archive : il y a très peu de chance pour qu’il convienne. Ils dépendent de votre environnement logiciel.

Le premier point est un frein à leur utilisation pendant la phase de développement. En effet, pendant cette phase, les fichiers sont susceptibles d’être modifiés fréquemment, ce qui impose des manipulations répétitives, simples mais chronophages, avec les fichiers mpy. Ce format est donc à éviter pendant cette étape, sauf, bien sûr, en cas de manque drastique de RAM. Par contre, les fichiers dont on est sûr qu’ils ne seront pas modifiés, comme des bibliothèques ou des fontes, peuvent sans inconvénient être utilisés sous leur forme compilée.

Le second point impose de connaître la révision de MicroPython installée dans le microcontrôleur que l’on va utiliser. Ça paraît trivial, mais quand on utilise plusieurs microcontrôleurs flashés à des périodes différentes avec des firmwares différents, on peut avoir des doutes. Cela dit, un petit script permettant d’afficher la version requise du mpy dans la console va nous permettre de lever cette incertitude. Les critères de compatibilité entre la version du fichier mpy utilisé et la révision de MicroPython qui va l’utiliser sont résumés dans le tableau suivant (voir Documentation MicroPython) :

mpy-cross est un utilitaire en ligne de commande. Vous devez donc ouvrir une console. Pour faire simple, ouvrez cette console dans le dossier contenant le fichier à compiler : ça évite d’avoir à saisir le chemin. Comme mpy-cross est dans le path, vous pouvez l’invoquer directement en exécutant :

mpy-cross

Évidemment, sans argument, on se doute qu’il ne va pas se passer grand-chose. L’utilitaire va malgré tout nous retourner no input file pour nous dire qu’il manque quelque chose, à savoir un fichier.

Qu’à cela ne tienne, on va lui fournir un fichier (MicroPython de préférence) :

mpy-cross script.py

Si tout se passe bien, le fichier script.mpy est généré et aucun message n’est retourné dans la console. Donc tout est pour le mieux dans le meilleur des mondes, à une petite exception près : qu’en est-il de la version du fichier mpy généré. Souvenez-vous qu’il doit y avoir adéquation entre la version du fichier mpy et la révision de MicroPython installée sur le microcontrôleur ciblé.

Sans autre argument, cela dépend de la version de mpy-cross installée. Jusqu’au 22 juin 2024, quand vous installiez la dernière version de mpy-cross, celui-ci n’était compatible qu’avec la dernière révision de MicroPython. Si vous vouliez compiler des fichiers pour une autre révision de MicroPython, il fallait installer la version adéquate de mpy-cross. À présent, à partir de la version mpy-cross 1.23.0.post2, on peut paramétrer mpy-cross pour qu’il génère la version voulue de fichier mpy. C’est nettement plus souple et si vous possédez une ou plusieurs des anciennes versions (comme moi), vous avez tout à gagner à effectuer une mise à jour vers cette nouvelle version.

Reste à déterminer la version de MicroPython embarquée sur le microcontrôleur, du moins si vous avez un doute. Je vous propose le script suivant :

import sys
sys_mpy = sys.implementation._mpy
arch = [None, 'x86', 'x64',
    'armv6', 'armv6m', 'armv7m', 'armv7em', 'armv7emsp', 'armv7emdp',
    'xtensa', 'xtensawin', 'rv32imc'][sys_mpy >> 10]
print('mpy version:', sys_mpy & 0xff)
print('mpy sub-version:', sys_mpy >> 8 & 3)
print('mpy flags:', end='')
if arch:
    print(' -march=' + arch, end='')
print()
a = sys.implementation[1]
print("MicroPython release " + str(a[0]) + "." + str(a[1]) +"." + str(a[2]))

issu de la documentation de MicroPython, qui donne la version et la sous-version des mpy compatibles ainsi que le type de processeur utilisé, auquel j’ai ajouté les deux dernières lignes pour afficher également la révision de MicroPython.

Sauvegardez le script ci-dessus dans un fichier que vous nommerez par exemple sys_mpy.py (ou utilisez directement le fichier fourni dans l’archive) puis faites exécuter ce fichier par votre microcontrôleur. Avec mpremote, la ligne de commande sera :

mpremote u0 run sys_mpy.py

Voici, par exemple, les résultats avec trois versions différentes de MicroPython :

• version 1.22.2 :

  

• version 1.23 :

  

• version 1.25 :

En se référant au tableau, on vérifie que la version mpy 6.2 correspond bien à la révision 1.22.x de MicroPython et que la version mpy 6.3 correspond bien aux révisions 1.23 et 1.25 de MicroPython.

mpy-cross offre deux possibilités pour générer le bytecode, à savoir :

• en fonction de la révision de MicroPython :

mpy-cross --compat 1.22.2 script.py

• en fonction de la version du fichier mpy à générer :

mpy-cross --bytecode 6.2 script.py