LOCODUINO

Forum de discussion
Dépôt GIT Locoduino
Flux RSS

samedi 27 mai 2017

43 visiteurs en ce moment

Des bus de communication pour l’Arduino

Un Arduino c’est bien, deux Arduino c’est mieux.

. Par : Jean-Luc

Un bus de communication permet d’échanger des informations entre des composants sur une même carte de circuit imprimé ou entre des cartes. Il permet donc également d’échanger des informations entre les Arduino. On trouve également des bus de communication dans les composants eux-mêmes où ils servent à l’échange d’informations entre des sous-composants. De manière générique, les composants, ou les Arduino, sont appelés des nœuds. Le bus réalise donc une connexion entre les nœuds. Le sens du mot bus est similaire à celui des bus urbains. Tous deux viennent du latin omnibus qui, dans ce contexte, signifie utilisable par tous c’est à dire tous les nœuds.

L’Arduino offre d’origine 2 bus de communication : le bus I2C   et le bus SPI  . Tous deux sont gérés par des circuits matériels intégrés à l’Arduino. La ligne série, disponible sur les broches 0 et 1 des Arduino n’est pas un bus car seuls deux nœuds peuvent être connectés ensemble par ce moyen. On peut également mettre en œuvre des bus ad-hoc en utilisant les entrées/sorties numériques de l’Arduino. C’est par exemple ce qui se passe quand on connecte un afficheur LCD alphanumérique. Il existe également des circuits intégrés que peuvent être ajoutés pour gérer d’autres bus, comme le bus CAN.

Nous reviendrons sur ces bus dans des articles dédiés. Pour le moment nous allons nous concentrer sur les principes de fonctionnement d’un bus.

Une affaire de protocole

Un bus est lié à un protocole qui définit la manière dont le bus est utilisé. Un protocole décrit les étapes qui doivent être suivies pour que tous les nœuds en communication se comprennent. Un protocole n’est pas limité à l’informatique et aux bus informatiques. Si vous lisez ceci, c’est que vous vous intéressez aux chemins de fer où les protocoles ont été utilisés avant l’invention des ordinateurs et le sont encore. Par exemple, les chemins de fer allemands définissent un protocole de gestion de la circulation des trains entre les gares sur les lignes à voie unique avec des opérateurs humains :

Protocole de communication pour la circulation des trains sur les lignes dépourvue de cantonnement automatique en Allemagne
Traduit de German Block and Interlocking Principles par Jörn Pachl. Reproduit avec l’accord de l’auteur que je remercie au passage.

Le médium de communication est ici le téléphone. Il y a un second protocole caché dans l’envoi et la réception des messages symbolisés par les flèches bleues et vertes sur la figure. Lorsque le chef de gare A envoie un message au chef de gare C, le protocole est le suivant :

Chef A appelle Chef C, B écoute
Chef A : Message train. Acceptez vous le train 52180 ?
Chef C : Train 52180 : Oui !
Chef A : Je répète : Train 52180, Oui !
Chef C : C’est correct !

On voit ici un second protocole visant à s’assurer que les messages sont transmis de manière fiable avec de la redondance (les chefs répètent les messages) et des acquittements (les chefs répondent à chaque message). On dit que les protocoles sont empilés et on parle même de pile de protocoles.

Les nœuds sur un réseau informatique ne font pas différemment et les protocoles sont également empilés. Il y a également quelques détails à régler comme le médium de communication et la façon dont on y accède (le téléphone ne va pas être utilisé) ainsi que la façon dont l’information est transmise (les nœuds n’utilisent pas de messages vocaux).

Bus maître-esclave et bus multi-maître

Un seul maître de bus

Avec un bus maître-esclave, le problème de l’accès au médium est résolu de manière simple : un seul nœud initie la communication, le maître, et les autres nœuds, les esclaves, ne communiquent qu’avec le maître et ne peuvent pas communiquer entre eux. Le protocole que nous avons vu ci-dessus ne peut pas être mis en œuvre de cette manière. Si on devait le transposer, il faudrait un grand chef de gare centrale. Ce grand chef de gare interrogerait tous les chefs de gare, l’un après l’autre pour demander à chacun si il a quelque chose à dire et s’occuperait de réexpédier les messages entre les chefs.

Ce mode de fonctionnement a le mérite de la simplicité mais nécessite plus de communications que nécessaire et demande un travail énorme au maître de bus.

le bus SPI   entre dans cette catégorie.

Plusieurs maîtres de bus

Dans un bus multi-maître, l’accès au médium nécessite un arbitrage. Dans l’exemple de protocole humain que nous avons donné, l’arbitrage est réalisé par le standard téléphonique. Si la ligne du correspondant est occupé, il faut réessayer plus tard. L’arbitrage doit remplir certaines fonctions. L’une d’entre elles est l’équité. Toujours dans notre exemple humain, l’équité n’est pas respectée : le standard téléphonique fonctionne selon un mode premier arrivé, premier servi. Il se peut donc que le chef de gare A n’arrive jamais à contacter le chef de gare C si la ligne de C est toujours occupée par d’autres communications.

Il est donc nécessaire de disposer d’un arbitrage qui soit intrinsèquement équitable ou bien que l’on puisse prédire : par exemple, on sait par construction que le chef de gare C ne sera pas contacté plus d’une fois par heure et pour une durée qui ne dépasse pas 6 minutes. Si tous les chefs de gares susceptibles de contacter C s’accordent sur les horaires, chacun pourra lui parler. On peut également résoudre ce problème d’accès au médium par un système de priorité. Dans ce cas la fréquence et la durée d’accès des plus prioritaires déterminera les créneaux laissés libres aux moins prioritaires.

Les bus I2C   et CAN entrent dans cette catégorie.

Contrôle de la transmission

Le contrôle de la transmission peut faire intervenir des signaux de contrôle en plus du ou des signaux de données. Ces signaux de contrôle permettent, par exemple, de signaler qu’une transmission débute, qu’une transmission se termine ou encore de signaler si il s’agit d’un envoi ou d’un réception. Il existe plusieurs façon de faire cela. Il peut également s’agir d’une horloge qui rythme la transmission.

Exemple : le bus I2C est constitué de deux signaux, l’un transporte l’horloge (SCL) qui rythme l’envoi des données, l’autre les adresses et données (SDA) elles même, bit après bit. Par ailleurs, l’état HIGH ou LOW de SCL combiné avec l’état HIGH ou LOW de SDA ont des significations particulières.

Le contrôle de la transmission peut également être mélangée avec les données. Dans ce cas des successions de données de valeur particulière et prédéterminée transportent ces informations de contrôle.

Exemple : dans le bus CAN, il n’y a que les fils de données. Une partie de chaque message constitue des informations de contrôle.

Quoiqu’il en soit, il est nécessaire d’avoir une information de contrôle permettant d’indiquer à quel moment les données transmises sont pertinentes. Cette information de contrôle peut prendre la forme d’une horloge dont les transitions, LOW vers HIGH ou HIGH vers LOW vont indiquer à quel moment la donnée est prête à être lue sur le ou les fils qui la transportent mais peut aussi être un signal de validité sur état comme dans la communication avec un écran LCD.

Cette horloge peut être soit explicite, il s’agit d’un fil, et piloté par le maître de bus comme c’est le cas dans l’I2C et le SPI ou soit implicite. Dans ce cas, qui ne se trouve que dans les bus série, émetteur et récepteur connaissent la vitesse de transmission et possèdent chacun une horloge. Comme les horloges ne sont pas synchrones, le récepteur recale son horloge en observant les changement d’état des données.

Transmission de l’information

Bus parallèle ou bus série

Le mode de transmission détermine combien de fils sont nécessaires à la transmission des données entre l’émetteur et le récepteur. Un bus parallèle transmet plusieurs bits en même temps sur plusieurs fils alors qu’un bus série transmet un bit à la fois sur un seul fil. En réalité la dichotomie n’est pas aussi nette. Par exemple, la connexion d’un écran LCD avec un bus 4 bits, voir à ce propos « Les écrans LCD alphanumériques » utilise les deux modes de transmissions. 4 bits sont transmis en même temps mais un octet est transmis en deux séries de 4 bits.

Codage des données par l’état ou le temps

Codage par l’état

Les données peuvent être codées par leur état, HIGH ou LOW. Émetteur et récepteur sont d’accord sur la vitesse de transmission. Le bus a un état de repos, HIGH par exemple. Quand une donnée doit être transmise, un bit LOW est transmis. Il indique au récepteur qu’un message va arriver et lui permet de caler son horloge pour la réception. Les bits qui suivent constituent la donnée que le récepteur lit en se servant de son horloge propre. Le bus CAN fonctionne de cette manière. La communication par la ligne série de l’Arduino, bien que n’étant pas un bus, fonctionne également de cette manière.

Codage par le temps

Le codage des données par le temps, également spécifique aux bus série, consiste à convenir d’une durée pour la transmission d’un 0 et d’une durée, différente et suffisamment distincte, pour la transmission d’un 1. Le comptage de temps entre l’émetteur et le récepteur doit être identique. Deux façons de coder de cette manière sont possibles. La première est de changer la durée d’une période du signal qui est transmis selon la valeur du bit. C’est le mode de fonctionnement du bus DCC   qui a déjà été présenté dans « L’Arduino et le système de commande numérique DCC ». La seconde façon de faire consiste à changer le rapport cyclique, c’est à dire la durée passée à l’état haut sur la période du signal. Par exemple, le 0 sera représenté par un rapport cyclique de 33% et le 1 par un rapport cyclique de 66%. C’est le mode de fonctionnement des DEL WS2812B.

Les critères de comparaison

Comparer des bus n’est pas chose aisée. Si on se limite à nos Arduino, le nombre de bus disponible n’est pas si élevé. Tout d’abord 2 bus sont disponibles d’origine : le SPI et l’I2C. On peut raisonnablement envisager 2 autres bus en ajoutant du matériel : l’Ethernet et le CAN. Parmi les critères de comparaison on retiendra la facilité de mise en œuvre, la quantité de logiciel à écrire, l’adéquation avec notre domaine et les performances. Nous n’allons pas comparer exhaustivement ces bus ici. Cette comparaison fera l’objet d’un article dédié après l’examen des 4 bus.

Le SPI est un bus série rapide mono-maître extrêmement simple. Par défaut sur l’Arduino sa vitesse est de 4Mbits/s. Ses caractéristiques seront examinées dans un article dédié. Il est réservé à la communication entre composants sur une même carte ou entre un Arduino et son shield   et n’est pas approprié à une communication entre cartes sur une plus longue distance.

L’I2C est également un bus série mono-maître mais de performance plus modeste. Sur l’Arduino, il est de 10 à 40 fois plus lent que le SPI. Il peut être employé sur une distance raisonnable entre cartes et peut donc être envisagé comme bus de rétro-signalisation. Par défaut sur l’Arduino, sa vitesse est de 100kbits/s.

L’Ethernet est un bus rapide multi-maître. Les shields   disponible pour l’Arduino permettent théoriquement des vitesses de 10Mbits/s. En pratique cette vitesse n’est jamais atteinte. L’Ethernet ayant été conçu pour la communication d’importante quantités de données entre ordinateurs, le nombre d’octets transmis en 1 communication est important, trop important en fait, ce qui grève ses performances pour la transmission des petites quantités de données dont nous avons besoin sur nos réseaux. Cela ne le disqualifie pas entièrement car la performance de base est importante. Un autre problème est la topologie du réseau de communication. En utilisant un shield   Ethernet, il est nécessaire de câbler en point à point chaque Arduino avec un switch. Cette topologie n’est pas des plus adaptée à nos applications.

Le CAN est un bus de performance intermédiaire et permet des vitesses de transmission jusqu’à 1Mbits/s sur une distance de 30 mètres. C’est ce qu’on appelle un bus de terrain, conçu pour les véhicules routiers puis utilisé dans les avions et les équipements industriels. Un message peut transmettre de 0 [1] à 8 octets. Ses caractéristiques en font un très bon candidat comme bus de rétro-signalisation. Un article dédié présentera ce bus en détails.

[1Ce qui sert à la signalisation d’un événement.

5 Messages

Réagissez à « Des bus de communication pour l’Arduino »

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rubrique « Matériel »

Fonctionnement et pilotage d’une DEL

Qu’est ce qu’une carte Arduino ?

Amplifier le signal de sortie d’un ARDUINO avec un ULN 2803

Résistances, kézako ?

Relais électromagnétique

Les diodes classiques

Détecteurs à ultrasons

La carte Arduino Uno

Bouton poussoir

Les différents types de mouvements d’un servo-moteur

Les encodeurs en quadrature

Les écrans LCD alphanumériques

Des bus de communication pour l’Arduino

Les interrupteurs

Le microcontrôleur ATtiny45 (1)

Le microcontrôleur ATtiny45 (2)

Le microcontrôleur ATtiny45 (3)

Le microcontrôleur ATtiny45 (4)

Le microcontrôleur ATtiny45 (5)

Le microcontrôleur ATtiny45 (6)

Signaux lumineux et Arduino

Les shields de prototypage et de connexion

Commande de moteur à courant continu

Les derniers articles

Commande de moteur à courant continu


Christian Bézanger

Le microcontrôleur ATtiny45 (6)


Christian Bézanger

Les shields de prototypage et de connexion


Christian Bézanger

Le microcontrôleur ATtiny45 (5)


Christian Bézanger

Signaux lumineux et Arduino


Christian Bézanger

Le microcontrôleur ATtiny45 (4)


Christian Bézanger

Le microcontrôleur ATtiny45 (3)


Christian Bézanger

Le microcontrôleur ATtiny45 (2)


Christian Bézanger

Le microcontrôleur ATtiny45 (1)


Christian Bézanger

Les interrupteurs


Thierry

Les articles les plus lus

Qu’est ce qu’une carte Arduino ?

Commande de moteur à courant continu

Les écrans LCD alphanumériques

La carte Arduino Uno

Bouton poussoir

Le microcontrôleur ATtiny45 (1)

Détecteurs à ultrasons

Fonctionnement et pilotage d’une DEL

Les shields de prototypage et de connexion

Les diodes classiques