Quelle est la différence entre le contrôle de flux matériel DTR/DSR et RTS/CTS ? Quand chacun d'eux est-il utilisé ? Pourquoi avons-nous besoin de plus d'un type de contrôle de flux matériel :)
Il existe de multiples façons de faire les choses, car aucun protocole n'a jamais été intégré aux normes. Vous utilisez la "norme" ad hoc que votre équipement met en œuvre.
Rien qu'en se basant sur les noms, RTS/CTS semblerait être une correspondance naturelle. Cependant, c'est à rebours des besoins qui se sont développés au fil du temps. Ces signaux ont été créés à une époque où un terminal envoyait par lots un écran rempli de données, mais où le récepteur pouvait ne pas être prêt, d'où la nécessité d'un contrôle de flux. Plus tard, le problème s'est inversé, car le terminal ne pouvait pas suivre les données provenant de l'hôte, mais les signaux RTS/CTS vont dans la mauvaise direction - l'interface n'est pas orthogonale et il n'y a pas de signaux correspondants dans l'autre sens. Les fabricants d'équipements se sont adaptés du mieux qu'ils ont pu, notamment en utilisant les signaux DTR et DSR.
EDIT
Pour ajouter un peu plus de détails, il s'agit d'une hiérarchie à deux niveaux, donc "officiellement" les deux doivent se produire pour que la communication ait lieu. Le comportement est défini dans la norme originale V.28 du CCITT (maintenant ITU-T).
Le DCE est un modem qui relie le terminal au réseau téléphonique. Dans le réseau téléphonique se trouvait une autre pièce d'équipement qui se séparait vers le réseau de données, par exemple X.25.
Le modem a trois états : Hors tension, Prêt ( Data Set Ready est vraie), et connectée ( Détection de la porteuse de données )
Le terminal ne peut rien faire tant que le modem n'est pas connecté.
Lorsque le terminal veut envoyer des données, il émet un signal RTS et le modem répond à la demande par un signal CTS. Le modem abaisse le CTS lorsque son tampon interne est plein.
C'est tellement nostalgique !
Note : DTR/DSR est devenu moins courant que RTS/CTS après le milieu des années 80. Le kernal Linux n'a jamais supporté DTR/DSR : au moment où le kernal Linux a supporté DTR/DSR, la série 232 était devenue obsolète.
@david Ces signaux ne sont pas limités à la RS232, mais sont également utilisés dans les UART TTL. Et ils sont loin d'être obsolètes.
La différence entre eux est qu'ils utilisent des broches différentes. Sérieusement, c'est tout. La raison pour laquelle ils existent tous les deux est que RTS/CTS n'était pas censé être un mécanisme de contrôle de flux, à l'origine ; c'était pour les modems half-duplex pour coordonner qui envoyait et qui recevait. RTS et CTS ont été si souvent utilisés à mauvais escient pour le contrôle de flux qu'ils sont devenus la norme.
J'avais complètement oublié le semi-duplex. Je me souviens vaguement d'avoir vu cela en action, sur une imprimante combinée ligne/lecteur de cartes. Merci pour cette réponse.
Maintenant superuser.com existe, et il nous dit qu'au moment de la demande, le noyau linux ne supportait pas la signalisation DTR/DSR. superuser.com/questions/345005/ . Ce qui montre une autre différence : La signalisation DTR/DSR est moins courante et n'était pas utilisée par les modems intelligents.
Une différence importante est que certains UARTs (16550 notamment) arrêteront de recevoir des caractères immédiatement si leur hôte leur demande de rendre DSR inactif. En revanche, les caractères seront toujours reçus si CTS est inactif. Je pense que l'intention ici est que DSR indique que le périphérique n'écoute plus et donc qu'il est inutile d'envoyer d'autres caractères, tandis que CTS indique qu'un tampon est plein ; ce dernier permet une certaine quantité de "dérapage" où la ligne de contrôle de flux a changé d'état entre l'échantillonnage du DTE et le prochain caractère transmis. Dans les dispositifs (relativement) plus récents qui prennent en charge une FIFO matérielle, il est possible qu'un certain nombre de caractères soient transmis après que l'ETTD ait mis CTS en état d'inactivité.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
