Comme cela a été souligné au chapitre C2‑I , si une carte Arduino ne permet pas de mettre en œuvre des entrées‑sorties standards, elle peut néanmoins échanger des données textuelles avec le poste de travail auquel elle est reliée via une liaison série W. De manière générale, une liaison série est constituée d'un médium – c'est‑à‑dire un câble ou autre support de transmission – associé à un protocole de communication (cf. chap. R1‑IV R) permettant, entre deux systèmes numériques :

• d'établir la communication (avec, par exemple, un bit de start), c'est‑à‑dire préparer chaque système à la transmission de données ;
• de transmettre des données les unes après les autres sur le médium – ce que sous‑tend le terme « série » ;
• de clore la communication (avec, par exemple, un bit de stop), éventuellement avec des éléments de vérification de bonne transmission (typiquement, par contrôle de parité).

Parce qu'elles ne requièrent qu'un nombre minimal de conducteurs (3 fils) dans le support de transmission, les liaisons séries ont depuis longtemps supplanté les liaisons parallèles. Ainsi, un protocole série ancien comme l'UART (universal asynchronous receiver transmitter) W reste très employé en informatique embarquée. Mais même s'il peut sembler simple par rapport à d'autres (Ethernet, etc.), sa mise en œuvre complète reste assez complexe Il ne suffit pas de quelques heures d'étude pour en comprendre tous les ressorts.

Heureusement, en programmation des microcontrôleurs, cette complexité est masquée par l'emploi de fonctions de haut niveau comme, par exemple, Serial.print dans le framework Arduino. Néanmoins, pour une bonne compréhension de ces fonctions, il est souhaitable de connaître quelques concepts et mécanismes sous‑jacents : buffer d'entrée‑sortie, circuit de sérialisation/désérialisation, etc. Mais attention ! Certains de ces aspects font appel des notions de codage qui n'ont été que peu ou pas étudiées jusqu'à présent dans ce module : objets, chaînes de caractères, pointeurs, interruptions… certaines notions n'étant même pas au programme du module de formation au langage C.

Ce chapitre n'a donc pas vocation à exposer en détail tous les aspects d'une liaison série (pour des compléments, on pourra se reporter à ce cours ). L'objectif est ici d'aborder les principes essentiels de communication par liaison série, afin de pouvoir ensuite coder, avec quand même une bonne maîtrise, des opérations de lecture et d'écriture de données dans le moniteur série émulé par le logiciel Arduino IDE ou dans l'environnement de simulation Tinkercad. Seront donc étudiés dans l'ordre :

• des rudiments sur les aspects matériels d'une liaison série de type UART ;
• les éléments sur lesquels reposent aspects logiciels d'une telle liaison série dans le framework Arduino, notamment l'objet Serial et ses buffers, ainsi que le moniteur série ;
• les quelques fonctions d'administration d'une telle liaison série ;
• les principales fonctions associées aux opérations de sortie, c'est‑à‑dire d'écriture dans le moniteur série ;
• les principales fonctions associées aux opérations d'entrée, c'est‑à‑dire de lecture dans le moniteur série ;

sachant que ce sont ces deux dernières sections du chapitre qui apportent les éléments de langage les plus opérationnels dans le bagage d'un codeur.

Aspects matériels  –  généralités

À titre d'exemple emblématique, une carte Arduino Uno R3 est équipée d'un port USB type B et embarque, en plus de son microcontrôleur principal, un deuxième microcontrôleur (un Atmel ATmega16U2), cadencé par un circuit oscillant externe à quartz 16 MHz. Ce dispositif est entièrement dédié à l'interface USB‑USART (cf. la figure ci‑contre).

Attention ! Sur les cartes clones de type « Uno » produites par des fabricants tiers (principalement chinois), à la place d'un microcontrôleur dédié, c'est plutôt un ASIC W (application‑specific integrated circuit) avec un circuit oscillant interne qui réalise l'interface USB‑USART. Typiquement, il peut s'agir :

• d'un circuit CP2102  de Silicon Labs ;
• ou d'un circuit CH340  de WCH.

Cette différence technologique peut poser des problèmes de connexion de la carte avec le poste de travail, notamment si le pilote du circuit n'est pas installé sur le système d'exploitation. Si tel est le cas, on pourra se reporter à cette remarque du chap. C1‑III .

Pour une liaison série, le médium de transmission employé est typiquement un câble USB (universal serial bus) raccordé au port USB de la carte. Cette liaison sert notamment au téléversement du programme utilisateur mais aussi, durant son exécution, à afficher du texte et lire des valeurs saisies par l'utilisateur sur le poste de travail. On parle de moniteur série, comme l'illustre la figure ci‑dessous.

Mais plus généralement, une liaison série peut aussi être employée pour échanger des données entre une carte à microcontrôleur et un serveur de données, une machine (station de mesure, dispositif contrôlé à distance…), un instrument de musique, etc.

Médium direct – broches TX & RX

Sur les cartes Arduino, on peut aussi employer un médium direct (cf. la carte Uno représentée partiellement en figure ci‑contre) constitué :

• d'une paire de fils torsadés reliée aux broches 0 et 1 du port numérique, lesquelles sont respectivement dédiées à l'émission (celle désignée TX) et à la réception (celle désignée RX) ;
• et d'un fil de masse relié à la broche GND, ce dernier fournissant le potentiel de référence pour déterminer les niveaux de tension bas et haut (respectivement 0 V et 5 V) sur les broches TX et RX.

On rappelle que c'est la raison pour laquelle il est recommandé de ne pas utiliser comme des entrées‑sorties usuelles les broches 0 et 1 du port numérique – même si cela reste possible moyennant certaines précautions – cf. chap. C2‑XIII .

Par ailleurs, la carte comporte deux leds désignées également TX et RX mais ces dernières ne sont pas reliées électriquement aux broches 0 et 1 du port numérique du microcontrôleur principal de la carte (cf. par exemple le schéma électronique d'une carte Uno R3 A). Elles ne reproduisent donc pas les niveaux de tension sur ces broches. En fait, ces led sont reliées à des broches du microcontrôleur dédié à l'interface USB‑USART, leur rôle étant de signaler l'activité de la liaison entre la carte et le poste de travail.

Remarque. La led TX clignote lorsque l'on génère (via le programme utilisateur) un signal variable sur la broche 1 du port numérique. Mais il s'agit alors simplement d'un artefact : le microcontrôleur de l'interface USB‑USART interprète à tort ce signal variable comme une activité de la liaison entre la carte et le poste de travail.

Ports série multiples

Sur certains modèles de cartes à microcontrôleur, il peut exister plusieurs autres paires de broches permettant la mise en œuvre d'autres liaisons série en plus de celle utilisée couramment.

Sur les cartes Arduino Mega et Arduino Due, On dispose en tout de 4 liaisons série avec les associations suivantes :

Nº broches	Fonctions	Objet
1 & 0	TX & RX	Serial
18 & 19	TX1 & RX1	Serial1
16 & 17	TX2 & RX2	Serial2
14 & 15	TX3 & RX3	Serial3

Schéma‑bloc de l'USART interne au microcontrôleur Atmel ATmega328p

Le schéma‑bloc ci‑dessous détaille l'implémentation matérielle de l'USART intégré au microcontrôleur Atmel ATmega328p, lequel équipe notamment les cartes Arduino Uno et Nano (cf. chap. C1‑III ).

Il est constitué de 3 principaux circuits :

• un circuit d'horloge (clock generator) qui, en divisant la fréquence du signal issu du circuit oscillant externe, génère le signal de cadencement de la liaison série à la vitesse spécifiée – ce qu'on appelle en anglais le baud rate ;
• un circuit d'émission (transmitter) dédié à la sortie des données, qui est lui‑même composé :
• d'un registre d'émission pour stocker un octet à émettre ;
• et d'un sous‑circuit de sérialisation qui, à partir des bits de l'octet contenu dans le registre d'émission, génère à la fréquence du circuit d'horloge le signal logique à écrire sur la broche TX ;
• un circuit de réception (receiver) dédié à l'entrée des données, qui est lui‑même composé :
• d'un sous‑circuit de désérialisation qui, à partir du signal logique reçu sur la broche RX, reconstitue un octet reçu ;
• cet octet étant stocké dans le registre de réception ;
• d'un groupe de 3 registres, d'un octet chacun, pour stocker les bits d'état et de commande de l'USART, à des fins de contrôle logiciel.

Cas des cartes à modules ESP8266 et ESP32

À la différence de la plupart des cartes Arduino, les cartes à modules ESP8266 et ESP32 (cf. chap. C1‑III ) ne sont pas dotées d'un microcontrôleur et d'un quartz externe dédiés pour la conversion USB‑USART.

Comme les cartes clones Arduino, elles sont équipées à la place d'un ASIC W (application‑specific integrated circuit) qui intègre un circuit oscillant interne. Cela peut éventuellement poser les mêmes problèmes de connexion de la carte au poste de travail si les pilotes de ces circuits ne sont pas installés sur le poste de travail (chap. C1‑III ).

En règle générale, on retrouve les mêmes fonctionnalités de liaisons séries que sur des cartes Arduino.

À titre d'exemple, la carte SBC‑NodeMCU à module ESP8266 de l'assembleur Joy‑It permet deux liaisons séries UART (cf. la figure ci‑contre dite pinout et le chap. C2‑VIII pour plus de détails) :

• UART0 sur les broches GPIO 1 & 3 (TXD0 & RXD0) ;
• UART2 sur les broches GPIO 15 & 13, étiquetée D8 & D7 sur la carte (TXD2 & RXD2) ;

sachant que la liaison UART0 est celle qui est prise en charge par défaut via le circuit d'interface USB‑USART de typeCP2102 (cf. supra ).

La carte SBC‑NodeMCU illustrant l'exemple supra possède aussi une liaison UART1 qui est réservée au téléversement du programme utilisateur et du firmware de la carte. Seule la broche TXD1 est déployée et porte le numéro GPIO 2, étiqueté D4 sur la carte .

Aspects logiciels  –  généralités

L'objet Serial

Instanciation de l'objet Serial

Buffers de l'objet Serial

L'objet Serial possède deux champs essentiels issus de la classe HardwareSerial, déclarés dans le fichier d'en‑tête HardwareSerial.h G :

• le buffer de réception :

    unsigned char _rx_buffer[SERIAL_RX_BUFFER_SIZE];

• le buffer d'émission :

    unsigned char _tx_buffer[SERIAL_TX_BUFFER_SIZE];

sachant qu'un buffer est un espace mémoire tampon permettant de stocker des données de façon temporaire.

Dans les instructions ci‑dessus, les deux buffers sont déclarés :

• comme des tableaux (notion abordée au chap. C5‑III ),
• dont les éléments sont de type unsigned char, donc encodés en binaire naturel sur 1 octet (8 bits) chacun,
• le nombre d'éléments étant respectivement spécifié par les pseudo‑constantes SERIAL_RX_BUFFER_SIZE et SERIAL_TX_BUFFER_SIZE, définies dans le fichier d'en‑tête HardwareSerial.h avec comme valeur par défaut :
• 16 octets si la mémoire pour les données est inférieure à 1 ko (par exemple, sur un microcontrôleur Atmel ATtiny – cf. chap. C1‑III ) ;
• 64 octets pour les cartes Arduino à cœur AVR (Uno R3, Nano, Mega…)  ;
• 128 octets pour les cartes Arduino à cœur ARM et les cartes à module ESP8266 et ESP32.

Remarque. Dans le framework Arduino, les identificateurs de ces deux pseudo‑constantes sont utilisables pour former des expressions dans les programmes sources.

De plus, les buffers d'émission et de réception de l'objet Serial sont l'un et l'autre implémentés de façon circulaire avec, pour chacun, un indice de queue (_buffer_tail) et un indice de tête (_buffer_head) W.

Comme illustré sur la figure ci‑contre, chaque buffer est opéré avec une gestion des priorités comme celle d'une file d'attente FIFO (first in first out W) :

L'indice de queue cible l'octet arrivé en premier dans le buffer (le plus ancien), qui doit être traité en premier (parmi tous ceux qu'il contient).
Il est incrémenté d'une unité à chaque octet traité ; par cette opération, un octet du buffer est libéré (son contenu n'est pas effacé, il sera simplement ultérieurement écrasé par un octet entrant).

L'indice de tête cible l'élément placé juste après l'octet arrivé en dernier dans le buffer (le plus récent), qui sera traité en dernier (parmi tous ceux qu'il contient).
Il est incrémenté d'une unité à chaque octet arrivé ; par cette opération, l'octet arrivé est comptabilisé dans le buffer.

Sachant sa circularité, le buffer est donc :

• vide lorsque l'indice de queue est égal à l'indice de tête (cf. le cas de figure ci‑contre) ;

• partiellement plein lorsque l'indice de tête est différent d'au moins deux unités (supérieur ou inférieur) à l'indice de queue (cf. les deux cas de figure ci‑dessous) ;

• plein lorsque l'indice de tête est égal moins une unité à l'indice de queue (cf. le cas de figure ci‑contre).

Avec cette structure de données, la capacité effective du buffer est inférieure d'une unité au nombre d'éléments du tableau.

Exemple. Dans le cas d'une carte Arduino Uno R3, puisque le nombre d'éléments des tableaux _rx_buffer et _tx_buffer vaut 64, la capacité effective des buffers est de 63 octets.

En résumé, pour une mise en œuvre asynchrone de la liaison série :

Méthodes associées à l'objet Serial

Dans la logique de la programmation orientée objet, un objet se manipule à l'aide de méthodes, c'est‑à‑dire des fonctions dédiées qui sont définies dans la déclaration de la classe à laquelle l'objet appartient ou des classes dont il descend (c'est la notion d'héritage).

  Serial.end();

Le moniteur série

Sur le poste de travail, l'application Arduino IDE V2 émule un moniteur série dans le cadre multi‑fonctions en dessous de la fenêtre d'édition du code (cf. chap. C1‑III . Par des instructions codées dans le programme utilisateur téléversé sur la carte,il permet à l'utilisateur de visualiser les affichages (sorties) et de saisir des valeurs (entrées) via la liaison série.

L'onglet du moniteur série peut être ouvert dans le cadre multi‑fonctions (sous la fenêtre d'édition de code) soit par une commande éponyme du menu Outils, soit en cliquant sur le bouton de raccourci en haut à droite de l'éditeur.

Dans cet onglet, on trouve :

• en haut, la barre de saisie pour les entrées de la carte, qui sont envoyées après validation par la touche ENTRÉE ↵ du clavier sur le poste de travail ;
• au centre, la zone d'affichage pour les sorties de la carte ;
• en haut à gauche, des boutons pour contrôler quelques fonctionnalités de la zone d'affichage des sorties – le défilement automatique (autoscroll), l'horodatage (timestamp) et l'effaçage ;
• juste en dessous, deux menus déroulants pour respectivement sélectionner :
• la séquence d'échappement newline générée à la fin de la saisie en entrée ;
• la vitesse de transmission de la liaison série (baudrate) – cf. infra .

Vitesse de transmission

Les valeurs standards de la vitesse de transmission vont de 300 à 2 000 000 Bd. Pour faire un bon choix, il faut avoir en tête les considérations suivantes :

• La valeur 9600 Bd est restée durant longtemps la vitesse par défaut. C'est un choix « historique » qui aujourd'hui est déconseillé car il peut être pénalisant pour la réactivité du programme utilisateur.
En effet, sachant qu'il faut au minimum 10 bits pour transmettre un octet, il faut compter environ 1 ms par octet transmis avec cette vitesse. Si le buffer d'émission en vient à être saturé, l'exécution du programme va inévitablement ralentir dans des proportions inacceptables pour un système temps‑réel.
Quant aux valeurs inférieures à 9600 Bd, elles sont complètement désuètes.
• La valeur 115200 Bd est aujourd'hui celle qui est employée préférentiellement ; elle tient lieu de nouvelle valeur par défaut. Elle est environ 10 fois supérieure à la précédente.
Mais lorsque le programme échange un gros volume de données échangées par liaison série sont très nombreuses, pour ne pas ralentir l'exécution des programmes, on peut éventuellement augmenter encore cette vitesse d'un facteur 10, c'est‑à‑dire jusqu'à 1000000 Bd. Toutefois, sur certaines cartes à microcontrôleur hautes‑performances et très miniaturisées (Teensy, par exemple), il peut exister un risque échauffement du convertisseur USB‑serial.

Le traceur série

En alternative au moniteur série, l'application Arduino IDE permet d'afficher sous forme de diagramme temporel les valeurs numériques de sortie d'une carte à microcontrôleur. C'est le traceur série (serial plotter).

On accède à ce mode d'affichage soit via une commande éponyme du menu Tools, soit en cliquant sur le bouton de raccourci en haut à droite de l'éditeur. Il peut être opérationnel même lorsque le moniteur série est également activé.

Pour chaque variable du programme exécuté dans la carte, dont les valeurs sont envoyées via la liaison série par une instruction répétitive (c'est‑à‑dire codée dans la fonction loop) de la forme :
Serial.print(identificateur);   (cf. infra )
le traceur trace sur un diagramme cartésien une courbe dont les points ont pour abscisse l'instant de réception et pour ordonnée la valeur de la variable transmise à cet instant.

On voit donc apparaître sur le diagramme autant de courbes de que variables suivies, chacune étant tracée avec une couleur distincte, automatiquement choisie.

Considérons le programme académique ci‑dessous qui, sur une carte Arduino Uno, effectue une lecture analogique de la broche A0 laissée flottante (c'est‑à‑dire reliée à aucun dispositif). Un appel de la fonction delay permet de limiter la fréquence des lectures.

void setup()
{
  Serial.begin(115200);
  Serial.println();
  Serial.flush();
  delay(100);
}

void loop()
{
  int randomAnalog = analogRead(A0);
  Serial.println(randomAnalog);
  delay(100);
}

La capture d'écran ci‑dessous montre l'affichage du traceur série lors de l'exécution :

Dans l'IDE VS Code

Dans l'IDE VS code avec installées les extensions Arduino Community Edition et Serial Monitor de Microsoft (cf. chap. C1‑III ), le moniteur série est accessible dans un onglet dédié du cadre inférieur sous le cadre d'édition de code – cf. la capture d'écran ci‑dessous. Il s'ouvre simplement par un clic de souris.

Ce moniteur série fournit plus de fonctionnalités et de possibilités de paramétrage que celui de l'application Arduino IDE. En particulier, il permet de gérer en parallèle plusieurs liaisons séries entre une carte Arduino ou compatible et le poste de travail. C'est pourquoi l'ouverture du moniteur série ne provoque pas d'activation immédiate de ce dernier. Pour cela, il faut effectuer deux actions :

1. via un menu déroulant, sélectionner le port USB auquel la carte est raccordée ;
2. cliquer sur le bouton ▷ Start Monitoring

Les messages envoyés par la carte peuvent alors apparaître dans la zone d'affichage. De plus, la barre de saisie s'active pour permettre à l'utilisateur d'envoyer des messages vers la carte.

Comme sur l'application Arduino IDE (et avec davantage de fonctionnalités), on dispose de plusieurs boutons de contrôle, respectivement pour :

• l'effacement du contenu de la zone d'affichage ;
• l'activation/désactivation de l'horodatage des messages (timestamp), du défilement automatique du texte (autoscroll), de la barre de saisie (terminal mode) et des messages internes à l'application (sent message echoing).

Par ailleurs, le bouton ⚙ permet d'accéder aux réglages fins du protocole de communication de la liaison série, que l'on ne détaillera pas ici (cf. chap. R3‑VII R).

L'extensions Arduino Community Edition, tout comme l'extension Serial Monitor de Microsoft, n'implémentent pas de traceur série.

On peut néanmoins pallier cette lacune en installant une extension dédiée, comme par exemple Teleplot.

Dans l'environnement en ligne Tinkercad

L'environnement de simulation Tinkercad permet de simuler le moniteur série comme si une vraie carte était reliée à l'ordinateur par liaison série.

Dans une fenêtre de circuit dont le volet code est ouvert, la simulation du moniteur série est activée par un clic en bas du volet.

Il apparaît alors un zone d'affichage pour visualiser les sorties et en dessous une barre de saisie pour taper au clavier des entrées, à valider en cliquant sur le bouton de droite « envoyer ».

On l'a déjà vu à plusieurs reprises, l'environnement Tinkercad ne simule pas bien certains aspects du fonctionnement de l'application Arduino IDE.

En particulier, la fenêtre du moniteur série n'interprète pas les octets au format UTF‑8 (cf. chap. C3‑IX ), mais en ASCII (cf. chap. C3‑VIII ). En conséquence, les caractères accentués ne sont pas correctement affichés : on est confronté à un problème classique de transcodage comme celui abordé dans l'exercice nº 4 de la feuille C3 ).

Administration d'une liaison série

Initialisation

Terminaison

Test

Opérations de sortie par liaison série

Principe général d'une opération de sortie

Modes d'écriture

Écriture par octets

1. Si l'argument expression est de type entier :
Elle est évaluée par conversion implicite dans le type unsigned char, avec rebouclage cyclique éventuel (cf. chap. C3‑VI . S'il s'agit d'une valeur de caractère saisie entre guillemets simples seul l'octet de poids faible de son code UTF‑8 est retenu. Dans tous les cas, un seul octet est écrit en tête du buffer d'émission.

Dans tous les exemples ci‑dessous, on fait l'hypothèse que le programme s'exécute sur une vraie carte Arduino reliée à un poste de travail où le moniteur série est activé. La liaison série est supposée initialisée correctement. Typiquement, le squelette de programme de test donné ci‑dessous suffit :

void setup()
{
  delay(500);
  Serial.begin(115200);
  Serial.println();
  // type your statement here
}

void loop() {}

Les instructions à tester sont à coder en ligne nº 6. Ainsi :

• L'instruction Serial.write(65); écrit l'octet de valeur numérique 65 (ou 0x41) dans le buffer d'émission. Et cet octet apparaît dans la zone d'affichage du moniteur série :
  A
  car 65 est le code UTF‑8 de la lettre « A » (cf. chap. C3‑VIII ).
L'instruction Serial.write(65 + 256); donne exactement le même résultat parce qu'un octet encode seulement 256 valeurs entières, donc le rebouclage opère modulo 256.
• L'instruction Serial.write('A'); donne aussi le même résultat parce que la valeur de caractère 'A' est évaluée par le compilateur comme son code UTF‑8, à savoir l'entier 65.
L'instruction Serial.write(128); écrit l'octet de valeur numérique 128 (ou 0x80) dans le buffer d'émission. Toutefois, cet octet apparaît dans la zone d'affichage du moniteur série comme le symbole générique :
⍰
car en UTF‑8, le code 128 n'est pas un code de caractère affichable.
L'instruction Serial.write('é'); écrit l'octet de valeur numérique 169 (ou 0xA9) dans le buffer d'émission car c'est la valeur de l'octet de poids faible du code UTF‑8 du caractère « é ». Et cet octet apparaît dans la zone d'affichage du moniteur série comme le symbole générique :
⍰
car en UTF‑8, le code 1169 n'est pas un code de caractère affichable.
2. Si l'argument expression est de type chaîne de caractères  :
Les codes UTF‑8 des caractères qui la composent (encodés sur un ou plusieurs octets) sont écrits sont l'un après l'autre en tête du buffer d'émission.

Comme supra , on fait l'hypothèse que le programme s'exécute sur une vraie carte Arduino reliée à un poste de travail où le moniteur série est activé, la liaison série étant initialisée. Et on utilise le même squelette de code.

• L'instruction Serial.write("C++"); écrit les trois octets de codes UTF‑8 respectifs 67 ('C'), 43 ('+') et 43 ('+') dans le buffer d'émission. Après réception dans le moniteur série, ils sont interprétés comme tels et apparaissent dans la zone d'affichage pour former le mot :
  C++
L'instruction Serial.write("é"); écrit le code UTF‑8 0xC3A9, soit les deux octets de valeur décimale 169 (0xA9) et 195 (0xC3) dans le buffer d'émission. Après réception dans le moniteur série, ils sont interprétés comme tels et apparaissent dans la zone d'affichage comme le caractère affichable attendu :
é
On peut donc apprécier la différence avec le résultat insatisfaisant produit par l'instruction Serial.write('é'); (cf. supra ).

Remarque. Comme exposé supra , l'environnement Tinkercad ne prend pas en charge le format UTF‑8 dans la simulation du moniteur série. Si l'on y teste l'instruction Serial.write("é"); on obtient l'affichage de la chaîne de caractères é dans la fenêtre de simulation du moniteur série. Ces deux glyphes correspondent respectivement aux valeurs de caractères des codes ASCII étendus 0xC3 et 0xA9 de la page de code CP1252 (cf. chap. C3‑VIII ), sachant que 0xC3A9 est le code UTF‑8 du caractère « é » (cf. l'exercice C3‑4 ).

Écriture par caractères

Principe de l'écriture par caractères

Pour bien comprendre la différence avec la méthode write, comparons l'affichage obtenu pour le même argument qu'au 1^er exemple supra  (pour mémoire, l'instruction Serial.write(65); affiche A sur le moniteur série car 65 est le code UTF‑8 du caractère « A »).

Syntaxes d'appel

1. Si l'expression est à valeur entière, signée ou non, alors la syntaxe d'appel est :
   Serial.print(expression [, base]) A
   où l'argument optionnel base spécifie la base de numération de la valeur formatée à écrire en tête du buffer d'émission de l'objet Serial.

   Ce formatage est appliqué quel que soit le préfixe (0x, 0b…) éventuellement spécifié dans l'expression passée comme premier argument.

   L'argument optionnel base peut être codé :

   • par n'importe quelle expression prenant la valeur 2, 8, 10 ou 16 ;
   • où, pour une meilleure lisibilité, par l'une des pseudo‑constantes BIN, OCT, DEC ou HEX définies dans le fichier d'en‑tête Print.h ;

   sachant que c'est par défaut la base 10 de formatage qui est adoptée.

   Pour tester la méthode print appliquées à des valeurs entières, comme précédemment, on fait l'hypothèse que le programme s'exécute sur une carte Arduino reliée à un poste de travail où le moniteur série est activé, la liaison série étant initialisée (cf. supra  pour le squelette du programme de test qu'on peut utiliser).

   • L'instruction Serial.print(6, BIN); affiche la chaîne de caractères 110.
   Plus précisément, cette instruction :
   • convertit la valeur 6 en base 2, aboutissant au nombre binaire 110,
   • convertit ce nombre binaire en la chaîne de trois caractères « 1 », « 1 » et « 0 »,
   • convertit ces caractères en leurs codes ASCII 0x31, 0x31 et 0x30,
   • écrit ces octets de code dans le buffer d'émission.
   Copiés l'un après l'autre dans le registre d'émission, puis sérialisés par l'USART, ces octets sont interprétés par le moniteur série comme des codes UTF‑8 (identiques aux codes ASCII restreints). Les caractère qui s'affichent sont donc les digits binaires de la constante littérale 6 passée en argument.
   • L'instruction Serial.print(0b1111, HEX); affiche la chaîne de caractères F.
   Plus précisément, cette instruction :
   • convertit la valeur binaire 1111 en base 16, aboutissant au nombre hexadécimal à un seul digit F (c'est‑à‑dire 15 en base 10) ;
   • convertit ce nombre en la chaîne de caractères équivalente à "F" ;
   • convertit ce caractère en son code ASCII 0x46,
   • écrit cet octet de code dans le buffer d'émission.
   Comme pour l'exemple précédent, cet octet est ensuite interprété comme un code UTF‑8 et apparaît donc comme F dans la zone d'affichage du moniteur série.

2. Si expression est à valeur décimale (c'est‑à‑dire codée dans un type flottant) alors la syntaxe d'appel est :
   Serial.print(expression [, digit]) A
   où l'argument optionnel digit spécifie le nombre de décimales près auquel arrondir la valeur formatée écrite en tête du buffer d'émission de l'objet Serial.

   L'argument optionnel digit peut être codé par n'importe quelle expression à valeur entière positive ou nulle.

   En principe, toutes les décimales spécifiées supplémentaires à celles encodées dans le type flottant de l'expression passée en premier argument sont formatées 0.

   Pour tester la méthode print appliquée à des valeurs décimales, comme précédemment, on fait l'hypothèse que le programme s'exécute sur une carte Arduino reliée à un poste de travail où le moniteur série est activé, la liaison série étant initialisée (cf. supra  pour le squelette du programme de test qu'on peut utiliser).

   • L'instruction Serial.print(12.345678, 3); affiche la chaîne de caractères 12.346.
   Plus précisément, cette instruction :
   • arrondit à 12.346 la valeur formatée (la 3^e décimale est passée à la valeur entière supérieure parce que la décimale suivante 6 est supérieure où égale à 5) ;
   • convertit cette valeur numérique en la chaîne de caractères équivalente à "12.346" ;
   • convertit chaque caractère de cette chaîne en son code ASCII ;
   • écrit ces octets de code dans le buffer d'émission.
   Interprétés comme des codes UTF‑8, ils formeront la chaîne de caractères décimaux souhaitée dans la zone d'affichage du moniteur série.
   L'instruction Serial.print(PI, 25) affiche :
   3.1415927410125732421875000
   sur le moniteur série (pour mémoire, le nombre π vaut 3,14159265 à 10⁻⁸ près).
   Le fait de spécifier 25 décimales n'apporte pas de précision supplémentaire au nombre affiché, qui reste tributaire de la résolution du type double dans lequel la pseudo‑constante PI (définie pourtant avec 31 décimales dans le fichier Arduino.h G) est implicitement convertie, sachant que sur une carte Uno, le type double est implémenté avec la même précision que le type float (cf. chap. C3‑V ).
   L'instruction Serial.print(123456789.012345, 2) affiche :
   123456792.00
   sur le moniteur série.
   Là encore, le nombre affiché diffère de celui spécifié à cause de sa conversion implicite dans le type double qui n'est implémenté qu'en simple précision.

3. Si l'expression prend une valeur de caractère ou de chaîne de caractères, alors la syntaxe d'appel est simplement :
   Serial.print(expression) A
   avec des résultats identiques à ceux obtenus par appel de la méthode write (cf. supra ).

   Pour tester la méthode print appliquées à des caractères ou des chaînes de caractères, comme précédemment, on fait l'hypothèse que le programme s'exécute sur une carte Arduino reliée à un poste de travail où le moniteur série est activé, la liaison série étant initialisée (cf. supra  pour le squelette du programme de test qu'on peut utiliser).

   Dans la zone d'affichage du moniteur série :

   • L'instruction Serial.print('e') donne e mais Serial.print('é') donne ⍰. On est confronté au même problème qu'avec la méthode write (cf. supra ), tout simplement parce que les caractères encodés en multi‑octets dans le format UTF‑8 ne sont pas pris en charge dans les expressions de valeurs de caractères – cf. chap. C3‑IX .
   • En revanche, l'instruction Serial.print("Hé") restitue bien la chaîne de caractère Hé, encodée par défaut en UFT‑8.

Spécificité de la méthode println

Gestion du buffer d'émission

On vient de voir que les méthodes write ou print(ln) se résument in fine à écrire des octets en tête de buffer d'émission.

Quant au transfert de ces octets dans le registre d'émission puis leur sérialisation en signal logique sur la broche TX, cela est effectué en arrière-plan de l'exécution du programme.

La préservation de l'intégrité des données se paye donc par une potentielle baisse de réactivité du programme. Pour prévenir ce phénomène, le module de bibliothèque HardwareSerial fournit :

• flush A, une méthode pour attendre que le buffer soit vide ;
• availableForWrite A, une méthode pour connaître le nombre d'éléments disponibles dans le buffer.

  if (Serial.availableForWrite() >= 17) { // message not urgent
    Serial.println("Wait, please...");
  } 

Gestion de la zone d'affichage du moniteur série

Opérations d'entrée par liaison série

Principe général d'une opération d'entrée

Méthodes de lecture

Le framework Arduino met à disposition du codeur une dizaine de méthodes de lecture associées à l'objet Serial. On peut les classer en deux catégories :

• les méthodes de bas niveau available, peek et read, définies dans le fichier hardwareSerial.cpp ;
• les méthodes de haut niveau, notamment readString, parseInt ou parseFloat, définies dans le fichier Stream.cpp.

Seules les méthodes citées ci‑dessus seront détaillées ci‑après. Pour les autres, on se reportera au lien suivant A.

Temporisation des méthodes de haut niveau

Gestion des fins de ligne dans la barre de saisie

Lorsque la barre de saisie du moniteur série est active (état signalé par le curseur clignotant dans la barre), l'appui sur la touche ENTRÉE ↵ du clavier est traité de différentes manières selon l'option choisie dans le menu déroulant en bas de la fenêtre (cf. la capture d'écran ci‑contre).

Lecture unitaire d'octets

La méthode read

void setup()
{
  delay(500);
  Serial.begin(115200);
  Serial.println();
  Serial.flush();
}

void loop()
{
  if (Serial.available()) {
    byte readByte = /* type your statement here */;
    Serial.print(readByte);
  }
  Serial.println();
}

  delay(1000);

Lecture de chaînes de caractères

Lecture de nombres formatés

La méthode parseInt

    int readInt = /* type your statement here */;

La méthode parseFloat

    float readFloat = /* type your statement here */;

while (Serial.available() > 0) {
  Serial.read(); // all bytes in _rx_buffer are lost 
}