ここには、互いにあまり関係のない 2 つの質問があるように思えます。
1つ目は「Linuxがデバイスドライバーに求めるものは何か?」です。ほとんどの場合、ドキュメントを読むことで答えが得られます。デバイス ドライバのドキュメントは、(ほぼ間違いなく) 通常のプログラムを作成するためのドキュメントよりも、完全でなく、読みやすくもありませんが、それでもかなりまともです。おそらく、通常のコードとの最大の違いはデバッグです。これは、ほとんどの場合、単純に出力することによって行われprintk
ます。
もう 1 つの質問は、次のようなものです。「SNES コントローラーなどの特定のハードウェアで使用されているプロトコル (または「プロトコル」) をどのように把握しますか。通常のハード ドライブやキーボードなどの開発を行っている場合、多くはドキュメンテーションに従うだけです. ハードウェアのバグを補う必要があることに気付くかもしれませんが (少なくとも私の経験ではよくあります), それ以上は (再び) ごく普通のプログラミングです.これらのケースでは、問題の特定のデバイスをシステムの残りの部分にどのように提示するかを決定するだけです.ハードドライブのようなものは一般的にかなり簡単ですが、ヒューマンインターフェースデバイスのようなものはもう少し難しいかもしれません(例: それ自体を提示しますか?または、キーボードやマウスなどの既存のタイプのデバイスをエミュレートしたいですか?)
実際に文書化されていないハードウェアの場合、状況が少し難しくなる可能性があります。ロジック信号を調べるための本当に汎用的なツールは、ロジック アナライザーです。よく知られているハードウェア インターフェイス (PS/2 キーボード/マウス、USB、SATA など) を使用するものがある場合は、より専門的なツール (および/またはロジック アナライザーのアドオン) を見つけることができます。より簡単に。NES や SNES のコントローラーのようなものはほぼ確実に独自のインターフェイスを使用しているため、最終的にはロジック アナライザーを使用することになります。幸いなことに、それらは非常に狭くて遅いインターフェイスである可能性が高いため、ロジック アナライザーはそれほど高速である必要も、膨大な数のチャネルをサポートする必要もありません。
ロジック アナライザーを使用すると、個々の信号をすべて見ることができますが、独自のインターフェイスの場合、どの信号が何をするかを理解するのはほとんどあなた次第です。典型的なケースでは、電源、グランド、おそらくクロックなど、かなり明白なものが少なくともいくつかあります。多くの場合、公式に文書化されていなくても、I 2 C、SPI などのよく知られたプロトコルに従っている可能性があることがすぐにわかります。