問題タブ [isr]

割り込みサービス ルーチン (ISR) でブレークポイントを使用できますか?

iPAQhx4700のCFポートを使用するカスタムデバイス用に開発したドライバーを移植しようとしています。

ターゲットは、Windows Mobile6を実行する新しいiPAQ210です。WM6（およびWindows CE 5.0）は新しいドライバーアーキテクチャに切り替えましたが、レガシードライバーをサポートしていると主張しています。

割り込み処理部分を除いて、すべてが正常に機能しています（登録、メモリマッピングなど） 。ISRをに登録しましCardRequestIRQ()たが、IRQが生成されると、ISRが呼び出されることはありません。

注意：私は明確に定義されたプラットフォーム（iPAQ 210）用に開発しているので、Platform Builder、OAL、...はありません。

私がこの問題に光を当てるのを助けることができるこの種のことを経験した人はいますか？

ARM926EJ などのマイクロプロセッサの FIQ 割り込みシステムと IRQ 割り込みシステムの違いを知りたいです。

まず、私が知っていることをすべて共有する必要がありますが、それは完全なカオスです。このトピックにはいくつかの異なる質問がありますので、イライラしないでください:)。

1) ISR を見つけるために、CPU には割り込み番号が提供されます。x86 マシン (286/386 以上) には、ISR を含む IVT があります。サイズが 4 バイトの各エントリ。したがって、ISR を見つけるには、割り込み番号に 4 を掛ける必要があります。最初の質問は、CPU が割り込みを受け取るメカニズムに完全に混乱していることです。割り込みを発生させるには、まずデバイスが IRQ をプローブする必要があります。割り込み番号は「IRQで」CPUに向かって移動しますか? また、データバスに ISR アドレスを配置するデバイスのようなものも読みました。それは何ですか？ISR をオーバーライドするデバイスの概念は何ですか。CPU が割り込みをポーリングするデバイスの例をいくつか教えてもらえますか? そして、それらの ISR をどこで見つけますか?

2) 2 つのデバイスが IRQ を共有している場合 (その可能性は非常に高い)、それらの間で CPU はどのように異なるのでしょうか? 両方のデバイスが同じ優先度の割り込みを同時に発生させた場合はどうなるでしょうか。同じタイプのマスキングと優先度の低い割り込みがあることを知りましたが、この通信は CPU とデバイス コントローラ間でどのように行われるのでしょうか? この問題に対する PIC と APIC の役割を調べましたが、理解できませんでした。

読んでくれてありがとう。回答ありがとうございました。

Linuxカーネル開発に関する以前の質問から得たフィードバックに続いて、

私は、既存のドライバーと比較し、そのコードから大幅に「借用」することによって (Linux カーネル v2.6.32 で) ドライバーを作成しました。ドライバーは正常に登録されています。init() と probe() は正常に動作しています。周辺機器のレジスタにもアクセスできます。:-)

しかし、私はIRQ/ISRについて少しぼんやりしています。周辺機器は入力デバイスであり、GPIO ピンで割り込みを発生させます。

現在の状態から先に進み、IRQ を処理して ISR 関数を実行するにはどうすればよいですか?

次の質問があります（x86アーキテクチャに関して）：

NMI進行中のマスカブル割り込みにノンマスカブル割り込み(例)が割り込むとどうなりますか? マスカブル割り込みが処理されたとき、またはインサービス レジスタのすべてのビットがクリアされたときに、横取りされた割り込みの対応する ISR (イン サービス レジスタ) フラグが割り込みコントローラの ISR レジスタに設定されたままになりますか?

前もって感謝します。

学校のプロジェクトの古いコードを見ていて、ラップトップでコンパイルしようとすると、いくつかの問題が発生しました。これは元々、古い 32 ビット バージョンの gcc 用に作成されたものです。とにかく、アセンブリの一部を 64 ビット互換コードに変換しようとしていたところ、いくつか問題が発生しました。

元のコードは次のとおりです。

pusha64 ビット モードでは無効です。それでは、64ビットモードでx86_64アセンブリでこれを行う適切な方法は何でしょうか?

が 64 ビット モードで有効にならないのには理由pushaがあるはずなので、すべてのレジスタを手動でプッシュするのは得策ではないのではないかと感じています。

リアル モードでのアセンブリによって、int 9h の ISR を作成しました。この ISR では、ハードディスクにデータを書き込むために INT 13h、AH=0x02 を呼び出します。ただし、データはハードディスクに書き込まれません。また、int 13h, ah=0x02 も機能しません (ハードディスクからデータを読み取る)。call int 13h の後、キャリー フラグはオンですが、AH と AL はゼロです。このコードを ISR から使用すると、うまくいきます。ISR の INT13h が機能しないのに、INT10h などの他の割り込みが正しく機能するのはなぜですか?

優れた 68k アセンブリ プログラマーはいますか?? Motorola 68040 用に商用の Green Hills コンパイラを使用していますが、コードから非常に奇妙な動作が見られます。場合によっては、コードが if/else 比較を行い、間違った分岐を取ることがあります。例えば：

コードは時々 d!? になります。このエラーが発生するたびに、比較を中断する特定の ISR が常に 1 つあります。ISR 用に生成されたアセンブリを調べたところ、意味をなさないものがいくつかありました。まず、浮動小数点ステータス レジスタ、FPSR、FPCR、および FPIAR が ISR に保存されていないようです。これは、if/else が間違った分岐を取っている理由を説明します。FPSR レジスタは比較の結果を決定するために使用され、そのレジスタが ISR で上書きされた場合、分岐は間違ったパスを取る可能性があります。以下は、コンパイラーによって生成された入り口と出口のアセンブリーです。

Programmer's Reference Manual を調べましたが、FSAVE または FMOVEM が FP ステータス レジスタを保存することを示唆するものは見つかりません。実際、「FSAVE はプログラマの浮動小数点ユニットのモデル レジスタを保存しません。マシンのユーザーの目に見えない部分だけを保存します。」というコメントを見ました。そのため、ISR の開始時にレジスタを保存し、最後に復元するために独自のアセンブリを追加しました。これにより、パフォーマンスが劇的に改善されましたが、まだいくつかの問題が見られます。以下は私が行った追加です。C コードでは、バックアップ変数は unsigned long として入力されます。

レジスターを保存しないことで、コンパイラーに実際にバグがあるとは信じられませんでした。そこで、FPx と Dx の値を調べて、それらが適切な値に復元されていることを確認しましたが、そうではないようです。ただし、アセンブリ コードに変更を加えていないということは 100% ではありません。以下は、レジスタを保存するために追加したコードです。デバッグ変数は unsigned long として入力されます。

要するに、私の質問は、

1) FPSR、FPCR、および FPIAR レジスターを保存しないという点で、生成されたアセンブリーに問題がありますか?

2) ISR に出入りするときに、レジスタの値を適切に保存していますか?

比較する別のコンパイラがあれば、それは素晴らしいことです。残念ながら、デバッガーをコードにアタッチできません。私は C/C++/C#/Java/Python/PHP などの経験が豊富ですが、アセンブリの専門家にはほど遠いです。

どんなアイデアでも大歓迎です！

「ByteBuffer」と呼ばれる Arduino ライブラリ (ここにあります) があり、これは循環バッファーの実装です。バイト以外のすべてのデータ型のサポートを切り捨て、いくつかの便利なメソッドを追加することで、少し変更しました (「ByteBufferPro」と呼びます)。私はこれを割り込みサービスルーチンで使用するつもりです。これはすでにいくつかの重労働を行っています。ISR のワークロードを少し軽減するために、ISR が情報のバイトを循環バッファーにプッシュできるようにするつもりですが (それらのキャプチャ/保存はタイム クリティカルであるため)、その情報の実際の処理はそれほどタイム クリティカルではありません。これはメイン loop() で行います。

ISR で更新できる変数は宣言に 'volatile' 修飾子を含める必要があるというロジックに従って、バッファーを volatile として宣言しましたが、これらのコンパイル エラーが発生しています。

理由は何ですか、どうすればこれを修正できますか? 'this' ポインターに関するクリベッジを取ると、ByteBuffer の実装を C++ から C のもの (OO から手続き型) に変更すると、それを修正する簡単な方法になるはずですが、OO は本当に気に入っています。セマンティクス。他に方法がない場合は、そうします。