GPIOのユーザ空間インタフェースは変更Linux 4.8 では、文字デバイス用の古い sysfs インターフェイスは使用されなくなりました。私はこの新しいモデルを私のユースケースに適したものに変換する方法を見つけようとしています。
GPIOを使用してARM CPUで制御できる周辺機器があります。従うべき開始順序があります。まず、5Vレギュレータ（別のデバイス）をオンにし、周囲の電源を入れ、最後に少なくとも5ミリ秒後にリセットを解除します。したがって、3つのGPIO、5v_en、power_on、およびReset_nがあります。周辺機器の電源から動作まで約1分かかりますので、不要な再起動は発生しません。他の要件は、ファームウェア/構成の更新を完了するためにリセットを切り替える必要があり、周辺機器とレギュレータがオフになる低電力モードが必要です。
3つのオプションを見ましたが、どちらも理想的ではありませんでした。
この例では、gpio0 = 5v_en、gpio1 = power_on、およびgpio2 = reset_nを想定しています。
オプション＃1：Sysfs（廃止予定）
cd /sys/class/gpio
echo 0 > export
echo 1 > export
echo 2 > export
echo out > gpio0/direction
echo out > gpio1/direction
echo out > gpio2/direction
echo 1 > gpio0/value
echo 1 > gpio1/value
sleep 1
echo 1 > gpio2/value
上記をinitスクリプトに入れてください。ピンの値を変更する必要がある場合は、open値ファイルに新しい値を書き込むだけです。これは私にとって最も意味があります。残念ながら、今は廃止されました。
オプション＃2：gpioset
gpioset -m signal -b 1 0=1
gpioset -m signal -b 1 1=1
sleep 1
gpioset -m signal -b 1 2=1
上記をinitスクリプトに入れてください。ピン値を変更する必要がある場合は、gpiosetプロセスのPIDを決定し、kill新しい値でプロセスを再起動します。 gpiosetが実行されていない場合、ピンの状態は技術的に「未定義」です。行く道ではないようです。
オプション＃3：デーモン
gpiosetを実行するのではなく、gpioキャラクタデバイス用のオープンファイル記述子を/ devに保持することが唯一の目的である独自のカスタムデーモンを作成しました。プログラムは、競合が発生した場合に管理されているすべてのGPIOの状態が定義されていないため、単純かつ最小化する必要があります。ただし、GPIOを制御したい他のプログラムと通信するには、ある種のIPCも維持する必要があります。デフォルトでは、GPIOを使用したい項目がGPIOを直接使用するのを防ぐために間接層を設定しました。
これは完全に過度にエンジニアリングされているように感じ、IPCプロトコルのドラフトの作成、実装、および文書化は、誰もが望むように/ sys / gpioを使用できるようにすることに比べて本当に迷惑です。
オプション＃3はLinuxが将来のGPIOを管理することを意図した方法ですが、この特定のユースケースでは何の利点もなく多くの追加作業を追加することになります。この質問を理解していただければ幸いです。
- 私が考慮していないものの中でもっと意味のある他の戦略はありますか？
- 未定義のGPIO状態によるプログラム競合のリスクを減らすにはどうすればよいですか？