Wsparcie sprzętowe dla RTS / CTS może być korzystne, a czasami konieczne, w zależności od tego, ile „wyprzedzenia” może wysłać urządzenie, gdy potrzebuje urządzenia nadawczego, aby się wstrzymać. Jeśli urządzenie odbierające nie ma wsparcia sprzętowego do automatycznego zwalniania RTS, będzie musiało być w stanie zapewnić, że zawsze będzie w stanie obsłużyć wszelkie przychodzące znaki, zanim nastąpi przepełnienie bufora sprzętowego. Jeśli urządzenie nie ma wsparcia sprzętowego do wstrzymywania CTS, to będzie musiało unikać podawania do UART większej liczby znaków niż odbiornik byłby w stanie obsłużyć po zwolnieniu RTS.
Jeśli zarówno nadajnik, jak i odbiornik obsługują sprzętowo RTS / CTS, będą w stanie niezawodnie komunikować się, nawet jeśli odbiornik ma tylko jednoznakowy bufor, a oprogramowanie odbiornika może czasami zająć trochę czasu, aby odpowiedzieć na przychodzące dane (jeśli odbiornik porzuciłby dane po odebraniu drugiego pełnego bajtu, musiałby zwolnić RTS, tak jak podczas odbierania pierwszego, co obniżyłoby wydajność; jeśli nie porzuciłby danych, dopóki nie nadejdzie bit początkowy trzeciego bajtu, to może pozostawić RTS potwierdzone, dopóki nie otrzyma drugiego). Jeśli odbiornik nie ma sprzętowej obsługi RTS, niezawodna komunikacja nie będzie możliwa, chyba że bufor odbiornika może pomieścić wszystko, co może nadejść, podczas gdy nie jest w stanie odpowiedzieć na przychodzące dane (np. Ponieważ jest zbyt zajęty przerwaniami o wyższym priorytecie). Jeśli odbiornik ma wsparcie sprzętowe, ale nadawca nie, niezawodna komunikacja będzie możliwa, ale tylko wtedy, gdy oprogramowanie nadawcy dostosuje się, aby nigdy nie przekazało UART więcej danych, niż można bezpiecznie przesłać.
W układach z funkcjami podobnymi do PLD na niektórych pinach może być możliwe sfałszowanie surowej obsługi RTS w układach, które nie mają rzeczywistego wsparcia sprzętowego, poprzez zaprogramowanie wyjścia tak, aby automatycznie zatrzasnęło się na wysokim poziomie za każdym razem, gdy pin odbioru szeregowego Niska. To spowodowałoby, że odbiorca zacząłby raportować o sobie, gdy tylko zaczyna się transmisja. Gdy oprogramowanie otrzyma bajt, będzie mogło ponownie potwierdzić CTS, aby powiadomić nadawcę, że może przesłać kolejny bajt. Wydajność przy takim podejściu prawdopodobnie byłaby zła, ale jeśli urządzenie, które nie ma sprzętowej obsługi RTS ani możliwości zagwarantowania dobrych czasów reakcji na przerwanie, musi otrzymywać dane z urządzenia, które zatrzymuje dane natychmiast po zwolnieniu jego CTS (RTS odbiornika) , takie podejście mogłoby zapewnić niezawodne działanie.
Innym podejściem, które może być przydatne w przypadkach, gdy urządzenie będzie reagować i nie odpowiadać w przewidywalnych odstępach czasu (np. ponieważ okresowo wykonuje pewne zadania wymagające 100% procesora bez żadnych zakłóceń, przez milisekundy na raz) mieć urządzenie RTS zwalniane za każdym razem, gdy ma wejść w stan braku odpowiedzi, niezależnie od tego, czy jego bufor odbioru byłby gotowy do przyjęcia niektórych danych. Największym problemem związanym z tym podejściem jest to, że jeśli jedno urządzenie jest gotowe do odbioru danych tylko w określonych porach, a inne sprawdza tylko, czy jest gotowe do odbioru danych w określonych momentach, żadne dane nie zostaną wysłane, chyba że te czasy się pokrywają.
Osobiście uważam, że sprzętowa obsługa RTS / CTS jest cenną funkcją, ale wielu producentów chipów tego nie robi.Na szczęście układy USB-to-szeregowe FTDI bardzo dobrze reagują na te sygnały (inne też mogą, ale nie testowałem ich), dzięki czemu urządzenie bez sprzętowej obsługi RTS / CTS może żądać jednego bajtu na raz przezkrótkie potwierdzenie RTS (nie jestem pewien, jaka byłaby minimalna szerokość) za każdym razem, gdy oprogramowanie odbiornika sprawdza nadchodzący bajt i zwalnia go wkrótce potem.Będzie to działać niezawodnie, pod warunkiem, że RTS nigdy nie zostanie przypadkowo potwierdzony dla więcej niż jednego odstępu między znakami na raz.