同じ作業を実行する別の方法がある場合、GPIO などの特定のデバイス用に組み込みシステムでデバイス ドライバーを作成することの利点を完全に理解できなかったと思います。
sysfs とデバイス ツリーを介して GPIO にアクセスできます。
- 新しいデバイスツリーオーバーレイを書いて有効にする
- /sys/class/gpioに移動します
- 必要なピンをエクスポートして使用を開始します (単純なシェル呼び出しまたは c/c++ アプリ内から)
独自のドライバーを作成します。
- 実際の機能をコーディングします。
- ドライバーをユーザー空間のノード (/dev/tty など) に公開します。
- ドライバーにアクセスするための別の C/C++ コードを記述します (単純なシェル呼び出し経由でもアクセスできます)
- 新しい機能が必要な場合は、まずドライバーを変更し、次にコードを変更します。(なぜですか?)
/dev/mem を直接使用します。
- mman.h をインクルードし、/dev/mem オブジェクトを使用して GPIO ステータスを設定または取得します。
それで、
- 1 -> は非推奨となり、遅くなります。(もちろん、高速なプロトタイピングには絶対に役立ちます)
- 2 -> どうして 1 より速いのですか? 1 番目も別の GPIO ドライバーですよね?
- 3 -> これが最良かつ最速の方法ではないでしょうか?
上記でいくつか質問しましたが、最大の疑問は、なぜ 3 番目の解決策を直接実行しないほうがよいのかということです。
答え1
オプション 2 の利点は、リクエストを 1 か所で検証できることです。たとえば、食器洗い機の場合、水をオンにする前にドア センサーがドアが閉まっていることを確認できます。もちろん、水をオンにする前にドアの状態を確認するようにユーザーに指示することはできますが、全員がそれを実行するでしょうか?
オプション 1 と 3 の潜在的な欠点は、権限です。組み込みデバイスの高度さによって異なりますが、異なるユーザー ID で異なる操作を実行したい場合があります。たとえば、ホーム ルーターでは、Web UI を実行する http サーバーを実行する別の uid と、フロント パネルの LED を操作する別のデーモンが使用される場合があります。gpio ドライバーではきめ細かなアクセス制御が可能ですが、ほとんどは「すべてかゼロか」のアプローチです。オプション 2 を使用すると、どのユーザーがどの機能にアクセスできるかを細かく決定できます。
オプション 2 の欠点は、より複雑で、通常はカーネル内にコードが必要になることです。