What is the difference between baud rate and bit rate in UART?

For UART, baud rate equals bit rate because each symbol carries exactly one bit. In other modulation schemes (like QAM used in modems), one symbol can encode multiple bits, so baud rate and bit rate differ. But for standard UART, 115200 baud means 115200 bits per second on the wire.

Why does my serial monitor show garbage characters?

The most common cause is a baud rate mismatch — one side is transmitting at a different speed than the other is receiving. Other causes include voltage level mismatch (3.3V vs 5V), swapped TX/RX lines, or incorrect data format settings (wrong number of data bits, stop bits, or parity).

What is the maximum reliable UART baud rate?

It depends on your hardware. Most MCUs with hardware UART peripherals reliably support up to 921600 baud with a crystal oscillator and short wires. Some chips like the ESP32 and FTDI adapters can reach 3 Mbaud or higher. Software (bit-banged) UART is typically limited to 38400 baud or less.

Why do 7.3728 MHz and 11.0592 MHz crystals exist?

These 'odd' crystal frequencies divide evenly into standard UART baud rates with zero error. For example, 11.0592 MHz / (16 × 6) = exactly 115200. Round frequencies like 8 MHz and 16 MHz produce fractional dividers that must be rounded, introducing baud rate error that can exceed the 2% tolerance for reliable communication.

How much clock error can UART tolerate?

The standard design rule is ±2% total cumulative error between transmitter and receiver. This means each side should be within ±1% of the target baud rate. Crystal oscillators (±20 ppm) easily meet this requirement, but internal RC oscillators (±1% to ±5%) may not, especially over temperature extremes.

Protocol2026년 5월 7일12분 읽기

UART 전송 속도 설명: 가비지 문자부터 신뢰할 수 있는 직렬 링크까지

9600 및 115200이 존재하는 이유, 클럭 오류로 인해 프레이밍 오류가 발생하는 이유, 실제 MCU를 사용한 실제 사례, 모든 임베디드 엔지니어가 알아야 하는 2% 규칙 등 UART 전송 속도에 대한 실용 가이드.

모두가 겪었던 순간
보드 레이트의 실제 정의
표준 전송 속도 (그리고 왜 이상한 숫자인지)
9600이 범용 기본값인 이유`9600`baud는 거의 모든 클럭 소스, 수 미터 미만의 와이어 길이, 모든 UART 주변 장치, 심지어 가장 기본적인 장치에서도 작동할 수 있을 만큼 충분히 느립니다.“딱 맞는” 속도입니다.GPS 모듈이 기본으로 설정되어 있습니다.부트로더가 사용합니다.기기가 말하는 속도를 모를 때는`9600`명령을 먼저 시도하세요.
작업 예: GPS 모듈 불일치
작업 예: 고속 센서 데이터 로깅
2% 규칙 — 클럭 허용 오차
왜 2% 일까요?
실제 2% 는 어떤 모습일까요`115200`보우드에서 2% 의 오차는 실제 전송 속도가 112,896에서 117,504 사이임을 의미합니다.비트 주기가 ±0.17µs 떨어졌습니다.10비트 프레임에서는 ±1.7µs의 드리프트가 누적되는데, 이는 비트 주기의 약 20% 에 해당합니다.여전히 안전하지만 마진을 다 쓰고 있습니다.`9600`보드에서는 비트 주기가 매우 넓기 때문에 2% 오류는 절대적인 측면에서 훨씬 덜 중요합니다 (비트당 ±2.08µs, 프레임당 ±20.8µs).`9600`기본값이 “안전한” 기본값인 또 다른 이유가 바로 여기에 있습니다. 심지어 끔찍한 오실레이터도 이에 부딪힐 수 있기 때문입니다.
MCU 클럭 소스 및 전송 속도 오류
크리스탈 오실레이터 (HSE)
내장 RC 오실레이터 (HSI)
BRR 디바이저 문제
흔히 저지르는 실수
1.코드의 전송 속도가 잘못되었습니다.
2.소프트웨어 UART (비트뱅잉) 제한
3.전압 레벨 불일치 (전송 속도 문제인 것 같음)
4.UART 오버헤드를 잊어버리는 중
5.온도 편차를 고려하지 않음
언제 어떤 전송 속도를 사용할까요?
계산기 사용
요약 참조: UART 전송 속도 공식

모두가 겪었던 순간

보드 두 개를 연결하면 돼요.TX에서 RX로, RX에서 TX로, 그라운드 투 그라운드.펌웨어를 플래시하고 시리얼 모니터를 열고... 쓰레기를 치우면,ÿÿÿÿ또는⸮⸮⸮⸮아니면 아무것도 없을 수도 있습니다.배선을 다시 한번 확인해 보세요.TX와 RX를 바꿉니다 (누구나 한 번은 이 작업을 수행합니다).아직도 쓰레기야.

그러자 누군가 이렇게 묻습니다. “전송 속도를 어떻게 설정하셨나요?”

그리고 저기 있어요.한쪽은9600언어로 말하고 다른 한쪽은115200에서 듣고 있습니다.전기 신호는 전압 수준, 배선 등 모든 것이 완벽하지만 두 장치의 음성 속도는 완전히 다릅니다.마치 누군가가 세 배 속도로 페이지를 넘기는 동안 책을 읽으려고 하는 것과 같습니다.등장인물이 전부 다 나와 있어서 도저히 이해가 안 돼요.

이는 임베디드 시스템에서 가장 흔히 발생하는 직렬 통신 장애로, 전송 속도가 실제로 무엇을 의미하고 UART에서 전송 속도가 왜 중요한지 이해하면 완전히 예방할 수 있습니다.

보드 레이트의 실제 정의

전송 속도는 와이어에서 초당 신호 전환 (기호) 이 발생하는 횟수입니다.특히 UART의 경우 각 심볼은 1비트이므로 전송 속도는 비트 레이트와 같습니다.115200보우를 설정하면 1/115200초마다 라인 전압을 변경하도록 송신기에 지시하는 것으로, 이는 비트당 약 8.68마이크로초로 계산됩니다.

중요한 점은 다음과 같습니다. UART에는 클럭 와이어가 없습니다. SPI나 I2C와 달리, 수신기에 샘플링 시기를 알려주는 별도의 신호가 없습니다.양측 모두 자체 클록에서 자체 타이밍을 독립적으로 생성합니다.양측 모두 미리 속도에 합의하기만 하면 됩니다.

마치 두 사람이 나눠서 티커 테이프를 읽는 것과 같다고 생각해 보세요.각 글자마다 종소리가 울리지 않습니다. 둘 다 8.68마이크로초마다 다음 글자를 보기로 동의했을 뿐이죠.한 사람의 시계가 5% 빠르게 작동한다면 결국에는 잘못된 문자를 읽기 시작하게 됩니다.UART에서는 시계가 일치하지 않을 때 바로 이런 일이 일어납니다.

수신기는 하이 (유휴) 에서 로우 비트로의 전환인 시작 비트를 관찰하여 바이트의 시작을 감지합니다.하강 에지가 감지되면 내부 타이머를 시작하고 예상 간격으로 데이터 비트를 샘플링합니다.비트 7이나 정지 비트에 도달할 때쯤이면 전송 속도가 약간이라도 떨어진다면 잘못된 순간에 샘플링을 한 것입니다.

표준 전송 속도 (그리고 왜 이상한 숫자인지)

시리얼을 사용해 본 적이 있다면 일반적인 용의자를 본 적이 있을 것입니다.

전송 속도	비트 기간	오리진
75	13.3밀리초	텔레그래프 (바우도트 코드)
110	9.1밀리초	텔레타이프 ASR-33
300	3.33밀리초	초기 어쿠스틱 모뎀
1200	833마이크로초	1200보드 모뎀 시대
2400	417마이크로초	V.22 표준
9600	104마이크로초	사실상의 “안전 기본값”
19200	52.1마이크로초	2× 9600
38400	26.0마이크로초	4× 9600
57600	17.4마이크로초	오드볼 (6× 9600 아님)
115200	8.68마이크로초	표준 “고속” UART
230400	4.34마이크로초	2× 115200
460800	2.17 마이크로초	많은 MCU에 적용 가능
921600	1.09마이크로초	한계 근접

왜 이렇게 특정한 수치가 나오나요?역사적으로 일어난 사고들이죠. 75 보드는 전신 시대에서 유래했습니다. 바우도 코드는 5비트 문자를 사용했고 75 보드는 작업자에게 출력물을 읽을 시간을 주었습니다. 110 보우드는 텔레타이프 모델 33의 속도였는데, 프린트 헤드의 기계적 한계로 설정되었습니다. 300 baud는 널리 사용된 최초의 모뎀 속도 (핸드셋을 꽂을 때 사용하는 어쿠스틱 커플러) 였습니다.이후 각 세대는 1200, 2400, 4800, 9600으로 약 두 배로 늘어났습니다.하지만 이 둘은 2의 거듭제곱이 아니라 300의 배수입니다.

그렇다면56400(더 깨끗한 배수) 대신57600이 표준 세트에 있는 이유는 무엇일까요?115200 / 2인데115200자체는 IBM PC에 사용되는 8250 UART 칩에서 나온 것입니다.8250에는 1.8432MHz 오실레이터가 장착되어 있고 제수가 1이면 115200 보드 (1843200/ 16 = 115200) 가 됩니다.16의 제수 오버샘플링은 하드웨어에 내장되어 있습니다.

그 결과, 우리는 모두 1981년에 선택한 크리스탈 주파수에 따라 결정되는 전송 속도를 여전히 사용하고 있습니다.

9600이 범용 기본값인 이유`9600`baud는 거의 모든 클럭 소스, 수 미터 미만의 와이어 길이, 모든 UART 주변 장치, 심지어 가장 기본적인 장치에서도 작동할 수 있을 만큼 충분히 느립니다.“딱 맞는” 속도입니다.GPS 모듈이 기본으로 설정되어 있습니다.부트로더가 사용합니다.기기가 말하는 속도를 모를 때는`9600`명령을 먼저 시도하세요.

그러나9600은 짧은 문자 메시지 이외의 모든 경우에 대해서도고통스러울 정도로 느리다.프레임당 10비트 (8N1 형식) 에서는 초당 960바이트를 얻을 수 있습니다.1KB 디버그 로그를 인쇄하는 데 1초 이상 걸립니다.대부분의 개발 작업에서115200기술을 사용하는 이유가 바로 여기에 있습니다. 최신 MCU 크리스탈을 사용해도 12배 더 빠르고 안정적입니다.

작업 예: GPS 모듈 불일치

유블럭스 NEO-6M GPS 모듈이 있다고 가정해 봅시다.기본적으로 NMEA 문장을9600보우드로 출력합니다.STM32 펌웨어가115200에서 실수로 USART2 설정을 합니다.무슨 일이 일어날까요?

GPS는$문자 (ASCII 0x24, 바이너리00100100) 를 전송합니다.9600보드의 와이어에서 각 비트의 너비는 104.17µs입니다.전체 10비트 프레임 (시작+8데이터+중지) 은 1.042ms가 걸립니다.

하지만 STM32 샘플링은115200속도로 진행되고 있습니다. 비트 폭은 8.68µs일 것으로 예상됩니다.시작 비트의 하강 에지가 보이면 8.68µs마다 샘플링을 시작합니다.GPS가 1비트 (104.17µs) 를 전송하는 데 걸리는 시간 동안 STM32 샘플링은 12회입니다.실제로는 단일 비트인 것에서 12개의 “비트”를 읽습니다.

결과: 터미널에서 무작위로 보이는 문자를 볼 수 있습니다.잘못된 문자만 있는 것이 아닙니다. 수신기가 파형을 의도한 것보다 12배 더 많은 조각으로 나누고 있기 때문에 전혀 예측할 수 없습니다.

해결 방법: 전송 속도를 일치시키세요.STM32 모드를9600모드로 설정하거나 (UBX 프로토콜 명령을 통해) GPS를115200모드로 재구성하세요.협상이나 자동 감지 기능도 없습니다 (대부분의 경우). 양측 모두 동일한 속도로 명시적으로 구성해야 합니다.

작업 예: 고속 센서 데이터 로깅

1kHz (초당 1000개 샘플) 의 속도로 가속도계를 읽는 데이터 로거를 만들고 있습니다.각 샘플에는 16비트 정수의 X, Y, Z축과 타임스탬프가 있습니다.PC 캡처를 위해 UART를 통해 FTDI USB 직렬 어댑터로 스트리밍하는 것이 좋습니다.

필요한 전송 속도를 알아봅시다.

1단계: 데이터 페이로드를 계산합니다.

3축 × 각 2바이트 = 샘플당 6바이트
타임스탬프의 경우 4바이트 = 4바이트
2바이트 오버헤드 (헤더+체크섬) = 2바이트
합계: 샘플당 12바이트

2단계: 초당 바이트 수를 계산합니다.

12바이트 × 1000 샘플/초 = 12,000바이트/초

3단계: 초당 비트 수로 변환 (UART 오버헤드 고려).

표준 8N1 프레이밍의 경우 와이어에서 각 바이트의 비용은 10비트입니다 (시작 1개+데이터 8개+스톱 1개).

12,000바이트 × 10비트/바이트 = 120,000비트/초

4단계: 마진이 있는 전송 속도를 선택합니다.

최소 12만 bps가 필요합니다.다음 표준 요금 인상은230400입니다.하지만 잠시만요.115200사용할 수 있나요?그러면 115,200bps의 회선 속도를 얻을 수 있는데, 이는 120,000 요구 사항보다 적은 수치입니다.데이터를 잃게 됩니다.230400즉 230,400/120,000 = 92% 의 헤드룸을 제공하는 셈이죠.이는 인터럽트 레이턴시, 버퍼 관리 및 가끔 발생하는 버스트 트래픽에 대한 충분한 여유입니다.

또는 샘플링 레이트를 960Hz (115,200/ 12/10 = 960) 로 줄이면115200을 사용할 수도 있습니다.실제로는 최대 1kHz 속도의230400을 사용하는 것이 좋습니다. 헤드룸이 펌웨어를 제대로 작동시킬 수 있기 때문입니다.

UART 전송 속도 계산기 를 사용하여 특정 MCU 클록에 대해 실제로 달성 가능한 속도와 오류를 확인할 수 있습니다.

2% 규칙 — 클럭 허용 오차

UART가 까다로워지는 부분은 바로 이것입니다.공유 클록이 없기 때문에 송신기와 수신기 모두 자체 오실레이터에서 전송 속도를 생성합니다.오실레이터가 서로 떨어지면 비트가 잘못 읽히게 됩니다.

신뢰할 수 있는 UART 통신의 표준 허용 오차는 양측 간의 ± 2% 누적 오류입니다.실제로 대부분의 문헌에서는 양측을 ± 1% 미만으로 유지할 것을 권장하므로 최악의 경우 총 불일치는 2% 미만으로 유지됩니다.

왜 2% 일까요?

UART 수신기는 16배 오버샘플링을 사용합니다. 즉, 비트 주기당 16번 라인을 샘플링하고 중간 샘플 (일반적으로 16개 샘플 중 7, 8, 9) 을 사용하여 비트 값을 결정합니다.따라서 타이밍 드리프트를 어느 정도 허용할 수 있습니다.

8N1 프레임 (총 10비트) 의 경우 마지막으로 샘플링된 비트는 비트 #10 (정지 비트) 입니다.해당 시점까지 누적된 오류는 다음과 같습니다.

\text{Accumulated error} = \text{bit error} \times 10 \text{ bits} = 0.5 \text{ bit (maximum)}

전체 타이밍 오류로 인해 프레임이 끝날 때까지 샘플링 포인트가 0.5비트 이상 드리프트되는 경우 잘못된 비트를 샘플링하게 됩니다.거꾸로 작업하기:

\text{Max error per bit} = \frac{0.5}{10} = 5\%

하지만 이는 완벽한 시작 비트 감지를 통한 이론적 최대치입니다.실제로 시작 비트 검출 자체의 불확도는 ±0.5 (샘플 16개 중) 이므로 마진을 잠식합니다.실제 안전 한계는 총 약 3.75% 이며 엔지니어들은 2% 를 보수적인 설계 규칙으로 사용합니다.

실제 2% 는 어떤 모습일까요`115200`보우드에서 2% 의 오차는 실제 전송 속도가 112,896에서 117,504 사이임을 의미합니다.비트 주기가 ±0.17µs 떨어졌습니다.10비트 프레임에서는 ±1.7µs의 드리프트가 누적되는데, 이는 비트 주기의 약 20% 에 해당합니다.여전히 안전하지만 마진을 다 쓰고 있습니다.`9600`보드에서는 비트 주기가 매우 넓기 때문에 2% 오류는 절대적인 측면에서 훨씬 덜 중요합니다 (비트당 ±2.08µs, 프레임당 ±20.8µs).`9600`기본값이 “안전한” 기본값인 또 다른 이유가 바로 여기에 있습니다. 심지어 끔찍한 오실레이터도 이에 부딪힐 수 있기 때문입니다.

MCU 클럭 소스 및 전송 속도 오류

모든 클록이 UART와 동일하게 생성되는 것은 아닙니다.

크리스탈 오실레이터 (HSE)

정확도: 일반적으로 ±20ppm (0.002%).기본적으로 UART에 완벽합니다. 모든 표준 전송 속도는 무시할 수 있을 정도로 오차가 거의 발생하지 않습니다.이는 ESP32, 대부분의 STM32 개발 보드, 아두이노 우노 (16MHz 크리스탈) 에서 사용하는 것입니다.

내장 RC 오실레이터 (HSI)

정확도: 온도 및 전압에 따라 ± 1% ~ ± 5%STM32 내부 8MHz HSI는 공장에서 25°C에서 ± 1% 로 트리밍되지만 전체 온도 범위에서 ± 2% 까지 드리프트될 수 있습니다.ATmega328p의 내장형 8MHz RC 오실레이터는 ± 10% 미보정 상태입니다 (!)하지만 공장 캘리브레이션 후에는 ± 2%.

여기서 상황이 위험해집니다.송신기와 수신기 모두 RC 오실레이터를 사용하는 경우 총 불일치가 최대 4% 까지 발생할 수 있습니다.UART는 간헐적으로 오류가 발생합니다. 즉, 실온의 벤치에서는 정상적으로 작동하다가 덥거나 추울 때는 필드에 문자를 떨어뜨립니다.

사용 법칙: 크리스탈 없이9600이상의 UART를 실행하는 경우 UART 계산기 를 사용하여 최악의 전송 속도 오류를 계산하고 2% 미만으로 유지되는지 확인하십시오.

BRR 디바이저 문제

완벽한 크리스탈을 사용하더라도 정확한 전송 속도를 얻지 못할 수 있습니다.UART 주변기기는 클럭을 정수 (BRR 레지스터) 로 나누어 전송 속도를 생성합니다.

\text{Actual Baud} = \frac{f_{clk}}{16 \times \text{BRR}}

나눗셈이 균등하게 나오지 않으면 양자화 오류가 발생합니다.예를 들어115200보우를 생성하려는 16MHz 클럭은 다음과 같습니다.

\text{BRR} = \frac{16{,}000{,}000}{16 \times 115200} = 8.68

8.68을 레지스터에 로드할 수 없습니다. 반올림하면 9로 반올림됩니다.실제 전송 속도는 다음과 같습니다.

\text{Actual} = \frac{16{,}000{,}000}{16 \times 9} = 111{,}111 \text{ bps}

오류:

(115200 - 111111) / 115200 = 3.55\%

.2% 를 초과합니다. 이 특정 클럭 및 전송 속도 조합은 분수 분배기가 지원되지 않으면 안정적으로 작동하지 않습니다.

일부 MCU (STM32, SAM, nRF) 에는 이 문제를 해결하는 소수 BRR 디바이더가 있습니다.다른 제품 (ATmega) 은 그렇지 않습니다. 크리스탈 주파수를 신중하게 선택해야 합니다.클래식 7.3728MHz 및 11.0592MHz 크리스탈은 표준 전송 속도로 균등하게 나뉘기 때문에 특별히 존재합니다.

크리스탈	115200의 경우 BRR	실제 보드	오류
7.3728 메가헤르츠	4	115200	0.00%
8메가헤르츠	4.34 → 4	125000	8.51%
11.0592 메가헤르츠	6	115200	0.00%
16메가헤르츠	8.68 → 9	111111	3.55%
18.432메가헤르츠	10	115200	0.00%
48메가헤르츠	26.04 → 26	115385	0.16%
72메가헤르츠	39.06 → 39	115385	0.16%

패턴을 보면 7.3728, 11.0592, 18.432MHz는 모두 115200 × 16× (일부 정수) 의 배수이기 때문에 오류 0이 됩니다.8MHz 및 16MHz와 같은 “라운드” 주파수는 UART의 경우 실제로 더 나쁩니다.

최신 STM32 및 ESP32 칩은 소수 비트가 4~8개인 소수 분할기를 사용하므로 이러한 문제를 효과적으로 해결할 수 있습니다.하지만 ATmega328p (아두이노 우노) 를 16MHz로 작업하는 경우115200에서 3.55% 의 오류가 발생하는 것은 사실입니다.아두이노 부트로더는 실제로115200를 사용하는데, 다른 쪽 끝에 있는 FTDI 칩은 매우 정확하고 내구성이 뛰어나지만 엣지 부분에서는 문제가 없기 때문입니다.

흔히 저지르는 실수

1.코드의 전송 속도가 잘못되었습니다.

연쇄 쓰레기의 가장 큰 원인.양쪽이 일치하는지 세 번 확인하세요.일반적인 함정:

GPS 모듈의 기본값은115200이 아니라9600입니다.

-74880보드에서 ESP32 부트 ROM이 출력됩니다 (이상한 소리)

일부 블루투스 모듈 (HC-05) 은 AT 명령에는38400, 데이터 모드에는9600를 사용합니다.
마케팅 부서에서 말하는 “고속”과는 상관없이 대부분의 센서는9600기본값을 사용합니다.

2.소프트웨어 UART (비트뱅잉) 제한

소프트웨어 UART (예: Arduino의SoftwareSerial) 는 지연 루프를 사용하여 소프트웨어에서 타이밍을 생성합니다.이는 다음을 의미합니다.

인터럽트는 비트 타이밍을 예측할 수 없을 정도로 늘릴 수 있습니다.
최대 신뢰 속도는 일반적으로19200—38400보드입니다.
CPU 부하는 전송 속도에 따라 선형적으로 확장됩니다.
전송 중 수신이 불가능한 경우가 많습니다.115200이상이 필요한 경우 하드웨어 UART 주변기기를 사용하십시오.항상 그래요.

3.전압 레벨 불일치 (전송 속도 문제인 것 같음)

5.V UART와 통신하는 3.3V UART (또는 그 반대) 는 전송 속도 불일치와 똑같은 왜곡된 출력을 생성할 수 있습니다.수신기의 임계값 전압이 제대로 초과되지 않아 잘못된 시작 비트가 발생하고 데이터가 손상됩니다.전송 속도를 탓하기 전에 항상 전압 호환성을 확인하십시오.

4.UART 오버헤드를 잊어버리는 중

신입 엔지니어는 종종 필요한 대역폭을data_rate / 8로 계산하고 이를 전송 속도로 설정합니다.하지만 유선에서 각 바이트의 비용은 10비트 (8N1) 또는 11비트 (8E1) 입니다.8N1을 사용한115200보드의 실제 유효 처리량은 다음과 같습니다.

\text{Throughput} = \frac{115200}{10} = 11{,}520 \text{ bytes/sec} = 11.25 \text{ KB/s}

14.4킬로바이트/s는 아닙니다 (115200/8이 될 것입니다).시작/중지 비트로 인한 20% 의 오버헤드가 중요합니다.

5.온도 편차를 고려하지 않음

UART 링크는 22°C의 벤치에서 완벽하게 작동한 다음 -20°C ~ +85°C에서 작동하는 제품에 연결됩니다. 내부 RC 오실레이터가 3% 드리프트하여 추운 아침에 갑자기 바이트가 감소하게 됩니다.항상 전체 작동 온도 범위에서 오실레이터 사양을 확인하십시오.

언제 어떤 전송 속도를 사용할까요?

몇 가지 실용적인 지침:

9600 — 알 수 없는 기기, GPS 모듈, 데이터 빈도가 낮은 센서 모듈, 부트로더 폴백의 기본값입니다.모든 클록 소스와 함께 작동합니다.
115200 — 개발/디버깅 표준, 중간 수준의 데이터 스트림, 대부분의 MCU-PC 통신.크리스탈 또는 캘리브레이션된 HSI가 필요합니다.
230400—460800 — 처리량이 많은 센서 로깅, UART를 통한 펌웨어 업데이트, FTDI 기반 도구.크리스탈과 짧은 와이어 (30cm 미만) 가 필요합니다.
921600—3000000 — 특수 고속 애플리케이션 (ESP32 로깅, 최대 속도의 FTDI).일치하는 크리스털, 짧은 트레이스, 우수한 PCB 레이아웃이 필요합니다.신호 무결성이 중요해지기 시작합니다.1 Mbaud이상에서는 UART가 편한 수준 이상으로 나아가고 있습니다.이때 SPI (동기식, 훨씬 빠름) 또는 USB (차동, 소음 방지) 로 전환하는 것을 고려해 보십시오.

계산기 사용

rftools.io의 UART 전송 속도 및 프레임 타이밍 계산기 는 지금까지 논의한 모든 내용을 계산합니다.

1.목표 전송 속도를 입력하십시오 —9600,115200또는 주변 장치에 필요한 모든 요구 사항을 입력하십시오. 2.프레임 형식 설정 — 데이터 비트 (보통 8), 정지 비트 (보통 1), 패리티 (보통 없음). 3.MCU 클럭 주파수를 입력하십시오 — APB/주변기기 클럭, 코어 클록일 필요는 없습니다.데이터시트를 확인하세요.

계산기는 다음을 반환합니다.

비트 주기 — 각 비트가 와이어에 있는 시간 (스코프 측정에 유용함)
프레임 기간 — 한 캐릭터의 총 시간
유효 처리량 — UART 오버헤드를 뺀 후의 실제 데이터 속도
BRR 제수 — 필요한 정확한 레지스터 값 (16배 오버샘플링의 경우)
실제 전송 속도 — 정수 반올림 후 실제로 얻을 수 있는 값

< 0.5%), yellow (0.5— 2%), red (>- 전송 속도 오류 — 녹색 (2%)

오류 표시기가 가장 중요한 출력입니다.빨간색이면 링크에 문제가 있는 것입니다.클럭 주파수를 변경하거나 분수 분배기를 사용하거나 (MCU에서 지원하는 경우) 다른 전송 속도를 선택하세요.

요약 참조: UART 전송 속도 공식

한 곳에서 수학하고 싶은 분들을 위해:

T_{bit} = \frac{1}{\text{Baud Rate}} \quad \text{(seconds per bit)}

\text{Frame bits} = 1 + \text{Data} + \text{Parity} + \text{Stop}

\text{Throughput} = \frac{\text{Baud Rate} \times \text{Data bits}}{\text{Frame bits}} \quad \text{(useful bps)}

\text{BRR} = \frac{f_{clk}}{16 \times \text{Baud Rate}} \quad \text{(16× oversampling)}

\text{Error} = \frac{|B_{actual} - B_{target}|}{B_{target}} \times 100\%

오차를 2% 미만으로 유지하십시오.속도가 중요할 때는 크리스탈을 사용하세요.전송 속도를 맞춰보세요.시리얼 링크를 보내주시면 감사하겠습니다.