文字は届くのに読めない

一言でいうと

UARTには、クロックの線がありません。そのため、両側が同じビット時間を信じている必要があり、その信頼が崩れると、フレームの後ろ側から崩れていきます。

なぜ必要なのか

センサー1つが、3秒ごとに1行ずつ測定値を送ります。ターミナルには読めない文字が表示されますが、長さは合っていて、改行も時間どおりに来ます。センサーを替えても同じで、ケーブルを替えても同じです。こうした形は、ほとんどの場合、速度の問題です。配線が切れていれば何も来ませんし、ノイズならときどき壊れますが、毎回同じ位置で同じように壊れることはありません。

UARTがこうした故障に弱いのは、設計がそうなっているからです。線が1本しかないので、「今がビットの境界」と知らせる方法がありません。送る側は自分の時計でビットを並べ、受ける側は自分の時計で切り分けます。2つの時計が同じである保証は、どこにもありません。あるのは、フレームごとに1回、位置を合わせる機会、スタートビットだけです。

どう動くのか

休んでいるとき、線はハイです。送るものができると、1ビット時間の間だけ下げます。これがスタートビットです。受ける側は、この立ち下がりエッジを見て、時計を合わせます。続いて、データのビットが下位から出てきて、設定によってパリティビットが1つ付き、最後に1ビット以上のハイのストップビットで終わります。8N1と呼ぶ設定は、データ8ビット、パリティなし、ストップ1ビットを意味します。

受ける側がすることは単純です。スタートエッジから(k + 0.5)ビット時間離れた所を、kビット目として読みます。ビットの枠の真ん中を選ぶ理由は、エッジから最も遠いからです。

      시작    d0    d1    d2    d3    d4    d5    d6    d7   정지
   ────┐     ┌─────┐           ┌─────────────────┐     ┌────────
       └─────┘     └───────────┘                 └─────┘
        ^     ^     ^     ^     ^     ^     ^     ^     ^     ^
        표본은 언제나 칸의 한가운데

この構造が、誤差の予算を決めます。8N1で最後に読む位置は、ストップビット、つまりスタートエッジから9.5ビット時間離れた所です。ここで枠を外れないためには、累積した誤差が0.5ビット以内にある必要があるので、2つの時計が許容する差は、0.5 ÷ 9.5、約5.3%です。この数字は、規格から書き写したものではなく、フレームの構造からそのまま出てきます。そのため、ずれはフレームの前側ではなく後ろ側から現れます。前のビットには、まだ余裕が残っているからです。

組み込みで、この誤差が生じる最もよくある経路は、ノイズではなく分周比です。ファームウェアが12MHzを仮定して分周比を決めたのに、ボードに載った水晶振動子が11.0592MHzなら、同じ分周比で出るボーレートは、9600 × 11.0592 ÷ 12 = 8847.36 Bdです。8%を超えるので、上の予算を外れます。このコースのキャプチャファイルがまさにその状況で、波形では、ビットの境界がフレームの中でだんだんずれていく形で現れます。

ここで、2つの安全装置が登場します。フレーミングエラーは、ストップビットの位置がローで読まれたという意味です。速度がずれると、最後の位置が最初にずれるので、よくかかります。パリティは、1の個数を奇数または偶数にそろえておく方法なので、ビットが奇数個反転したときだけかかります。偶数個が反転すると、そのまま通過します。sigrokのUARTデコーダーのドキュメントも、この2つを、それぞれparity errorとframe errorとして区別して扱っています(ドキュメント)。

直す側は、意外と簡単です。キャプチャファイルの中に答えがあります。フレームを休まずにつなげて送ったなら、すべてのエッジが同じビットの格子の上にあるので、どの2つのエッジの間も、整数個のビット時間です。最も短い間隔で粗い値をつかみ、基線を延ばしながらその整数を丸め直すと、精度が上がります。一度に全体の長さでしてはいけません。粗い値の誤差にビットの個数を掛けた値が0.5ビットを超えた瞬間、丸めが見当違いの整数を選びます。

現場での姿

「文字が壊れる」という報告を受けたら、まず尋ねます。毎回同じ位置が壊れるのか、それともランダムなのか。同じ位置なら速度で、ランダムなら電気的な問題です。そして、フレーミングエラーのカウンターが上がるかを見ます。上がればタイミング、上がらないのに値がおかしければ、さらに悪い側です。検出されない破損です。

パリティをオンにして、「これで安全になりました」と言う設計書を、よく見かけます。このコースの8E1のキャプチャでは、11個のフレームのうち10個が間違っていたのに、パリティとフレーミングが捕まえたのは8個でした。3個は何の表示もなく、誤った値のまま通過しました。パリティは「問題がある」という信号であって、「問題がない」という保証ではありません。

次のラボですること

キャプチャファイルを3つ受け取ります。正常なものが1つ、クロックがずれているものが2つです。しきい値の関数とフレームデコーダーを自分で書き、サンプルを間引きながら判読が崩れる地点を探し、ずれたキャプチャから実際のビット時間を測り直して、読める文を復元します。最後に、パリティが何を捕まえて何を見逃したかを、数字で数えます。