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

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

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

目次

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

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

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

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

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

実際のボーレートとは

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

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

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

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

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

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

ボー・レートビットピリオドオリジン
7513.3 ms電信 (ボードーコード)
1109.1 msテレタイプ ASR-33
3003.33 ms初期のアコースティックモデム
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多くの MCU では限界に近い
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がユニバーサル・デフォルトな理由

9600 baudは、ほとんどすべてのクロックソース、数メートル未満の配線長、および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% になります。まだ安全ですが、マージンを使い果たしています。 9600 baudでは、ビット周期が非常に広いため、絶対値では 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 calculatorを使用してワーストケースのボーレート誤差を計算し、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のクリスタルが存在するのは、標準ボーレートに均等に分割されるからです。

クリスタルBRR for 115200実際のボードエラー
7.3728 MHz41152000.00%
8 MHz4.34 → 41250008.51%
11.0592 MHz61152000.00%
16 MHz8.68 → 91111113.55%
18.432 MHz101152000.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—38400 baudです。
  • 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.52 KB/s\text{Throughput} = \frac{115200}{10} = 11{,}520 \text{ bytes/sec} = 11.52 \text{ KB/s}

14.4 KB/s（つまり 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% 未満に抑えてください。速度が重要なときには水晶を使う。ボーレートに合わせてください。シリアルリンクはきっとあなたのお役に立ちます。

よくある質問

UART では、各シンボルのビットが 1 ビットだけなので、ボーレートはビットレートと等しくなります。他の変調方式 (モデムで使われている QAM など) では、1 つのシンボルで複数のビットをエンコードできるため、ボーレートとビットレートが異なります。しかし、標準的な UART の場合、115200 のボーは、回線上では 115200 ビット/秒に相当します。
最も一般的な原因はボーレートのミスマッチです。つまり、一方の側がもう一方の側が受信している速度とは異なる速度で送信しています。その他の原因としては、電圧レベルの不一致 (3.3V対5V)、TX/RXラインのスワップ、データフォーマット設定の誤り (データビット数、ストップビット数、またはパリティの誤り) などがあります。
ハードウェアによって異なります。ハードウェア UART ペリフェラルを搭載したほとんどの MCU は、水晶発振器と短いワイヤで最大 921600 ボーを確実にサポートします。ESP32 や FTDI アダプタなどのチップの中には、3 Mbaud以上に達するものもあります。ソフトウェア (ビットバンジ) UART は通常 38400 ボー以下に制限されています。
これらの「奇数」の水晶周波数は標準UARTボーレートに均等に分配され、誤差はゼロです。たとえば、11.0592 メガヘルツ/ (16 × 6) = 正確には 115200 です。8 MHz や 16 MHz のような丸い周波数では、分数分周器が生成され、四捨五入する必要があるため、信頼性のある通信を実現するには 2% の許容誤差を超えるボーレート誤差が生じることがあります。
標準設計ルールは、トランスミッタとレシーバ間の合計累積誤差が± 2% です。つまり、両側が目標ボーレートの± 1% 以内でなければなりません。水晶発振器 (±20 ppm) はこの要件を容易に満たしますが、内蔵 RC 発振器 (± 1% ～ ± 5%) は、特に極端な温度条件では満たさない場合があります。

関連記事

Protocols

LIN Bus Timing: Protocol Calculations Guide

Learn how to precisely calculate LIN bus timing parameters, understand frame structures, and avoid common design pitfalls in automotive communication systems.

2026年4月25日

Protocols

CAN Bus Bit Timing: Precise Configuration

Learn how to calculate precise CAN bus timing parameters for reliable embedded communication across different microcontroller clock speeds and baud rates.

2026年3月23日

Protocols

Will Your Ethernet Cable Work? Calculate Attenuation

Calculate Ethernet cable attenuation, max length, and pass/fail status for Cat5e–Cat8 runs. Includes worked examples and real engineering numbers.

2026年3月16日

← ブログに戻る