UARTエラーが発生する理由と、そのようなエラーをチェックするタイミングを知りたいのですが。ここに、オーバーラン、パリティなどの個々のエラーの処理について尋ねる投稿があります。データオーバーランが発生する理由、パリティエラーが発生する理由は明らかですが、根本的な原因を知りたいのですが。私の質問は、これらのエラーが発生する理由（物理的な理由）と、エラーチェックをアプリケーションの要因にすべき場合に焦点を当てています。
これまでのところ、私のプログラムは（エラーチェックなしで）うまく機能しているように見えますが、ノイズによって混乱が生じる可能性があることはわかっています。UART Rx / Txポートが失敗する原因となる条件をどのようにシミュレートできますか？
回答:
どの回路にも、ノイズの発生源がいくつかあります。最も一般的なものは次のとおりです。
さらに、（@ jippieが言及したように）クロックスキューは、所定のデータレートを使用するあらゆる種類のシリアル通信におけるエラーの非常に一般的な原因です。外部水晶を使用しており、正確であると合理的に期待できる別のシステムとのインターフェースを使用している場合、問題が発生する可能性は低くなります。ただし、内部発振器は、水晶よりも数桁も悪い許容誤差を持ち、温度範囲全体でさらに変動する傾向があります。
実行中のシステムで実行できる、インターフェイスの基本的なノイズ（およびスキュー）耐性を判断するためのいくつかの基本的なテストがあります。
他にもたくさんあります-実際、EMC認定に特化した大規模な試験所があります。
一般に、データ損失の最小レベルが許容できる場合を除き、通信コードに何らかのエラーチェックを含めることは常に賢明です。単純なチェックサムでも、何もないよりはましです。
信号レベル品質（ノイズ、立ち上がり/立ち下がり時間）に加えて、UARTのエラーの一般的な原因の1つは、クロックスキューです。トランスミッタークロックとレシーバークロックが同じソースから派生していない場合（ほとんどの場合）、一方が他方より速く実行されます。タイミングエラーが大きすぎると、間違ったビットを読み取ることがあります。
ほとんどのエラーは、次の3つの原因から生じます。（2）送信機の信号が生成されたときに受信されなかったか、（3）受信時にデータを処理する準備ができていませんでした。私が問題1で見た最も一般的な原因は、データを送信している間に再構成またはシャットダウンされるトランスミッタです。問題＃2は、電波干渉などの結果として「外の世界」を移動する信号で簡単に発生する可能性があります（携帯電話は意外に厄介な場合があります！）。問題＃3は、処理できるバイト数よりも速く到着するバイト数が多すぎるか、送信中にレシーバーが再構成、シャットダウン、または起動されたために発生します。
多くの場合、これらの問題をすべて完全になくすことは困難です。彼らの目標は、彼らによって行われる「損害」の合計（発生の確率、発生ごとの損害の倍数）が許容範囲内であることを確実にすることです。これは、信頼性の悲観的な見積もりを選択し、自分の見積もりと一致していた最悪の障害がシステムパフォーマンスに与える影響が許容範囲内になるようにプロトコルを設計することによって、最も簡単に行うことができます。
フレーミングエラーは、@ jippieが言及していることによって発生する可能性があります-レシーバーはスタートビットを検出し、ストップビットが予期される場所でデータが反転します。これは、ストップビットに影響を与えるライン干渉によって引き起こされるデータ破損が原因である可能性もあります。受信したバイトごとに常にこれを確認する必要があります。
パリティエラーは、データリンクにパリティが実装されていて、受信データにパリティの不一致を引き起こす破損がある場合に発生します。受信したバイトごとに常にこれを確認する必要があります。
受信ブレークもエラーと見なされますが、これは実際には、着信データが1バイトを超えるデータの間に論理ゼロに落ちたことを示しています。通常、論理1は、連続するデータバイト間の「周囲の」状態であり、このままです。それは私が思う古い電信システムへの回帰です。この "機能"を使用して（たとえば）リセットコマンドをレシーバーに示す場合を除いて、私はこれをチェックしません。
オーバーランエラーは、前のバイトがCPUによって読み取られる前に新しいバイトが受信された場合です。FIFOが含まれる場合は少し異なりますが、同じことになります。有効な受信データはCPUの速度低下により失われます。バイトを読み取る前に必ずこれを確認し、バイトが長いメッセージ（またはコマンド）の一部である場合は、メッセージ/コマンド全体を破棄し、何らかの方法でトランスミッターにメッセージ/コマンド全体を再送信するように要求します。
アンダーランは実際にはエラーではありませんが、送信バッファに空であること、つまり新しいバイトを送信するよう要求していることを送信UARTに示します。これを確認する必要はありません。
これらのエラーに対処するには、より高いレベルの論理プロトコルを実装する必要があります。TCPに似たもの、またはOSIスタックのアイデアを確認してください。
基本的に、最初に開始する2つの重要な部分は、チェックサムとタイムアウトです。アルゴリズムを使用して、各メッセージの内容をより小さな形式で表す冗長値を計算します。次に、受信したメッセージでこれを確認します。合計が一致しない場合は、フレーミングエラー、ビットノイズなどが発生している可能性があります。メッセージを破棄して、なんらかの回復、再送信、NACK（確認応答されていない）信号などを試行する必要があります。
また、上位レベルのプロトコルにタイムアウトを実装してください。何らかのフレーミングエラーが発生した場合、UARTが回復せず、再び処理を開始する場合があります。送信側UARTが送信済みであると考えるフレームでストップビットを待機している可能性がありますが、ノイズやクロックスキューなどによって破損しています。これにより、入力コードが無限ループに送信されます。このメッセージを破棄することを決定するまで入力の読み取りを待機する必要がある時間について、適切な制限があることを確認し、再度、再試行、NACK、破棄などを行います。