Что такое сигналы RTS и CTS в интерфейсе RS-232. Как работает аппаратное управление потоком с помощью RTS/CTS. Для чего нужно управление потоком данных. Когда стоит использовать RTS/CTS, а когда можно обойтись без него.
Что такое RTS и CTS в RS-232
RTS (Request To Send) и CTS (Clear To Send) — это сигналы управления потоком данных в интерфейсе RS-232. Они используются для аппаратного квитирования между передающим и принимающим устройствами.
Основные характеристики RTS и CTS:
- RTS — выходной сигнал от DTE (компьютера) к DCE (модему)
- CTS — входной сигнал от DCE (модема) к DTE (компьютеру)
- Активный уровень сигналов — низкий (логический 0)
- Используются для управления передачей данных между устройствами
Как работает аппаратное управление потоком RTS/CTS
Механизм управления потоком с помощью RTS/CTS работает следующим образом:
- Передающее устройство активирует сигнал RTS, запрашивая разрешение на передачу
- Принимающее устройство, если готово принимать данные, активирует CTS
- Передающее устройство, получив активный CTS, начинает передачу данных
- Если принимающее устройство не готово, оно деактивирует CTS
- Передатчик, увидев неактивный CTS, приостанавливает передачу
Таким образом, RTS/CTS обеспечивает двунаправленное управление потоком данных между устройствами.
Для чего нужно управление потоком данных
Управление потоком данных необходимо в следующих случаях:
- Для предотвращения переполнения буферов принимающего устройства
- При разной скорости обработки данных передатчиком и приемником
- Для синхронизации передачи в полудуплексных системах
- При передаче больших объемов данных на высокой скорости
Без управления потоком возможна потеря данных из-за переполнения буферов или рассинхронизации устройств.
Преимущества аппаратного управления потоком RTS/CTS
Аппаратное управление потоком с помощью RTS/CTS имеет ряд преимуществ:
- Надежность — сигналы передаются по отдельным линиям
- Быстродействие — мгновенная реакция на изменение сигналов
- Независимость от протокола передачи данных
- Работает на физическом уровне без участия программного обеспечения
- Позволяет эффективно использовать пропускную способность канала
Недостатки RTS/CTS
У аппаратного управления потоком есть и некоторые недостатки:
- Требует дополнительных линий связи (проводов)
- Усложняет схемотехнику устройств
- Может вызывать проблемы при неправильном подключении или настройке
- Не работает на длинных линиях из-за задержек сигналов
Когда следует использовать RTS/CTS
Аппаратное управление потоком RTS/CTS рекомендуется применять в следующих случаях:
- При передаче больших объемов данных на высокой скорости
- В системах реального времени с жесткими требованиями к задержкам
- При соединении устройств с разной скоростью обработки данных
- В полудуплексных системах для переключения направления передачи
- Для повышения надежности передачи в помехозащищенных каналах
Когда можно обойтись без RTS/CTS
В некоторых ситуациях можно не использовать аппаратное управление потоком:
- При передаче небольших порций данных на низкой скорости
- Если устройства имеют достаточные буферы для хранения данных
- В простых системах с предсказуемым потоком данных
- При использовании программного управления потоком (XON/XOFF)
- Если длина линии связи не позволяет использовать RTS/CTS
Настройка RTS/CTS в последовательном порту
Для использования аппаратного управления потоком RTS/CTS необходимо:
- Физически соединить линии RTS и CTS между устройствами
- В настройках COM-порта включить опцию «Hardware flow control»
- Настроить параметры UART (скорость, биты данных, четность)
- Убедиться, что оба устройства поддерживают RTS/CTS
- Протестировать работу управления потоком на разных скоростях
Типичные проблемы при использовании RTS/CTS
При работе с аппаратным управлением потоком могут возникать следующие проблемы:
- Устройства не реагируют на изменение сигналов RTS/CTS
- Передача данных блокируется из-за неправильного подключения
- Потеря данных при переполнении буферов
- «Подвисание» передачи при рассинхронизации сигналов
- Конфликты с программным управлением потоком XON/XOFF
Для решения этих проблем необходимо тщательно проверить подключение и настройки RTS/CTS на обоих устройствах.
Альтернативы аппаратному управлению потоком
Вместо RTS/CTS могут использоваться другие методы управления потоком данных:
- Программное управление XON/XOFF
- Управление на уровне протокола передачи данных
- Использование больших буферов в устройствах
- Согласование скоростей приема и передачи
- Пакетная передача с подтверждением приема
Выбор метода зависит от конкретной задачи и характеристик системы передачи данных.
Все страницы — Юнионпедия
Все страницы — ЮнионпедияНовый! Скачать Юнионпедия на вашем Android™ устройстве!
Скачать
Более быстрый доступ, чем браузер!
Все страницы · Предыдущая (Rozenbergs) · Следующий (Rudolf Mayer)
Из:
| RTS1 | RTS2 | RTSH |
| RTSI | RTSJ | RTSP |
| RTT | RTTI | RTU |
| RTV (телеканал, Словакия) | RTV SLO | RTV Slovenija |
| RTVE | RTVI | RTVi |
| RTVideo | RTVS | RTVSLO |
| RTW 1 | RTW 2 | RTX |
| RTZ | RTZ1 | RTZ10 |
| RTZ11 | RTZ2 | RTZ3 |
| RTZ4 | RTZ5 | RTZ6 |
| RTZ7 | RTZ8 | RTZ9 |
| RTД | Ru | RU |
| RU Cancri | RU Center | RU Cnc |
| RU Music | RU TV | RU Рака |
| RU-27 | Ru-Board | Ru-board |
| Ru-board. com | Ru-Center | RU-CENTER |
| RU-COM | Ru.Board | Ru.board |
| RU.FM | RU.FM (радио) | RU.TV |
| Ru.wikipedia.org | RU3AX | RuArts |
| Ruíz | RUB | Rubacer |
| Rubato | Rubén Amorín | Rubén Ayala |
| Rubén Baraja | Rubén Bentancourt | Rubén Blades Bellido de Luna |
| Rubén Blanco | Rubén Botta | Rubén Castro |
| Rubén da Silva | Rubén Da Silva | Rubén de la Red |
| Rubén Galván | Rubén García Santos | Rubén González |
| Rubén González Rocha | Rubén Héctor Sosa | Rubén José Suñé |
| Rubén Marcelo Gómez | Rubén Marino Navarro | Rubén Miño |
| Rubén Morán | Rubén Olivera da Rosa | Rubén Omar Romano |
| Rubén Omar Romano Cachía | Rubén Oscar Glaría | Rubén Oscar Glaria |
| Rubén Oscar Pagnanini | Rubén Oswaldo Díaz | Rubén Pagnanini |
| Rubén Pardo | Rubén Paz | Rubén Pérez del Mármol |
| Rubén Plaza Molina | Rubén Rochina | Rubber Soul |
| Rubber Soul (band) | Rubber Soul (группа) | Rubbernecking |
| Rube Lautenschlager | Rubel | Rubella Ballet |
| Rubem Fonseca | Rubempré | Ruben Gunawan |
| Ruben Loftus-Cheek | Ruben Yttergård Jenssen | Ruben Zadkovich |
| Rubens Barrichello | Rubens de Falco da Costa | Rubens Fernando Moedim |
| Rubens Josué da Costa | Rubens Minelli | Rubens Osvaldo Jesús Udaquiola Laport |
| Rubens Sambueza | Rubenstein | Rubeola |
| Rubeola maritima | Rubeosaurus | Rubettes |
| Rubia | Rubia cretacea | Rubia palustris |
| Rubia tinctorum | Rubiaceae | Rubicon |
| Rubicon Group | Rubicon Race Team | Rubiconia |
| Rubidgea | Rubidgea atrox | Rubieae |
| Rubik’s 360 | Rubiner | Rubinius |
| Rubinoboletus balloui | Rubinoboletus ballouii | Rubinoboletus rubinus |
| Rubio Rubin | Rubisco | Rubius |
| Rubkow | Rublacklist. net | Ruboard |
| RuBoard | Rubroboletus legaliae | Rubroboletus pulcherrimus |
| Rubroboletus rhodoxanthus | Rubus | Rubus (subgenus) |
| Rubus abruptus | Rubus aestivalis | Rubus aetneus |
| Rubus albescens | Rubus appenninus | Rubus arcticus |
| Rubus armeniacus | Rubus avellanifolius | Rubus ×loganobaccus |
| Rubus baronicus | Rubus bellidiflorus | Rubus bujedanus |
| Rubus caesius | Rubus canduliger | Rubus castellanus |
| Rubus ceratifolius | Rubus chamaemorus | Rubus chinensis |
| Rubus cocullotinus | Rubus comintanus | Rubus commersonii |
| Rubus communis | Rubus coronarius | Rubus crispulus |
| Rubus cyrenaicae | Rubus debilis | Rubus edouardii |
| Rubus ellipticus | Rubus erectus | Rubus ernestibolli |
| Rubus exaltatus | Rubus fastigiatus | Rubus franciscanus |
| Rubus fructicosus | Rubus fruticosus | Rubus gerundensis |
| Rubus glandulosopunctatus | Rubus glaucus | Rubus hawaiensis |
| Rubus helleri | Rubus hispanicus | Rubus holmiensis |
| Rubus hopingensis | Rubus idaeus | Rubus jamaicensis |
| Rubus karstianus | Rubus laciniatus | Rubus legionensis |
| Rubus lejeunei | Rubus lindleianus | Rubus longipetiolatus |
| Rubus macropetalus | Rubus menziesii | Rubus mingendensis |
| Rubus minusculus | Rubus nelliae | Rubus nessensis |
| Rubus neveus | Rubus niveus | Rubus oculus-junonis |
| Rubus odoratus | Rubus panormitanus | Rubus phoenicolasius |
| Rubus plicatus | Rubus polymorphus | Rubus procerus |
| Rubus ribifolius | Rubus rosifolius | Rubus rosulentus |
| Rubus rusticanus | Rubus saxatilis | Rubus siculus |
| Rubus sinusifolius | Rubus sirbenus | Rubus spectabilis |
| Rubus spicifolius | Rubus stenopetalus | Rubus subg. Rubus |
| Rubus subgen. Anoplobatus | Rubus subgen. Rubus | Rubus tagallus |
| Rubus taiwanianus | Rubus teutobergensis | Rubus ulmifolius |
| Rubus ursinus | Rubus vadalis | Rubus valentinus |
| Rubus vulgaris | Ruby | Ruby Bhatia |
| Ruby Blue | Ruby Jerins | Ruby on Rails |
| Ruby on rails | Ruby Tuesday | Rubycon |
| RubyGems | RubyMine | RUC |
| RuCenter | Rucervus duvaucelii | Rucervus eldii |
| Rucervus schomburgki | RUCOM | Rud Immanuel Langgaard |
| RuDa | Ruda | Rudas gyógyfürdő |
| Rudé právo | Rudé Právo | Rudbeckia |
| Rudbeckia hirta | Rudbeckia purpurea | Rude |
| Rude Awakening | Rude Awakening (DVD) | Rude Boy |
| Rude boys | Rude Boys | Rudebox |
| Rudel | Rudge | Rudi Assauer |
| Rudi Bommer | Rudi Garcia | Rudi Gutendorf |
| Rudi Kargus | Rudi Schuricke | Rudi Völler |
| Rudi Zygadlo | Rudiger Vogler | Rudimental |
| Rudimentary Peni | Rudisiricius | Rudisiricius belli |
| Rudnei da Rosa | Rudolf August Wilhelm Bockelmann Louis | Rudolf Brunnenmeier |
| Rudolf Caracciola | Rudolf Franz Joseph Bing | Rudolf Gutendorf |
| Rudolf Heinrich Greinz | Rudolf Kampf | Rudolf Kämpf |
| Rudolf Kämpf Porzellan fabrik GmbH, Grünlas | Rudolf Keller | Rudolf Kirchschläger |
| Rudolf Klein-Rogge | Rudolf Kner | Rudolf Leuckart |
Страничка эмбеддера » Сигналы квитирования (RTS, CTS итп) и RS232 вообще
У стандартного модемного интерфейса (rs232) кроме линий RxD и TxD есть еще куча разных, их называют “сигналами квитирования”.
Я всегда путался в них — во всех этих RTS’ах, CTS’ах и прочих DSR’ах. В этой статье, я попробую систематизировать и кратко описать эти сигналы.
Итак, первое что стоит знать – интерфейс rs232 соединяет два типа устройств
DTE (Data Terminal Equipment) – это обычно компьютер или заменяющее его устройство. Для простоты, дальше я DTE буду называть компьютер. На компьютер устанавливается разъем типа “папа”
DCE (Data Circuit-terminating Equipment) – это обычно модем, или его заменяющее оборудование. Для простоты я буду называть DCE модемом. На DCE устанавливается разъем типа “мама”
Сигналы я буду описывать на примере 9-контактного разъема, так как он самый распространенный. Взглянем на него.
Как видно, контакты на разъемах перевернуты. Таким образом, прямой провод соединит контакты с одинаковыми номерами, тоесть, к примеру, контакту 2 на “папе” будет соответствовать контакт 2 на “маме”.
А вот и сводная табличка сигналов. Под названием вывода – номер его штырька в 9-контактном разъеме.
| Сигналы, которыми управляет компьютер | Сигналы, которыми управляет модем |
| Передача данных компьютером, прием модемом | TxD 3 | ||
| RxD 2 | Передача данных модемом, прием компьютером | ||
| Компьютер готов передавать данные, либо компьютер разрешает модему передавать данные | RTS 7 | ||
| CTS 8 | Модем разрешает компьютеру передавать данные | ||
| DSR 6 | Готовность модема к работе. | ||
| Готовность компьютера к работе. | DTR 4 | ||
| RI 9 | Индикатор звонка | ||
| DCD 1 | Индикатор наличия несущей. Устанавливается после соединения. | ||
| Земля | SG 5 | SG 5 | Земля |
Ну, и немного подробнее опишем каждый сигнал.
Я буду рассматривать сигналы обычных логических уровней – так, как они выглядят на выходах или входах микроконтроллера.
Сигналы в кабеле (после преобразователя уровня, к примеру max232) перевернуты и уровни сдвинуты. Так, логической 1 на выходе контроллера соответствуют уровни напряжения от –3 до –15 вольт, а логическому нулю – +3…+15 вольт.
TxD (Tramsmit Data)
Сразу скажу, что откуда в сокращении буква “x” – я не знаю.
По этой линии происходит передача данных от компьютера к модему. По умолчанию на ней — высокий уровень. Прием байта начинается по стартовому биту (а точнее, по переходу линии из высокого состояния в низкое). Стартовый бит всегда является логическим нулем.
Далее, передаются данные. Обычно это 8 бит, хотя бывает и по другому. Данные передаются младшим битом вперед и в прямой логике (нулю на ножке контроллера соответствует принятый нулевой бит).
После этого идет не обязательный бит четности (на картинке его нет). Бит четности дополняет количество единиц до четного (even) или нечетного (odd).
К примеру, если в байте было 3 единицы и четность установлена как “even”, то бит четности будет равен 1, чтобы дополнить количество единиц до четырех – четного числа. Четность служит для проверки правильности передачи байта.
После бита четности идет один, один с половиной или два стоп-бита. Стоп бит используется, чтобы правильно отработался старт-бит (чтобы между байтами всегда был перепад из высокого уровня в низкий). Это бит всегда установлен в логическую 1.
К примеру, передача 0xEE будет выглядеть на линии UART’а так:
Параметры последовательного порта обычно пишут так – “9600, 8N1”. 9600 – это скорость передачи бит/с, 8 – количество бит данных в посылке, N – бит четности не используется (может быть E или O, если используется), 1 – один стоп бит.
Заметьте, что количество передаваемых байт в секунду зависит не только от скорости передачи, но и от формата байта. К примеру, один байт в формате 8N1 занимает 10 бит (стартовый + 8 бит данных + стоповый), а в формате 8E1 уже 11бит – добавляется бит четности.
Соответственно, байтовая скорость при битовой 9600бод станет 960байт/с в первом случае и 872.7байт/с во втором.
RxD (Receive Data)
Тоже самое, что и TxD, только хозяин этой линии – модем.
CTS (Clear To Send)
Рассмотрим такую ситуацию – компьютер отправляет модему большое количество данных на скорости 38400 бод, а модем подключен к другому модему на скорости 9600 бод.
Буфер внутри модема быстро заполняется, и, для того, чтобы он не переполнился, модем должен сообщить компьютеру “прекрати передачу!”. Для этого и служит линия CTS.
Активный уровень CTS – низкий. Тоесть, модем разрешает передачу данных, когда на ножке контроллера 0.
Пример из руководства по LPC17xx.
Как видно, компьютер передавал данные, пока на ножке был ноль. Когда появился высокий уровень, компьютер закончил передавать текущий байт и остановился.
RTS (Request To Send)
Вот с этой ножкой неразбериха.
Проблема в том, что на месте этой ножки по стандарту могут быть два сигнала – RTS (номер цепи по стандарту — 105) и RTR (номер 133).
RTS (Ready To Send) – компьютер сигнализирует модему о том, что он сейчас будет передавать данные. Модем должен приготовиться и активировать CTS, после чего компьютер начинает передавать данные.
RTR (Ready To Receive) – компьютер сообщает модему о том, что он готов принимать данные. Это – аналог CTS, только со стороны компьютера.
Сейчас основная часть оборудования использует RTS как RTR! И даже аппаратное квитирование у LPC17xx, LPC2xxx, AT91SAM7 реализует именно механизм RTR.
Активный уровень как и у CTS – низкий.
Рассмотрим механизм подробнее на примере из руководства по LPC17xx
Сначала — сигнал RTS – низкий, принимаются байты.
Как только буфер приемника заполнился N символами, RTS переходит в высокое состояние, что запрещает модему передавать данные.
Но, как видно, модем не успел среагировать на RTS и передал еще один байт, поэтому очень важно оставлять в буфере запас для как минимум одного байта.
Далее, байты читаются, и, когда их количество в буфере становится равным M, RTS возвращается в низкое состояние (разрешает модему передавать данные).
Подробнее про RTS/CTS — https://en.wikipedia.org/wiki/RS-232_RTS/CTS#RTS.2FCTS_handshaking
DTR (Data Terminal Ready)
Сигнал от компьютера к модему, обозначающий, что компьютер включен и котов к работе с модемом. Активное состояние, как обычно, низкое. Тоесть, если на ножке контроллера 0, то модем должен подготовиться к подключению к линии. Если-же компьютер выставит на этой ножке логическую 1, то модем обязан отключиться от линии (положить трубку, к примеру)
DTR также часто использовался как источник питания для внешнего малопотребляющего оборудования (к примеру, для мышки).
Подробнее: https://en.wikipedia.org/wiki/Data_Terminal_Ready
DSR (Data Set Ready)
Сигнал от модема к компьютеру.
Говорит о том, что модем включен, проинициализирован, и готов к общению с компьютером. До тех пор, пока этот сигнал не активен нет смысла передавать что-либо в модем. Модем готов, когда на ножке контроллера логический 0.
RI (Ring Indicator)
Сигнал от модема к компьютеру. Как не сложно догадаться, этот сигнал дергается, когда на модем звонят. Скорость переключения сигнала – маленькая, порядка секунд, сигнал довольно точно повторяет огибающую звонка (огибающую того, что вы слышите, когда звонит аналоговый телефон).
На практике, этот сигнал используется редко. Обычно программа просто ждет сообщения “RING” от модема.
Логический 0 на ножке контроллера значит, что идет вызов.
подробнее: https://en.wikipedia.org/wiki/Ring_Indicator
DCD (Data Carrier Detect)
Сигнал от модема к компьютеру. Сообщает компьютеру о том, что модем подключен к удаленному модему.
Эта ножка – очень важна, так как дает возможность определить спонтанные отключения.
Логический 0 означает, что связь между модемами активна.
подробнее: https://en.wikipedia.org/wiki/Data_Carrier_Detect
Теперь кратко про кабель
Теперь про кабель. Стандарт определяет максимальную емкость кабеля как 2.5нФ. Это, примерно, 25метров.
Однако, на практике, это ограничение игнорируют, так как целостность сигнала определяется не только емкостью но и скоростью. Вот максимальные длинны, используемые на практике для низких скоростей.
| Скорость (бод) | Длинна экранированного кабеля, метры | Длинна неэкранированного кабеля, метры |
| 110 | 1500 | 300 |
| 300 | 1200 | 300 |
| 1200 | 900 | 150 |
| 2400 | 600 | 150 |
| 4800 | 150 | 75 |
| 9600 | 75 | 30 |
Стандарт
Если у вас остались какие-то вопросы, то лучше обратиться непосредственно к стандарту.
как оказалось, найти его довольно сложно, поэтому выкладываю еще и у себя.
Что такое управление потоком RTS и CTS?
спросил
Изменено 10 лет, 8 месяцев назад
Просмотрено 16 тысяч раз
\$\начало группы\$
Недавно я заказал два ключа Bluetooth для своих Arduino, чтобы они могли обмениваться данными на большом расстоянии. Ключи, которые я заказал, имеют контакт с маркировкой CTS-I и контакт с маркировкой RTS-0. Я немного погуглил и обнаружил, что они как-то связаны с «управлением потоком», что это такое?
У меня есть Arduinos, которые правильно обмениваются данными без использования этих контактов. Для чего предназначены эти два штифта? Должен ли я хотеть их использовать? Как я могу их использовать?
- регулятор расхода
\$\конечная группа\$
\$\начало группы\$
Управление потоком — это общий термин, обозначающий средство, с помощью которого объект, желающий передать информацию другому, может избежать отправки ее быстрее, чем может принять получатель.
Одна из самых ранних форм управления потоком, которая все еще широко используется, обычно называется xon/xoff; он использовался для связи между телетайпами в ситуациях, когда один телетайп использовал свой считыватель бумажной ленты для отправки данных на другой телетайп. Хотя телетайпный принтер обычно мог не отставать от устройства чтения бумажной ленты (оба работали со скоростью десять символов в секунду), это зависело бы от таких вещей, как достаточный запас бумаги. Оператор, который заметил, что необходимо заменить бумагу в телетайпе, который принимал передачу, мог нажать Control-S, чтобы отправить символ XOFF, который попросит считыватель бумажной ленты на другом конце остановиться. После замены бумаги оператор мог нажать Control-Q, чтобы перезапустить устройство чтения бумажных лент. Эти символы все еще используются по сей день, хотя дальним концом соединения обычно является компьютер, а не устройство чтения ленты.
Протокол RTS/CTS — это метод квитирования, при котором используется один провод в каждом направлении, что позволяет каждому устройству указывать другому, готово ли оно к приему данных в любой момент.
Одно устройство отправляет в RTS и слушает в CTS; другой делает обратное. Устройство должно установить на своем проводе вывода квитирования низкий уровень, когда оно готово к приему данных, и высокий уровень, когда он не готов. Устройство, которое хочет отправить данные, не должно начинать отправку каких-либо байтов, пока на проводе рукопожатия низкий уровень; если он видит, что провод квитирования становится высоким, он должен закончить передачу текущего байта, а затем дождаться, пока провод квитирования перейдет в низкий уровень, прежде чем передавать дальше.
Обратите внимание, что, хотя устройства в идеале никогда не должны отправлять больше байта после того, как их ввод рукопожатия становится высоким (если линия становится высокой в тот момент, когда они начинают передавать символ, они должны разрешить передачу этого символа полностью), многие последовательные порты ПК делают это. не соблюдайте это, даже когда квитирование включено. Последовательные порты позволяют программному обеспечению определять состояние входящего провода квитирования и ожидать, что программное обеспечение решит, когда данные должны быть поставлены в очередь для передачи.
К сожалению, единственный способ добиться хорошей производительности с последовательным портом — это поставить данные в очередь для передачи немного раньше, чем они будут фактически отправлены, и многие последовательные порты ПК всегда будут передавать любые данные в очереди так быстро, как они могут, независимо от того, для проводов рукопожатия. Следовательно, последовательные порты ПК нередко отправляют около дюжины символов даже после того, как их попросили подождать.
\$\конечная группа\$
4
\$\начало группы\$
RTS = Запрос на отправку. Передающее устройство говорит другому концу подготовиться к приему и установить свою линию CTS, когда будет готово.
CTS = Разрешить отправку. Принимающий конец готов («все чисто») и сообщает дальнему концу начать отправку символов.
Раньше полудуплексные соединения были обычным явлением.
Это были односторонние соединения, и эти сигналы использовались, чтобы «перевернуть линию», чтобы вы не пытались отправить, когда вам что-то посылали.
Аппаратное квитирование при неправильном использовании было классической проблемой «зависания компьютера» и вызывало столько проблем, что большинство разработчиков просто отказались от попыток использовать этот метод квитирования. Вот почему ты добился успеха.
Если символы продолжают отправляться после того, как дальний конец отправляет команду об остановке, это может быть связано с «FIFO» (первым пришел — первым обслужен) в устройстве. Это может хранить (буферизировать) несколько символов для отправки, поэтому компьютеру не нужно останавливаться и проверять после каждого символа. Но, как уже говорилось, иногда его трудно остановить! Отсюда и создание приемных буферов…
\$\конечная группа\$
2
Зарегистрируйтесь или войдите в систему
Зарегистрируйтесь с помощью Google
Зарегистрироваться через Facebook
Зарегистрируйтесь, используя электронную почту и пароль
Опубликовать как гость
Электронная почта
Требуется, но никогда не отображается
Опубликовать как гость
Электронная почта
Требуется, но не отображается
Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie
.
Необходимо ли управление потоком UART (RTS/CTS) для правильной работы беспроводных модулей?
Laird настоятельно рекомендует разработчикам использовать RTS/CTS для управления потоком в своих приложениях.
При обращении к CTS/RTS:
Модуль UART CTS является входным модулем
RTS является выходным
Модуль UART CTS является входом и подключен к RTS хоста, который, следовательно, является выходом.
Хост может сообщить модулю, что он готов принимать данные через UART, управляя его выходом RTS, который сигнализирует модулю через вход CTS модуля. Таким образом, модуль не будет отправлять данные, пока не будет подтверждено CTS. По сути, подтвержденный вывод RTS сообщает узлу, что отправка данных узлом безопасна.
Хост может остановить модуль, отправляющий ему данные, установив высокий уровень RTS, который, в свою очередь, установит высокий уровень CTS модуля.
Точно так же модуль может остановить отправку данных хостом, приняв высокий уровень RTS, что приведет к высокому уровню CTS хоста.
Рис. 1: Рекомендуемый минимум проводки UART при правильном использовании CTS/RTS (рекомендуется).
Отключение управления потоком
Однако, если приложение требует пропускной способности в эфире, которая ниже, чем пропускная способность настройки UART (скорость передачи, контроль четности и стоповые биты) или риск потенциальной потери данных или сброс модуля принимается разработчиком, тогда входная линия CTS может быть подключена к 0v/Gnd, а выходная линия RTS может быть плавающей, как показано на рисунке 2.9.0005
Рисунок 2: Минимальная проводка UART без правильного использования управления потоком CTS/RTS (не рекомендуется).
Прежде чем отказываться от правильного использования CTS/RTS, обратите внимание на следующее
Проблема №1: модуль не отвечает на команды
Модуль UART_CTS является входом, и не рекомендуется оставлять его плавающим.
Если он непреднамеренно окажется на уровне 3,3 В из-за конструкции схемы, модуль будет считать, что хост не готов к приему данных. Хост отправляет ему команду, например «at», но не получает ответа, поскольку модуль определяет, что он не может отправить, потому что хост не готов получать данные от модуля. Это обычная проблема для разработчиков, которые пропускают использование комплекта разработчика и подключаются напрямую к модулю, используя только UART TX, RX и GND.
Решения
1. Правильно используйте управление потоком (настоятельно рекомендуется), см. рис. 1.
2. Привяжите модуль UART CTS к 0 В, чтобы модуль всегда предполагал, что хост готов к приему данных (не рекомендуется) , см. рис. 2.
Проблема № 2: переполнение модуля, вызывающее потерю данных
В отличие от проводного соединения, радиосоединение более подвержено ухудшению качества из-за увеличения радиуса действия и помех. В какой-то момент пропускная способность по воздуху может упасть ниже пропускной способности UART (обратите внимание, что максимальная пропускная способность при отсутствии четности и настроенном одном стоповом бите составляет 80% от скорости передачи), и в этот момент модуль включит свои руки.
эфир и сказать: «Подождите, прекратите отправлять данные, чтобы я мог наверстать упущенное». Он делает это, поднимая свой RTS (выход) на высокий уровень. Хост видит, что его CTS (вход) следует его примеру, и прекращает отправку данных. Давайте рассмотрим, что происходит, когда CTS/RTS используется неправильно, а модуль UART_CTS привязан к Gnd или 0V. Когда это происходит, модуль переполняется данными от хоста, вскидывает руки в воздух и говорит «хватит», но модуль UART_RTS никуда не уходит, поэтому хост продолжает отправлять, не обращая внимания на бедственное положение модуля. В какой-то момент может произойти переполнение, что может привести к потере данных или, возможно, даже к сбою модуля.
Решения
1. Используйте надлежащее управление потоком CTS/RTS (настоятельно рекомендуется, см. рис. 1.
2. Смиритесь с тем, что вы можете потерять данные.
Вопрос № 3: А как насчет хоста? также ожидает правильного использования CTS/RTS, у него также могут возникнуть проблемы, когда дело доходит до отправки данных в модуль, поскольку ему может не быть сообщено, что модуль готов принять его данные.
