RTS·CTS·DTR·DSR로 이해하는 하드웨어 흐름 제어

RTS·CTS·DTR·DSR로 이해하는 하드웨어 흐름 제어#

1장 데이터는 보내는 것보다 멈추는 것이 더 어려울 수 있다#

1.1 수신 장비가 데이터를 따라가지 못한다면#

시리얼 통신에서 흔히 생각하는 문제는 다음과 같습니다.

송신 장비
↓
데이터 전송
↓
수신 장비

하지만 송신 장비가 계속 데이터를 보내는데 수신 장비가 그 속도를 처리하지 못한다면 어떻게 될까요?

수신 장비 내부에는 일반적으로 데이터를 임시로 저장하는 Buffer가 있습니다.

Serial Line
    ↓
Receive Buffer
    ↓
Application

Application이 충분히 빠르게 데이터를 가져가지 못하면 Buffer가 계속 쌓입니다.

10%
↓
40%
↓
80%
↓
100%

결국 Buffer가 가득 차면 새로운 데이터를 잃을 수 있습니다.

이때 필요한 것이 Flow Control입니다.

2장 Flow Control이란 무엇인가#

Flow Control은 송신 장비와 수신 장비 사이에서:

계속 보내도 되는가?

잠시 멈춰야 하는가?

다시 보내도 되는가?

를 조절하는 기능입니다.

대표적으로 두 가지 방식이 있습니다.

Hardware Flow Control
→ 별도의 신호선 사용

Software Flow Control
→ Data Stream 안의 제어 문자 사용

RS-232에서는 Hardware Flow Control에 RTS·CTS 신호가 널리 사용됩니다.

3장 9600-8-N-1에는 Flow Control이 포함되지 않는다#

앞에서 살펴본:

9600-8-N-1

은 다음을 의미합니다.

9600
Baud Rate

8
Data Bits

N
No Parity

1
Stop Bit

여기에는 Flow Control 정보가 없습니다.

따라서 두 장비가 모두:

9600-8-N-1

이라고 해도 한쪽은:

Flow Control
None

이고 다른 쪽은:

Flow Control
RTS/CTS

라면 통신 문제가 발생할 수 있습니다.

실제 Serial 설정은 다음처럼 봐야 합니다.

9600
8 Data Bits
No Parity
1 Stop Bit
RTS/CTS

또는:

9600-8-N-1
Flow Control: None

처럼 별도로 확인해야 합니다.

4장 RTS와 CTS는 무엇인가#

4.1 RTS#

RTS는:

Request To Send

입니다.

4.2 CTS#

CTS는:

Clear To Send

입니다.

이 이름만 보면 다음처럼 이해하기 쉽습니다.

송신측
"보내도 될까?"
↓ RTS

수신측
"보내도 된다."
↓ CTS

전통적인 RS-232와 Modem 환경에서는 이러한 이름의 역사적 의미가 중요했습니다.

다만 현대의 UART 기반 장비에서는 RTS와 CTS가 송신 가능 여부를 제어하는 Hardware Handshake 신호로 사용되는 경우가 많습니다.

따라서 실제 장비에서는 신호 이름만 보고 동작 방식을 단정해서는 안 됩니다.

5장 현대적인 RTS/CTS Flow Control은 어떻게 동작할까#

가장 이해하기 쉬운 구조는 다음과 같습니다.

장비 A                         장비 B

TX  ───────────────────────→ RX

RX  ←─────────────────────── TX

RTS ───────────────────────→ CTS

CTS ←─────────────────────── RTS

장비 B가 데이터를 더 받을 수 없는 상태가 되면 Hardware Handshake를 이용해 장비 A의 송신을 일시적으로 제한할 수 있습니다.

Buffer에 여유가 생기면 다시 송신을 허용합니다.

개념적으로:

수신 Buffer 여유 있음
↓
송신 가능
↓
데이터 전송

수신 Buffer 부족
↓
송신 일시 정지

Buffer 처리
↓
여유 발생
↓
송신 재개

입니다.

정확한 신호 활성 상태와 RTS 사용 방식은 UART·Driver·장비 제조사 구현에 따라 달라질 수 있으므로 Manual을 확인해야 합니다.

6장 CTS가 없으면 왜 데이터가 전혀 안 나갈 수 있을까#

다음 상황을 생각해보겠습니다.

PC 설정:

9600-8-N-1
RTS/CTS Enabled

Cable:

TX
RX
GND

만 연결되어 있습니다.

즉 CTS Line이 없습니다.

Software나 UART Driver가 CTS 상태를 확인한 뒤에만 송신하도록 구성되어 있다면:

CTS 확인
↓
송신 허가 없음
↓
TX 대기

상태가 될 수 있습니다.

사용자가 보기에는:

Port도 열렸는데
왜 아무 데이터도 안 나가지?

라는 현상으로 보입니다.

그래서 3선 Cable을 사용하는 장비에서는 Flow Control 설정도 반드시 확인해야 합니다.

7장 DB9에서 RTS와 CTS는 어디에 있을까#

전통적인 DTE DB9 기준의 대표적인 Pin은 다음과 같습니다.

Pin Signal 의미
2 RxD Receive Data
3 TxD Transmit Data
4 DTR Data Terminal Ready
5 GND Signal Ground
6 DSR Data Set Ready
7 RTS Request To Send
8 CTS Clear To Send

Hardware Flow Control을 사용하는 대표적인 연결에서는 RTS와 CTS까지 Cable에 포함될 수 있습니다.

단순 3선 통신:

TX
RX
GND

Hardware Handshake를 포함한 통신:

TX
RX
RTS
CTS
GND

처럼 생각할 수 있습니다.

다만 실제 Cable 구성은 DTE·DCE 관계와 장비 Pinout에 따라 달라집니다.

8장 DTR과 DSR은 무엇인가#

RTS·CTS와 함께 많이 보이는 것이:

DTR
DSR

입니다.

8.1 DTR#

DTR은:

Data Terminal Ready

를 의미합니다.

전통적으로 DTE 측 장비가 준비되어 있다는 상태를 나타내는 데 사용되었습니다.

8.2 DSR#

DSR은:

Data Set Ready

를 의미합니다.

전통적인 DCE 장비가 준비되어 있다는 상태를 나타냅니다.

개념적으로:

DTE
"나는 준비되어 있다."
↓
DTR

DCE
"나도 준비되어 있다."
↓
DSR

입니다.

9장 DTR·DSR은 RTS·CTS와 같은 Flow Control일까#

완전히 같은 역할은 아닙니다.

일반적으로:

RTS / CTS
→ Data 송수신 흐름과 관련된 Handshake

DTR / DSR
→ 장비의 Ready 상태와 관련된 제어 신호

로 구분하는 것이 좋습니다.

다만 실제 산업 장비에서는 이 신호들을 표준적인 용도와 다르게 사용하는 경우도 있습니다.

예를 들어 특정 장비가 DTR 상태를 이용해:

장비 활성화

통신 세션 초기화

Reset

특정 Operating Mode 전환

등을 구현할 수도 있습니다.

따라서 DTR을 임의로 On/Off하면 안 됩니다.

10장 DTR 때문에 장비가 Reset되는 경우도 있다#

개발자가 Serial Port를 열었는데 연결된 장비가 갑자기 재부팅한다고 가정해보겠습니다.

원인이 Data Packet이 아닐 수도 있습니다.

일부 Serial Driver나 Library는 Port를 열거나 닫을 때:

DTR

상태를 변경할 수 있습니다.

연결된 장비가 DTR 변화를 Reset 또는 Control Signal로 사용하도록 설계돼 있다면:

Port Open
↓
DTR 상태 변화
↓
장비 Reset

이 발생할 수 있습니다.

Microcontroller 개발 환경에서도 유사한 구조를 볼 수 있습니다.

따라서:

Serial Port를 열었더니
장비가 재부팅된다.

면 DTR 동작도 확인할 가치가 있습니다.

11장 Software Flow Control은 무엇인가#

Hardware Flow Control이 별도의 Signal Line을 사용한다면 Software Flow Control은 Data Stream 자체를 이용합니다.

대표적으로:

XON
XOFF

가 있습니다.

일반적으로:

XON
0x11

XOFF
0x13

제어 문자를 사용합니다.

12장 XON과 XOFF는 어떻게 동작할까#

수신 장비의 Buffer가 가득 차기 시작합니다.

Receive Buffer
10%
↓
50%
↓
90%

수신 장비가 송신 장비에:

XOFF
0x13

를 보냅니다.

의미는:

잠시 멈춰라.

입니다.

Buffer가 비워지면:

XON
0x11

을 보냅니다.

의미는:

다시 보내라.

입니다.

13장 Hardware와 Software Flow Control의 차이#

항목 RTS/CTS XON/XOFF
방식 별도 Signal Line Data 안의 제어 문자
추가 배선 필요 불필요
Data 내용 영향 거의 없음 제어 문자와 충돌 가능
Binary Data 비교적 다루기 편함 설계에 주의 필요
구현 Hardware·Driver 지원 필요 Software 처리 가능
대표 신호 RTS·CTS 0x11·0x13

14장 Binary Protocol에서는 XON/XOFF를 조심해야 한다#

Binary Protocol에서 다음 Byte가 정상 Data라고 생각해보겠습니다.

13

Hexadecimal로는:

0x13

입니다.

그런데 Software Flow Control이 활성화되어 있다면 이 값이:

XOFF

로 해석될 수 있습니다.

Protocol이나 Driver가 이를 Flow Control Character로 처리하면 예상하지 못한 송신 중단이 발생할 수 있습니다.

따라서 Binary Protocol에서는:

XON/XOFF 사용 여부

Byte Escaping

Driver 설정

Protocol 설계

를 함께 확인해야 합니다.

15장 Hardware Flow Control이 항상 더 좋은 것은 아니다#

RTS/CTS에는 장점이 있습니다.

Data Stream을 오염시키지 않음

Hardware 수준에서 빠르게 제어 가능

Binary Data와 함께 사용하기 편함

하지만 단점도 있습니다.

추가 배선 필요

Pinout 복잡

장비 지원 필요

Cable 호환성 문제

따라서 간단한 저속 통신에서는:

Flow Control
None

을 사용하는 장비도 많습니다.

16장 Flow Control이 없어도 정상적인 시스템은 많다#

예를 들어 장비가:

명령 10 Byte 수신
↓
응답 20 Byte 송신
↓
대기

처럼 매우 적은 Data를 주고받는다면 Buffer가 가득 찰 가능성이 낮을 수 있습니다.

이런 시스템에서는:

9600-8-N-1
Flow Control: None

만으로 충분한 경우가 많습니다.

반대로:

연속 Log

대용량 Data

고속 전송

처리 속도가 느린 수신기

같은 환경에서는 Flow Control의 중요성이 커질 수 있습니다.

17장 Flow Control과 Protocol ACK는 다르다#

자주 혼동하는 부분입니다.

RTS/CTS Flow Control:

지금 데이터를 보내도 되는가?

를 제어합니다.

Protocol의 ACK:

특정 Message를 정상적으로 받았는가?

를 확인하는 데 사용될 수 있습니다.

둘은 목적이 다릅니다.

RTS / CTS
→ 전송 흐름

ACK / NACK
→ Protocol Message 처리 결과

입니다.

Hardware Flow Control을 사용한다고 해서 Application 수준의 ACK가 필요 없어지는 것은 아닙니다.

18장 TCP Flow Control과도 다른 개념이다#

TCP에도 Flow Control이 있습니다.

하지만 RS-232의 RTS/CTS와는 다른 계층의 기능입니다.

RS-232
RTS / CTS
→ Serial Hardware 수준

TCP
Receive Window
→ Network Transport 수준

두 기술 모두 상대의 처리 능력을 고려해 송신량을 조절한다는 목적은 비슷하지만 동작 방식은 완전히 다릅니다.

19장 RS-485의 송수신 전환과도 구분해야 한다#

RS-485 2선식 Half Duplex에서는 Transceiver가:

송신 Mode
↕
수신 Mode

를 전환해야 합니다.

일부 Serial Converter에서는 RTS를 이 전환 제어에 사용하기도 했습니다.

예:

RTS Active
↓
RS-485 Driver Enable
↓
송신

RTS Inactive
↓
Receive Mode

하지만 이것은 RTS/CTS Hardware Flow Control과 같은 개념이 아닙니다.

하나는:

상대방과의 흐름 제어

이고 다른 하나는:

RS-485 Transceiver 방향 제어

입니다.

현장에서 두 기능을 혼동하면 장애 분석이 어려워집니다.

20장 실제 현장에서 자주 발생하는 장애#

20.1 3선 Cable인데 RTS/CTS가 켜져 있다#

구성:

Cable
TX
RX
GND

PC:

Hardware Flow Control
ON

증상:

Port Open 정상

Error 없음

그런데 Data가 나가지 않음

먼저 Flow Control 설정을 확인합니다.

20.2 장비는 RTS/CTS를 요구하는데 Cable에 선이 없다#

장비 Manual:

Hardware Handshake
Required

Cable:

TX
RX
GND

만 존재합니다.

이 경우 장비가 의도한 방식으로 동작하지 않을 수 있습니다.

20.3 한쪽은 XON/XOFF, 한쪽은 None#

송신 장비는:

XON/XOFF Enabled

수신 장비는:

Flow Control None

이라고 하겠습니다.

수신 쪽에서는 XON·XOFF Byte를 일반 Data로 처리할 수도 있고, 송신 쪽에서는 예상하지 못한 Data 값 때문에 흐름이 중단될 수도 있습니다.

20.4 RTS와 CTS Pin이 잘못 연결되어 있다#

일반적인 Hardware Handshake 관계에서는 상대 장비의 Output과 Input 관계가 맞아야 합니다.

잘못 연결되면:

CTS 상태 변화 없음
↓
송신 대기
↓
통신 정지

처럼 보일 수 있습니다.

21장 주차관제 현장에서의 예#

예를 들어 출입 Reader가 Controller와 RS-232로 연결되어 있다고 하겠습니다.

Reader
↓
RS-232
↓
Gate Controller

평소에는 문제가 없는데 차량이 집중되는 시간에 간헐적으로 Data가 누락됩니다.

무조건 Flow Control 문제라고 판단하면 안 됩니다.

다음 요소를 먼저 확인해야 합니다.

실제 Serial Data가 손실되는가?

Reader 내부 Buffer가 넘치는가?

Controller Application이 Port를 제때 읽는가?

Baud Rate가 충분한가?

RTS/CTS를 지원하는가?

Cable에 RTS/CTS가 실제 배선되어 있는가?

Protocol 수준에서 Message가 유실되는가?

증상만으로 Hardware Flow Control을 추가하는 것보다 먼저 어느 Buffer에서 Data가 사라지는지 확인하는 것이 중요합니다.

22장 Flow Control 문제인지 확인하는 방법#

장애가 발생하면 다음 순서로 확인합니다.

1. 장비 Manual 확인
↓
2. Flow Control 방식 확인
↓
3. Cable Pinout 확인
↓
4. RTS / CTS 배선 확인
↓
5. Serial Driver 설정 확인
↓
6. Signal 상태 확인
↓
7. 실제 Byte Stream 확인
↓
8. Application Buffer 확인

23장 Linux에서 RTS/CTS 설정하기#

Linux의 stty에서 지원되는 환경이라면 다음과 같이 Hardware Flow Control을 활성화할 수 있습니다.

stty -F /dev/ttyS0 crtscts

비활성화:

stty -F /dev/ttyS0 -crtscts

현재 설정 확인:

stty -F /dev/ttyS0 -a

예를 들어 9600-8-N-1과 RTS/CTS를 함께 설정한다면:

stty -F /dev/ttyS0 9600 cs8 -parenb -cstopb crtscts

처럼 구성할 수 있습니다.

운영 장비에 적용하기 전에 반드시 현재 설정을 기록하고 시험 환경에서 검증해야 합니다.

24장 Python에서 RTS/CTS 사용하기#

pySerial에서는 다음과 같이 설정할 수 있습니다.

import serial

ser = serial.Serial(
    port="/dev/ttyS0",
    baudrate=9600,
    bytesize=serial.EIGHTBITS,
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_ONE,
    rtscts=True,
    timeout=1
)

ser.write(b"TEST\r\n")

response = ser.readline()

print(response)

ser.close()

여기서:

rtscts=True

가 Hardware Flow Control 사용 설정입니다.

Software Flow Control을 사용할 경우 Library에서 별도의 XON/XOFF 설정을 제공합니다.

25장 DTR과 RTS를 Application에서 직접 변경할 수도 있다#

일부 Serial Library에서는 RTS와 DTR 상태를 Application에서 직접 제어할 수 있습니다.

예를 들어 pySerial에서는 장치와 환경에 따라 다음과 같은 접근이 가능합니다.

ser.rts = True
ser.dtr = True

하지만 실제 장비에서는 이 신호가 어떤 기능에 연결돼 있는지 반드시 확인해야 합니다.

특히 DTR이나 RTS를 제조사가:

Reset

Enable

Mode Select

RS-485 Direction Control

등으로 사용했다면 단순한 테스트가 실제 장비 동작에 영향을 줄 수 있습니다.

26장 RTS/CTS를 사용한다고 Buffer Overflow가 절대 발생하지 않는 것은 아니다#

Hardware Flow Control이 있더라도 다음과 같은 문제는 남아 있을 수 있습니다.

OS Driver Buffer Overflow

Application 처리 지연

잘못된 Driver 구현

Hardware FIFO 크기 제한

Flow Control 반응 지연

Protocol Parser 지연

따라서:

RTS/CTS 켜면
데이터 손실 문제가 전부 해결된다.

라고 생각하면 안 됩니다.

시스템 전체 Data Path를 봐야 합니다.

Device
↓
UART FIFO
↓
Driver Buffer
↓
OS
↓
Application Buffer
↓
Parser
↓
Business Logic

어느 단계에서도 병목이 발생할 수 있습니다.

27장 Serial 통신의 Buffer를 이해하자#

실제 통신은 단순히:

TX → RX

만 존재하는 것이 아닙니다.

대략적으로:

송신 Application
↓
송신 Buffer
↓
UART
↓
Cable
↓
UART
↓
수신 Buffer
↓
수신 Application

구조를 가집니다.

Flow Control은 이 흐름 중 상대의 처리 능력을 고려해 Data 전송을 조절하는 방법입니다.

28장 Flow Control과 Baud Rate는 함께 봐야 한다#

예를 들어 수신 Application이 초당 처리할 수 있는 Data보다 송신 속도가 훨씬 빠르다면 Buffer가 계속 증가할 수 있습니다.

Input
100 KB/s

Processing
10 KB/s

라면 장기적으로는 Flow Control만으로 문제를 없애기 어렵습니다.

송신을 계속 멈추게 될 뿐입니다.

이 경우:

Baud Rate

Application 처리 성능

Buffer Size

Protocol 구조

Data 발생량

까지 함께 검토해야 합니다.

29장 장애 증상으로 Flow Control 문제를 추정하기#

증상 확인할 항목
Port는 열리지만 송신이 안 됨 CTS·RTS/CTS 설정
일정량 보내다 멈춤 CTS 상태·Buffer
짧은 명령은 정상, 대량 전송 실패 Flow Control·Buffer
특정 Byte 이후 멈춤 XON/XOFF
Binary Data에서 간헐적으로 정지 Software Flow Control
Port Open 시 장비 Reset DTR
RS-485 Converter가 송신 후 수신 못 함 Direction Control
일부 Data 누락 Buffer·Flow Control·Application 처리

30장 Logic Analyzer와 Serial Analyzer로 확인하기#

Flow Control 문제를 정확하게 확인하려면 Data Line뿐 아니라 Control Line도 같이 관찰하면 좋습니다.

예:

TX
RX
RTS
CTS
DTR
DSR

를 시간축으로 확인합니다.

예를 들어:

CTS Active
───────┐
       │
       └────

TX Data
████████
       STOP

처럼 CTS 변화에 맞춰 TX가 실제로 멈추는지 확인할 수 있습니다.

이렇게 보면 Software 설정 문제와 실제 배선 문제를 구분하기 쉬워집니다.

31장 RTS·CTS 신호 극성은 이름만 보고 판단하지 않는다#

RS-232는 흔히 사용하는 TTL Logic과 전압 및 Active 상태 표현이 다를 수 있습니다.

또한 Operating System과 Serial API에서는:

True
False

로 표시되는 상태가 물리 Line의 전압과 단순히 같은 의미가 아닐 수도 있습니다.

따라서:

High니까 On

Low니까 Off

처럼 일반 Digital Logic 개념만으로 판단하지 않는 것이 좋습니다.

Serial Driver와 Hardware Manual의 신호 정의를 확인해야 합니다.

32장 흐름 제어와 장비 Protocol은 별개의 층이다#

장비 Protocol:

STX
CMD
DATA
CRC
ETX

Hardware Flow Control:

RTS
CTS

UART:

Start
Data
Parity
Stop

RS-232:

Electrical Signal

을 계층으로 놓으면:

Application Protocol
↓
Byte Stream
↓
UART
↓
Hardware Flow Control
↓
RS-232 Electrical Interface

처럼 이해할 수 있습니다.

실제로는 각 기능이 Hardware와 Driver에서 상호작용하지만 장애 분석을 위해 계층을 구분해 보는 것이 매우 유용합니다.

33장 보안에서도 Control Line을 무시하면 안 된다#

RTS·CTS·DTR·DSR 자체는 인증이나 암호화 기능이 아닙니다.

특히 Serial Console이나 Maintenance Port가 외부에서 접근 가능하다면:

장비 설정 변경

Debug Mode 진입

Log 조회

관리 Command 실행

등이 가능할 수 있습니다.

따라서 다음이 중요합니다.

물리 Port 접근 통제

제어반 잠금

작업자 권한 관리

Console 사용 기록

Maintenance 절차

Serial Port 자체가 Network에 노출되지 않는다고 해서 자동으로 안전한 것은 아닙니다.

34장 산업 현장에서 가장 중요한 것은 제조사 문서다#

RS-232라는 표준 이름을 사용한다고 모든 장비가 동일하게 동작하지는 않습니다.

제조사가 다음과 같이 구현할 수 있습니다.

RTS/CTS 사용 안 함

DTR 필요

DSR 무시

RTS를 RS-485 방향 제어로 사용

3선 Cable만 지원

자체 Pinout 사용

따라서 현장에서는 다음 순서를 따르는 것이 좋습니다.

Interface 확인
↓
Pinout 확인
↓
9600-8-N-1 확인
↓
Flow Control 확인
↓
RTS / CTS 확인
↓
DTR / DSR 확인
↓
실제 Signal 측정
↓
Protocol 확인

35장 흔히 하는 잘못된 판단#

35.1 RTS는 무조건 송신 요청이고 CTS는 그 응답이다#

이름의 역사적 의미는 그렇지만 현대 장비에서 Hardware Flow Control을 구현하는 방식은 UART·Driver·장비 설계에 따라 다를 수 있습니다.

실제 Manual을 확인해야 합니다.

35.2 RTS/CTS만 켜면 데이터 손실이 사라진다#

아닙니다.

Application 처리 속도, Buffer, Driver, Protocol 문제는 별도로 존재합니다.

35.3 DTR과 DSR도 RTS/CTS와 같은 흐름 제어다#

동일한 기능은 아닙니다.

전통적으로 DTR·DSR는 장비 Ready 상태를 나타내는 Control Line입니다.

35.4 3선 Cable에서도 RTS/CTS를 그냥 켜면 된다#

CTS 입력을 정상적으로 받지 못하면 오히려 송신이 멈출 수 있습니다.

35.5 XON/XOFF는 모든 Binary Protocol에서 문제없다#

제어 문자가 실제 Data Byte와 겹칠 수 있으므로 Protocol과 Driver 동작을 확인해야 합니다.

35.6 RTS는 RS-485에서도 항상 Flow Control이다#

아닙니다.

일부 Converter에서는 RTS를 Transceiver의 송수신 방향 제어에 사용하기도 합니다.

36장 자기 점검#

36.1 Hardware Flow Control은 왜 필요한가#

수신 장비가 처리할 수 있는 속도에 맞춰 송신을 멈추거나 다시 시작하기 위해 사용합니다.

36.2 RTS와 CTS는 어디에 사용되는가#

RS-232에서 Hardware Handshake와 Flow Control에 널리 사용되는 Control Signal입니다.

정확한 동작은 장비 구현을 확인해야 합니다.

36.3 DTR과 DSR은 무엇인가#

전통적으로 DTE와 DCE의 준비 상태를 나타내는 RS-232 Control Signal입니다.

36.4 XON과 XOFF는 어떤 값인가#

일반적인 Software Flow Control에서:

XON
0x11

XOFF
0x13

을 사용합니다.

36.5 9600-8-N-1이 같으면 Flow Control도 같은가#

아닙니다.

Flow Control은 별도의 Serial 설정입니다.

37장 현장 점검 체크리스트#

RS-232 Hardware Flow Control 문제를 의심한다면 다음을 확인합니다.

□ 장비가 RTS/CTS를 지원하는가?

□ Flow Control이 None인지 RTS/CTS인지 확인했는가?

□ Cable에 RTS와 CTS가 실제 연결되어 있는가?

□ 장비 Pinout이 표준적인 DB9 배열을 따르는가?

□ DTE·DCE 관계를 확인했는가?

□ CTS 상태 때문에 송신이 막혀 있지 않은가?

□ XON/XOFF가 동시에 활성화돼 있지 않은가?

□ DTR 상태 변경이 장비에 영향을 주지 않는가?

□ Serial Driver Buffer 상태를 확인했는가?

□ Application이 Receive Buffer를 충분히 빠르게 처리하는가?

38장 이 글을 마치며#

Serial 통신은 단순히:

TX
RX
GND

만 연결한다고 항상 완성되는 것은 아닙니다.

Data가 많아지거나 장비의 처리 속도가 서로 달라지면:

언제 보내는가?

언제 멈추는가?

언제 다시 시작하는가?

라는 문제가 생깁니다.

이 문제를 해결하기 위해 Hardware Flow Control에서는:

RTS
CTS

를 사용할 수 있고, Software Flow Control에서는:

XON
XOFF

를 사용할 수 있습니다.

또한 RS-232에는:

DTR
DSR

같은 장비 상태 관련 Control Signal도 존재합니다.

핵심은 이 신호들의 이름을 외우는 것이 아닙니다.

실제 Serial 통신을 다음 흐름으로 이해하는 것입니다.

Application
↓
송신 Buffer
↓
UART
↓
RTS / CTS
↓
RS-232 Line
↓
UART
↓
수신 Buffer
↓
Application

그리고 문제가 생겼을 때:

배선
↓
Serial 설정
↓
Flow Control
↓
Buffer
↓
Protocol
↓
Application

순으로 범위를 좁힙니다.

특히 다음 네 가지를 기억하면 됩니다.

9600-8-N-1에는 Flow Control 설정이 포함되어 있지 않습니다.

RTS·CTS는 Hardware Flow Control에 사용할 수 있지만 실제 동작 방식은 장비와 Driver 구현을 확인해야 합니다.

DTR·DSR는 전통적으로 장비 준비 상태를 나타내며 RTS·CTS와 같은 역할로 단순화하면 안 됩니다.

Flow Control은 데이터의 양을 조절하는 기능이지 Packet의 정상 처리나 장비의 실제 동작 완료를 보장하는 기능이 아닙니다.

RS-232를 제대로 이해하려면 Data Line뿐 아니라 Data가 언제 흘러도 되는지를 결정하는 Control Line까지 함께 읽을 수 있어야 합니다.

이 페이지의 목차