Skip to content
RFrftools.io
Protocol2026年5月7日12分で読める

UART ボーレートの説明:不要な文字から信頼性の高いシリアルリンクまで

UARTのボーレートに関する実践ガイド。9600と115200が存在する理由、クロックエラーがフレーミング障害の原因となる仕組み、実際のMCUでの実例、すべての組み込みエンジニアが知っておく必要がある 2% の法則などについて説明しています。

目次

# #みんなが経験した瞬間

2枚のボードを配線します。TXからRX、RXからTX、グラウンドからグラウンドへ。ファームウェアをフラッシュして、シリアルモニターを開いて... ゴミ（ÿÿÿÿか⸮⸮⸮⸮）か、あるいはまったく何もないかもしれません。配線を再確認してください。TXとRXを交換します（全員が少なくとも1回は交換します）。まだゴミです。

すると誰かが「ボーレートはどのくらいに設定されていますか？」と尋ねます。

そして、それが実現しました。一方は9600で話し、もう片方は115200で聞いています。電気信号は、電圧レベル、配線、すべて正常に動作していますが、2つのデバイスはまったく異なる速度で話しています。誰かが3倍の速さでページをめくっている間に本を読もうとするようなものです。文字が全部そこにあって、意味が分からないだけです。

これは組み込みシステムで最も一般的なシリアル通信障害であり、ボーレートが実際に何を意味し、なぜそれがUARTにとってそれほど重要なのかを理解すれば、完全に防ぐことができます。

実際のボーレートとは

ボーレートとは、ワイヤ上の 1 秒あたりの信号遷移 (シンボル) の数です。具体的には UART の場合、各シンボルは 1 ビットなので、ボーレートはビットレートと等しくなります。115200baudを設定すると、1/115200秒ごとにライン電圧を変更するようにトランスミッタに指示することになります。つまり、ビットあたり約8.68マイクロ秒になります。

ここで重要なのは、UARTにはクロックワイヤがないということです。 SPIやI2Cとは異なり、いつサンプリングするかをレシーバに伝える個別の信号はありません。どちらの側も、それぞれのクロックから独自のタイミングを個別に生成します。あらかじめ、速度について合意していればいいのです。

二人が共有のティッカーテープを読んでいるようなものだと考えてください。文字ごとにベルが鳴るわけではなく、両者とも8.68マイクロ秒ごとに次の文字を見ることに同意しただけです。ある人の時計が 5% 速く動くと、やがて間違った文字を読み始めることになります。UART では、時計が一致しない場合にまさにこのようなことが起こります。

レシーバは、スタートビット、つまりハイ (アイドル) からローへの遷移を監視して、バイトの開始を検出します。下降エッジが見つかると、内部タイマーを起動し、予想される間隔でデータビットをサンプリングします。ボーレートが少しでもずれていると、ビット 7 またはストップビットに達する頃には、間違ったタイミングでサンプリングが行われています。

標準ボーレート (そしてなぜこの奇妙な数値なのか)

シリアルを扱ったことがある人なら、よくある容疑者を見たことがあるでしょう:

ボーレートビットピリオドオリジン
7513.3 ミリ秒テレグラフ (ボードーコード)
1109.1 ミリ秒テレタイプ ASR-33
3003.33 ミリ秒初期のアコースティックモデム
1200833 µs1200 ボー・モデムの時代
2400417 µsV.22 スタンダード
9600104 µs事実上の「安全なデフォルト」
1920052.1 µs2× 9600
3840026.0 µs4× 9600
5760017.4 µsオッドボール (6× 9600 ではない)
1152008.68 µs標準の「高速」UART
2304004.34 µs2× 115200
4608002.17 µs多くのマイコンに採用されている
9216001.09 µs限界に近い
なぜこれらの特定の数値なのか？歴史に残る事故だよ 75 baudは電信時代のものです。Baudotコードは5ビット文字を使用し、75baudはオペレーターに印刷物を読む時間を与えました。110baudはテレタイプモデル33の速度で、プリントヘッドの機械的な制限によって設定されました。 300 baudは、最初に広く使われたモデム速度 (携帯電話の受話器をつなぎ込むアコースティックカプラー) でした。そこから各世代がおよそ2倍になり、1200人、2400人、4800人、9600人になりました。ただし、これらは 2 の累乗ではなく、300 の倍数です。

では、なぜ標準セットでは56400(よりクリーンな倍数) ではなく、57600が標準セットにあるのでしょうか。これは115200 / 2で、115200自体は IBM PC で使われている 8250 UART チップに由来しています。8250 には 1.8432 MHz の発振器が搭載されており、除数を 1 にすると 115200 ボー (1843200/16 = 115200) になります。16 の除数のオーバーサンプリングはハードウェアに組み込まれています。

その結果、今でも 1981 年に選ばれた水晶周波数によって決まるボーレートが使われているのです。

9600がユニバーサル・デフォルトな理由9600baudは、ほとんどすべてのクロックソース、数メートル未満の配線長、およびUART周辺機器（最も基本的なものも含む）で動作するのに十分遅いです。「ちゃんと動く」のはスピードです。GPS モジュールはデフォルトでこれに設定されます。ブートローダーが使用します。デバイスが話す速度がわからない場合は、まず9600を試してください。

しかし、9600は、短いテキストメッセージ以外のものに対しても、痛々しいほど遅いです。フレーム当たり 10 ビット (8N1 形式) では、1 秒あたり 960 バイトになります。1 KB のデバッグログの印刷には 1 秒以上かかります。そのため、ほとんどの開発作業では115200が使用されています。これは12倍高速で、最新のMCUクリスタルでも信頼性があります。

動作例:GPS モジュールのミスマッチ

ユーブロックスのNEO-6M GPSモジュールを持っているとしましょう。デフォルトでは NMEA センテンスを9600ボーで出力します。お使いの STM32 ファームウェアが誤って115200で USART2 を設定してしまいました。何が起きるの？

GPSは$文字 (ASCII 0x24、バイナリ00100100) を送信します。9600ボーのワイヤでは、各ビットの幅は 104.17 µs です。10 ビットフレーム全体 (開始 + 8 データ + 停止) には 1.042 ミリ秒かかります。

しかし、ご使用のSTM32は115200でサンプリングされています。つまり、ビット幅が8.68 µsであることを想定しています。スタートビットの立ち下がりエッジを確認すると、8.68 µsごとにサンプリングが開始されます。GPS が 1 ビット (104.17 µs) を送信するまでの時間内に、STM32 は12 回をサンプリングします。実際の 1 ビットから 12「ビット」を読み取ります。

その結果、端末にランダムな外観の文字が表示されます。間違った文字だけでなく、まったく予測不可能なゴミです。受信機が波形を意図したよりも12倍多くの断片に切り分けているからです。

解決策: ボーレートを合わせてください。お使いの STM32 を9600に設定するか、GPS を (UBX プロトコル・コマンドを使用して)115200に再設定します。ネゴシエーションや自動検出 (ほとんどの場合) はありません。両側を明示的に同じ速度に設定する必要があります。

実際の例:高速センサーデータロギング

1 kHz (1 秒あたり 1000 サンプル) で加速度計を読み取るデータロガーを構築しています。各サンプルには、16 ビット整数の X、Y、Z 軸とタイムスタンプがあります。これを UART 経由で FTDI USB シリアルアダプタにストリーミングして PC でキャプチャしたいとします。

必要なボーレートを考えてみましょう。

ステップ 1: データペイロードを計算します。

-3 軸 × 各 2 バイト = サンプルあたり 6 バイト -タイムスタンプ 4 バイト = 4 バイト -2 バイトのオーバーヘッド (ヘッダ+チェックサム) = 2 バイト -合計:1 サンプルあたり 12 バイト

ステップ 2:1 秒あたりのバイト数を計算します。

12 バイト × 1000 サンプル/秒 = 12,000 バイト/秒

ステップ 3: ビット/秒への変換 (UART オーバーヘッドを考慮に入れる)。

標準の 8N1 フレーミングでは、各バイトの回線コストは 10 ビットです (1 スタート + 8 データ + 1 ストップ)。

12,000 バイト × 10 ビット/バイト = 120,000 ビット/秒

ステップ 4: マージンのあるボーレートを選択してください。

少なくとも 120,000 bps が必要です。次に標準レートを上げるのは230400です。ちょっと待ってください。115200を使えますか？これにより、電線上の消費電力は115,200bpsとなり、12万ビット/秒の要件を下回ります。データは失われます。

つまり、230400です。つまり、230,400/120,000 = 92% のヘッドルームとなります。割り込み待ち時間、バッファ管理、時折発生するバーストトラフィックには十分な余裕があります。

あるいは、サンプルレートを 960 Hz (115,200/12/10 = 960) に下げる場合は、115200を使用することもできます。実際には、1 kHz のフルレートの230400をお勧めします。ヘッドルームがあると、ファームウェアの動作が妨げられます。

UART ボーレート計算ツール を使用して、特定の MCU クロックで実際に達成可能なレートと誤差を確認してください。

2% ルール — クロックトレランス

UART が扱いにくくなるのはここです。共有クロックがないため、トランスミッタとレシーバの両方がそれぞれ独自のオシレータからボーレートを生成します。これらの発振器が離れると、ビットが誤って読み取られます。

信頼性の高いUART通信の標準許容誤差は、両端間の± 2% の累積誤差です。実際には、ほとんどの参考文献では、両側を± 1% 未満に抑えることを推奨しています。そうすれば、最悪の場合でもミスマッチの合計は 2% 未満にとどまります。

なぜ 2% なの？

UART レシーバは 16 倍のオーバーサンプリングを使用します。1 ビット周期で 16 回ラインをサンプリングし、中間サンプル (通常は 16 個中 7、8、9 個のサンプル) を使用してビット値を決定します。これにより、タイミングドリフトがある程度許容されます。

8N1 フレーム (合計 10 ビット) の場合、最後にサンプリングされるビットはビット #10 (ストップビット) です。その時点での累積誤差は次のようになります。

Accumulated error=bit error×10 bits=0.5 bit (maximum)\text{Accumulated error} = \text{bit error} \times 10 \text{ bits} = 0.5 \text{ bit (maximum)}
トータル・タイミング・エラーが原因で、フレームの終わりまでにサンプリング・ポイントが 0.5 ビット以上ずれている場合は、間違ったビットをサンプリングすることになります。逆方向に作業する場合:
Max error per bit=0.510=5%\text{Max error per bit} = \frac{0.5}{10} = 5\%
しかし、これは完全なスタートビット検出による理論上の最大値です。実際には、スタートビットの検出自体には (16 サンプルのうち) ±0.5 サンプルの不確かさがあり、マージンを食い尽くしてしまいます。実際の安全限界は合計で約 3.75% で、エンジニアは保守的な設計ルールとして 2％を使用しています。

実際の 2% はどのようなものか115200ボーでは、2％の誤差は実際のボーレートが112,896から117,504の間であることを意味します。ビット周期は ±0.17 µs ずれています。10 ビットのフレームでは、蓄積されたドリフトは ±1.7 µs、つまりビット周期の約 20% になります。まだ安全ですが、マージンを使い果たしています。9600baudでは、ビット周期が非常に広いため、絶対値では 2% の誤差はそれほど重要ではありません（ビットあたり±2.08 µs、フレームあたり±20.8 µs）。これが、9600が「安全な」デフォルトであるもう1つの理由です。ひどい発振器でもヒットする可能性があります。

MCU クロックソースとボーレートエラー

UART ではすべてのクロックが同じように作られているわけではありません。

水晶発振器 (HSE)

精度:通常は ±20 ppm (0.002%)。基本的に UART に最適です。 どの標準ボーレートでも、ごくわずかな誤差で動作します。これは ESP32、ほとんどの STM32 デベロッパーボード、Arduino Uno (16 MHz クリスタル) が使用しているものです。

内蔵 RC オシレーター (HSI)

精度:± 1% ～ ± 5% (温度と電圧によって異なります)。STM32の内蔵8MHz HSIは、工場出荷時に25℃で± 1% に調整されていますが、全温度範囲で± 2% までドリフトする可能性があります。ATmega328Pの内蔵8MHz RCオシレータは、± 10% のキャリブレーションが行われていません（！）。ただし、工場出荷時のキャリブレーション後は± 2% です。

これは物事が危険になるところです。送信機と受信機の両方がRC発振器を使用している場合、合計で最大4％のミスマッチが発生する可能性があります。UART は断続的に故障します。室温ではベンチで正常に動作し、暑いときや寒いときはフィールドで文字を落としてしまいます。

経験則： 水晶なしで9600ボー以上のUARTを実行している場合は、UART計算機 を使用してワーストケースのボーレート誤差を計算し、2% 未満にとどまっていることを確認してください。

BRR 除数問題

完璧な水晶でも、正確なボーレートは得られないかもしれません。UART ペリフェラルはクロックを整数 (BRR レジスタ) で除算してボーレートを生成します。

Actual Baud=fclk16×BRR\text{Actual Baud} = \frac{f_{clk}}{16 \times \text{BRR}}
割り算が均等にならないと、量子化誤差が出ます。例えば、16 MHz のクロックが115200のボーを生成しようとするとします。
BRR=16,000,00016×115200=8.68\text{BRR} = \frac{16{,}000{,}000}{16 \times 115200} = 8.68
8.68 をレジスターに読み込むことはできません。四捨五入すると 9 になります。実際のボーレートは次のようになります。
Actual=16,000,00016×9=111,111 bps\text{Actual} = \frac{16{,}000{,}000}{16 \times 9} = 111{,}111 \text{ bps}
エラー:(115200−111111)/115200=3.55%(115200 - 111111) / 115200 = 3.55\%。2% を超えています。 この特定のクロックとボーレートの組み合わせは、分数分周器のサポートがないと確実に動作しません。

一部のマイコン (STM32、SAM、nRF) には、これを解決するフラクショナル BRR 分周器が搭載されています。他の製品 (ATmega) にはありません。水晶振動子の周波数を慎重に選択する必要があります。従来の7.3728MHzと11.0592MHzのクリスタルが存在するのは、標準ボーレートに均等に分割されるからです。

クリスタル115200用BRR実際のボーエラー
7.3728 MHz41152000.00%
8 MHz4.34 → 41250008.51%
11.0592 MHz61152000.00%
16 メガヘルツ8.68 → 91111113.55%
18.432 メガヘルツ101152000.00%
48 MHz26.04 → 261153850.16%
72 MHz39.06 → 391153850.16%
7.3728、11.0592、18.432 MHz というパターンは、すべて 115200 × 16 × (ある整数) の倍数なので、ゼロエラー になることに注意してください。8 MHz や 16 MHz のような「丸い」周波数は、実際には UART の方が劣ります。

最新の STM32 および ESP32 チップは、4 ～ 8 ビットの分数分周器を使用しているため、この問題は事実上解消されています。しかし、16 MHz の ATmega328P (Arduino Uno) を使っているのであれば、115200の 3.55% の誤差は現実のものです。Arduinoブートローダーは実際には115200を使用しており、反対側のFTDIチップは非常に正確で許容範囲が広いため、問題ありません。しかし、それはまさに限界です。

よくある間違い

1.コードのボーレートが間違っています

シリアルガベージの最大の原因。両側が一致していることをトリプルチェックしてください。一般的なトラップ: -GPS モジュールのデフォルトは115200ではなく9600-ESP32 ブート ROM が74880ボーで出力される (変なやつだ) -ブルートゥースモジュール (HC-05) の中には、AT コマンドには38400を使用しますが、データモードには9600を使用するものもあります。 -マーケティングが「高速」についてどう言っているかに関わらず、多くのセンサーはデフォルトで9600に設定されています

2。ソフトウェア UART (ビットバンギング) の制限事項

ソフトウェア UART (例えば Arduino のSoftwareSerial) は、遅延ループを使用してソフトウェアでタイミングを生成します。つまり、 -割り込みによってビットタイミングが予期せず伸びることがある -最大信頼速度は通常19200—38400baudです -CPU 負荷はボーレートに比例してスケーリングします -送信中の受信は不可能な場合が多い115200以上が必要な場合は、ハードウェア UART 周辺機器を使用してください。常に。

3。電圧レベルのミスマッチ (ボーレート問題のようです)

3.3V UARTと5V UART（またはその逆）が通信すると、ボーレートのミスマッチとまったく同じように見える文字化けした出力が生成されることがあります。レシーバのスレッショルド電圧が正しく超えていないため、誤ったスタートビットやデータの破損が発生しています。ボーレートのせいにする前に、必ず電圧の互換性を確認してください。

4.UART オーバーヘッドを忘れる

新しいエンジニアは、必要な帯域幅をdata_rate / 8と計算し、それをボーレートとして設定することがよくあります。しかし、各バイトの回線コストは 10 ビット (8N1) または 11 ビット (8E1) です。8N1を使用した場合の115200ボーの実際の有用なスループットは次のとおりです。

Throughput=11520010=11,520 bytes/sec=11.25 KB/s\text{Throughput} = \frac{115200}{10} = 11{,}520 \text{ bytes/sec} = 11.25 \text{ KB/s}
14.4 キロバイト/秒 (つまり 115200/8) ではありません。スタート/ストップビットによる 20% のオーバーヘッドは重要です。

5.温度ドリフトを考慮していない

UART リンクは 22°C のベンチで完璧に動作し、その後 -20°C ～ +85°C で動作する製品に移行します。内蔵の RC 発振器が 3% ドリフトし、寒い朝に突然バイトが減ってしまいます。必ず動作温度範囲全体にわたって発振器の仕様を確認してください。

どのような場合にどのボーレートを使用するか

いくつかの実用的なガイドライン:

-9600 — 未知のデバイス、GPS モジュール、データの頻度が低いセンサーモジュール、ブートローダーフォールバックのデフォルト。どのクロックソースでも動作します。 -115200 — 開発/デバッグ用の標準、中程度のデータストリーム、ほとんどのMCU-PC間通信。水晶またはキャリブレーション済みの HSI が必要です。 -230400—460800 — ハイスループットセンサーロギング、UART 経由のファームウェアアップデート、FTDI ベースのツール。クリスタルとショートワイヤー (30 cm 未満) が必要です。 -921600—3000000 — 特殊な高速アプリケーション (ESP32 ロギング、最大速度での FTDI)。マッチングしたクリスタル、短いトレース、適切な PCB レイアウトが必要です。シグナルインテグリティが重要になり始めています。1 Mbaudを超えると、UART が快適な領域を超えて押し進められることになります。その時点で、SPI (同期、はるかに高速) またはUSB (差動、ノイズ対策) への切り替えを検討してください。

計算機の使用

rftools.io の UART ボーレート&フレームタイミング計算ツール は、これまで説明してきたことをすべて計算してくれます。

1.目標ボーレートを入力してください —9600、115200、または周辺機器が必要とするものは何でも入力してください。 2.フレームフォーマットを設定 — データビット (通常は8)、ストップビット (通常1)、パリティ (通常はなし)。 3.MCU クロック周波数を入力してください — APB/周辺クロック。コアクロックである必要はありません。データシートを確認してください。

計算機の返り値: -ビット周期 — ワイヤ上の各ビットの長さ (スコープの測定に便利) -フレーム期間 — 1 文字の合計時間 -有効スループット — UART オーバーヘッドを差し引いた後の実際のデータレート -BRR 除数 — 必要な正確なレジスタ値 (16 倍のオーバーサンプリングの場合) -実際のボーレート — 整数を丸めた後に実際に得られる値 < 0.5%), yellow (0.5— 2%), red (>-ボーレートエラー — 緑 (2%)

エラーインジケータは最も重要な出力です。赤色の場合は、リンクに問題がある可能性があります。クロック周波数を変更するか、分数分周器 (MCU がサポートしている場合) を使用するか、別のボーレートを選択してください。

クイックリファレンス:UART ボーレートフォーミュラ

数学を一か所にまとめたい方へ:

Tbit=1Baud Rate(seconds per bit)T_{bit} = \frac{1}{\text{Baud Rate}} \quad \text{(seconds per bit)}
Frame bits=1+Data+Parity+Stop\text{Frame bits} = 1 + \text{Data} + \text{Parity} + \text{Stop}
Throughput=Baud Rate×Data bitsFrame bits(useful bps)\text{Throughput} = \frac{\text{Baud Rate} \times \text{Data bits}}{\text{Frame bits}} \quad \text{(useful bps)}
BRR=fclk16×Baud Rate(16× oversampling)\text{BRR} = \frac{f_{clk}}{16 \times \text{Baud Rate}} \quad \text{(16× oversampling)}
Error=∣Bactual−Btarget∣Btarget×100%\text{Error} = \frac{|B_{actual} - B_{target}|}{B_{target}} \times 100\%
誤差は 2% 未満に抑えてください。速度が重要な場合は水晶を使用してください。ボーレートに合わせてください。シリアルリンクはきっとあなたのお役に立てるでしょう。

関連記事

Sensors

Thermocouple Voltage to Temperature Conversion

Learn how to accurately calculate thermocouple voltages, handle cold junction compensation, and avoid common measurement pitfalls.

2026年5月2日

Motor Control

BLDC Motor Winding Design for Peak Performance

Master BLDC motor winding design with our comprehensive calculator. Learn wire selection, turns calculation, and performance optimization techniques.

2026年5月1日

Audio Engineering

Class D Amplifier Design for Power Efficiency

Uncover the secrets of Class D amplifier efficiency, from MOSFET selection to power loss calculation with practical engineering insights.

2026年4月30日

← ブログに戻る