La prise en charge matérielle de RTS / CTS peut être avantageuse et parfois nécessaire, en fonction du "préavis" qu'un appareil peut donner quand il a besoin d'un appareil émetteur pour se retenir. Si un périphérique récepteur n'a pas de support matériel pour la libération automatique de RTS, il devra être en mesure de s'assurer qu'il est toujours en mesure de traiter tous les caractères entrants avant que la mémoire tampon matérielle puisse déborder. Si un appareil n'a pas de support matériel pour se retenir sur CTS, il devra alors éviter d'alimenter l'UART plus de caractères que le récepteur ne serait capable de gérer après la sortie de RTS.
Si l'émetteur et le récepteur incluent tous deux un support matériel pour RTS / CTS, ils pourront communiquer de manière fiable même si le récepteur ne dispose que d'un tampon à un seul caractère et que le logiciel du récepteur peut parfois prendre un certain temps pour répondre aux données entrantes (si le le récepteur abandonnerait des données à la réception du deuxième octet complet, il devrait libérer RTS comme pendant qu'il reçoit le premier, ce qui dégraderait les performances; s'il ne perdrait pas de données à moins que / jusqu'à ce que le bit de début d'un troisième octet arrive, il pourrait laisser RTS affirmé jusqu'à ce qu'il reçoive le second). Si le récepteur ne prend pas en charge le RTS matériel, une communication fiable ne sera pas possible à moins que le tampon du récepteur puisse contenir tout ce qui pourrait arriver alors qu'il est incapable de répondre aux données entrantes (par exemple, parce qu'il est trop occupé avec des interruptions de priorité plus élevée). Si le destinataire dispose d'un support matériel mais pas l'expéditeur, une communication fiable sera possible, mais seulement si le logiciel de l'expéditeur se met en marche pour ne jamais donner à l'UART plus de données que ce qui peut être transmis en toute sécurité.
Dans les puces avec des fonctionnalités de type PLD sur certaines broches, il peut être possible de truquer le support RTS brut dans les puces qui n'ont pas de support matériel réel en programmant une sortie pour se verrouiller automatiquement à chaque fois que la broche de réception série est faible. Cela aurait pour effet d'amener le récepteur à se signaler qu'il n'est pas prêt à chaque fois qu'une transmission commence. Une fois que le logiciel reçoit un octet, il serait alors en mesure de réaffirmer CTS pour faire savoir à l'expéditeur qu'il peut transmettre un autre octet. Les performances utilisant une telle approche seraient probablement mauvaises, mais si un appareil qui n'a ni le support matériel RTS ni la capacité de garantir de bons temps de réponse d'interruption doit recevoir des données d'un appareil qui arrête les données immédiatement lorsque son CTS (le RTS du récepteur) est libéré , une telle approche pourrait permettre un fonctionnement fiable.
Une autre approche qui peut parfois être utile dans les cas où un appareil sera réactif et non réactif à des intervalles prévisibles (par exemple, parce qu'il exécute périodiquement une tâche qui nécessite 100% de CPU, sans interruption, pendant des millisecondes à la fois) est pour qu'un périphérique libère RTS chaque fois qu'il est sur le point d'entrer dans un état non réactif, que son tampon de réception soit prêt à accepter certaines données. Le plus gros problème avec cette approche est que si un appareil n'est prêt à recevoir des données qu'à certaines heures et qu'un autre vérifie uniquement s'il est prêt à recevoir des données à certains moments, aucune donnée ne sera envoyée à moins que ces heures ne coïncident.
Personnellement, je considère que le support matériel RTS / CTS est une fonctionnalité intéressante, mais beaucoup de fabricants de puces ne semblent pas le faire.Heureusement, les puces FTDI USB-série répondent très bien à ces signaux (d'autres peuvent aussi bien, mais je ne les ai pas testés), ce qui permet à un périphérique sans support matériel RTS / CTS de demander un octet à la fois enaffirmer brièvement RTS (je ne suis pas sûr de la largeur minimale) chaque fois que le logiciel récepteur vérifie un octet entrant et le libère peu de temps après.Cela fonctionnera de manière fiable à condition que RTS ne soit jamais affirmé accidentellement pendant plus d'un intervalle de caractères à la fois.