В чем разница между аппаратным управлением потоком DTR / DSR и RTS / CTS? Когда каждый из них используется? Зачем нам нужно более одного вида аппаратного управления потоком? :)
В чем разница между управлением потоком DTR / DSR и RTS / CTS?
Ответы:
- DTR - готовность терминала данных
- DSR - набор данных готов
- RTS - Запрос на отправку
- CTS - ясно для отправки
Есть несколько способов сделать что-то, потому что в стандарты никогда не были встроены протоколы. Вы используете любое специальное «стандартное» оборудование.
Судя по названиям, RTS / CTS кажется естественным. Однако это отсталость от потребностей, которые развивались с течением времени. Эти сигналы были созданы в то время, когда терминал пакетно отправлял экран, полный данных, но получатель мог быть не готов, отсюда и необходимость управления потоком. Позже проблема была бы обращена вспять, поскольку терминал не мог справляться с данными, поступающими от хоста, но сигналы RTS / CTS идут в неправильном направлении - интерфейс не ортогонален, и нет соответствующих сигналов, идущих в обратном направлении. Производители оборудования адаптировались как могли, в том числе с использованием сигналов DTR и DSR.
РЕДАКТИРОВАТЬ
Чтобы добавить немного больше деталей, это двухуровневая иерархия, поэтому «официально» оба должны происходить, чтобы коммуникация имела место. Поведение определено в исходном стандарте CCITT (теперь ITU-T) V.28.
DCE - это модем, соединяющий терминал и телефонную сеть. В телефонной сети был другой элемент оборудования, который отделялся от сети передачи данных, например. X.25.
Модем находится в трех состояниях: выключен, готов ( набор данных готов ) и подключен ( обнаружение носителя данных ).
Терминал ничего не может сделать, пока не будет подключен модем.
Когда модем хочет отправить данные, он поднимает RTS, и модем передает запрос с помощью CTS. Модем снижает CTS, когда его внутренний буфер заполнен.
Такая ностальгическая!
1
Красиво резюмировано. Затем появился «мягкий» контроль потока xOn / xOff.
—
n8wrl 05
Примечание: DTR / DSR стал менее распространенным, чем RTS / CTS после середины 80-х годов. Ядро Linux никогда не поддерживало DTR / DSR: к тому времени, когда ядро Linux поддерживало DTR / DSR, серийный номер 232 устарел.
—
Дэвид
@david Эти сигналы не ограничиваются RS232, но также используются в TTL UART. И они далеко не устарели.
—
glglgl
Таким образом, с точки зрения DTE (компьютер) и DCE (модем) RTS / CTS гарантирует, что DCE (модем) не перегружен данными, а DTR / DSR гарантирует, что DTE (компьютер) не будет перегружен данными. Это правильно?
—
skinnedKnuckles
@skinnedKnuckles, это правильно, насколько я помню. Прошло слишком много лет с тех пор, как мне приходилось беспокоиться об этом.
—
Марк Рэнсом,
Разница между ними в том, что они используют разные булавки. Серьезно, вот и все. Причина, по которой они оба существуют, заключается в том, что изначально RTS / CTS никогда не предполагалось быть механизмом управления потоком; это было для полудуплексных модемов, чтобы координировать, кто отправляет, а кто принимает. RTS и CTS настолько часто использовались для управления потоком, что стали стандартом.
Совсем забыл про полудуплекс. Я смутно помню, как видел это в действии на комбинированном принтере / картридере. Спасибо за ответ.
—
Марк Рэнсом,
Теперь superuser.com существует, и он сообщает нам, что на момент запроса ядро linux не поддерживало сигнализацию DTR / DSR. superuser.com/questions/345005/… . Это указывает на другое отличие: сигнализация DTR / DSR менее распространена / не использовалась смарт-модемами.
—
Дэвид
Важное отличие состоит в том, что некоторые UART (в частности, 16550) прекращают прием символов немедленно, если их хост дает им команду установить DSR в неактивное состояние. Напротив, символы все равно будут приниматься, если CTS неактивен. Я считаю, что здесь подразумевается, что DSR указывает, что устройство больше не слушает, и поэтому посылать любые дальнейшие символы бессмысленно, в то время как CTS указывает, что буфер заполняется; последний допускает определенную величину «скольжения», когда линия управления потоком изменяет состояние между выборкой DTE и следующим передаваемым символом. В (относительно) более поздних устройствах, которые поддерживают аппаратный FIFO, возможно, что некоторое количество символов может быть передано после того, как DCE установит CTS в неактивное состояние.