開発ノート ⁽⁹¹⁾

前日来実験している割り込みの性能テスト。Jessieの構築に成功したので、こちらでも実験してみました。Jessie [埋め込み: https://www.youtube.com/embed/Kcfzx9skA0s] Wheezy [埋め込み: https://www.youtube.com/embed/1FmXSB2xkmg] カーネルと基本パッケージが変わるだけでそれほど性能差は出ないだろうと思っていましたが、２割ぐらいレスポンスが違うように見えます。最適化されたということらしいので、そのあたりが影響しているのでしょうか。あと使っているJessieがLITEなので文字通り軽いのかもしれません。”””

Raspberry PiのオンボードLEDをコントロールする方法が無いかと検索していたら、こちらの記事を発見。Can we control the on-board leds[コラム] Raspberry Pi 2のオンボードLEDを自由に光らせようどのキーワードに括弧書きを付けているかをechoで変更するので何かおかしいなと思っていたら、nanoで手動で書き換えても元に戻ります。これは一種のデバイスファイルで、読み取りが状態表示、キーワードの書き込みがデバイスに対する操作を行っているのだと思います。で、指示通りsuでrootになって作業をしたらちゃんとコントロールできたのですが、sudoで実行したらエラー。 pi@raspberrypi:~ $ sudo echo heartbeat > /sys/class/leds/led0/trigger -bash: /sys/class/leds/led0/trigger: Permission denied suだとスクリプトから実行しにくいですし、rootになったまま他の作業を実施してしまいそうで怖いんです。で、調べてみるとリダイレクトするとリダイレクト部分だけがsudoの実行元のユーザーが実行されてしまうとのこと。なのでリダイレクトではなくパイプで渡して、渡された先でteeを使ってファイルに書き込むとエラーになりませんでした。 pi@raspberrypi:~ $ echo none | sudo tee /sys/class/leds/led0/trigger nonepi@raspberrypi:~ $ echo heartbeat | sudo tee /sys/class/leds/led0/trigger heartbeat この通り実行してみるとチカッチカッと。 [埋め込み: https://www.youtube.com/embed/Cpm5Tb6aiJQ] GPIOに連動させる設定にしてサーバーアプリの状態監視に使う予定です。”””

当たり前のことではあるのですが、PiでGPIOを指定するときはコアであるBCMの番号が原則です。が、WiringPiは何故かGPIOに対して独自の付番をしているので、対照関係が結構ややこしいです。ヘッダピンの番号がさらにまた別になっています。で、今回オンボードLEDのコントロールのため、以下のコマンドでGPIOに対応させるようにしたのですが、このコマンドはBCMの番号で指定します。 system(""echo gpio | sudo tee /sys/class/leds/led0/trigger""); system(""echo 21 | sudo tee /sys/class/leds/led0/gpio""); 一方このGPIOをWiring PiでコントロールするときはWiring PiでコントロールするときはWiring Piの番号でコントロールします。 while(1) { digitalWrite(29， 1); usleep( 50000); digitalWrite(29， 0); usleep(950000); } コード上ではWiring Piの世界とBCMの世界の区別がぱっと見ではわかりにくいので、気をつけた方がいいですね。””” 本文の対比は既定のwiringPiSetup()でWiringPi番号を使った例です。wiringPiSetupGpio()ならBCM番号、wiringPiSetupPhys()ならヘッダの物理番号を使うため、WiringPiだから常に独自番号とは限りません。オンボードLEDの接続や制御方法も基板ごとに異なります。

service – Unix， Linux Commandserviceコマンドが環境変数の影響を排除してinit.dのスクリプトを実行できるということは色々なサイトに書かれていて概ね理解できていました。が、serviceが実態として、rc.dのリンクを実行していて、その時点でのランレベルに応じた起動をするのか、とにかくinit.dにある方のスクリプトを直接実行しているのかが分からなかったのですが、このサイトによるとinit.dにある方を実行しているとのこと。で、実際にinsservでrc.dのシンボリックを全削除してみたところ、それでもserviceコマンドでサービスのstart/stopができました。で更に実験としてinit.dの中のスクリプト名を変更したら、もちろん実行できなかったのですが、warningの中にあるsystemctlを実行すると、何故かktdが実行できるようになりました。 pi@raspberrypi:/etc/init.d $ sudo mv ktd tttdpi@raspberrypi:/etc/init.d $ sudo service ktd startWarning: Unit file of ktd.service changed on disk， 'systemctl daemon-reload' recommended.Job for ktd.service failed. See 'systemctl status ktd.service' and 'journalctl -xn' for details.pi@raspberrypi:/etc/init.d $ systemctl daemon-reloadFailed to execute operation: Access…

低電圧からの流れは世界的なトレンドのようで、PIC/AVR/H8の5Vから、ARM系の3.3Vに主流が移っていますね。周辺用のモジュールも3.3V対応のものが増えてきましたので、接続には困らないことが多いです。が、それでも困るのがMOS-FET。街中の電子部品店に出回っているMOS-FETは「エンハンスメントタイプ」とあってもゲート電圧が4Vを超えて初めてそれなりのIDが流せるものが多いです。そのため3.3V系のマイコンでは直接駆動できず、ゲートドライバを別途接続しないといけなくなります。ただ良く探してみると、MOS-FETにも3.3Vで直接駆動できるものがあります。私がSTM本の執筆の時によく使っていたのが、IRL2505。IRL2505 – International Rectifierデータシート上ではゲート電圧3V時に30A程流せます。最大電流が100Aありますので、モータードライブも楽勝です。オン抵抗わずか0.01Ω。難点は馬鹿高いこと。何と１コ400円もします。後継品も同じぐらいです。そこで他に使えるものが無いかと探してみて、これを入手してみました。共立電子で140円です。2SK975 – Renesas Electronicsゲート電圧3V時に1.5A程度流せます。オン抵抗0.4Ωぐらい。マイコンの周辺回路で1Aも食うものはそう無いので、実用上は充分かなと。TO-92みたいな感じでブレッドボードも楽勝。ただもうディスコンっぽいです。まだ入手できていないのですが気になっているのが秋月の掘り出し品のこちら。ＮｃｈＭＯＳＦＥＴ ２ＳＫ２４１２ （６０Ｖ２０Ａ）「3V駆動で100A」という記述は誤りです。連続電流・パルス電流の絶対最大定格と、3V時の参考特性は別です。部品ごとのVGS、温度、パルス幅、放熱条件、オン抵抗の保証条件を確認して選定します。あとはこの3点も使えるかもしれません。Ｎｃｈ ＭＯＳＦＥＴ ２ＳＫ３１３４Ｌ－Ｅ （３０Ｖ７５Ａ）ＮｃｈパワーＭＯＳＦＥＴ ＥＫＩ０４０３６ ４０Ｖ８０Ａ次の秋月への発注の際には忘れずにカートに加えておきます。共立だとこれ。2SK4019 – Toshiba “”” ゲートしきい値電圧は、負荷を十分低いオン抵抗で駆動できる電圧を意味しません。IRL2505の絶対最大連続電流も、VGS=10V、ケース温度などの条件付きです。典型特性グラフだけを根拠に、3.3Vで同じ大電流を連続して流せるとは判断できません。本文の価格・入手状況は執筆当時の記録です。