Retour à la première
page
1. Où est le problème ?
2. Communication en série :
je vous en mets combien ?
3. L’accusé de réception : Tu
m’entends ?
4. Un réseau, des adresses : Qui
cause à qui ?
5. Les conditions de départ et de
fin
Il reste à comprendre pourquoi Toto envoie une condition
de stop alors qu’il pourrait très bien ne se servir que de ‘restart’.
En fait, tout est histoire de politesse. Un maître est, en principe, prévu
pour libérer la ligne I˛C sitôt qu’il n’en a plus besoin, pour
laisser la place à... un autre maître qui en aurait besoin.
Et oui, la communication I˛C prévoit non seulement une construction en réseau d’esclaves, mais aussi de maîtres. Comme sur un réseau informatique de type Ethernet, si tu connais, il y a partage de la ligne.
Avant d’utiliser la ligne I˛C, un maître doit observer si elle est disponible. Pour simplifier, disons qu’il peut le savoir en observant si les lignes SCL et SDA sont inactives. Si c’est le cas, il peut prendre le contrôle. Comme il aime bien voir sa ligne disponible, il doit penser aux autres maîtres connectés au bus I˛C qui sont comme lui. C’est pour cette raison qu’à la fin de son utilisation, chaque maître doit envoyer une condition de stop. Cette opération rend inactives les deux lignes SCL et SDA. N’importe quel maître peut alors prendre la ligne.
A savoir : Non seulement les esclaves ont une
adresse, mais les maîtres aussi. Cette qualité permet à
un maître de s’adresse à un autre maître pour lui transmettre
ou lui demander des informations.
Nous n’entreront pas dans les détails de l’utilisation multi-maîtres
du bus I˛C.
Pénultième remarque : je t’épargne la revue des conflits possibles dans une communication I˛C, ainsi que leur gestion par les différents composants. Sache que c’est une force du bus I˛C. Peut-être pour un article ultérieur qui parlerait de la mise au point d’un logiciel de contrôle du bus.
![]() |
Il est possible de connecter sur une même ligne I˛C plusieurs composants I˛C maîtres en plus des composants I˛C esclaves. |