Quelles sont les implications de l'utilisation d'une connexion série semi-duplex par rapport à une connexion duplex? Que se passe-t-il si les deux parties essaient d'envoyer des données en même temps? Vous vous retrouvez avec des données corrompues arrivant des deux côtés? Le contrôle de flux vous aide-t-il?Quelles sont les implications des connexions série semi-duplex?
Sur la ligne, les données seront brouillées, ce qui peut ou non conduire à des dispositifs recevant les données brouillées. Parfois, cela sera utilisé pour détecter que la transmission a échoué en raison d'une collision.
Normalement, vous n'utilisez pas le mode semi-duplex de la même manière que le mode duplex intégral pour envoyer des caractères uniques en mode asynchrone. Au lieu de cela, vous utiliseriez un protocole de paquet qui détermine qui a le droit d'envoyer à quels moments, et qui inclut une somme de contrôle (généralement un CRC) pour détecter la corruption.
Le contrôle de flux n'aide pas beaucoup pour cela. Son but est de s'assurer que le récepteur n'est pas envahi par beaucoup de données. Il existe un contrôle de flux logiciel qui utilise les caractères ASCII XON et XOFF pour démarrer et arrêter la transmission, et le contrôle de flux matériel qui utilise les lignes de contrôle RTS (Request To Send) et CTS (Clear To Send). Le contrôle de flux logiciel XON/XOFF ne fonctionnera pas avec le mode semi-duplex.
Ces jours vous ne voyez pas le semi-duplex avec les modems et RS-232 ordinaires (je l'ai utilisé avec des coupleurs acoustiques dans les années quatre-vingt, c'était rare même alors). Mais il est commun pour RS-485, qui est utilisé dans le contrôle industriel avec divers protocoles. Il existe également de nombreuses autres normes de transmission de données qui fonctionnent en semi-duplex, principalement lorsqu'il y a plus de deux périphériques connectés à la même ligne (Ethernet 10base2, CAN, LIN, FlexRay, I2C, ...).
Mon Dieu, où avez-vous trouvé une ligne semi-duplex de nos jours? De toute façon, la réponse est que si les deux extrémités conduisent la ligne, il devient tout confus. Pour cette raison, il existe des caractères ASCII spécifiés: Clear to Send et Data Terminal Ready (CTS et DTR) utilisés pour établir une liaison. Voir this tutorial pour plus.
Augh, j'aurais dû aller me coucher. Tutorial à droite, moi stoopid.
Eh bien, je suis corrigé. – Chris
Et je n'ai jamais, jamais vu un port série sans broches d'envoi/réception dédiées. – Chris
Oh mon dieu, c'est faux sur tant de niveaux. CTS et DTR sont des lignes de contrôle, pas des caractères ASCII. Pour le contrôle de flux (pas de handshaking!) RTS et CTS sont utilisés, DTR est plus comme un commutateur global "On". Et pour le semi-duplex, ce n'est généralement pas le cas ... – starblue
D'une part, vous écrivez que "le contrôle de flux logiciel ne fonctionnera pas en semi-duplex". D'un autre côté, vous écrivez "vous utiliseriez un protocole de paquet qui détermine qui a le droit d'envoyer à quel moment". Pourquoi ce dernier travail si le premier échoue? Ne sont-ils pas tous les deux des contrôles logiciels qui peuvent échouer dans le contexte de semi-duplex? N'existe-t-il pas un moyen d'utiliser RTS/CTS pour contrôler qui a le droit d'envoyer quand? – Gili
L'expression «contrôle de flux logiciel» désigne la pratique consistant pour un destinataire de données à envoyer un caractère de contrôle «arrêter le lecteur de bande» à l'émetteur * pendant la transmission * pour demander que l'expéditeur suspende la transmission jusqu'à nouvel ordre (sous forme de une commande "Démarrer le lecteur de bande papier"). En revanche, les protocoles de coordination semi-duplex négocient qui va envoyer avant que des données "réelles" soient envoyées, et/ou incluent un moyen de retransmettre des données si elles sont perdues à cause d'une collision (ou d'une autre cause). Comme exemple hypothétique ... – supercat
... deux appareils pourraient convenir que lorsque l'un d'entre eux a quelque chose à dire, il enverra un caractère "Want to transmit".Quand l'un d'eux entend ce personnage, il envoie, dans un certain temps, un caractère "Prêt à recevoir" et écoute les données. L'appareil qui souhaite transmettre émettra alors, dans un certain délai, un caractère "Début de données", suivi des données et d'un caractère "Fin de données". Si un périphérique envoie "Envoi d'un message" mais ne reçoit aucune réponse, il attendra un certain temps avant d'essayer à nouveau (au cas où l'autre partie tenterait d'envoyer en même temps). – supercat