« Fonctionnement d'un ordinateur/Les bus et liaisons point à point (généralités) » : différence entre les versions
Contenu supprimé Contenu ajouté
m →Le codage des données/commandes sur un bus : Suppression d'un exemple "erroné" |
|||
Ligne 168 :
==Le codage des données/commandes sur un bus==
Sur les bus série, ces trames sont transmises bit par bit grâce à des circuits spécialisés : la trame est mémorisée dans un registre à décalage, qui envoie celle-ci bit par bit sur sa sortie (reliée au bus). Pour les bus parallèles, les choses peuvent être plus variables. Il est possible d'envoyer des trames plus grosses que la largeur du bus : la trame est envoyée par paquets de données, octet par octet ou byte par byte. Mais sur la plupart des bus parallèles, toute la trame est envoyée d'un coup sur le bus : cela simplifie fortement le codage de la trame, vu qu'il n'y a pas besoin de coder la longueur de la trame ou de préciser quand sa transmission est terminée
▲Pour les bus série, il faut aussi que le récepteur puisse extraire des informations utiles du flux de bits transmis : quelle est l'adresse du récepteur, quand la transmission se termine-t-elle, et bien d'autres. Pour résoudre ces problèmes, les transmissions sur le bus sont standardisées de manière à rendre l'interprétation du flux de bit claire et sans ambiguïté. Deux composants électroniques communiquent entre eux en s'envoyant des '''trames''', des flux de bits où chaque information nécessaire à la transmission est à une place précise. Le codage des trames indique comment l'émetteur doit envoyer les données sur le bus, ce qui permet aux récepteurs de détecter les données transmises et les interpréter. Le terme trame réfère aux données transmises : toutes les informations nécessaires pour une transmission sont regroupées dans une trame, qui est envoyée telle quelle sur le bus.
▲Sur les bus série, ces trames sont transmises bit par bit grâce à des circuits spécialisés : la trame est mémorisée dans un registre à décalage, qui envoie celle-ci bit par bit sur sa sortie (reliée au bus). Pour les bus parallèles, les choses peuvent être plus variables. Il est possible d'envoyer des trames plus grosses que la largeur du bus : la trame est envoyée par paquets de données, octet par octet ou byte par byte. Mais sur la plupart des bus parallèles, toute la trame est envoyée d'un coup sur le bus : cela simplifie fortement le codage de la trame, vu qu'il n'y a pas besoin de coder la longueur de la trame ou de préciser quand sa transmission est terminée. Ce cas correspond à celui qu'on a vu dans les premiers chapitres, quand on reliait la sortie d'un composant sur l'entrée d'un autre. Par exemple, reprenons le bus d'une mémoire RAM, composé d'un bus d'adresse, d'un bus de données et d'un bus commande : dans ce cas, la trame proprement dite est composée de l'adresse, des bits de commande et de la donnée, et il est évident que la trame est envoyée en une seule fois. Mais on a aussi vu le cas, plus rare, où les données sont envoyées l'une après l'autre : on envoie l'adresse, puis la donnée, par exemple. Ou encore, on envoie l'adresse haute, puis l'adresse basse, et enfin la donnée. Dans ce cas, la trame complète est la même, mais elle est envoyée en plusieurs fois, par paquets de la taille du bus (ou presque). La même chose est possible avec d'autres bus que le bus mémoire, ainsi qu'avec d'autres formes de données/trames. Si la mémoire avait un bus série, on pourrait lui envoyer la trame bit par bit.
===Le codage des trames===
Ligne 180 ⟶ 178 :
====Le codage du début et de la fin de transmission====
La communication sur un bus est légèrement différente de ce qu'on a vu dans les chapitres précédents. Auparavant, quand deux composants devaient communiquer, on se contentait de relier les deux par un fil, et faire en sorte que de nouvelles données soient envoyées à chaque cycle. Mais sur un bus, ce n'est pas toujours le cas : il arrive que le bus soit inutilisé durant un certain temps, sans données transmises. Les composants qui veulent communiquer doivent donc déterminer quand le bus est inutilisé afin de ne pas confondre l'état de repos du bus avec une transmission de données. Une transmission est un flux de bits qui a un début et une fin : le codage des trames doit indiquer quand commence une transmission et quand elle se termine. Le récepteur ne reçoit en effet qu'un flux de bits, et doit détecter le début et la fin des trames. Ce processus de segmentation d'un flux de bits en trames n’est cependant pas simple et l'émetteur doit fatalement ajouter des bits pour coder le début et la fin de la trame. Pour cela, on peut certes ajouter un bit au bus de commande, qui indique si le bus est en train de transmettre une trame ou s'il est inactif. Mais il y a moyen de se passer de ce genre d'artifice avec des méthodes plus ingénieuses.
De nos jours, la quasi-totalité des protocoles utilisent la même technique pour délimiter le début et la fin d'une trame. Ils utilisent un octet spécial (ou une suite d'octet), qui indique le début de la trame, et un autre octet pour la fin de la trame. Ces octets de synchronisation, respectivement nommés START et STOP, sont standardisés par le protocole. Entre ces octets de synchronisation, on trouve un en-tête standardisé, les données à transmettre et éventuellement des données de contrôle d'erreur. Un problème peut cependant survenir : il se peut qu'un octet de la trame soit identique à un octet START ou STOP. Mais il y a moyen de résoudre le problème assez simplement. Pour cela, il suffit de faire précéder ces pseudo-octets START/STOP par un octet d'échappement, lui aussi standardisé. Les vrais octets START et STOP ne sont pas précédés de cet octet d'échappement et seront pris en compte, là où les pseudo-START/STOP seront ignoré car précédés de l'octet d'échappement. Il arrive plus rarement que ces octets de START/STOP soient en réalité codés par des bits spéciaux. Un bon exemple est celui du bit I²C, où les bits de START et STOP sont codés par des fronts sur les bus de données et de commande. Il en est de même sur le BUS RS-232 et RS-485, comme nous le verrons plus tard.
| |||