UARTレシーバーのクロック速度


14

私はUARTの基礎を理解しようとしていました。

  • 非同期通信プロトコルであるため、TXクロックとRXクロックは互いに独立しています
  • データの受信は、スタートビットと1つ以上のストップビットの使用によって保証されます。さらに、受信に使用れるSIPOレジスタを駆動する適切なクロックを生成するために、レシーバはデータレートを認識する必要があります。

ここでの質問は

通常、ビットレートの16倍のクロックを使用してデータを回復することが言及されています。では、bpsからクロック周波数への変換はどのように可能ですか?UARTレシーバーで採用されているクロッキングメカニズムを研究するための参考資料を提供してください。

回答:


18

送信機と受信機のクロックは、独立して生成されるという点で互いに独立していますが、適切な送信を保証するためには、それらをうまく一致させる必要があります。

T0T0T0×T0開始ビットの立ち下がりエッジです。開始ビットのサンプリングは実際には必要ありませんが(低いことがわかっています)、開始エッジがスパイクではないことを確認することは有用です。

ここに画像の説明を入力してください

×

私が正しく思い出すと、68HC11は最初、中間、最後のいくつかのサンプルを取りました。最初と最後はおそらくレベルの変化がある場合に再同期します(保証されていません)。

サンプリングクロックはビットレートから得られるのではなく、逆の方法です。9600 bpsの場合、サンプリングクロックを153 600 Hzに設定する必要があります。これは、マイクロコントローラーのクロック周波数からプリスケーラーを介して取得します。次に、ビットクロックは、16による別の除算によって得られます。

不一致のクロック
これは、レシーバのクロックがトランスミッタのクロックと同期していない場合に発生することです。

ここに画像の説明を入力してください

レシーバーのクロックは6.25%遅いため、次のビットごとのサンプリングはどんどん遅くなることがわかります。典型的なUART送信は、10ビットで構成されます:1つのスタートビット、8つのデータビットのペイロード、および1つのストップビット。次に、ビットの真ん中でサンプリングする場合、最後のビットであるストップビットで半ビットオフする余裕があります。10ビットの半分は5%なので、6.25%の偏差では問題が発生します。これは、図にはっきりと示されています。すでに3番目のデータビットで、エッジ近くでサンプリングしています。


私は助けに感謝します。ありがとう!!。開始ビットはT0 + 52usではなくT0 + 104usでサンプリングされるべきではありませんか?
ビベックマラン

1
@ Vivek27-いいえ、104 usが開始ビットの持続時間であるため、中間ではなく、終了ビットでサンプリングすることになります。数分いただければ、写真を更新します。:
スティーブン

1
@Vivek:実際には、開始ビットは実際には「サンプリング」されていません。その全体的な目的は、キャラクターの残りの部分が相対的なタイミングであるラインアイドルからの初期遷移を提供することです。「値」は常にアイドル状態の反対の行であり、それ自体にはデータが含まれていません。
オリンラスロップ

7
@Olin - 私は、スタートビットをサンプリングしますのみ開始エッジがスパイクではなかったことを確認します。
-stevenvh

1
@downvoter-ここで何が悪いのか教えていただければ、修正できるかもしれません。しかし、あなたは私たちに何かを言わなければなりません。(あなたも今日、他の答えを下した人と同じですか?)
stevenvh

11

少し戻って、UARTで使用される低レベルの信号プロトコルについて話しましょう。TXおよびRXはデータラインであり、クロックではありません。クロックは各UART内にのみ存在するため、ボーレートについて事前に合意する必要があります。

送信しない場合、回線はアイドル状態のままになります。バイトを送信するために(たとえば、他のデータ幅も可能)、トランスミッターは最初にスタートビットを送信します。レシーバーは、スタートビットのリーディングエッジの時間と既知のボーレートを使用して、残りの文字をデコードします。簡単にするために、100 kBaudが使用されているとしましょう。つまり、各ビット時間は10 µsです。これには、開始ビット、データビット、および停止ビットが含まれます。したがって、最初のデータビットの中央は開始ビットのリーディングエッジから15 µs、2番目のビットは25 µsなどになります。

受信機と送信機のクロックが同じである限り、これは永遠に続く可能性があります。ただし、それらがまったく同じになることはないため、永遠に続くことはできません。レシーバーのクロックをトランスミッターのクロックに再同期できるようにするために、データ文字が終了し、回線が少しの間アイドル状態のままになり、プロセスが繰り返されます。タイミングエラーはスタートビットのリーディングエッジから蓄積されるため、最大ドリフトは最後のビットにあります。そのキャラクターが終了すると、レシーバーはリセットされ、次の開始ビットを待機し、プロセスが繰り返されます。

8データビットの場合、タイミングの最悪のケースは最後のビットのサンプリングです。これは、開始ビットのリーディングエッジであるタイミング基準から8.5ビット時間です。レシーバーが1/2ビット以上オフになっている場合、異なるビットの間に最後のビットをサンプリングします。明らかにそれは悪いことです。これは、8 1/2ビットの1/2ビット、つまり5.9%のクロック周波数の不一致で発生します。これが不一致の失敗を保証するものです。信頼性のために、通常、レシーバーがトランスミッターの半分、つまり2.9%に一致することを確認する必要があります。これは、最後のビットでの1/4ビット時間エラーを表します。

ただし、それほど単純ではありません。上記のシナリオでは、受信機は基本的にスタートビットのリーディングエッジでストップウォッチを開始します。理論的にはアナログエレクトロニクスで行うことができますが、それは複雑で高価であり、デジタルチップに簡単に統合することはできません。代わりに、ほとんどのデジタルUART実装には、期待されるビットレートの16倍で動作する内部クロックがあります。「ストップウォッチ」はこれらの16サイクルをカウントします。つまり、すべてのビットサンプリング時間に1/16ビットのエラーが追加される可能性があります。これは、最後のビットでのもう1つの0.7%クロックミスマッチのようなものです。

これにより、ストップビットとは何か、ビットタイミングがどのように機能するか、16xクロックが何であるかが明確になることを願っています。私はほとんどストップビットをスキップしましたが、少なくとも1つのストップビットが必要な理由を自分で確認できるかもしれません。基本的に、ストップビットは、文字間の最小強制ラインアイドル時間です。これは、受信者が文字の受信を完了し、開始ビットの次のリーディングエッジの準備ができている時間です。ストップビットがない場合、最後のデータビットはスタートビットと同じ極性になる可能性があり、レシーバにはストップウォッチを開始するエッジがありません。

昔、このプロトコルはカム、レバー、および回転する車輪によってデコードされていました。多くの場合、メカニズムをリセットできるようにするために2つのストップビットが使用されました。今日では、すべてがデジタルロジックで行われ、1ストップビットがほぼ普遍的に使用されています。低レベルプロトコルは、8データビット、パリティビットなし(これらを忘れて、今日ではほとんど使用されない)、1ストップビットを意味する8-N-1と略記されます。そこにはオプションがないため、開始ビットが暗示されています。

8-N-1を使用すると、8ビットバイトのデータは実際に送信に10ビット時間かかります。これが、「ビットレート」と「ボーレート」に違いがある1つの理由です。ボーレートは、開始ビットと停止ビットを含む個々のビット信号時間を指します。100 kBaudでは、開始ビットと停止ビットを含め、送信される各ビットは10 µsかかります。したがって、文字全体は100 µsかかりますが、転送されるのは8ビットの実データのみです。ボーレートは100 kですが、より高いレベルの観点からのデータ転送ビットレートは80 kBits / sのみです。


5

送信のビットレートは、クロックレートを(通常は)16で割ったものです。フレーミングビット(開始、パリティ、停止)には、データ以外のビットもあります。したがって、16000Hzクロックの場合、1秒あたり1000ビットを取得しますが、最小限のフレーミングビットを挿入すると、800データビットまたは1秒あたり100バイトしか挿入されません。

受信するために、受信機はスタートビット16クロックの中央からカウントし、「最初のデータビット」と見られる回線コールをサンプリングします。このカウントを繰り返し、シンボル全体を読み取るのに十分な回数サンプリングしてから、ストップビットの存在を確認し、次のスタートビットの待機を開始します。

受信機のクロックが送信機のクロックのレートに近い限り、サンプリングは送信信号の正しい部分にヒットします。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.