Piloter Arduino depuis un PC avec Python et Boa Constructor

Le fait de n’avoir pas besoin d’inclure la bibliothèque Serial, puisqu’elle l’est d’origine, ne nous exonère pas d’avoir à initialiser la liaison série. Ceci va se passer dans la zone de setup() et les lignes suivantes vont s’en charger :

Serial.begin(115200); // Initialise le port série à 115 200 Bd
Serial.flush(); // On vide le tampon de réception par précaution

Avec les matériels actuels, l’utilisation du port série à 115 200Bd ne pose aucun problème. Il ne faudra pas oublier de répercuter cette valeur sur le moniteur série sous peine d’avoir des dysfonctionnements.

L’instruction destinée à vider le tampon peut être omise ici. C’est normalement sans conséquence. Comme ça ne coûte rien d’être prudent, et à moins de manquer de place mémoire, laissez-la.

Deux instructions fournies par la bibliothèque Serial vont nous permettre de réceptionner les données. Celles-ci arrivent sur le port série sous forme d’octets, lesquels sont stockés dans un tampon pour permettre leur récupération à fin de traitement. Le tampon peut stocker jusqu’à 64 octets. Même si cela peut sembler faible au regard des données que nous sommes habitués à manipuler, ça devrait suffire pour le type d’application que nous sommes censés développer sur cette plateforme.

L’instruction :

Serial.read();

renvoie l’octet se trouvant en « sortie » de tampon et le supprime de celui-ci. On comprend tout de suite que faire appel à cette instruction autant de fois qu’il y aura d’octets dans le tampon permettra d’en récupérer la totalité, sous forme de nombres entiers, tout en le vidant.

Cet octet peut représenter différentes choses. Comme le message reçu est censé représenter une chaîne de caractères, il faudra bien sûr convertir cet octet en caractère pour construire la chaîne. Cette conversion sera assurée par la fonction char(octet) qui retourne le caractère codé par l’octet passé en argument.

L’instruction :

Serial.available()

retourne le nombre d’octets présents dans le tampon. Cette instruction va nous permettre d’utiliser l’instruction précédente dans une boucle pour récupérer le contenu exact du tampon.

Voici à quoi va ressembler cette boucle :

while (Serial.available() > 0)
{
  reception = Serial.read();
  commande += char(reception);
  delay(1);
}

Notez l’usage des accolades ouvrante et fermante { }. Elles servent en C/C++, langage sur lequel est basé le langage Arduino, à délimiter un bloc d’instructions. Ici, par exemple, la boucle while() exécute les trois instructions comprises entre les accolades tant que le critère « il reste un octet dans le tampon » est respecté. S’il n’y avait pas de délimiteur de bloc d’instructions, while() ne porterait que sur l’instruction placée immédiatement après, c’est-à-dire jusqu’au premier point-virgule suivant. Donc, ici, while() portera sur les instructions comprises entre la première accolade ouvrante qui le suit et la première accolade fermante de même niveau. Il peut en effet y avoir d’autres blocs d’instructions à l’intérieur d’un bloc, chacun délimité également par une accolade ouvrante et une accolade fermante de son niveau.

Cette boucle doit impérativement se trouver dans la boucle principale void loop(), qui contient le corps du programme, et qui est parcourue séquentiellement en permanence. Le programme peut provoquer une rupture de séquence pour effectuer un traitement particulier, comme une boucle while() par exemple. Quand ce traitement est terminé, la séquence reprend depuis l’endroit où elle avait été quittée.

À chaque boucle du programme principal, la ligne while (Serial.available() > 0) sera exécutée, et si le test indique la réception d’un message (au moins un octet dans le tampon), les instructions qui suivent seront à leur tour exécutées afin de transférer ce message dans la variable commande, pour pouvoir l’utiliser par la suite, et le tampon sera vidé. C’est la détection du tampon vide qui met fin à la boucle. Cerise sur le gâteau, le tampon étant vide, il peut accepter un nouveau message.

Si vous avez bien suivi, vous avez peut-être remarqué une « anomalie » dans la ligne while (Serial.available() > 0) : elle ne se termine pas par ;, contrairement à ce que j’ai indiqué plus haut. Eh bien ! en fait, c’est normal, car cette ligne ne constitue pas, à proprement parler, une instruction. C’est une structure de branchement indiquant au programme dans quelles conditions il doit exécuter une instruction (ou un bloc d’instructions).

Bien entendu, les variables reception et commande devront être déclarées en début de programme (dans la zone déclarations) de la manière suivante :

int reception;
String commande = "";  // Chaîne vide

Nous avons vu int plus haut.

String (n’oubliez pas la majuscule) permet de déclarer une chaîne de caractères. En fait, String c’est beaucoup plus que ça, mais ici, nous ne verrons que cet aspect de son utilisation. Je vous invite naturellement à consulter la « référence » du langage Arduino en cliquant sur l’entrée éponyme dans le menu « Aide » de l’EDI. Elle s’affichera dans votre navigateur.

Une chaîne de caractères est délimitée classiquement par les guillemets anglais « " », et donc la chaîne « "" » est une chaîne vide puisqu’il n’y a rien entre les guillemets.

Maintenant que vous avez récupéré le message, il va vous falloir le traiter. Comme je l’ai dit plus haut, le message sera une chaîne de caractères. C’est à vous de décider quelle chaîne vous allez utiliser. Comme il s’agit d’allumer et d’éteindre une LED, je vous propose d’utiliser deux vocables qui, s’ils ne font pas partie du vocabulaire français, ont au moins le mérite d’être quasiment universellement compris (si tant est qu’on puisse réduire l’Univers à la planète Terre) : il s’agit de « on » et « off ».

Vous allez donc devoir tester si la commande reçue est « on », auquel cas vous allumerez la LED, ou « off », et alors il faudra l’éteindre.

Pour ce faire, nous allons utiliser une structure quasiment incontournable en programmation : la structure if…else. Cette structure est une structure de branchement conditionnel, à savoir que, si une condition est réalisée, on fait quelque chose, et si elle ne l’est pas, on fait autre chose (ou rien).

En pseudo-langage, notre code pourrait ressembler à ceci :

si message = on
  on allume la LED
sinon
  on éteint la LED

Vous pourriez m’objecter, à juste titre, que l’on n’a donc pas besoin de « off ». Alors dans ce cas précis, effectivement, il suffit d’envoyer « on » pour allumer la LED, et « n’importe quoi » pour l’éteindre. Mais on va essayer de faire mieux directement, en traitant par exemple la réception d’une commande erronée.

Voici ce que ça pourrait donner en pseudo-langage :

si message = on
  on allume la LED
sinon
  si message = off
    on éteint la LED
  sinon
    on retourne « commande inconnue » au donneur d’ordre

et en langage Arduino :

if (commande == "on")
{
  digitalWrite(led, HIGH);
}
  else if (commande == "off")
  {
    digitalWrite(led, LOW);
  }
    else
  {
    // Traitement de la commande inconnue.  
  }

Nous verrons le « traitement de la commande inconnue » un peu plus loin.

Outre le branchement conditionnel, vous découvrez ici un nouveau symbole : == (deux signes « égal » accolés). Ce symbole permet de comparer deux éléments pour en vérifier l’égalité.

Il s’agit là de bien comprendre la différence entre une « affectation » et une « comparaison » :

• =, symbole d’affectation. Syntaxe : variable = valeur, valeur devant être du même type que variable. Une fois que cette affectation est exécutée, variable vaudra valeur, et toute référence à cette variable équivaudra à faire référence à cette valeur.
  L’affectation modifie la valeur de la variable ;
• ==, symbole de comparaison. Syntaxe : (argument1 == argument2). Cette expression est de type boolean (booléen en français) et vaut TRUE (vrai) si les deux arguments sont égaux, et FALSE (faux) dans le cas contraire. argument1 et argument2 doivent être de même type.
  La comparaison ne modifie pas la valeur des éléments comparés.

Pour donner un petit exemple, après :

int var;

…

var = 5;

l’expression :

(var == 5)

sera vraie, alors que l’expression :

(var == 3)

sera fausse.

Voici à quoi ressemble notre programme à présent :

/* Ne pas hésiter à donner ici des renseignements sur le programme qui suit,
à la fois pour vous et pour d’éventuels utilisateurs.
*/

const int led = 13;

int reception;
String commande = "";

void setup()
{
  pinMode(led, OUTPUT);
  Serial.begin(115200);
  Serial.flush();
}

void loop()
{
  while (Serial.available() > 0)
  {
    reception = Serial.read();
    commande += char(reception);
    delay(5);
  }
  if (commande == "on")
  {
    digitalWrite(led, HIGH);
  }
  else if (commande == "off")
  {
    digitalWrite(led, LOW);
  }
    else
  {
    // Traitement de la commande inconnue.
  }
}

À priori, ça devrait fonctionner !

Copiez ce code dans l’EDI Arduino et téléversez le sketch. Les LED TX et RX vont clignoter, ce qui est bon signe, et la zone de notification devrait vous afficher « avrdude done. Thank you. » en orange sur fond noir, signe que tout s’est bien passé.

Cliquez sur le bouton en haut à droite de l’EDI pour ouvrir le moniteur série. Vérifiez en bas du moniteur que vous êtes en mode « Pas de fin de ligne », et que le débit est bien réglé sur 115 200 Bds.

Dans la zone de saisie, saisissez « on » et cliquez sur « Envoyer » ou appuyez sur « Entrée ».

Victoire : la LED s’allume.

Ne vous arrêtez pas en si bon chemin et réitérez la manipulation, mais en saisissant « off », cette fois-ci.

Et paf : plus victoire. Tout s’effondre autour de vous. La LED ne s’éteint pas. Que se passe-t-il ?

Le problème ne vient pas de la réception de la commande puisque la LED s’allume quand on envoie « on ». Quant aux branchements conditionnels, ils sont tout ce qu’il y a de simple et une erreur à ce niveau semble exclue.

La seule chose qui a changé entre l’envoi de « on » et l’envoi de « off » est la variable commande. Suivons son parcours. À la réception du premier message, à savoir « on », la variable commande, initialisée comme chaîne vide lors de sa déclaration, est utilisée dans la boucle while() pour stocker le dit message. En sortie de boucle, commande vaut « on ». On traite la commande, ce qui conduit à l’allumage de la LED puisque la comparaison (commande == "on") vaut TRUE. Jusque-là tout va bien.

À réception du second message, c’est-à-dire « off », commande est à nouveau utilisée dans la boucle while() pour récupérer ce nouveau message. Mais commande n’est plus une chaîne vide ! commande vaut « on » ! Ce qui fait qu’après son utilisation par la boucle while(), commande vaut « onoff ». Le nouveau message a simplement été ajouté au précédent. Et donc, la comparaison (commande == "off") vaut FALSE puisque « onoff » est à l’évidence différent de « off » : La LED ne sera donc pas éteinte. L’erreur vient de là. Il ne faut pas oublier de réinitialiser la variable commande.

Voici le code retouché :

/* Ne pas hésiter à donner ici des renseignements sur le programme qui suit,
à la fois pour vous et pour d’éventuels utilisateurs.
*/

const int led = 13;

int reception;
String commande = "";

void setup()
{
  pinMode(led, OUTPUT);
  Serial.begin(115200);
  Serial.flush();
}

void loop()
{
  while (Serial.available() > 0)
  {
    reception = Serial.read();
    commande += char(reception);
    delay(5);
  }
  if (commande == "on")
  {
    digitalWrite(led, HIGH);
  }
  else if (commande == "off")
  {
    digitalWrite(led, LOW);
  }
    else
  {
    // Traitement de la commande inconnue.
  }
  commande = "";
}

Ouvrez le moniteur série de l’EDI et saisissez successivement « on » et « off ». La LED s’allume et s’éteint : tout va bien.

Vous allez à présent modifier ce code pour le rendre à la fois plus lisible et plus facile à manipuler en déplaçant la partie chargée du traitement de la commande dans une fonction que l’on va appeler traitement(), faisons simple, et en invoquant cette fonction dans le programme principal void loop(). Voici le code :

/* Ne pas hésiter à donner ici des renseignements sur le programme qui suit,
à la fois pour vous et pour d’éventuels utilisateurs.
*/

const int led = 13;

int reception;
String commande = "";

void setup()
{
  pinMode(led, OUTPUT);
  Serial.begin(115200);
  Serial.flush();
}

void loop()
{
  while (Serial.available() > 0)
  {
    reception = Serial.read();
    commande += char(reception);
    delay(5);
  }
  traitement();  // Appel de la fonction
}

// Fonctions

void traitement()  // Fonction de traitement de la commande
{
  if (commande == "on")
  {
    digitalWrite(led, HIGH);
  }
  else if (commande == "off")
  {
    digitalWrite(led, LOW);
  }
    else
  {
    // Traitement de la commande inconnue.
  }
  commande = "";
}

La déclaration de la fonction commence par le mot clé void (vide en anglais), car la fonction ne retourne rien. Donc, en toute rigueur, ce n’est pas une fonction. L’appellation « procédure » serait plus indiquée, mais bon ! Son nom est traitement() selon notre choix et les parenthèses sont vides, car elle n’attend pas de paramètre. Le code de cette fonction commence par une accolade ouvrante et se termine par une accolade fermante, lesquelles délimitent un bloc d’instructions qui lui-même peut être composé de plusieurs blocs d’instructions, etc.

Cette déclaration se situe en dehors de la boucle principale void loop(), et vous pouvez déclarer autant de fonctions que vous le désirez, la seule limite étant la taille de la mémoire dont vous disposez.

Ce code, s’il fonctionne, n’est pas satisfaisant.

En premier lieu, examinons le programme principal :

Ce programme, à savoir ce qui se trouve dans la boucle void loop(), nous sommes d’accord, va être parcouru séquentiellement, en première approximation, du début jusqu’à la fin, et va boucler, c’est-à-dire se répéter, tant que votre Arduino sera alimenté en électricité. Donc, à chaque passage, dont la fréquence dépend de la charge de votre programme, le test de réception (notre boucle while()) va être effectué, ce qui est parfait puisqu’on n’a à priori aucun autre moyen de savoir quand une commande va être reçue. C’est le moyen le plus simple (voire le seul) pour « rester à l’écoute ».

Par contre, et là, c’est moins bien, la fonction traitement() va également être appelée à la même fréquence, mais sans aucun intérêt tant qu’une nouvelle commande nécessitant une actualisation de l’état de la LED n’aura pas été reçue. Dans l’état actuel du programme, cela n’a aucune incidence, mais nous verrons un peu plus loin que ce n’est pas toujours le cas.

Il va donc falloir trouver un moyen pour ne permettre l’appel à cette fonction que quand c’est utile, à savoir à la réception d’un message.

En second lieu, il serait souhaitable de mettre le donneur d’ordre au courant de la bonne (ou mauvaise) exécution de ses consignes. Bien sûr, dans le cas présent, vous êtes devant votre ordinateur, la carte Arduino est entre votre clavier et votre écran (c’est du moins mon cas), et vous voyez immédiatement le résultat de votre commande. Mais dans la « vraie vie », le résultat de votre commande ne sera pas forcément visible immédiatement, et vous voudriez peut-être bien être malgré tout informé du bon déroulement des opérations.

Un retour d’information de l’Arduino vers le PC sera donc le bien venu, et, par conséquent, il va falloir l’implémenter.

Eh bien ! nous allons justement commencer par cette implémentation, car cela va nous permettre de mettre en évidence la nécessité de n’autoriser l’appel à la fonction traitement() que lorsque c’est nécessaire.

Vous avez vu un peu plus haut l’utilisation de la bibliothèque Serial pour recevoir une chaîne de caractères au travers de la liaison série (USB). Vous allez voir maintenant son utilisation pour l’envoi d’une chaîne de caractères. Comme au lieu de « lire », vous devez « écrire », au lieu de read() vous utiliserez print() ou println(), selon que vous souhaitez que les écritures successives se fassent sur une même ligne ou chacune sur une nouvelle ligne. Pas compliqué !

Voici l’instruction à utiliser :

Serial.print("texte");

ou

Serial.println("texte");

où « texte » représente la chaîne de caractères que vous voulez envoyer.

Maintenant, on pourrait être tenté d’envoyer le message dans le même bloc d’instructions que celui qui code pour l’actualisation de la LED. Par exemple :

  if (commande == "on")
  {
    digitalWrite(led, HIGH);
    Serial.println("ledOn");
  }

en imaginant qu’on va envoyer le message « ledOn » pour indiquer que la LED est allumée, ce qui n’est pas absurde.

Mais quelle est la valeur de cette information ? Bon ! Elle n’est pas nulle, mais elle indique seulement que la commande a bien été transmise. C’est déjà ça, me direz-vous, mais on peut faire mieux. Nous allons tester l’état de la broche concernée, et si cette broche est à l’état haut (HIGH), on enverra « ledOn », et dans le cas contraire on enverra « ledOff ».

Vous allez me dire qu’après l’instruction digitalWrite(led, HIGH); , si la broche n’est pas à l’état haut, c’est que la carte Arduino UNO a un sérieux problème, et c’est tout à fait vrai. Les deux informations auront ici la même valeur. Mais dans le cadre d’une application réelle, ce n’est bien sûr pas l’état de la broche de commande que vous allez tester, mais, par exemple, l’état d’une autre broche, reliée à un capteur lié au matériel piloté par la broche de commande. Au niveau de l’exercice, cela revient exactement au même.

Vous allez donc compléter la fonction traitement() comme suit :

void traitement()  // Fonction de traitement de la commande
{
  if (commande == "on")
  {
    digitalWrite(led, HIGH);
  }
  else if (commande == "off")
  {
    digitalWrite(led, LOW);
  }
    else
  {
    // Traitement de la commande inconnue.
  }
  commande = "";
  if (digitalRead(led) == HIGH)
  {
    Serial.println("ledOn");
  }
  else
  {
    Serial.println("ledOff");
  }
}

Vous remarquerez la nouvelle instruction digitalRead(numBroche) qui renvoie HIGH si la broche passée en argument est à l’état haut, et LOW dans le cas contraire.

Téléversez ce sketch sur votre carte. Ouvrez le moniteur série, et constatez le défilement de « ledOff ». Saisissez « on » : la LED va s’allumer, signe que ça fonctionne, et le moniteur affiche maintenant un défilement de « ledOn ».

Pourquoi ce défilement : tout simplement parce que la fonction « traitement() » est appelée à chaque boucle du programme principal, et elle envoie à chaque fois sur la liaison série le compte rendu de l’état de la LED, au lieu de l’envoyer uniquement lors d’un changement d’état. Vous pouvez constater que la LED TX de votre carte Arduino UNO est allumée en permanence (en réalité elle clignote très vite) car la carte envoie en permanence des données vers le PC. Et donc, comme vu plus haut, il faut trouver un moyen pour n’appeler cette fonction que lorsqu’un nouveau message est reçu.

La solution est extrêmement simple. Il suffit d’utiliser le branchement conditionnel suivant :

if (commande != "")
{
  traitement();
}

L’opérateur de comparaison != signifie « différent de », et donc ce code signifie :

• si commande est différent dune chaîne vide, c’est-à-dire si on a reçu un message, on exécute la fonction traitement() ;
• comme on n’a rien de spécifique à faire dans le cas contraire, il n’y a pas de clause else.

Ce qui nous donne :

/* Ne pas hésiter à donner ici des renseignements sur le programme qui suit,
à la fois pour vous et pour d’éventuels utilisateurs.
*/

const int led = 13;

int reception;
String commande = "";

void setup()
{
  pinMode(led, OUTPUT);
  Serial.begin(115200);
  Serial.flush();
}

void loop()
{
  while (Serial.available() > 0)
  {
    reception = Serial.read();
    commande += char(reception);
    delay(5);
  }
  if (commande != "")
  {
    traitement(); // Appel de la fonction
  }
}

// Fonctions

void traitement() // Fonction de traitement de la commande
{
  if (commande == "on")
  {
    digitalWrite(led, HIGH);
  }
  else if (commande == "off")
  {
    digitalWrite(led, LOW);
  }
    else
  {
    // Traitement de la commande inconnue.
  }
  commande = "";
  if (digitalRead(led) == HIGH)
  {
    Serial.println("ledOn");
  }
  else
  {
    Serial.println("ledOff");
  }
}

Lancez le moniteur série et entrez « on », « off » et « toto » à plusieurs reprises dans un ordre quelconque et regardez ce qui se passe :

• Quand vous saisissez « on », la LED s’allume et le message « ledOn » s’affiche une seule fois.
• Quand vous saisissez « off », la LED s’éteint et le message « ledOff » s’affiche une seule fois.
• Quand vous saisissez « toto » ou quoi que ce soit de différent de « on » et « off », il n’y a pas de modification de l’état de la LED, et le message affiche l’état inchangé de la LED une seule fois.
• Entre deux commandes, la liaison série est inactive, ce qui était le but à atteindre.

Il ne nous reste plus qu’à traiter le cas de la commande inconnue.

On va se contenter ici d’envoyer un message indiquant que la commande reçue est inconnue en saisissant dans la clause else prévue à cet effet :

Serial.print("Commande '" + commande + "' inconnue : ");

L’instruction Serial.print() fait la même chose que Serial.println(), mais ne provoque pas de « retour chariot » ou « saut de ligne », ce qui fait que la chaîne reçue suivante sera affichée sur la même ligne. Cette différence sera à l’origine d’un petit problème quand nous réaliserons l’interface graphique avec Boa Constructor, mais elle va nous permettre ici d’obtenir l’affichage voulu.

Notez la différence entre l’instruction Serial.print("Commande"), qui affichera la chaîne « Commande », et l’instruction Serial.print(commande) qui affichera « le contenu de la variable commande ».

Notez également la concaténation (assemblage) des chaînes obtenue à l’aide de l’opérateur +.

Voici votre sketch finalisé :

/* Ne pas hésiter à donner ici des renseignements sur le programme qui suit,
à la fois pour vous et pour d’éventuels utilisateurs.
*/

const int led = 13;

int reception;
String commande = "";

void setup()
{
  pinMode(led, OUTPUT);
  Serial.begin(115200);
  Serial.flush();
}

void loop()
{
  while (Serial.available() > 0)
  {
    reception = Serial.read();
    commande += char(reception);
    delay(5);
  }
  if (commande != "")
  {
    traitement(); // Appel de la fonction
  }
}

// Fonctions

void traitement() // Fonction de traitement de la commande
{
  if (commande == "on")
  {
    digitalWrite(led, HIGH);
  }
  else if (commande == "off")
  {
    digitalWrite(led, LOW);
  }
    else
  {
    Serial.print("Commande '" + commande + "' inconnue : ");// Traitement de la commande inconnue.
  }
  commande = "";
  if (digitalRead(led) == HIGH)
  {
    Serial.println("ledOn");
  }
  else
  {
    Serial.println("ledOff");
  }
}

Téléversez-le, lancez le moniteur série et testez.

Par exemple, la saisie successive de « on », « off », « toto », « on » et « toto » doit vous donner ce qui suit :

Votre sketch est opérationnel, à savoir qu’il fait ce qu’on lui demande de faire, et ce n’est déjà pas si mal. Il va vous permettre maintenant d’écrire et de tester votre script Python.

Comme pour le programme Arduino, nous aurons besoin d’une bibliothèque gérant la liaison série (USB). Cette bibliothèque s’appelle pySerial. Comme celle-ci ne fait pas partie intégrante du langage, ce qui est logique, car vous n’en avez pas forcément besoin, il va falloir l’importer. Contrairement à la clause include du langage Arduino, la clause équivalente du langage Python, import, ne doit pas nécessairement être invoquée au début du programme. Le seul impératif est qu’elle soit invoquée avant que la bibliothèque à laquelle elle fait référence soit utilisée.

Cette invocation se fait tout simplement de la manière suivante :

import serial

Comme pour le programme Arduino, et pour les mêmes raisons, nous aurons besoin d’une temporisation, et pour la mettre en place, nous devrons importer la bibliothèque dédiée à la « gestion du temps ». Cette bibliothèque s’appelle time. Elle est installée en standard avec Python, et est donc immédiatement disponible : vous n’aurez pas besoin de la télécharger.

Il peut sembler « lourd » d’avoir à importer des bibliothèques pour un oui ou pour un non, mais cela permet une meilleure gestion de l’encombrement mémoire. On peut même affiner en n’important d’une bibliothèque que ce qu’on veut utiliser. L’inconvénient de l’utilisation de bibliothèques non fournies en standard est que vous ne saurez pas toujours si elles sont présentes sur le système cible. Vous devrez donc les fournir avec le script, sous peine de voir échouer le démarrage du programme.

Notre script commencera donc comme suit :

#!/usr/bin/python
# coding: utf8

import serial
import time

Comme avec Arduino, vous devrez établir une liaison série. IL va cependant y avoir quelques différences dans la façon de procéder.

L’établissement de la liaison série consiste à créer une « instance » de l’objet serial, qui va vous fournir des « méthodes » et des « propriétés » pour exploiter le port série que vous allez utiliser, puis à ouvrir le port concerné.

Pour créer cette instance, vous avez besoin d’au moins trois informations.

VII-B-2-a. Nommage de l’instance▲

VII-B-2-b. Identifiant système du port▲

ls /dev/tty*

ls /dev/ttyACM*

VII-B-2-c. Vitesse de transmission des données.▲

VII-B-2-d. Initialisation▲

portCom = serial.Serial("/dev/ttyACM0", 115200)

portCom = serial.Serial()
portCom.port = "/dev/ttyACM0"
portCom.baudrate = 115200

portCom.propriété
portCom.méthode

VII-B-2-e. Ouverture du port▲

portCom.open()

Maintenant que la liaison série est opérationnelle, on va pouvoir l’exploiter. Pour allumer et éteindre la LED, la carte Arduino UNO « attend » la réception de la chaîne « on » ou de la chaîne « off » : vous avez expérimenté cela précédemment dans ce tutoriel, en utilisant le moniteur série de l’EDI Arduino. Eh bien ! vous allez faire la même chose, mais à partir d’une console standard.

Dans la mesure où vous devez envoyer une chaîne de caractères, il vous faut une « zone de saisie ». Dans une console, il n’y a pas, à proprement parler de zone de saisie, comme celles que l’on trouve dans les applications graphiques. Elle sera remplacée par un texte expliquant ce qu’on attend de l’utilisateur, suivi de la classique « invite de commande » (ou prompt), matérialisée assez souvent par un rectangle plein clignotant (mais ça peut dépendre du paramétrage de votre console). À la suite de ce prompt, vous saisirez « on » ou « off » puis presserez la touche « Entrée », comme vous l’auriez fait avec le moniteur série Arduino.

Comment réaliser ceci ? Le plus simplement du monde, en utilisant une instruction Python dédiée à l’entrée de chaînes de caractères (string) en mode console. Voici cette instruction :

chaine = raw_input(texte)

où « chaine » représente la variable qui recevra la chaîne que vous aurez saisie, et « texte » la chaîne explicative affichée avant le prompt. Cette instruction est bloquante, c’est-à-dire que, tant que vous n’aurez pas appuyé sur la touche entrée, il ne se passera rien.

La ligne de code suivante fera très bien l’affaire :

commande = raw_input("Entrez une commande : ")

qui permettra de stocker dans la variable « commande » le texte que vous aurez saisi.

Maintenant, cette commande, il vous faut l’envoyer. La bibliothèque serial fournit la méthode serial.write() pour réaliser cela en toute simplicité. Cette méthode, une fonction, prend les données à envoyer comme paramètre, ici une chaîne de caractères (string), mais plus généralement des octets ou des tableaux d’octets, et retourne le nombre d’octets envoyés, à des fins de contrôle par exemple, fonctionnalité que nous n’utiliserons pas dans ce tutoriel.

Voici comment se présentera cette instruction dans notre script :

portCom.write(commande)

Le corps du programme, très simple ici, sera donc composé de ces deux lignes :

commande = raw_input("Entrez une commande : ")
portCom.write(commande)

Nous pouvons d’ores et déjà, avec ce que nous venons de voir, écrire le script suivant :

#!/usr/bin/python
# coding: utf8

import serial
import time

portCom = serial.Serial()
portCom.port = "/dev/ttyACM0"
portCom.baudrate = 115200

portCom.open()

commande = raw_input("Entrez une commande : ")
portCom.write(commande)

Je vous propose de le copier dans un fichier que vous nommerez comme bon vous semblera, et que je nommerai pour ma part « test-serial_1.py ».

Sauvegardez ce fichier et modifiez ses permissions pour le rendre exécutable, par exemple en entrant cette ligne dans un terminal :

chmod +x test-serial_1.py

Maintenant, lancez l’exécution du script. Si vous avez « tout bien fait comme je vous ai dit », vous devriez avoir quelque chose comme ça :

Saisissez « on », puis appuyez sur « Entrée ». La LED de votre carte s’allume : tout va bien.

Alors, oui et non. Oui, parce que ça fonctionne, et non, parce que la console se ferme, et que, par conséquent, vous vous retrouvez dans l’impossibilité d’envoyer d’autres commandes. La console se ferme, car l’interpréteur arrive en fin de fichier et considère que le programme est terminé, ce qui est techniquement le cas.

Pour pallier ce problème, il faut empêcher l’interpréteur d’arriver en fin de fichier. On va utiliser une méthode très classique : mettre le corps du programme dans une boucle while().

Modifiez votre script comme suit :

#!/usr/bin/python
# coding: utf8

import serial
import time

portCom = serial.Serial()
portCom.port = "/dev/ttyACM0"
portCom.baudrate = 115200

portCom.open()

while True:
  commande = str(raw_input("Entrez une commande : "))
  portCom.write(commande)

Si, jusqu’à présent, les lignes de code saisies n’étaient pas vraiment différentes de ce qu’elles auraient pu être avec un autre langage, mis à part l’absence du « ; » en fin d’instruction, nous abordons ici une caractéristique particulière de la syntaxe Python concernant les blocs d’instructions. La notion de bloc d’instructions n’est, bien sûr, pas spécifique à Python, mais c’est la façon de délimiter ce bloc qui est originale.

En Python, un bloc n’est pas délimité, comme dans beaucoup d’autres langages courants, par les accolades {…} du C, ni par le begin…end; du Pascal, par exemple : il est ouvert par une ligne de code se terminant par « : », et les instructions qui le composent doivent être indentées uniformément par rapport à cette ligne. Le bloc se termine par un retour au niveau de l’indentation de la ligne qui l’a ouvert ou à un niveau inférieur.

Un bloc peut, naturellement, contenir d’autres blocs, chacun respectant la règle ci-dessus, par exemple :

structure-ouvrante-1:        # Début du bloc 1
  instruction-1-1            # Indentation niveau 1
  instruction-1-2
  structure-ouvrante-2:      # Début du bloc 2 (fait partie du bloc 1)
    instruction-2-1          # Indentation niveau 2
    instruction-2-2
    …
    instruction-2-n          # Dernière instruction du bloc 2
  instruction-1-3            # Retour à l’indentation niveau 1 (fin du bloc 2)
  …
  instruction-1-n            # Dernière instruction du bloc 1
suite-du-programme           # Retour à l’indentation niveau 0 (fin du bloc 1)

La structure ouvrante peut être une structure de contrôle de flux comme if ou while, une déclaration de méthode comme def… terminée par « : », ce qui oblige à passer à l’indentation supérieure sous peine de déclencher une erreur. Le bloc 2 est un bloc imbriqué dans le bloc 1. On voit qu’on quitte un bloc d’instructions en revenant à un niveau d’indentation inférieur. Il n’y a pas d’ambiguïté.

Pour ceux qui ont l’habitude d’indenter leur code, ce qui est une pratique conseillée, notamment pour une meilleure lisibilité, cette syntaxe permet de faire l’économie des symboles ouvrant et fermant, quels qu’ils soient, sans changer leurs habitudes. C’est plutôt bien vu.

Ici, notre structure de contrôle est while True:. Cette boucle ne s’arrête jamais, car l’expression True est, à l’évidence, toujours vraie. Le bloc d’instructions concerné par cette boucle est le corps du programme en lui-même, et donc le programme va se répéter indéfiniment. Vous avez peut-être remarqué que while n’était pas suivi de parenthèses. En Python, celles-ci ne sont pas obligatoires. Attention toutefois, elles peuvent être nécessaires dans des expressions complexes pour lever toute ambiguïté.

Collez ce script dans un fichier appelé « test-serial_2.py » et exécutez-le. Cette fois-ci, ça fonctionne de façon satisfaisante, en ce sens que vous êtes à même d’allumer et d’éteindre la LED à votre convenance.

Vous pourriez vous arrêter là. Si votre but est simplement de commander individuellement les éclairages de votre bureau et de piloter le ventilateur, ce script, étendu au nombre de broches utilisées, fera l’affaire, l’allumage d’un spot étant un retour d’information suffisant.

Toutefois, comme on a implémenté le retour d’information dans le sketch Arduino, il serait dommage de ne pas l’utiliser, d’autant qu’en fonction de votre projet, cette fonctionnalité pourrait être indispensable.

Dans un premier temps, et même si ça ne se voit pas, il faut bien être conscient du fait qu’à chaque commande envoyée depuis votre PC, votre carte UNO poste en retour l’information concernant l’état de la LED. Elle ne peut pas faire autrement, le sketch que vous avez écrit pour elle l’impose.

Cette information est disponible dans le tampon de réception de votre port série, simplement votre script actuel ne l’utilise pas, ce qui ne l’empêche pas, bien sûr, de fonctionner. Nous allons remédier à cela.

Retour vers la bibliothèque serial : si elle nous a fourni une méthode pour écrire sur le port série, elle devrait bien nous fournir une méthode pour lire sur ce même port. Eh bien ! oui. Cette méthode existe (heureusement) et s’appelle read(). C’est une fonction qui demande en paramètre le nombre d’octets à lire parmi ceux qui sont présents dans le tampon, et qui retourne les octets lus, qui, ici, représentent une chaîne de caractères, et que l’on va récupérer dans une variable. Si aucun paramètre n’est fourni, cette fonction lira (et donc retournera) par défaut un seul octet à chaque appel.

C’est bien gentil tout ça, mais on ne sait pas forcément combien d’octets se trouvent dans le tampon. Pas de panique, tout (ou presque) est prévu. La bibliothèque serial propose la propriété ad hoc : in_waiting.

Ajoutons dans notre script ces deux lignes :

  nbCar = portCom.in_waiting
  retour = portCom.read(nbCar)

dans lesquelles nbCar est la variable stockant le nombre d’octets présents dans le tampon, et retour la variable stockant la chaîne représentée par ces octets.

Un programme ne faisant jamais que ce qu’on lui demande de faire, il ne faut pas oublier de lui demander d’afficher la chaîne à l’écran, sinon il n’y aura rien de fait. Pour ce faire, l’instruction Python print() est ce qu’il nous faut. Dans son utilisation la plus triviale, cette instruction envoie la chaîne passée en argument sur la sortie standard, à savoir l’écran dans notre cas. C’est cette fonctionnalité qui nous intéresse, et qui va s’écrire sous cette forme :

  print(retour)

que vous allez ajouter à votre script.

Voici votre script actuellement :

#!/usr/bin/python
# coding: utf8

import serial
import time

portCom = serial.Serial()
portCom.port = "/dev/ttyACM0"
portCom.baudrate = 115200

portCom.open()

while True:
  commande = raw_input("Entrez une commande : ")
  portCom.write(commande)
  nbCar = portCom.in_waiting
  retour = portCom.read(nbCar)
  print(retour)

Sauvegardez-le sous le nom «test-serial_3.py » par exemple, exécutez-le puis entrez une série de commandes « on » et « off » (pas cinquante, quatre ou cinq suffiront). Vous allez constater le phénomène suivant :

• commande « on » : la LED s’allume mais pas de retour ;
• commande « off » : la LED s’éteint et le retour est « ledOn » ce qui est contraire à la réalité ;
• commande « on » : la LED s’allume et le retour est « ledOff » ce qui est contraire à la réalité ;
• commande « off » : la LED s’éteint et le retour est « ledOn » ce qui est contraire à la réalité ;
• commande « on » : la LED s’allume et le retour est « ledOff » ce qui est contraire à la réalité ;
• …

Inutile d’aller plus loin : vous avez compris qu’il y avait un décalage entre l’état de la LED et le retour d’information concernant cet état. Cela est dû au fait que les opérations effectuées sur le port série ne sont pas instantanées, et que, en l’occurrence, la lecture du tampon intervient avant la réception de l’information.

• À la première commande « on » envoyée, la lecture du tampon se faisant avant la réception de l’information « ledOn », il n’y a rien dedans, et donc rien n’est affiché à l’écran.
• À la commande « off » qui suit, la lecture du tampon se faisant également avant la réception de « ledOff », le problème est le même, mais le tampon n’est plus vide. Il contient le « ledOn » reçu en réponse à la commande précédente, trop tard, certes, en regard du traitement informatique, mais bien avant que vous ayez tapé une nouvelle commande. Donc, c’est « ledOn » qui va s’afficher, alors que la LED est éteinte.
• À la commande « on » qui suit, bis repetita placent, et c’est donc « ledOff » qui va s’afficher alors que la LED est allumée.
• …

La solution consiste à faire une pause entre l’envoi de la commande et le traitement de la réception. Une méthode de la bibliothèque time va nous permettre de faire cela, et c’est pourquoi je vous ai fait importer cette bibliothèque précédemment. La méthode en question est time.sleep(), une procédure à laquelle vous devez fournir un paramètre : la durée du délai souhaité, exprimée en secondes. Cette durée sera fixée à 0,05 s, valeur couramment employée et fonctionnant, à priori, dans tous les cas.

Voici le script finalisé :

#!/usr/bin/python
# coding: utf8

import serial
import time

portCom = serial.Serial()
portCom.port = "/dev/ttyACM0"
portCom.baudrate = 115200

portCom.open()

while True:
  commande = str(raw_input("Entrez une commande : "))
  portCom.write(commande)
  time.sleep(0.05)
  nbCar = portCom.in_waiting
  retour = portCom.read(nbCar)
  print(retour)

Le cahier des charges est respecté, à savoir que ce script réalise ce qu’on faisait avec le moniteur série fourni par l’EDI Arduino, à ceci près que nous sommes ici dans un environnement complet de programmation, et que par conséquent, on n’est plus du tout limité au seul affichage du retour.

L’avantage n’est pas évident au premier abord, étant donné la simplicité de l’exemple, mais le problème est différent si vous avez en retour des données plus complexes et variables à traiter, comme des températures, des débits, des pressions…

Si vous devez adapter les commandes en fonction, par exemple, de l’évolution de ces données ou de leur moyenne, vous comprendrez vite l’intérêt du système, et les 32 Kio de la mémoire flash de la carte Arduino UNO ne seront plus une limite, d’autant que vous pouvez piloter plusieurs cartes, autant que de ports disponibles en fait, et, par exemple, réserver une carte aux capteurs et une autre aux actionneurs.

Bien entendu, dans ce type d’utilisation, nous ne sommes à priori plus sur de l’embarqué, et la carte Arduino devient une interface entre le PC et les entités pilotées. Cela dit, si le PC est un nano-ordinateur, l’embarqué reste d’actualité.

Ce script est très basique : il respecte juste le cahier des charges.

Vous avez pu constater, par exemple, au chapitre VII.B.3, que l’absence du port série empêchait le démarrage du programme. Dans notre cas, ça n’avait pas de réelle importance mais ce n’est pas toujours le cas. Il ne faut pas qu’une erreur à l’exécution interdise l’utilisation du programme : il faut simplement traiter cette erreur.

De plus, pour arrêter ce programme, la seule solution est de fermer la console. Ce type d’arrêt « à la hussarde », s’il est efficace, n’est pas satisfaisant.

Je vous propose donc ce script amélioré, sans pour autant le détailler car cela sort du cadre de ce tutoriel. En vous penchant un peu sur la question, vous devriez comprendre les mécanismes mis en jeu. Je vous propose de jeter un œil ici pour avoir de plus amples renseignements sur l’utilisation de try, quant aux autres modifications, les explications précédentes devraient permettre de les comprendre.

#!/usr/bin/python
# coding: utf8

import serial
import time

print("Initialisation du port")
portCom = serial.Serial()
portCom.port = "/dev/ttyACM0"
portCom.baudrate = 115200

print("Ouverture du port...")
try:
  portCom.open()
except serial.SerialException:
  print(u"Un problème s'est produit à l'ouverture du port.\n"
    "Vérifiez que le port utilisé par la carte Arduino est\n"
    "bien '/dev/ttyACM0'. Si ce n'est pas le cas, modifiez\n"
      "le script Python en conséquence.")
  saisie = ""
  while saisie != "q":
  saisie = str(raw_input("Entrer 'q' pour quitter: "))

while portCom.is_open:
  commande = str(raw_input("Saisir une commande ('q' pour quitter): "))
  if commande != "q":
    portCom.write(commande)    
    time.sleep(0.05)
    nbCar = portCom.in_waiting
    retour = portCom.read(nbCar)
    print(retour)
    portCom.reset_input_buffer()
  else:
    portCom.close()

Sauvegardez ce script dans un fichier et exécutez-le avec et sans la carte Arduino raccordée à votre PC, pour voir ce qui se passe. Ici, le traitement de l’erreur est réduit à l’affichage d’un message, mais dans un cas réel, ce traitement peut, par exemple, vous fournir la possibilité de modifier le port ou ses paramètres, et, d’une manière générale, vous fournir la possibilité de régler le problème sans avoir à quitter le programme, si c’est possible.

Une dernière petite chose avant de clore ce chapitre : nous avons « traîné » depuis le début la ligne # coding: utf8 en tête de script. Je la mets systématiquement, mais jusqu’à présent, il faut bien avouer qu’elle ne servait à rien. Pour ce dernier script, par contre, cette ligne est nécessaire, car nous utilisons des caractères accentués (non ASCII) dans un des messages. Pour vous en persuader, supprimez-la et exécutez le script. Vous déclencherez une erreur.

#!/usr/bin/python
# coding: utf8
from __future__ import unicode literals

La première des choses à faire est donc d’accéder à cette fiche. Rien de plus simple. Si ce n’est déjà fait, sélectionnez l’onglet du fichier sur lequel vous désirez travailler (ici, ComLed) et cliquez sur l’icône de la barre d’outils de l’éditeur. Si ce fichier ne représente pas une fenêtre, par exemple dans le cas où vous auriez créé un module d’utilitaires pour votre programme, cette icône sera absente.

La fiche est identique à la fenêtre de l’application que vous venez de fermer. Alors, quand je dis identique, comme vous pouvez le constater, ce n’est pas tout à fait vrai. Elle comporte en effet un quadrillage qui va servir de repère pour déposer les composants, et qui n’existe qu’au niveau de la maquette, heureusement ! Toutes les modifications que vous apporterez à cette fiche seront répercutées à l’identique dans la fenêtre de l’application. C’est ce qui fait l’intérêt du système.

L’accès à la fiche, donc à l’édition graphique, entraîne le peuplement de l’inspecteur de propriétés avec différents paramètres concernant l’objet sélectionné, ici la fenêtre de l’application. C’est en jouant sur ces paramètres que vous allez personnaliser cette fenêtre :

Je vous propose, dans un premier temps, pour vous échauffer, de modifier les propriétés Name et Title. Il suffira pour ça de cliquer sur la ligne contenant la propriété à modifier, puis de remplacer la valeur sélectionnée par la nouvelle valeur. Modifiez les valeurs pour obtenir ceci :

puis cliquez sur pour valider vos modifications, c’est-à-dire les écrire dans le code, et sur pour les sauvegarder dans le fichier.

Regardez les modifications engendrées sur la fiche, mais également dans le code. Il est important de garder le contact avec ce code, même s’il est généré automatiquement. Il enseigne beaucoup de choses.

Avant de déposer des composants sur la fiche, il convient de préciser ce dont on a besoin. En l’occurrence, nos besoins ne sont pas dispendieux :

• un bouton pour quitter l’application ;
• un bouton pour allumer la LED ;
• un bouton pour éteindre la LED ;
• un voyant pour rendre compte de l’état de la LED.

On pourrait même faire plus simple en utilisant un unique bouton à bascule pour allumer et éteindre la LED. On pourrait également se passer du voyant qui peut ne pas être nécessaire, ainsi que du bouton destiné à quitter l’application, le bouton système de fermeture étant là pour ça. Donc, techniquement, un seul bouton pourrait suffire. Cela dit, il y aura déjà si peu de choses sur la fiche que cette économie de moyens n’a pas de réelle raison d’être. Et puis ceci est un tutoriel. Nous ne cherchons pas forcément l’optimisation à tout prix, quelle qu’elle soit, mais plutôt à utiliser le matériel.

VIII-C-2-a. Sélection et personnalisation des composants ▲

Vous allez donc déposer ces quatre composants sur la fiche.

Dans l’onglet Boutons de la palette de composants, cliquez sur l’icône (wx.lib.buttons.GenButton) puis n’importe où sur la fiche. Répétez cette opération deux fois encore pour avoir trois boutons sur la fiche.

Dans l’onglet Composants de base de la palette de composants, cliquez sur (wx.StaticBitmap) puis quelque part sur la fiche.

Votre maquette devrait avoir un aspect proche de ceci :

Tous ces éléments sont déplaçables et redimensionnables :

• soit à l’aide de la souris ;
• soit en modifiant les paramètres Position et Size dans l’inspecteur de propriétés ;
• soit en utilisant les touches <Maj> ou <Ctrl> conjointement avec les touches fléchées pour modifier respectivement les dimensions ou la position.

Vous pouvez également modifier le texte affiché sur les boutons en modifiant leur propriété Label. Enfin, vous pouvez leur donner un nom explicite, par lequel ils seront connus dans le code, en modifiant leur propriété Name, toujours dans l’inspecteur de propriétés.

Détaillons le processus pour le bouton « genButton1 » :

• sélectionnez le bouton à l’aide de la souris ;

• allez dans l’onglet « Constr » de l’inspecteur de propriétés :

  

• modifiez les propriétés Label et Name comme suit :

  

• cliquez sur puis sur pour réactiver le mode graphique ;

• placez le bouton en haut à gauche de la fiche en faisant un glisser-déposer avec la souris pour obtenir quelque chose comme ça :
  

Répétez ces opérations avec les boutons genButton2 et genButton3 en modifiant leur propriété Label respective en « Éteindre » et « Quitter », et leur propriété Name respective en Eteindre et Quitter. Notez que la valeur de la propriété Name n’est pas une chaîne de caractères mais un nom de variable, et que, comme telle, elle doit respecter les règles de nommage de Python qui, en l’occurrence, interdisent les caractères accentués. Par conséquent, affecter la valeur Éteindre à cette propriété déclencherait une erreur à l’interprétation.

Dans cet exemple, le label et le nom sont (quasiment) identiques, mais ce n’est absolument pas nécessaire. C’est simplement logique et pratique (c’est du moins mon opinion).

Sélectionnez maintenant le composant (wx.StaticBitmap )que vous avez posé sur votre fiche. Ce composant a pour fonction d’afficher une image. Cette image peut provenir de différentes sources et exister sous différents formats. En ce qui nous concerne, nous allons utiliser deux images contenues dans des fichiers PNG (Portable Network Graphics). Ces images étant au format 32 x 32 pixels, nous allons redimensionner ce composant qui, par défaut, est au format 16 x 16 pixels. Retour à l’inspecteur de propriétés :

Cliquez sur le carré bleu en regard de Size, puis paramétrez Height et Width à 32 pixels.

N’oubliez pas de valider vos modifications en cliquant sur .

Déplacez à présent vos composants et redimensionnez la fenêtre pour obtenir quelque chose qui ressemble à ceci :

Cliquez maintenant sur pour enregistrer le fichier, puis sur pour lancer l’application. Peut-être avez-vous oublié de cliquer sur  ? Si la fenêtre de votre application ne reflète pas les derniers changements, ce doit être le cas. Fermez simplement cette fenêtre, validez vos modifications, enregistrez le fichier et relancez le programme : voilà qui est mieux.

Deux constatations s’imposent :

• le composant image a disparu. Alors, en fait non. Simplement, on ne lui a pas encore affecté d’image, et par conséquent il n’affiche rien ;
• de plus, si vous êtes curieux, vous avez pu vous apercevoir que, quand vous cliquez sur un bouton, il ne se passe rien. C’est tout à fait normal, et pour tout dire, rassurant. En effet, il serait pour le moins bizarre que votre application fasse des choses que vous ne lui avez pas demandées de faire : bizarre et inquiétant.

Nous allons donc devoir traiter ces deux points.

Je voudrais avant tout faire une remarque : jusqu’à présent, vous n’avez pas saisi une seule ligne de code, et vous avez déjà la fenêtre définitive, sur le plan interface s’entend, de votre application. Ce n’est quand même pas mal.

Vous m’objecterez que vous avez modifié une ligne de code en bas du script, et ajouté deux lignes d’entête. Certes, mais il s’agit là plus de patchs destinés à combler certaines lacunes de Boa Constructor que de codage à proprement parler. Si vous avez créé le fichier template.py dont je vous ai parlé plus haut, vous n’aurez plus besoin de faire ces retouches, et votre maquette ne demandera réellement plus une ligne de code, du moins si on se contente des composants wxPython fournis par Boa Constructor. Donc, on peut dire que, techniquement, tout ce que vous avez fait pour l’instant, c’est paramétrer quelques composants : point.

Comme je l’ai dit plus haut, il arrive un moment où il faut mettre les mains dans le cambouis.

Par quoi va-t-on commencer ? Par mettre des gants ! Non, ça ne devrait pas être nécessaire ici, du moins si votre clavier est propre. Je vous propose plutôt de nous occuper d’abord du bouton « Quitter ». Comme il sera probablement présent dans la plupart de vos applications, vous pouvez même l’ajouter au contenu du fichier template.py.

VIII-C-2-b. Les gestionnaires d’évènement▲

Pour qu’un bouton déclenche une action, quelle qu’elle soit, il faut satisfaire deux conditions :

• cliquer sur ce bouton : cliquer sur un bouton constitue ce que l’on appelle un « évènement » (event en anglais). Il est important de comprendre que l’évènement est à la base du fonctionnement de l’interface utilisateur. Sans évènement, il ne se passe rien (du moins en première approximation). Un évènement, ça peut être beaucoup de choses. Par exemple :

  • un clic de souris (droite ou gauche),
  • le survol d’un élément par la souris,
  • la frappe au clavier (une touche ou plusieurs touches simultanément),
  • le changement du contenu d’une zone de saisie de texte,
  • liste non exhaustive, loin de là…
• avoir associé à cet évènement le code déterminant l’action à effectuer : cette association se fait à l’aide d’une procédure appelée « gestionnaire d’évènement ».

Cliquer sur un bouton, je suppose que vous savez faire. Nous allons donc nous concentrer sur le second point.

Là encore, Boa Constructor va nous faciliter la tâche, dans la mesure où il va écrire pour nous le squelette du gestionnaire d’évènement, nous laissant la responsabilité d’écrire le code associé.

Marche à suivre :

• cliquez sur le bouton « Quitter » (de la maquette, bien sûr) ;
• dans l’inspecteur de propriété, affichez l’onglet Evts (Events). La colonne de gauche vous propose différents types d’évènements, dont « ButtonEvent », le premier, qui est, vous l’avez deviné, celui qui va nous intéresser. Cliquez dessus ;
• la colonne de droite affiche alors la liste des évènements, liés aux boutons, disponibles fournis par wxPython (qui interface wxWidgets).

• comme apparemment il n’y en a qu’un, wx.EVT_BUTTON, pas besoin de se casser la tête, faites un double clic dessus :

  

• le gestionnaire d’évènement OnQuitterButton est associé automatiquement à cet événement. Le nom des gestionnaires d’évènement commence toujours par On et se termine par le nom générique de l’objet auquel il est lié, ici Button. Ce nom est construit à partir du texte que vous avez attribué à la propriété Name, ce qui vous indique deux choses :

  • il est important que le nom de cette propriété soit représentatif de l’objet qu’il concerne car cela permet de repérer facilement le gestionnaire d’évènement associé à cet objet dans le code,

  • il est cohérent que ce nom commence par une majuscule pour améliorer la lisibilité du nommage ;

• cliquez sur pour insérer ce gestionnaire dans votre code. N’oubliez pas que, tant que vous n’avez pas cliqué sur cette icône, le code n’est pas mis à jour, ce qui vous permet d’ailleurs d’annuler vos modifications.

À partir de maintenant, vous êtes obligé d’aller voir du côté du code. Je suppose que vous avez déjà dû y jeter un coup d’œil, ne serait-ce que pour le fun, mais à présent, comme il vous faut modifier le « source », ce n’est plus une option. Deux fragments de code, complémentaires, ont été ajoutés :

1. Le premier réalise l’association entre le bouton Quitter, l’évènement traité à savoir wx.EVT_BUTTON, et le gestionnaire d’évènement self.OnQuitterButton à l’aide de la procédure Bind() :
   
   

    

   Sélectionnez

   self.Quitter.Bind(wx.EVT_BUTTON, self.OnQuitterButton, id=wxID_FBASEQUITTER)

2. Cette ligne, placée immédiatement après le code d’insertion du bouton, ne nécessite aucune intervention de votre part, Boa Constructor disposant de tous les éléments nécessaires à son élaboration ;

3. Le second va vous permettre d’implémenter le gestionnaire d’évènement OnQuitterButton() en lui-même. Il s’agit d’une déclaration de méthode tout à fait standard, recevant les arguments imposés pour un gestionnaire d’évènement. L’appel de cette méthode lors d’un clic sur le bouton entraîne l’exécution de l’instruction event.Skip() (littéralement, « sauter l’évènement ») dont la fonction est, si on peut dire, de ne rien faire.

La présence par défaut de l’instruction event.Skip() est justifiée par la nécessité de fournir un code valide. Une déclaration de méthode sans code à exécuter entraînerait automatiquement une erreur à l’exécution en raison d’une indentation incorrecte du bloc suivant. Or, en cours de développement, il n’est pas forcément pertinent de coder les gestionnaires d’évènement au fur et à mesure de l’ajout de contrôles à une fiche, la première raison étant qu’on peut être amené à supprimer un ou plusieurs de ces contrôles, et que par conséquent les codes concernés auront été écrits pour rien.

 

Sélectionnez

    def OnQuitterButton(self, event):
        event.Skip()

• Contrairement au fragment précédent, votre intervention est ici nécessaire pour remplacer cette instruction provisoire par le code que vous souhaitez voir exécuter lorsque l’utilisateur clique sur le bouton.

Comme vous pouvez encore le constater, mis à part le codage de l’action à réaliser, et qu’il ne peut pas deviner, Boa Constructor s’est occupé de tout. Vous savez maintenant comment implémenter un gestionnaire d’évènement, ce que vous allez vous empresser de faire pour les deux autres boutons.

Revenons à notre bouton « Quitter ». Je lève enfin le suspens concernant l’utilisation de ce bouton. On va s’en servir pour quitter l’application. Oh ! Est-ce possible ? Bon, soyons sérieux. L’instruction utilisée dans de nombreux langages pour quitter une application est Close(). Python faisant preuve de solidarité, cette instruction est également valable ici. Utilisons-la :

 

Sélectionnez

    def OnQuitterButton(self, event):
        self.Close()

Modifiez votre code en conséquence. Sauvegardez le fichier et exécutez le script. Vous devriez constater que votre bouton « Quitter » est à présent fonctionnel. Au passage, je vous fais remarquer que c’est la première vraie ligne de code que vous saisissez.

Je vous propose, pour contrôle, une petite récapitulation de ce qui a été fait jusqu’à maintenant.

 

Sélectionnez

#!/usr/bin/python
# coding: utf8
#Boa:Frame:FBase

import wx
import wx.lib.buttons

def create(parent):
    return FBase(parent)

[wxID_FBASE, wxID_FBASEALLUMER, wxID_FBASEETEINDRE, wxID_FBASEQUITTER, 
 wxID_FBASESTATICBITMAP1, 
] = [wx.NewId() for _init_ctrls in range(5)]

class FBase(wx.Frame):
    def _init_ctrls(self, prnt):
        # generated method, don't edit
        wx.Frame.__init__(self, id=wxID_FBASE, name=u'FBase', parent=prnt,
              pos=wx.Point(542, 387), size=wx.Size(227, 168),
              style=wx.DEFAULT_FRAME_STYLE, title=u'Commande LED')
        self.SetClientSize(wx.Size(223, 135))

        self.Allumer = wx.lib.buttons.GenButton(id=wxID_FBASEALLUMER,
              label=u'Allumer', name=u'Allumer', parent=self, pos=wx.Point(16,
              16), size=wx.Size(86, 31), style=0)

        self.Eteindre = wx.lib.buttons.GenButton(id=wxID_FBASEETEINDRE,
              label=u'\xc9teindre', name=u'Eteindre', parent=self,
              pos=wx.Point(16, 56), size=wx.Size(86, 31), style=0)

        self.Quitter = wx.lib.buttons.GenButton(id=wxID_FBASEQUITTER,
              label=u'Quitter', name=u'Quitter', parent=self, pos=wx.Point(128,
              96), size=wx.Size(86, 31), style=0)
        self.Quitter.Bind(wx.EVT_BUTTON, self.OnQuitterButton,
              id=wxID_FBASEQUITTER)

        self.staticBitmap1 = wx.StaticBitmap(bitmap=wx.NullBitmap,
              id=wxID_FBASESTATICBITMAP1, name='staticBitmap1', parent=self,
              pos=wx.Point(152, 32), size=wx.Size(32, 32), style=0)

    def __init__(self, parent):
        self._init_ctrls(parent)

    def OnQuitterButton(self, event):
        self.Close()


if __name__ == '__main__':
    app = wx.App()
    frame = create(None)
    frame.Show()

    app.MainLoop()

Si vous avez fait le choix de suivre précisément ce tutoriel, votre code devrait être très proche de celui présenté ci-dessus : seules quelques valeurs numériques sont susceptibles d’être différentes dans la mesure où il y a peu de chances pour que vous ayez positionné les widgets et redimensionné la fenêtre exactement comme moi.

Si vous avez fait cavalier seul, ça ne pose aucun problème tant que vous vous y retrouvez. Toutefois, si vous êtes débutant, ce n’est pas forcément la meilleure idée. Il est préférable, de mon point de vue, de mener à bien cette réalisation puis d’apporter ensuite toutes les modifications qui vous plairont, et de travailler de préférence sur une copie, pour pouvoir revenir si besoin est à une version fonctionnelle, ou tout au moins pour garder une référence.

Quoi qu’il en soit, je vais vous laisser bosser tout seul pour créer les gestionnaires d’évènement associés aux deux autres boutons. Laissez pour le moment l’instruction event.Skip() fournie par défaut, car nous n’avons pas encore tous les éléments pour écrire le code attaché. C’est d’ailleurs intéressant car ça démontre parfaitement la raison d’être de cette instruction.

VIII-C-2-c. Affichage d’une image à partir d’un fichier▲

Avant d’aller plus loin, vous allez devoir télécharger les deux images dont nous allons nous servir. Pour cela, il vous suffit de cliquer sur ces deux liens :

• voyant_on.png :

• voyant_off.png :

Vous allez récupérer ces deux fichiers dans le dossier cible de vos téléchargements, qui s’appelle assez souvent « Téléchargements », et les copier, pour simplifier les chemins, dans le dossier où se trouve votre application ComLED.py, à savoir /chemin/boa/ si vous avez utilisé le nom que je vous ai proposé.

De retour sur votre fiche, cliquez sur le composant wxStaticBitmap puis affichez l’onglet Constr de l’inspecteur de propriétés, si ce n’est déjà fait :

Le nom actuel de ce composant, StaticBitmap1, n’est pas vraiment parlant. Vous allez le renommer « Voyant », de la même façon que pour renommer les boutons, comme nous avons vu plus haut. Je n’insiste pas là-dessus.

Plus intéressant, vous allez maintenant cliquer sur la ligne Bitmap :

Cliquez sur le bouton à droite de la ligne, un dialogue de sélection de fichier s’ouvre. Déplacez-vous vers le dossier de votre application et sélectionnez le fichier « voyant_off.png » que vous venez de télécharger :

Validez puis cliquez sur pour enregistrer les changements. Sauvegardez le fichier avec puis exécutez le programme en cliquant sur  :

Voilà ! Votre composant image affiche le voyant éteint, et toujours sans saisir de code . Je sais, je suis lourd à toujours vous faire cette remarque, mais c’est pour bien vous persuader de l’intérêt d’utiliser ce RAD. C’est quand même l’un des buts de ce tutoriel, et si vous utilisez Boa Constructor ne serait-ce que de temps en temps, j’estimerai ce but atteint.

L’inspecteur de propriétés de Boa Constructor ne permet pas de saisir « à la main » le nom du fichier. Il ouvre automatiquement une boite de dialogue. L’inconvénient est que cette boite de dialogue renvoie le chemin absolu du fichier. Cela rend l’application peu portable.

En ce qui me concerne, quand c’est possible naturellement, je mets tout ce qui concerne mon application dans le même dossier, et je remplace manuellement dans l’éditeur les chemins absolus par des chemins relatifs à ce dossier.

Dans notre cas, si vous avez suivi mes propositions, il vous suffit donc de remplacer la chaîne « /home/…/boa/voyant_off.png » par « voyant_off.png », dans la ligne qui commence par « self.Voyant = ».

En ce qui concerne la maquette, l’IHM (interface homme-machine), comme on dirait si on n’avait pas peur du ridicule, on a fait le tour. Les composants sont en place et paramétrés, on ne devrait pas avoir à y revenir.

À partir de maintenant, pour ce que je vais appeler le code fonctionnel, on va revenir à une programmation qui va peut-être vous être plus habituelle.

Si vous regardez bien le code de gestion des évènements des boutons « Allumer » et « Éteindre », une chose devrait vous sauter aux yeux : ils sont quasiment identiques. En informatique, on essaye au maximum d’éviter les redondances ou les doublons. Le même code étant utilisé deux fois, vous allez en faire une procédure qui sera appelée par les deux gestionnaires.

Ici, c’est très facile. La procédure sera « copie conforme » du code commun aux deux gestionnaires. Ce n’est pas toujours aussi simple. Voici la procédure que j’ai nommée majLed(self) pour « mise à jour LED » que je vous propose :

def majLed(self)
  time.sleep(0.05)
  nbCar = portCom.in_waiting
  retour = portCom.read(nbCar)
  if (retour == "ledOn"):
    bitmap=wx.Bitmap(u"voyant_on.png",wx.BITMAP_TYPE_PNG)
  else:
    bitmap=wx.Bitmap(u"voyant_off.png",wx.BITMAP_TYPE_PNG)
  self.Voyant.SetBitmap(bitmap)

Nous allons placer cette procédure avant les gestionnaires d’évènement qui vont l’utiliser, comme d’habitude, ce qui va donner :

def majLed(self)
  time.sleep(0.05)
  nbCar = portCom.in_waiting
  retour = portCom.read(nbCar)
  if (retour == "ledOn"):
    bitmap=wx.Bitmap(u"voyant_on.png",wx.BITMAP_TYPE_PNG)
  else:
    bitmap=wx.Bitmap(u"voyant_off.png",wx.BITMAP_TYPE_PNG)
  self.Voyant.SetBitmap(bitmap)

def OnAllumerButton(self, event):
  portCom.write("on")
  self.majLed()

def OnEteindreButton(self, event):
  portCom.write("off")
  self.majLed()

On peut même faire encore mieux en passant la commande en paramètre à la procédure majLed(self) qui devient majLed(self, commande) et modifier le code ci-dessus de la façon suivante :

def majLed(self, commande)
  portCom.write(self, commande)
  time.sleep(0.05)
  nbCar = portCom.in_waiting
  retour = portCom.read(nbCar)
  if (retour == "ledOn"):
    bitmap=wx.Bitmap(u"voyant_on.png",wx.BITMAP_TYPE_PNG)
  else:
    bitmap=wx.Bitmap(u"voyant_off.png",wx.BITMAP_TYPE_PNG)
  self.Voyant.SetBitmap(bitmap)

def OnAllumerButton(self, event):
  self.majLed("on")

def OnEteindreButton(self, event):
  self.majLed("off")

Voici le code opérationnel définitif (pour l’instant) :

#!/usr/bin/python
# coding: utf8
#Boa:Frame:FBase

import wx
import wx.lib.buttons
import serial
import time

portCom = serial.Serial()
portCom.port = '/dev/ttyACM0'
portCom.baudrate = 115200
portCom.open()

def create(parent):
    return FBase(parent)

[wxID_FBASE, wxID_FBASEALLUMER, wxID_FBASEETEINDRE, wxID_FBASEQUITTER, 
 wxID_FBASEVOYANT, 
] = [wx.NewId() for _init_ctrls in range(5)]

class FBase(wx.Frame):
    def _init_ctrls(self, prnt):
        # generated method, don't edit
        wx.Frame.__init__(self, id=wxID_FBASE, name=u'FBase', parent=prnt,
              pos=wx.Point(542, 387), size=wx.Size(227, 168),
              style=wx.MINIMIZE_BOX | wx.CLOSE_BOX | wx.CAPTION,
              title=u'Commande LED')
        self.SetClientSize(wx.Size(223, 135))

        self.Allumer = wx.lib.buttons.GenButton(id=wxID_FBASEALLUMER,
              label=u'Allumer', name=u'Allumer', parent=self, pos=wx.Point(16,
              16), size=wx.Size(86, 31), style=0)
        self.Allumer.Bind(wx.EVT_BUTTON, self.OnAllumerButton,
              id=wxID_FBASEALLUMER)

        self.Eteindre = wx.lib.buttons.GenButton(id=wxID_FBASEETEINDRE,
              label=u'\xc9teindre', name=u'Eteindre', parent=self,
              pos=wx.Point(16, 56), size=wx.Size(86, 31), style=0)
        self.Eteindre.Bind(wx.EVT_BUTTON, self.OnEteindreButton,
              id=wxID_FBASEETEINDRE)

        self.Quitter = wx.lib.buttons.GenButton(id=wxID_FBASEQUITTER,
              label=u'Quitter', name=u'Quitter', parent=self, pos=wx.Point(128,
              96), size=wx.Size(86, 31), style=0)
        self.Quitter.Bind(wx.EVT_BUTTON, self.OnQuitterButton,
              id=wxID_FBASEQUITTER)

        self.Voyant = wx.StaticBitmap(bitmap=wx.Bitmap(u'voyant_off.png',
              wx.BITMAP_TYPE_PNG), id=wxID_FBASEVOYANT, name=u'Voyant',
              parent=self, pos=wx.Point(152, 32), size=wx.Size(32, 32),
              style=0)

    def __init__(self, parent):
        self._init_ctrls(parent)

    def OnQuitterButton(self, event):
        self.Close()

    def majLed(self, commande):
        portCom.write(commande)
        time.sleep(0.05)
        nbCar = portCom.in_waiting
        retour = portCom.read(nbCar)
        if (retour == "ledOn"):
            bitmap=wx.Bitmap(u"voyant_on.png",wx.BITMAP_TYPE_PNG)
        else:
            bitmap=wx.Bitmap(u"voyant_off.png",wx.BITMAP_TYPE_PNG)
        self.Voyant.SetBitmap(bitmap)

    def OnAllumerButton(self, event):
        self.majLed("on")

    def OnEteindreButton(self, event):
        self.majLed("off")

if __name__ == '__main__':
    app = wx.App()
    frame = create(None)
    frame.Show()

    app.MainLoop()

Techniquement, dans ce code, il n’y a que 18 lignes saisies à la main. Boa Constructor s’est chargé du reste.

Je ne sais pas si vous l’avez remarqué, mais la fenêtre de votre application est redimensionnable. Il y a des applications pour lesquelles c’est nécessaire, d’autres où c’est simplement utile, et d’autres, c’est le cas de celle-ci, où c’est franchement dommageable. Agrandissez ou rapetissez votre fenêtre et vous le constaterez par vous-même. Comme je suis d’un naturel serviable, je le fais pour vous. Que ce soit ça :

ou ça :

ce n’est pas très joli ! Si je vous en parle, c’est qu’on peut aisément empêcher cela.

Sélectionnez la fiche, et dans l’onglet Constr de l’inspecteur de propriétés, déroulez la propriété Style (clic sur le carré bleu).

Comme vous pouvez le constater, un certain nombre de constantes, dont le rôle est de modifier l’affichage ou le comportement de la fenêtre, sont prédéfinies. Par défaut, quand vous instanciez un objet wx.Frame, une fenêtre donc, la constante DEFAULT_FRAME_STYLE est affectée à la propriété Style. Cette constante, définissant le comportement d’une fenêtre d’usage général, est en elle-même le regroupement de plusieurs constantes définissant chacune un comportement spécifique :

DEFAULT_FRAME_STYLE = MINIMIZE_BOX | MAXIMIZE_BOX | RESIZE_BORDER | SYSTEM_MENU | CAPTION | CLOSE_BOX | CLIP_CHILDREN

Nous n’avons pas besoin de tout ça. Je vous propose donc de mettre cette propriété globale à False et de mettre individuellement à True les propriétés suivantes :

• CAPTION : affiche le titre de la fenêtre ;
• CLOSE_BOX : affiche le bouton système de fermeture ;
• MINIMIZE_BOX : active le bouton système de réduction de la fenêtre.

Ce qui donne :

Comme d’habitude, suivi de suivi de , mais ça doit être devenu un réflexe maintenant : vérifiez le résultat.

La seule chose visible directement est que le bouton système « Maximiser » a disparu de la barre de titre. Vous constaterez également que la fenêtre n’est plus redimensionnable avec la souris.

Je vous engage bien entendu à tester d’autres configurations. Une petite remarque : contrairement à ce qui se passe quand vous élaborez votre maquette, les modifications que vous effectuez ici ne sont pas répercutées visuellement sur la fiche. Elles n’apparaîtront qu’au lancement du programme.

Comme pour votre script « console », je vous propose ici, sans le commenter, le même script intégrant la gestion d’une éventuelle erreur à l’ouverture du port. Cette gestion s’accompagne de l’affichage d’une fenêtre de dialogue en cas d’erreur détectée. Je vous fournis ci-après les deux scripts : celui de l’application et celui de la fenêtre de dialogue. Vous devrez les mettre dans le même dossier, avec les fichiers PNG.

Code de l’application :

#!/usr/bin/python
# coding: utf8
#Boa:Frame:FBase

import wx
import wx.lib.buttons
import serial
import time

portCom = serial.Serial()
portCom.port = '/dev/ttyACM0'
portCom.baudrate = 115200
 

def create(parent):
    return FBase(parent)

[wxID_FBASE, wxID_FBASEALLUMER, wxID_FBASEETEINDRE, wxID_FBASEQUITTER, 
 wxID_FBASEVOYANT, 
] = [wx.NewId() for _init_ctrls in range(5)]

class FBase(wx.Frame):
    def _init_ctrls(self, prnt):
        # generated method, don't edit
        wx.Frame.__init__(self, id=wxID_FBASE, name=u'FBase', parent=prnt,
              pos=wx.Point(542, 376), size=wx.Size(227, 168),
              style=wx.DEFAULT_FRAME_STYLE | wx.CLOSE_BOX | wx.MINIMIZE_BOX | wx.CAPTION,
              title=u'Commande LED')
        self.SetClientSize(wx.Size(223, 135))

        self.Allumer = wx.lib.buttons.GenButton(id=wxID_FBASEALLUMER,
              label=u'Allumer', name=u'Allumer', parent=self, pos=wx.Point(16,
              16), size=wx.Size(86, 31), style=0)
        self.Allumer.Bind(wx.EVT_BUTTON, self.OnAllumerButton,
              id=wxID_FBASEALLUMER)

        self.Eteindre = wx.lib.buttons.GenButton(id=wxID_FBASEETEINDRE,
              label=u'\xc9teindre', name=u'Eteindre', parent=self,
              pos=wx.Point(16, 56), size=wx.Size(86, 31), style=0)
        self.Eteindre.Bind(wx.EVT_BUTTON, self.OnEteindreButton,
              id=wxID_FBASEETEINDRE)

        self.Quitter = wx.lib.buttons.GenButton(id=wxID_FBASEQUITTER,
              label=u'Quitter', name=u'Quitter', parent=self, pos=wx.Point(128,
              96), size=wx.Size(86, 31), style=0)
        self.Quitter.Bind(wx.EVT_BUTTON, self.OnQuitterButton,
              id=wxID_FBASEQUITTER)

        self.Voyant = wx.StaticBitmap(bitmap=wx.Bitmap(u'voyant_off.png',
              wx.BITMAP_TYPE_PNG), id=wxID_FBASEVOYANT, name=u'Voyant',
              parent=self, pos=wx.Point(152, 32), size=wx.Size(32, 32),
              style=0)

    def __init__(self, parent):
        self._init_ctrls(parent)
        try:
            portCom.open()
        except serial.SerialException:
            import Dialog1 
            dlg = Dialog1.Dialog1(self)
            try:
                dlg.ShowModal()
            finally:
                dlg.Destroy()            

    def OnQuitterButton(self, event):
        self.Close()

    def majLed(self, commande):
        portCom.write(commande)
        time.sleep(0.05)
        nbCar = portCom.in_waiting
        retour = portCom.read(nbCar)
        if (retour == "ledOn"):
            bitmap=wx.Bitmap(u"voyant_on.png",wx.BITMAP_TYPE_PNG)
        else:
            bitmap=wx.Bitmap(u"voyant_off.png",wx.BITMAP_TYPE_PNG)
        self.Voyant.SetBitmap(bitmap)

    def OnAllumerButton(self, event):
        self.majLed("on")

    def OnEteindreButton(self, event):
        self.majLed("off")

if __name__ == '__main__':
    app = wx.App()
    frame = create(None)
    frame.Show()

    app.MainLoop()

Code de la fenêtre de dialogue :

#Boa:Dialog:Dialog1

import wx

def create(parent):
    return Dialog1(parent)

[wxID_DIALOG1, wxID_DIALOG1BITMAPBUTTON1, wxID_DIALOG1STATICTEXT1, 
 wxID_DIALOG1STATICTEXT2, 
] = [wx.NewId() for _init_ctrls in range(4)]

class Dialog1(wx.Dialog):
    def _init_ctrls(self, prnt):
        # generated method, don't edit
        wx.Dialog.__init__(self, id=wxID_DIALOG1, name='', parent=prnt,
              pos=wx.Point(461, 347), size=wx.Size(365, 189),
              style=wx.DEFAULT_DIALOG_STYLE, title='Dialog1')
        self.SetClientSize(wx.Size(361, 156))

        self.bitmapButton1 = wx.BitmapButton(bitmap=wx.Bitmap(u'ok_btn.png',
              wx.BITMAP_TYPE_PNG), id=wxID_DIALOG1BITMAPBUTTON1,
              name='bitmapButton1', parent=self, pos=wx.Point(140, 120),
              size=wx.Size(80, 28), style=wx.BU_AUTODRAW)
        self.bitmapButton1.Center(wx.HORIZONTAL)
        self.bitmapButton1.Bind(wx.EVT_BUTTON, self.OnBitmapButton1Button,
              id=wxID_DIALOG1BITMAPBUTTON1)

        self.staticText1 = wx.StaticText(id=wxID_DIALOG1STATICTEXT1,
              label='staticText1', name='staticText1', parent=self,
              pos=wx.Point(8, 8), size=wx.Size(203, 18), style=0)
        self.staticText1.SetLabelText(u"Probl\xe8me \xe0 l'ouverture du port")
        self.staticText1.SetFont(wx.Font(10, wx.SWISS, wx.NORMAL, wx.BOLD, True,
              u'Noto Sans'))
        self.staticText1.SetForegroundColour(wx.Colour(117, 27, 27))

        self.staticText2 = wx.StaticText(id=wxID_DIALOG1STATICTEXT2,
              label='staticText2', name='staticText2', parent=self,
              pos=wx.Point(32, 40), size=wx.Size(300, 72), style=0)
        self.staticText2.SetLabelText(u'Les deux causes suivantes sont les plus probables:\n\t- La carte n\'est pas connect\xe9e\n \t- Le port syst\xe8me n\'est pas "/dev/ttyACM0"\n')

    def __init__(self, parent):
        self._init_ctrls(parent)

    def OnBitmapButton1Button(self, event):
        self.Close()

Vous devrez également télécharger le fichier PNG de l’image affichée par le bouton de la boite de dialogue et le coller dans le dossier de votre application.

La façon la plus simple de tester cette nouvelle fonctionnalité est de déconnecter votre carte et de lancer l’application.

Je n’ai pas personnalisé cette fenêtre de dialogue, vous laissant le soin de le faire si vous le souhaitez. Vous devrez l’enregistrer sous « Dialog1.py » pour qu’elle soit reconnue par l’application. Vous pouvez bien sûr changer ce nom, à condition de faire la modification équivalente dans le script « ComLED.py ». À vous de jouer.