Il supporto hardware per RTS / CTS può essere vantaggioso e talvolta necessario, a seconda di quanto "preavviso" un dispositivo può dare quando ha bisogno di un dispositivo di trasmissione per trattenerlo. Se un dispositivo ricevente non dispone del supporto hardware per il rilascio automatico di RTS, dovrà essere in grado di assicurarsi di essere sempre in grado di servire i caratteri in arrivo prima che il buffer hardware possa traboccare. Se un dispositivo non dispone del supporto hardware per tenere a bada il CTS, dovrà evitare di fornire all'UART più caratteri di quelli che il ricevitore sarebbe in grado di gestire dopo aver rilasciato RTS.
Se sia il trasmettitore che il ricevitore includono il supporto hardware per RTS / CTS, saranno in grado di comunicare in modo affidabile anche se il ricevitore ha solo un buffer a carattere singolo e il software del ricevitore a volte può impiegare un po 'di tempo per rispondere ai dati in arrivo (se il il destinatario rilascia i dati dopo aver ricevuto il secondo byte completo, dovrebbe rilasciare RTS come mentre sta ricevendo il primo, il che peggiorerebbe le prestazioni; se non rilascia i dati a meno che / fino a quando non arriva il bit di inizio di un terzo byte, esso potrebbe lasciare RTS affermato fino a quando non riceve il secondo). Se il ricevitore non dispone del supporto hardware RTS, non sarà possibile una comunicazione affidabile a meno che il buffer del ricevitore non possa contenere tutto ciò che potrebbe arrivare mentre non è in grado di rispondere ai dati in arrivo (ad esempio perché è troppo occupato con interrupt a priorità più alta). Se il destinatario ha il supporto hardware ma il mittente no, sarà possibile una comunicazione affidabile, ma solo se il software del mittente si sincronizza da solo in modo da non fornire mai all'UART più dati di quelli che possono essere trasmessi in sicurezza.
Nei chip con funzionalità simile a PLD su alcuni pin, potrebbe essere possibile confondere il supporto RTS grezzo in chip che non hanno un supporto hardware reale programmando un'uscita in modo che si agganci automaticamente alto ogni volta che il pin di ricezione seriale è Basso. Ciò avrebbe l'effetto di far sì che il ricevitore inizi a segnalare se stesso non pronto ogni volta che inizia una trasmissione. Una volta che il software riceve un byte, sarà quindi in grado di riaffermare CTS per far sapere al mittente che può trasmettere un altro byte. Le prestazioni utilizzando un tale approccio sarebbero probabilmente cattive, ma se un dispositivo che non ha né il supporto hardware RTS né la capacità di garantire buoni tempi di risposta all'interrupt deve ricevere i dati da un dispositivo che arresta i dati immediatamente quando il suo CTS (RTS del ricevitore) viene rilasciato , un tale approccio potrebbe consentire un funzionamento affidabile.
Un altro approccio che a volte potrebbe essere utile nei casi in cui un dispositivo sarà reattivo e non reattivo a intervalli prevedibili (ad esempio perché esegue periodicamente alcune attività che richiedono il 100% della CPU, senza interruzioni, per millisecondi alla volta) è fare in modo che un dispositivo rilasci RTS ogni volta che sta per entrare in uno stato di non risposta indipendentemente dal fatto che il suo buffer di ricezione sia pronto ad accettare alcuni dati. Il problema più grande con questo approccio è che se un dispositivo è pronto a ricevere dati solo in determinati periodi e un altro controlla solo se è pronto a ricevere dati in determinati momenti, nessun dato verrà inviato a meno che quei tempi non coincidano.
Personalmente, ritengo che il supporto hardware RTS / CTS sia una funzionalità preziosa, ma molti produttori di chip non sembrano farlo.Fortunatamente, i chip FTDI da USB a seriale rispondono molto bene a quei segnali (altri potrebbero anche, ma non li ho testati), rendendo possibile per un dispositivo senza supporto hardware RTS / CTS di richiedere un byte alla voltaaffermando brevemente RTS (non sono sicuro di quale sarebbe la larghezza minima) ogni volta che il software del ricevitore verifica la presenza di un byte in arrivo e lo rilascia subito dopo.Funzionerà in modo affidabile a condizione che l'RTS non venga mai affermato accidentalmente per più di un intervallo di caratteri alla volta.