2

従来の理由から、限られた仕様しか利用できないサードパーティのデバイスとプログラムが通信できるようにする必要があります。これ自体は実際には問題ではなく、すべてのシリアルエラーを無視するときに問題なく通信できるコードがいくつかあります。

ただし、エラーを無視しないようにしたいと思いますが、問題は、デバイスから受信したすべてのメッセージが最初のバイトでフレーミングエラーを生成することです（メーカー側の奇妙な設計上の決定による）。

デバイスが応答を送信すると、ライン上に6ビット回スペースをアサートし、次に2ビット回マークをアサートしてから、通常のフレーミング（1スペーススタートビット、8データビット、2マークストップビット）に落ち着くようです。 。言い換えると、送信された最初のバイトは5ビットのフレーミングを使用しているように見えますが、後続のすべてのバイトは8ビットのフレーミングを使用しています。または、その最初のバイトは実際には非常に短いブレーク条件です。（この癖を除けば、メッセージ形式はかなりうまく設計されており、明確です。）これは、ある種の割り込みウェイクアップ信号として意図されたものだと思いますが、なぜ同じフレーミングを使用しないのかわかりません。メッセージの残りの部分、または1文字より長い本物の割り込み条件。

当然のことながら、これはOSを苛立たせ、最初の「バイト」を検出するとフレーミングエラーを生成します。現在、このデバイスと通信するためにWindowsベースのプログラムを使用しています（ただし、後でLinuxに移行する可能性があります）。Windowsでは、オーバーラップしたI / Oを使用しReadFileExて、実際のデータを読み取り、ClearCommErrorエラー状態を検出しています。残念ながら、これは、データとは関係なくフレームエラーが報告されることを意味します。これは、読み取られるデータのチャンク全体（通常は一度に8バイト、場合によってはそれ以上）のエラーとして扱われ、実際にはそうは思えません。さらにローカライズします。

（フレーミングエラーにより、着信メッセージの2番目のバイトも破損することがありますが、幸い、この特定のメッセージ形式の解釈に問題は発生しません。）

ポート処理コードがこれをプロトコル処理コードに渡すことができ、メッセージの重要な部分の外部で発生するエラーを無視できるように、どのバイトが特にフレーミングエラーを引き起こしたかを識別できるようにしたいと思います。しかし、パフォーマンスを低下させたくありません（これは、バイトごとに読み取ろうとした場合に発生すると思われます。それでもうまくいくかどうかはわかりません）。

これを行う良い方法はありますか？それとも、アイデア全体を忘れて、フレーミングエラーを完全に無視したほうがいいでしょうか？

4

2 に答える 2

0

これが堅牢なソリューションであるかどうかは100％確信できませんが、これまでのところうまくいくようです。

フレーミングエラーを検出すると、次の読み取りで1バイトが読み取られ、その後の読み取り（フレーミングエラーがまだない場合）が可能な限り読み取りに戻るように作成しました。これにより、エラーを超えてクリアされ、問題なく次のバイトを受信するようです。（少なくとも、それらのバイト自体にフレーミングの問題がない場合。それらがどのように機能するかをテストする方法がわかりません。）

于 2013-03-26T02:23:59.853 に答える
-1

RTMmouseを使用して、約6か月前にマスク可能なフレーミングエラーが発生しました。DOS 7.10デバッグで修正しましたが、今はまた修正しました...なぜですか？DOS 7.10プライマリアプリケーションにWIN95をインストールし、ブートパーティションを除くすべてのセカンダリアプリケーションも変換しました。win95プライマリパリチロンへのアプリケーションで正常に動作した後、Windowsを再インストールしました。これによりNMIがアクティブになりました。エラーを見つけるにはどうすればよいですか。これは、ブートストラップ上にあります[CSDPMIサーバーが提供されているlockdrv.batを呼び出した後、マウスドライバーを介したRTM.EXEリダイレクトでこれに対するブレークポイントがあります。

したがって、最初の起動後、私はこれをすぐに実行します：

C> debug -u

autoexec.batの実行から生成された一連のコードを取得します

8ビットのオペランドをnaemlyトレースすると、CPUがこの方法でNMIを提供していることがわかります-メモリからのこの構造の正確さはわかりませんが、lock %%のすべての％fに対するlockdrv.batからのAX計算のようなものです

次にAXをプッシュします。次にCPUは他のことを行います-AXをプッシュしてからahをゼロに設定します

プッシュアックスmovah、00

これは無効になっているビットです-他のデータビットをそのまま維持しますこれはフラットアセンブリのフレームエロアです---これより前にbxのsiとdxを介してすべての呼び出しが行われます：

[si +dx];alを追加します

コンピュータはモデムデータビットを認識しますが、送信または受信するものがありません[ラルフブラウンの割り込みリストとデバッグで最後の夜まで起きていました]これは本当に楽しかったです。しかし、これはフレームエラーです。int14エラーを次のように確認しました。フレームエラーとして0Cに割り込む-win95は、ブレークポイントが気に入らないために生成したはずです[v86を介して存在する必要はありませんが、NMIを生成します-マイナーであるフレームエラーはまだあり、CPUの場合はNMIですはそれを認識していません-これは、発生する可能性のある基本的または単純なNMIの1つです。NMIは、マスクできないことを意味するか、例外がないことを意味します。例としては、IRQの競合や、2つ以上のプログラムが競合する場合にリアルモードで通常発生する16ビットの一般的な保護障害を形成するための割り込みの競合が原因で絶対的な答えを損なうことができない除算オーバーフローがあります-またはWIN95 ralモードでマルチタスクにDOSGUIを使用しようとしています-WIN95はファイルの紛失とファイル共有のためのDOSリアルモード共有プログラムをサポートしていないためです。

于 2015-05-25T14:06:24.553 に答える