組み込み Linux 設計で SC16IS752 チップに取り組んでいます。チップは、シリアル アクティビティの通常の条件下で、両方の COM ポートでうまく動作します。ただし、シリアル セッション内で約 30 秒間データを送受信しない場合、TX ラインで送信される次のバイトは、すべてのボー レート 38400 以上でビットシフトされることがわかりました。興味深いことに、この問題は 19k ボー以下 (より遅いボーレート) では発生しません。
ボーレートが高くなると、問題はさらに悪化します。38k ボーで、送信されたバイトは 1 ビットシフトされます (0x66 を送信しようとすると、0xB3 が送信されます)。115k ボーで、送信されたバイトは 4 ビットシフトされます (0x66 を送信しようとすると、0xF6 が送信されます)。
この問題は、既存のシリアル セッションで非アクティブ状態が 30 秒間続いた後にのみ発生します。つまり、新しいシリアル セッションの最初のバイトは常に正しく送信されます。
30 秒待って代わりに NXP チップでバイトを受信すると、NXP チップは、後続の送信バイトが正しく送信される良好な状態になります (受信バイトより 30 秒以内に送信される限り)。 .
SC16IS752 のデータシート、アプリケーション ノート、正誤表を調べましたが、役に立ちませんでした。スリープ モード、受信タイムアウト、およびすべてのステータス レジスタを調査しました。また、データを送信する前に送信 fifo をクリアしようとしました。試してデバッグするものがなくなりました。Linuxドライバーのデバッグから、SPIを介してNXPシリアルチップに送信された正しいバイトを取得していることを知っています。
ところで、私が使っている Linux ドライバーは、Manuel Stahl によって書かれたもので、Linux カーネルに取り込もうとして (失敗しましたが) Linux カーネル メーリング リストに投稿しました。
その後の調査により、次のことが明らかになりました。
LED を使用してすべてのピンの状態を示すインライン RS-232 デバイスを接続しました。私たちの SC16 シリアル チップ (DTE として構成されている) では、Tx または Rx トランザクションの後、32 秒間「TD」および「RTS」ライトがアクティブになり、その時点で TD および RTS ライトの両方がオフになることに気付きました。
これは、SC16 チップが 32 秒のタイムアウトを持ち、その時点でそれらのピンを無効にすることを意味します。その時点で、Tx トランザクション (SC16 チップがデータを送信する) によってビットシフトの問題が発生します (以前と同様に、ビットシフトされるのは最初のバイトのみです)。
ここで興味深いのは、Windows と "RealTerm" を CTE (SC16 シリアル接続のもう一方の端) として接続したデバッグ ラップトップを使用すると、"CTS" ピンを切り替えることができることです。このピンを (オンまたはオフに) 切り替えると、SC16 チップから TD および RTS ライトが「起動」し、その時点で Tx トランザクション (SC16 チップにデータを送信させる) が成功します!
したがって、要約は次のとおりです。
- SC16 チップの TD ライトと RTS ライトが点灯すると、後続の Tx トランザクションが成功します。
- SC16 TD および RTS ライトは、32 秒後にタイムアウト (消灯) します。後続の Tx トランザクションにはビットシフトの問題があります。
- CTE の RTS ピンを切り替えて SC16 チップをくすぐると、SC16 チップの TD および RTS ライトが「目覚め」、後続の Tx トランザクションが成功します。
SC16 データシートには、このタイプのタイムアウトについて言及しているものはありません。唯一の言及は、私が無効にした「スリープモード」です。