ソフトウェアUARTでのスタートビットの検出

GPIOピンを使用して、マイクロコントローラーでソフトウェアUARTを書き込む実験をしています。これは、より多くのUARTポートを備えたuCを使用する新しいデザインが実装されるまで、プロジェクトにUARTチャネルを一時的に追加することです。

私が問題を抱えているのは、シリアルストリームのスタートビットを正しく検出することです。ストリームのソースは外部であり、デバイスの電源がいつオンになってもかまいません。したがって、デバイスの電源がオンになり、バイト送信の途中でデータビットが表示されるようになる可能性が非常に高くなります。間違いなく、それによって私のソフトウェアUARTは誤った値を読み取ることになります。これは、スタートビットと他の高から低への遷移との違いがわからないためです。

これはUARTチャネルの避けられない問題ですか？または、uCメーカーがハードウェアUARTで使用する巧妙なトリックはありますか？

1.5ビット時間など、データストリームの残りの部分から簡単に識別できるストップビット長を使用すると、送信途中で受信を開始しやすくなります。ただし、これにはオーバーヘッドの増加という犠牲が伴います。ストップビットの長さを長くすると、使用可能な総データスループットが低下します。

頻繁にバスを使用しておらず、フレーム間に頻繁にギャップがある場合は、これらのギャップの1つが発生するのを待ってから、最初のハイロー送信を最初のハイロートランスミッションとしてピックアップするだけで問題ない場合があります。次のスタートビット。

フレームサイズと同様に、データビットの数は予測可能である必要があることに注意してください。バスの容量を100％使用していて、ストップビットがシングルビットタイムの場合でも、そのビットを見つけることができるはずです。十分な数のフレームを収集した場合、開始ビット。すべてのフレームにhi-loトランジションが含まれることが保証されています。ストップビットは常にハイです。スタートビットは常にローのビットです。データがランダム（または十分にランダム）であると仮定すると、フレームのサイズのバッファーを作成し、そのすべてのビットを設定し、フレームを収集し、バッファーが1になるまでこのバッファーにAND演算するだけで、簡単なことができます。ビットセット。このビットはあなたのストップビットです。その次があなたのスタートビットです。出来上がり！あなたはそれを見つけました。

パリティビットを使用している場合、別のオプションは、2フレーム分のデータを取得し、最初の下位ビットを開始ビットとして選択して、チェックサムを計算し、パリティビットと比較することです。一致する場合は、（おそらく）開始ビットを見つけました。そうでない場合は、次の下位ビットを選択し、適切なチェックサムが得られるまで繰り返します。2つのデータフレームで有効な開始ビットとしてチェックアウトされるビットが見つからない場合、データが破損しているため、さらに2つのフレームを取得する必要があります。

ハードウェアUARTにも同じ問題があります。しかし、それは通常、とにかく短い順序で自動的に解決するものです。各フレームの終わりにストップビットをチェックし、それがハイでない場合は、フレームを破棄し、次のハイからローへの遷移を待ちます。ソースからのデータが完全に異常ではない（たとえば、「UUUU」の長い文字列、またはASCII 0x55）と想定すると、UARTは最終的に実際のスタートビットまで「ウォーク」します。

8N1送信を想定しています。

一連の9つの上位ビットまたは下位ビットの文字列を待つ必要があります。

高い場合は、データのアイドルギャップまたは0xFF文字と​​STOPビット
または
低い場合はSTARTビットとNULL 0x00文字の。

これらの条件のいずれかにより、再同期が可能になります。

データを高速化するには：データ内で使用できない特定の文字がわかっている場合は、受信したデータを（事実の後で）ビットごとに繰り返し解析でき、意味のない一連の7文字（高ビットセット、低大文字、小文字、制御コード、句読点など）の後に有効な文字が続く場合は、再同期されていることをかなり確信で​​きます。

組み込みのUARTペリフェラルを使用してビット単位の評価を行うことができず、すべてのフレーミングエラービットなどが発生した場合は（特に電源投入時に）リセットすることを忘れないようにすると、同様の問題が発生します。