[ Arduino 301] Généralités sur la voie série

La communication… que ferait-on sans ! Le téléphone, Internet, la télévision, les journaux, la publicité… rien de tout cela n’existerait s’il n’y avait pas de communication. Évidemment, ce n’est pas de ces moyens là dont nous allons faire l’objet dans la partie présente. Non, nous allons voir un moyen de communication que possède la carte Arduino. Vous pourrez ainsi faire communiquer votre carte avec un ordinateur ou bien une autre carte Arduino ! Et oui ! Elle en a sous le capot cette petite carte ! 😉

Communiquer, pourquoi ?

Nous avons vu dans la partie précédente où nous faisions nos premiers pas avec Arduino, comment utiliser la carte. Nous avons principalement utilisé des LED pour communiquer à l’utilisateur (donc vous, à priori) certaines informations. Cela pouvait être une LED ou un groupe de LED qui peut indiquer tout et n’importe quoi, ou bien un afficheur 7 segments qui affiche des chiffres ou certains caractères pouvant tout aussi bien indiquer quelque chose. Tout dépend de ce que vous voulez signaler avec les moyens que vous mettez à disposition. On peut très bien imaginer un ensemble de LED ayant chacune un nom, sigle ou autre marqueur pour indiquer, selon l’état d’une ou plusieurs d’entre-elles, un mode de fonctionnement ou bien une erreur ou panne d’un système. Cependant, cette solution reste tout de même précaire et demande à l’utilisateur d’être devant le système de signalisation. Aujourd’hui, avec l’avancée de la technologie et du « tout connecté », il serait fâcheux de ne pouvoir aller plus loin. Je vais donc vous présenter un nouveau moyen de communication grâce à la voie série (ou « liaison série »), qui va vous permettre de communiquer des informations à l’utilisateur par divers intermédiaires. A la fin de la partie, vous serez capable de transmettre des informations à un ordinateur ou une autre carte Arduino.

Transmettre des informations

Tel est le principal objectif de la communication. Mais comment transmettre des informations… et puis quelles informations ? Avec votre carte Arduino, vous aurez certainement besoin de transmettre des mesures de températures ou autres grandeurs (tension, luminosité, etc.). Ces informations pourront alimenter une base de donnée, servir dans un calcul, ou à autre chose. Tout dépendra de ce que vous en ferez.

Émetteur et récepteur

Lorsque l’on communique des informations, il faut nécessairement un émetteur, qui va transmettre les informations à communiquer, et un récepteur, qui va recevoir les informations pour les traiter.

Dans le cas présent, deux carte Arduino communiquent. L’une communique à l’autre tandis que l’autre réceptionne le message envoyé par la première.

Pourtant, il y a deux flèches sur ton dessin. L’autre aussi, qui réceptionne le message, peut envoyer des données ?

Absolument ! Cependant, tout dépend du type de communication.

La communication en trois cas

Pour parler, on peut par exemple différencier trois types de conversations. A chaque conversation, il n’y a que deux interlocuteurs. On ne peut effectivement pas en faire communiquer plus dans notre cas ! On dit que c’est une communication point-à-point.

  • Le premier type serait lorsqu’un interlocuteur parle à son compère sans que celui-ci dise quoi que ce soit puisqu’il ne peut pas répondre. Il est muet et se contente d’écouter. C’est une communication à sens unilatérale, ou techniquement appelée communication simplex. L’un parle et l’autre écoute.
  • Le deuxième type serait une conversation normale où chacun des interlocuteurs est poli et attend que l’autre est finie de parler pour parler à son tour. Il s’agit d’une communication half-duplex. Chaque interlocuteur parle à tour de rôle.
  • Enfin, il y a la conversation du type « débat politique » (ce n’est évidemment pas son vrai nom :mrgreen: ) où chaque interlocuteur parle en même temps que l’autre. Bon, cela dit, ce type de communication marche très bien (pas au sens politique, je parle au niveau technique !) et est très utilisé ! C’est une communication dite full-duplex.

A notre échelle, Arduino est capable de faire des communications de type full-duplex, puisqu’elle est capable de comprendre son interlocuteur tout en lui parlant en même temps.

Le récepteur

Qu’en est-il ? Eh bien il peut s’agir, comme je le sous-entendais plus tôt, d’une autre carte Arduino. Cela étant, n’importe quel autre appareil utilisant la voie série et son protocole de communication pourrait communiquer avec. Cela peut être notamment un ordinateur, c’est d’ailleurs le principal interlocuteur que nous mettrons en relation avec Arduino.

C’est quoi ça, un protocole de communication ?

C’est un ensemble de règles qui régissent la façon dont communiquent deux dispositifs entre eux. Cela définit par exemple le rythme de la conversation (le débit de parole des acteurs si vous préférez), l’ordre des informations envoyées (la grammaire en quelque sorte), le nombre d’informations, etc… On peut analogiquement comparer à une phrase en français, qui place le sujet, le verbe puis le complément. C’est une forme de protocole. Si je mélange tout ça, en plaçant par exemple le sujet, le complément et le verbe, cela donnerait un style parlé de maître Yoda… bon c’est moins facilement compréhensible, mais ça le reste. En revanche, deux dispositifs qui communiquent avec un protocole différent ne se comprendront pas correctement et pourraient même interpréter des actions à effectuer qui seraient à l’opposé de ce qui est demandé. Ce serait en effet dommage que votre interlocuteur « donne le chat à manger » alors que vous lui avez demandé « donne à manger au chat » :mrgreen: Bref, si les dispositifs communiquant n’utilisent pas le bon protocole, cela risque de devenir un véritable capharnaüm !

La norme RS232

Des liaisons séries, il en existe un paquet ! Je peux en citer quelques unes : RS-232, Universal Serial Bus (USB), Serial ATA, SPI, … Et pour dire, vous pouvez très bien inventer votre propre norme de communication pour la voie série que vous décidez de créer. L’inconvénient, bien que cela puisse être également un avantage, il n’y a que vous seul qui puissiez alors utiliser une telle communication.

Et nous, laquelle allons-nous voir parmi celles-là ? Il y en a des meilleurs que d’autres ? oO

D’abord, nous allons voir la voie série utilisant la norme RS-232. Ensuite, oui, il y en a qui ont des avantages par rapport à d’autres. On peut essentiellement noter le type d’utilisation que l’on veut en faire et la vitesse à laquelle les dispositifs peuvent communiquer avec.

Applications de la norme

La norme RS-232 s’applique sur trois champs d’une communication de type série. Elle définit le signal électrique, le protocole utilisé et tout ce qui est lié à la mécanique (la connectique, le câblage, etc…).

La mécanique

Pour communiquer via la voie série, deux dispositifs doivent avoir 3 câbles minimum.

  • Le premier câble est la référence électrique, communément appelée masse électrique. Cela permet de prendre les mesures de tension en se fixant un même référentiel. Un peu lorsque vous vous mesurez : vous mesurez 1,7 mètre du sol au sommet de votre tête et non pas 4,4 mètre parce que vous êtes au premier étage et que vous vous basez par rapport au sol du rez-de-chaussé. Dans notre cas, on considérera que le 0V sera notre référentiel électrique commun.
  • Les deux autres câbles permettent la transmission des données. L’un sert à l’envoi des données pour un émetteur, mais sert aussi pour la réception des données venant de l’autre émetteur. Idem pour l’autre câble. Il permet l’émission de l’un et la réception de l’autre.

Deux cartes Arduino reliées par 3 câbles :
  • Le noir est la masse électrique commune
  • Le vert est celui utilisé pour l’envoi des données de la première carte (à gauche), mais sert également à la réception des données envoyées pour la deuxième carte (à droite)
  • Le orange est celui utilisé pour l’envoi des données de la deuxième carte (à droite), mais sert également à la réception des données envoyées pour la première carte (à gauche)

Cela, il s’agit du strict minimum utilisé. La norme n’interdit pas l’utilisation d’autres câbles qui servent à faire du contrôle de flux et de la gestion des erreurs.

Le signal électrique et le protocole

Avant tout, il faut savoir que pour communiquer, deux dispositifs électronique ou informatique utilisent des données sous forme de bits. Ces bits, je le rappel, sont des états logiques (vrai ou faux) qui peuvent être regroupés pour faire des ensembles de bits. Généralement, ces ensembles sont constitués de 8 bits qui forment alors un octet.

Les tensions utilisées

Ces bits sont en fait des niveaux de tension électrique. Et la norme RS-232 définit quelles tensions doivent être utilisées. On peut spécifier les niveaux de tension imposés par la norme dans un tableau, que voici :

Niveau logique 0 Niveau logique 1
Tension électrique minimale +3V -3V
Tension électrique maximale +25V -25V

Ainsi, toutes les tensions au delà des valeurs imposées, donc entre -3V et +3V, au dessous de -25V et au dessus de +25V, sont hors normes. Pour les tensions trop élevées (aux extrêmes de + et -25V) elles pourraient endommager le matériel. Quand aux tensions comprises entre + et -3V, eh bien elles sont ignorées car c’est dans ces zones là que se trouvent la plupart et même la quasi totalité des parasites. C’est un moyen permettant d’éviter un certain nombre d’erreurs de transmissions.

Les parasites dont je parle sont simplement des pics de tensions qui peuvent survenir à cause de différentes sources (interrupteur, téléviseur, micro-ondes, …) et qui risquent alors de modifier des données lors d’une transmission effectuée grâce à la voie série.

Lorsqu’il n’y a pas de communication sur la voie série, il y a ce qu’on appelle un état de repos. C’est à dire un niveau logique toujours présent. Il s’agit du niveau logique 1. Soit une tension comprise entre -3V et -25V. Si cet état de repos n’est pas présent, c’est qu’il peut y avoir un problème de câblage.

Les données

Les données qui transitent par la voie série sont transmises sous une forme binaire. C’est à dire avec des niveaux logiques 0 et 1. Prenons une donnée que nous voudrions envoyer, par exemple la lettre « P » majuscule. Vous ne le saviez peut-être pas mais une lettre du clavier est codé sur un nombre de 8 bits, donc un octet. Réellement c’est en fait sur 7 bits qu’elle est codée, mais en rajoutant un 0 devant le codage, cela conserve sa valeur et permet d’avoir un codage de la lettre sur 8 bits. Ces codes sont définis selon la table ASCII. Ainsi, pour chaque caractère du clavier, on retrouve un codage sur 8 bits. Vous pouvez aller consulter cette table pour comprendre un peu comment elle fonctionne en suivant ce lien. En haut à gauche de la table ASCII, on observe la ligne : « Code en base… » et là vous avez : 10, 8, 16, 2. Respectivement, ce sont les bases décimale (10), octale (8), hexadécimale (16) et binaire (2). Certaines ne vous sont donc pas inconnues puisque l’on en a vu. Nous, ce qui va nous intéresser, c’est la base binaire. Oui car le binaire est une succession de 0 et de 1, qui sont les états logiques 0 (LOW) et 1 (HIGH). En observant la table, on tombe sur la lettre « P » majuscule et l’on voit sa correspondance en binaire : 01010000.

Je crois ne pas bien comprendre pourquoi on envoie une lettre… qui va la recevoir et pour quoi faire ? o_O

Il faut vous imaginer qu’il y a un destinataire. Dans notre cas, il s’agira avant tout de l’ordinateur avec lequel vous programmez votre carte. On va lui envoyer la lettre « P » mais cela pourrait être une autre lettre, une suite de lettres ou autres caractères, voire même des phrases complètes. Pour ne pas aller trop vite, nous resterons avec cette unique lettre. Lorsque l’on enverra la lettre à l’ordinateur, nous utiliserons un petit module intégré dans le logiciel Arduino pour visualiser le message réceptionné. C’est donc nous qui allons voir ce que l’on transmet via la voie série.

L’ordre et les délimiteurs

On va à présent voir comment est transmit un octet sur la voie série en envoyant notre exemple, la lettre « P ». Analogiquement, je vais vous montrer que cette communication par la voie série se présente un peu comme un appel téléphonique :

  1. Lorsque l’on passe un coup de fil, bien généralement on commence par dire « Bonjour » ou « Allo ». Ce début de message permet de faire l’ouverture de la conversation. En effet, si l’on reçoit un appel et que personne ne répond après avoir décroché, la conversation ne peut avoir lieu. Dans la norme RS-232, on va avoir une ouverture de la communication grâce à un bit de départ. C’est lui qui va engager la conversation avec son interlocuteur. Dans la norme RS-232, ce dernier est un état 0.
  2. Ensuite, vous allez commencer à parler et donner les informations que vous souhaitez transmettre. Ce sera les données. L’élément principal de la conversation (ici notre lettre ‘P’).
  3. Enfin, après avoir renseigné tout ce que vous aviez à dire, vous terminez la conversation par un « Au revoir » ou « Salut ! », « A plus ! » etc. Cela termine la conversation. Il y aura donc un bit de fin ou bit de stop qui fera de même sur la voie série. Dans la norme RS-232, c’est un état 1.
Chronogramme d'un échange sur la voie série

C’est de cette manière là que la communication série fonctionne. D’ailleurs, savez-vous pourquoi la voie série s’appelle ainsi ? En fait, c’est parce que les données à transmettre sont envoyées une par une. Si l’on veut, elles sont à la queue leu-leu. Exactement comme une conversation entre deux personnes : la personne qui parle ne peut pas dire plusieurs phrases en même temps, ni plusieurs mots ou sons. Chaque élément se suit selon un ordre logique. L’image précédente résume la communication que l’on vient d’avoir, il n’y a plus qu’à la compléter pour envoyer la lettre « P ».

Ha, je vois. Donc il y a le bit de start, notre lettre P et le bit de stop. D’après ce qu’on a dit, cela donnerait, dans l’ordre, ceci : 0 (Start) 01010000 (Données) et 1 (Stop). 😀

Eh bien… c’est presque ça. Sauf que les petits malins ingénieurs qui ont inventé ce protocole ont eu la bonne idée de transmettre les données à l’envers… Par conséquent, la bonne réponse était : 0000010101. Avec un chronogramme, on observerait ceci :

Chronogramme de la transmission de la lettre 'P'

Un peu de vocabulaire

Avant de continuer à voir ce que compose le protocole RS-232, voyons un peu de vocabulaire, mais sans trop en abuser bien sûr ! 😛 Les données sont envoyées à l’envers, je le disais. Ce qu’il faut savoir c’est que le bit de donnée qui vient après le bit de start s’appelle le bit de poids faible ou LSB en anglais pour Less Significant Bit. C’est un peu comme un nombre qui a des unités (tout à droite), des dizaines, des centaines, des milliers (à gauche), etc. Par exemple le nombre 6395 possède 5 unités (à droite), 9 dizaines, 3 centaines et 6 milliers (à gauche). On peut faire référence au bit de poids faible en binaire qui est donc à droite. Plus on s’éloigne et plus on monte vers… le bit de poids fort ou MSB en anglais pour Most Significant Bit. Et comme les données sont envoyées à l’envers sur la liaisons série, on aura le bit de poids faible juste après le start, donc à gauche et le bit de poids fort à droite. Avec le nombre précédent, si l’on devait le lire à l’envers cela donnerait : 5936. Bit de poids faible à gauche et à droite le bit de poids fort.

Il est donc essentiel de savoir où est le bit de poids faible pour pouvoir lire les données à l’endroit. Sinon on se retrouve avec une donnée erronée !

Pour regrouper un peu tout ce que l’on a vu sur le protocole de la norme RS-232, voici une image extraite de cette page Wikipédia :

Vous devrez être capable de trouver quel est le caractère envoyé sur cette trame… alors ? 😀 Indice : c’est une lettre… On lit les niveaux logiques de gauche à droite, soit 11010010 ; puis on les retourne soit 01001011 ; enfin on compare à la table ASCII et on trouve la lettre « K » majuscule. Attention aux tensions négatives qui correspondent à l’état logique 1 et les tensions positives à l’état logique 0.

La vitesse

La norme RS-232 définit la vitesse à laquelle sont envoyée les données. Elles sont exprimés en bit par seconde (bit/s). Elle préconise des vitesse inférieures à 20 000 bits/s. Sauf qu’en pratique, il est très courant d’utiliser des débits supérieurs pouvant atteindre les 115 200 bits/s. Quand on va utiliser la voie série, on va définir la vitesse à laquelle sont transférées les données. Cette vitesse dépend de plusieurs contraintes que sont : la longueur du câble utilisé reliant les deux interlocuteurs et la vitesse à laquelle les deux interlocuteurs peuvent se comprendre. Pour vous donner un ordre d’idée, je reprend le tableau fourni sur la page Wikipédia sur la norme RS-232 :

Débit en bit/s Longueur du câble en mètres (m)
2 400 900
4 800 300
9 600 150
19 200 15

Plus le câble est court, plus le débit pourra être élevé car moins il y a d’affaiblissement des tensions et de risque de parasites. Tandis que si la distance séparant les deux interlocuteurs grandie, la vitesse de communication diminuera de façon effective.

La gestion des erreurs

Malgré les tensions imposées par la norme, il arrive qu’il y ai d’autres parasites et que des erreurs de transmission surviennent. Pour limiter ce risque, il existe une solution. Elle consiste à ajouter un bit de parité. Vous allez voir, c’est hyper simple ! 😉 Juste avant le bit de stop, on va ajouter un bit qui sera pair ou impair. Donc, respectivement, soit un 0 soit un 1. Lorsque l’on utilisera la voie série, si l’on choisi une parité paire, alors le nombre de niveaux logiques 1 dans les données plus le bit de parité doit donner un nombre paire. Donc, dans le cas ou il y a 5 niveaux logiques 1 sans le bit de parité, ce dernier devra prendre un niveau logique 1 pour que le nombre de 1 dans le signal soit paire. Soit 6 au total :

Chronogramme pair

Dans le cas où l’on choisirait une parité impaire, alors dans le même signal où il y a 5 niveaux logiques 1, eh bien le bit de parité devra prendre la valeur qui garde un nombre impaire de 1 dans le signal. Soit un bit de parité égal à 0 dans notre cas :

Chronogramme impair

Après, c’est le récepteur qui va vérifier si le nombre de niveaux logiques 1 est bien égale à ce que indique le bit de parité. Dans le cas où une erreur de transmissions serait survenu, ce sera au récepteur de traiter le problème et de demander à son interlocuteur de répéter. Au fait, ne vous inquiétez pas, on aura l’occasion de voir tout ça plus tard dans les prochains chapitres. De quoi s’occuper en somme… 😈

Connexion série entre Arduino et …

Et on connecte quoi à où pour utiliser la voie série avec la carte Arduino et le PC ? C’est le même câblage ? Et on connecte où sur le PC ?

Là, on va avoir le choix…

Émulation du port série

Le premier objectif et le seul que nous mettrons en place dans le cours, va être de connecter et d’utiliser la voie série avec l’ordinateur. Pour cela, rien de plus simple, il n’y a que le câble USB à brancher entre la carte Arduino et le PC. En fait, la voie série va être émulée à travers l’USB. C’est une forme virtuelle de cette liaison. Elle n’existe pas réellement, mais elle fonctionne comme si c’était bien une vraie voie série. Tout ça va être géré par un petit composant présent sur votre carte Arduino et le gestionnaire de port USB et périphérique de votre ordinateur.

Le composant entouré en rouge gère l’émulation de la voie série

C’est la solution la plus simple et celle que nous allons utiliser pour vos débuts.

Arduino et un autre microcontrôleur

On a un peu abordé ce sujet, au début de la présentation sur la voie série. Mais, on va voir un peu plus de choses. Le but de connecter deux microcontrôleur ensemble est de pouvoir les faire communiquer entre eux pour qu’ils puissent s’échanger des données.

La tension des microcontrôleurs

Tension
NL0 0V
NL1 +5V

Contrairement à ce qu’impose la norme RS-232, les microcontrôleur ne peuvent pas utiliser des tensions négatives. Du coup, ils utilisent les seuls et uniques tensions qu’ils peuvent utiliser, à savoir le 0V et le +5V. Il y a donc quelques petits changement au niveau de la transmission série. Un niveau logique 0 correspond à une tension de 0V et un niveau logique 1 correspond à une tension de +5V. (cf. tableau ci-contre) Fort heureusement, comme les microcontrôleurs utilisent quasiment tous cette norme, il n’y a aucun problème à connecter deux microcontrôleurs entre-eux. Cette norme s’appelle alors UART pour Universal Asynchronous Receiver Transmitter plutôt que RS232. Hormis les tensions électriques et le connecteur, c’est la même chose !

Croisement de données

Il va simplement falloir faire attention à bien croiser les fils. On connecte le Tx (broche de transmission) d’un microcontrôleur au Rx (broche de réception) de l’autre microcontrôleur. Et inversement, le Tx de l’autre au Rx du premier. Et bien sûr, la masse à la masse pour faire une référence commune. Exactement comme le premier schéma que je vous ai montré :

Tx -> Rx, fil vert || Rx -> Tx, fil orange Masse -> Masse, fil noir

La couleur des fils importe peu, évidemment ! 😛

Arduino au PC

Le connecteur série (ou sortie DB9)

Alors là, les enfants, je vous parle d’un temps que les moins de vingt ans ne peuvent pas connaittttrrreuhhh… Bon on reprend ! Comme énoncé, je vous parle de quelque chose qui n’existe presque plus. Ou du moins, vous ne trouverez certainement plus cette « chose » sur la connectique de votre ordinateur. En effet, je vais vous parler du connecteur DB9 (ou DE9). Il y a quelques années, l’USB n’était pas si véloce et surtout pas tant répandu. Beaucoup de matériels (surtout d’un point de vue industriel) utilisaient la voie série (et le font encore). A l’époque, les équipements se branchaient sur ce qu’on appelle une prise DB9 (9 car 9 broches). Sachez simplement que ce nom est attribué à un connecteur qui permet de relier divers matériels informatiques entre eux.

Photos extraites du site Wikipédia – Connecteur DB9 Mâle à gauche ; Femelle à droite

A quoi ça sert ?

Si je vous parle de ça dans le chapitre sur la voie série, c’est qu’il doit y avoir un lien, non ? o_O Juste, car la voie série (je parle là de la transmission des données) est véhiculée par ce connecteur dans la norme RS-232. Donc, notre ordinateur dispose d’un connecteur DB9, qui permet de relier, via un câble adapté, sa connexion série à un autre matériel. Avant, donc, lorsqu’il était très répandu, on utilisait beaucoup ce connecteur. D’ailleurs, la première version de la carte Arduino disposait d’un tel connecteur !

La première version de la carte Arduino, avec un connecteur DB9

Aujourd’hui, le connecteur DB9 a déjà bien disparu mais reste présent sur les « vieux » ordinateurs ou sur d’autres appareils utilisant la voie série. C’est pourquoi, le jour où vous aurez besoin de communiquer avec un tel dispositif, il vous faudra faire un peu d’électronique…

Une petite histoire d’adaptation

Si vous avez donc l’occasion de connecter votre carte Arduino à un quelconque dispositif utilisant la voie série, il va falloir faire attention aux tensions…oui, encore elles ! Je l’ai déjà dis, un microcontrôleur utilise des tensions de 0V et 5V, qu’on appel TTL. Hors, la norme RS-232 impose des tensions positives et négatives comprise en +/-3V et +/-25V. Il va donc falloir adapter ces tensions. Pour cela, il existe un composant très courant et très utilisé dans ce type de cas, qu’est le MAX232.

Je vous laisse regarder la datasheet et comprendre un peu le fonctionnement. Aussi, je vous met un schéma, extrait du site internet sonelec-musique.com :

Le principe de ce composant, utilisé avec quelques condensateur, est d’adapter les signaux de la voie série d’un microcontrôleur vers des tensions aux standards de la norme RS-232 et inversement. Ainsi, une fois le montage installé, vous n’avez plus à vous soucier de savoir quelle tension il faut, etc…

En revanche, n’utilisez jamais ce composant pour relier deux microcontrôleurs entre eux ! Vous risqueriez d’en griller un. Ou alors il faut utiliser deux fois ce composant (un pour TTL->RS232 et l’autre pour RS232->TTL 🙄 ), mais cela deviendrait alors peu utile.

Donc en sortie du MAX232, vous aurez les signaux Rx et Tx au standard RS-232. Elles dépendent de son alimentation et sont en générale centrées autour de +/-12V. Vous pourrez par exemple connecter un connecteur DB9 à la sortie du MAX232 et relier la carte Arduino à un dispositif utilisant lui aussi la voie série et un connecteur DB9. Ou même à un dispositif n’utilisant pas de connecteur DB9 mais un autre (dont il faudra connaitre le brochage) et qui utilise la voie série.

Au delà d’Arduino avec la connexion série

Voici une petite annexe qui va vous présenter un peu l’utilisation du vrai port série. Je ne vous oblige pas à la lire, elle n’est pas indispensable et peu seulement servir si vous avez un jour besoin de communiquer avec un dispositif qui exploite cette voie série.

Le connecteur série (ou sortie DB9)

Le brochage au complet !

Oui, je veux savoir pourquoi il possède tant de broches puisque tu nous as dit que la voie série n’utilisait que 3 fils.

Eh bien, toutes ces broches ont une fonction bien précise. Je vais vous les décrire, ensuite on verra plus en détail ce que l’on peut faire avec :

  1. DCD : Détection d’un signal sur la ligne. Utilisée uniquement pour la connexion de l’ordinateur à un modem ; détecte la porteuse
  2. RXD : Broche de réception des données
  3. TXD : Broche de transmission des données
  4. DTR : Le support qui veut recevoir des données se déclare prêt à « écouter » l’autre
  5. GND : Le référentiel électrique commun ; la masse
  6. DSR : Le support voulant transmettre déclare avoir des choses à dire
  7. RTS : Le support voulant transmettre des données indique qu’il voudrait communiquer
  8. CTS : Invitation à émettre. Le support de réception attend des données
  9. RI : Très peu utilisé, indiquait la sonnerie dans le cas des modems RS232

Vous voyez déjà un aperçu de ce que vous pouvez faire avec toutes ces broches. Mais parlons-en plus amplement.

Désolé, je suis occupé…

Dans certains cas, et il n’est pas rare, les dispositifs communicant entre eux par l’intermédiaire de la voie série ne traitent pas les données à la même vitesse. Tout comme lorsque l’on communique avec quelqu’un, il arrive parfois qu’il n’arrive plus à suivre ce que l’on dit car il en prend des notes. Il s’annonce alors indisponible à recevoir plus d’informations. Dès qu’il est à nouveau prêt, il nous le fait savoir. Il y a un moyen, mis en place grâce à certaines broches du connecteur pour effectuer ce genre d’opération que l’on appelle le contrôle de flux. Il y a deux manières d’utiliser un contrôle de flux, nous allons les voir tout de suite.

Contrôle de flux logiciel

Commençons par le contrôle de flux logiciel, plus simple à utiliser que le contrôle de flux matériel. En effet, il ne nécessite que trois fils : la masse, le Rx et le TX. Eh oui, ni plus ni moins, tout se passe logiciellement. Le fonctionnement très simple de ce contrôle de flux utilise des caractères de la table ASCII, le caractère 17 et 19, respectivement nommés XON et XOFF. Ceci se passe entre un équipement E, qui est l’émetteur, et un équipement R, qui est récepteur. Le récepteur reçoit des informations, il les traite et stockent celles qui continuent d’arriver en attendant de les traiter. Mais lorsqu’il ne peut plus stocker d’informations, le récepteur envoie le caractère XOFF pour indiquer à l’émetteur qu’il sature et qu’il n’est plus en mesure de recevoir d’autres informations. Lorsqu’il est à nouveau apte à traiter les informations, il envoie le caractère XON pour dire à l’émetteur qu’il est à nouveau prêt à écouter ce que l’émetteur à a lui dire.

Contrôle de flux matériel

On n’utilisera pas le contrôle de flux matériel avec Arduino car la carte n’en est pas équipée, mais il est bon pour vous que vous sachiez ce que c’est. Je ne parlerai en revanche que du contrôle matériel à 5 fils. Il en existe un autre qui utilise 9 fils. Le principe est le même que pour le contrôle logiciel. Cependant, on utilise certaines broches du connecteur DB9 dont je parlais plus haut. Ces broches sont RTS et CTS.

Voilà le branchement adéquat pour utilise ce contrôle de flux matériel à 5 fils. Une transmission s’effectue de la manière suivante :

  • Le dispositif 1, que je nommerais maintenant l’émetteur, met un état logique 0 sur sa broche RTS1. Il demande donc au dispositif 2, le récepteur, pour émettre des données.
  • Si le récepteur est prêt à recevoir des données, alors il met un niveau logique 0 sur sa broche RTS2.
  • Les deux dispositifs sont prêts, l’émetteur peut donc envoyer les données qu’il a à transmettre.
  • Une fois les données envoyées, l’émetteur passe à 1 l’état logique présent sur sa broche RTS1.
  • Le récepteur voit ce changement d’état et sait donc que c’est la fin de la communication des données, il passe alors l’état logique de sa broche RTS2 à 1.

Ce contrôle n’est pas très compliqué et est utilisé lorsque le contrôle de flux logiciel ne l’est pas.

Avec ou sans horloge ?

Pour terminer, faisons une petite ouverture sur d’autres liaisons séries célèbres…

L’USB

On la côtoie tout les jours sans s’en soucier et pourtant elle nous entoure : C’est la liaison USB ! Comme son nom l’indique, Universal Serial Bus, il s’agit bien d’une voie série. Cette dernière existe en trois versions. La dernière, la 3.1, vient juste de sortir. Une des particularités de cette voie série est qu’elle se propose de livrer l’alimentation de l’équipement avec lequel elle communique. Par exemple votre ordinateur peut alimenter votre disque dur portable et en même temps lui demander des fichiers. Dans le cas de l’USB, la communication se fait de manière « maître-esclave ». C’est l’hôte (l’ordinateur) qui demande des informations à l’esclave (le disque dur). Tant qu’il n’a pas été interrogé, ce dernier n’est pas censé parler. Afin de s’y retrouver, chaque périphérique se voit attribuer une adresse. La transmission électrique se fait grâce à un procédé « différentiel » entre deux fils, D+ et D-, afin de limiter les parasites.

L’I2C

L’I²C est un autre protocole de communication qui fut tout d’abord propriétaire (inventé par Philips) et né de la nécessité d’interfacer de plus en plus de microcontrôleurs. En effet, à ce moment là une voie série « classique » ne suffisait plus car elle ne pouvait relier que deux à deux les microcontrôleurs. La particularité de cette liaison est qu’elle transporte son propre signal d’horloge. Ainsi, la vitesse n’a pas besoin d’être connu d’avance. Les données sont transportées en même temps que l’horloge grâce à deux fils : SDA (Data) et SCL (Clock). Comme pour l’USB, la communication se fait sur un système de maître/esclave.

30 commentaires

  1. Super intéressant, dommage que l’I2C ne soit que survolé, un tuto là-dessus serais tombé à pic ! (en plein dans la prog d’1master DUE et 2 slave MEGA)…si tu connais une bonne adresse (fr), je suis preneur !!

    • Tu vas rire mais j’ai un brouillon de commencé sur l’I2C (mais vide), j’attends d’avoir de la motivation et j’aurais aimé un composant pour jouer avec… Cependant, si un jour je me sent de le faire je le ferais ptet entre Arduino et RPi par exemple (les deux seuls trucs I2C qui traine sur mon bureau pour le moment)

  2. Merci pour ce tutoriel, Mais il reste quelque chose de pas clair pour moi: USB/Serie: quest-ce qui circule sur le fil : un protocole ou l’on ne reconnaitra pas les bits du « A » que l’on envoi? ou bien les 0 et 1 correspondant au caractères « A »?
    Autrement dit comment connecter 2 arduino entre eux via le simple port USB existant: quel sera le protocole a adopter?
    MON VRAI PROBLEME, le voila:
    J’ai un cas très concret qui me fait douter et me poser des questions:
    J’ai un appareil qui comporte une prise USB femelle qui est pilotable par un soft qui tourne sur un PC: Je relie les 2 avec un câble USB mâle / mâle et ils communiquent dans un mode de liaison série virtuelle 9600bauds, avec des commande de caractères courtes
    Si j’utilise hyperterminal (ou la fenêtre COM du soft Arduino) pour envoyer les même séquence a l’appareil celui-ci les reconnait bien et applique l’ordre reçu (les chaines de caractères sont identiques dans un sens ou vers l’autre sens: ca simplifie les choses…)
    Je programme une carte arduino nano pour reproduire ces séquences de caractère: Serial.print(« ABCD: »);
    Quand je branche l’arduino sur le PC le soft reconnait bien les chaine de caractères et applique bien les ordres.
    Alors je branche la carte arduino sur la prise de l’appareil: et là rien ne se passe (?!)

    Ma question est: le port USB de l’arduino ne permettrait pas de communiquer avec autre chose qu’un PC parceque le PC est le seul gestionnaire de cette prise USB.???
    Je suis dans un cas favorable ou il faut un câble mâle/mâle il est facile de brancher l’arduino a l’appareil,

    MAIS cela veut-il dire que les port USB des arduino ne peuvent pas communiquer ente eux ? ( même si on les raccordait avec un câble adapté? )
    Mystère…

    • Pour ca :
      > MAIS cela veut-il dire que les port USB des arduino ne peuvent pas communiquer ente eux ?

      La réponse est : OUI. L’USB de l’Arduino doit être géré par un PC ou autre. Il ne peut pas être utilisé en « Host » (sous entendu gestionnaire de périphérique). Pour relier deux arduino on passer alors par les broches Rx/Tx que l’on croisera.

      Du coup je suis pas sur d’avoir tout compris à ton problème mais une idée de la réponse sera ceci :
      Si ton périphérique est capable de gérer un USB Host, alors il pourra accueillir l’Arduino. Sinon, il faudra faire autrement.

      RS232 (et voie série) != USB (parce que l’USB embarque un paquet de truc qui existe pas sur la voie série)

      • Merci bien, j’ignorai comment fonctionnait les port USB plus habitué à RS232: J’ai bien compris désormais qu’il y a un USB Host .
        Donc mon appareil qui peut être commandé par un PC via USB (par un COM virtuel), ne pourra néanmoins jamais être commandé par le port usb d’un arduino pour remplacer le PC.
        Cet aspect Host est-il inscrit dans l’électronique sur le PC et pas dans le circuit interface du arduino ou bien existe-t-il des librairie Host pour arduino?
        Je viens de découvrir que c’était possible pour arduino Due mais pas pour les autres arduino!: il existe en effet une librairie Host.
        http://arduino.cc/en/Reference/USBHost
        Sinon pour les autres c’est un shiel : donc une autre électronique. dommage
        En tout cas merci pour votre réponse claire (dans mon cas je ne voulais pas démonter l’appareil pour accéder au Rx/Tx) mais simplement pluger un câble connecté a mon arduino pour commander mon appareil sans PC.
        Merci

  3. Bonjour,
    j’ai besoin de votre aide,
    je voudrais programmer une algorithme qui devrait faire la reconnaissance des formes en se basant sur les sorties de cette caméra : http://linksprite.com/wiki/index.php5?title=JPEG_Color_Camera_Serial_UART_Interface_(TTL_level) et Arduino. Sachant que la caméraY201 est une conception modulaire qui produit des images JPEG par UART, sous cette forme HEX : FF EC FF FE 00 24 60 80 0D 88 00 80 00 00 00 00 80 00 00 00 00 00 00 00 00 F0 80 40 81 13 80 B2
    1D 8E 1D 1D 1D 63 C7 67 C7 AC AC AC D6 AC AC AC AC D6 AC AC AC D6 AC AC D6 AC D4 AC AC D6 AC FE
    1D 8E 1D 1D 1D C7 C7 67 C7 AC D6 AC AC EC FE 00 61 C0 C0 80 FF C0 80 11 08 00 F0 80 40 81 01 76

    Merci

    • Bonjour !

      Ce blog n’est pas la pour faire de l’aide individualise sur des problemes complexes. Je peux répondre a des questions simples, mais la ce n’est pas vraiment le cas 😉 . Je te conseille d’aller demander de l’aide sur un forum comme ceux d’arduino.cc ou d’OpenClassrooms (rubrique électronique).
      Enfin, sache que l’Arduino n’est pas adapte pour faire du traitement d’images. Ce n’est qu’un petit microcontrôleur 8 bits après tout…

  4. Bonjour eskimon, super ton blog… Je suis entrain d’essayer de réaliser la liaison entre 2 arduinos (écrire dans la liaison série de l’un avec un ordi et récupérer les données avec l’autre arduino connecté à un second ordi) . la liaison PC seul se passe bien, je l’ai testée. Par contre quand je relis les 2 arduinos (sans oublier la masse bien sûr) le téléversement ne se passe plus bien, j’ai cette erreur : « avrdude: stk500_getsync(): not in sync: resp=0x00 » j’ai regardé dans les forums la raison pour laquelle on pouvait avoir ce genre d’erreur mais je ne trouve pas vraiment une réponse spécifique à mon problème. De plus quand je téleverse sans faire les liaisons et ensuite effectuer les liaisons Tx-Rx, lorsque j’écris dans le port série le second arduino ne reçoit rien et même le PC relié au premier arduino ne reçoit rien… Donc ce que je voudrais savoir c’est si j’ai oublié quelque chose parce que j’ai suivi ton tuto à la lettre et j’y arrive pas. En espérant que ce ne soit pas un question complexe 😉 Merci d’avance

    • Pour la première question (pas possible de programmer si la carte est branche a l’autre) c’est surement du au fait que les deux cartes s’embrouille l’une avec l’autre et du coup la communication déconne pendant la programmation
      Pour la seconde (communication entre les deux), as tu bien croise les fils Rx/Tx ?

      • Oui oui je les ai bien croisés… au fait maintenant ça marche, mon problème était dû au fait que j’utilisais de petits câbles de téléphones avec un petit diamètre… j’en ai donc cherché d’autres, un peu plus épais dans mon bazar et ça marche :D. Cependant là, j’ai les bons câbles mais je ne connais toujours pas leur épaisseur. Si donc une prochaine fois, j’ai besoin de câbles et que je n’ai rien sous la main c’est mort pour moi (vu que je ne sais pas lequel acheter :/). Tu ne le connaitrais pas toi, la bonne taille de câble et la longueur max sur laquelle elle peut fonctionner par hasard ? Merci en tout cas, ton blog et tes exos m’aident beaucoup ! 😉

        • Aucune idée, c’est quand même bizarre que de petits cables n’aient pas fait l’affaire… Je pense qu’il ne devait pas faire un contact très franc et que du coup ca ne passait pas comme il fallait… Pour ce qui est de la longueur max., ca doit pouvoir se trouver à grand renfort de google (ou de calcul mais j’ai pas/plus les formules…).

  5. Rebonjour eskimon, encore moi ! je suis vraiment relou hein ! :/ … Bon après avoir bien réussi l’interraction entre deux cartes arduino… Là ce que je voudrais c’est envoyer les données d’une balance à un arduino en passant par l’autre avec un cable rs232 / usb qui lui mm passera par un convertisseur usb femelle/femelle pour ensuite aller à l’arduino. En gros, je relie direct mon arduino à ma balance, je l’alimente avec une alim extérieure, je fais les liaisons Rx-Tx avec mon second arduino et j’attends de voir les données de ma balance sur mon second arduino. Je dois aussi préciser que quand je relis la balance directement à mon ordi et que j’ouvre son port com, je reçois bien ses données de pesée (un pilote a été installé avant). Cependant quand je fais mon petit montage, je ne reçois absolument rien du côté port com du second arduino, je pense même que le premier ne reçoit rien. Il me semble que je n’ai pas besoin du MAX232 vu que j’ai déja un convertiseur rs232/USB … je me demandais donc si ce n’est pas une librairie qui permet de lire ces données (comme le pilote) dont j’ai besoin. j’ai testé avec le Wire.h mais rien, ça ne marche toujours pas… T’aurais pas une idée dessus ? PS : j’espère que ce n’est pas une question difficile ! 😉

    • Je pense que tu as mis le doigt sur ce qu’il faut… Le pilote !
      On ne sait pas comment la balance envoie les données a l’ordinateur et comment elle exploite la liaison USB. Donc il est quasiment impossible de l’exploiter pour utiliser les données de la liaison sur une USB. Mais si ta balance est en RS232 et non pas en USB pur et dure, alors il y a un espoir 🙂
      Je te propose cependant d’ouvrir un sujet sur un forum comme ceux d’OpenClassrooms (section électronique), ce sera plus simple que cette section commentaire qui est plus fait pour des commentaires sur le tuto lui-même 🙂

  6. Deux petites coquilles que j’ai aperçu (c’est la nouit, alors il est possible que d’autres se planquent encore) :

    « On va lui envoyer la lettre “P” mais cela pourrait être une autre lettre, une suite de lettres ou autres caractères, voir même des phrases complètes. »
    Hormis le fait que je suis un adepte du « nous », c’est le mot « voire » qui a sa place avant « même », et non cet imposteur de « voir » !

    « Sauf que les –petits malins– ingéieurs qui ont inventé ce protocole »
    Manque le « n » à « ingénieurs ».

    Sinon nickel ! Ça m’a rappelé mes bons vieux cours d’électronique. :3

  7. bonjour,
    merci pour vos tutoriels, cela m’aide énormément.

     » A chaque conversation, il n’y a que deux interlocuteurs. On ne peut effectivement pas en faire communiquer plus dans notre cas !  »

    je me demandais s’il est possible de faire communiquer avec RS232 et les broches Rx/Tx plusieurs arduinos (plus que 2), par un système maître/ esclave, si le maître interroge chaque arduino chacun son tour (ou bien est-cela l’I2C ?)

    encore merci pour les tutos.

  8. Pingback: onglets utilisés en tpe | Jardiworld

  9. Bonjour,

    Je demande un éclairecissement sur un point de ton tuto ( trés bien fait, j’adore) sur ton exemple
    ou tu nous aprend le langage des bits avec la lettre K , tu nous dis que sa fait 11010010 ,
    or dans le lien que tu nous donne menant aux tableaux ,cette donnée n’existe pas .
    Est-ce du à moi qui est fait une erreurs de compréhension ou un changement du langage
    ( Je suis désolé pour mes fautes d’hortographes )

    Merci d’avance de me répondre.

  10. Pingback: What Could Go Wrong: Asynchronous Serial Edition - SHelfinger

  11. Pingback: What Could Go Wrong: Asynchronous Serial Edition | BH

  12. Pingback: What Could Go Wrong: Asynchronous Serial Edition – HackerWorld

  13. Pingback: What Could Go Wrong: Asynchronous Serial Edition – Vloda.com

  14. Pingback: What Could Go Wrong: Asynchronous Serial Edition | Ad Pub

  15. bonsoir , j’ai lu ,c’est instructif , je me permet de venir avec mes interrogations : la finalité est la commande d’un mécanisme que j’ai déjà programmé en python ; c’est convenable mais limité en vitesse et accessible à l’utilisateur et je voudrai améliorer : pour les moteurs ,switch et electrovannes le arduino semble bien convenir ; pour les affichages , boutons, labels ,enregistrements et séquençage global , du java sur le pc .
    Quand tout est au point , je pense que les échanges pc-arduino peuvent se faire par l’usb , par contre dans la mise au point je souhaiterai échanger avec des pins rx tx et un usb du pc ; ou pourrai-je trouver de bonnes infos sur une façon de réaliser une liaison bidirectionnelle rx tx et usb pc ?
    Merci pour vos tutos

  16. Suite et interrogations ; j’ai commandé un arduino méga (en Chine) ; dans mon systeme , le pc devra trouver le arduino en automatique (pas question de demander à l’utilisateur de le chercher ) ; là je vois à peu près , le pc envoie des valeurs sur les ports com et celui qui répond est le bon
    ——————-
    Pour le reste, j’ai regardé les exemples donnés sur https://www.arduino.cc/en/Tutorial et là je patauge , voila mon trouble:
    -on déclare une serial.begin ……Ok
    je pense que c’est la liaison arduino-pc , qui se fera sur un certain port COM
    -dans les exemples donnés , on peut déclarer un serial1.begin et il est précisé que l’on a besoin que d’un pc , d’un arduino et d’un cable ; est-ce que cela ouvre un autre port COM sur le pc au travers de la liaison usb ?
    -les pin 10 , 11,etc qui peuvent être utilisées en rx ou tx , sont-elles utilisables pour causer avec d’autres appareils seulement en liaison filaire?
    Bon , je suis pas satisfait de ce que j’ai écrit , mais si quelqu’un a de bonnes bases dans les liaisons série , je le remercie de m’éclairer

Laisser un commentaire