Raspberry Pi使い方のパターン [Raspberry Pi]
仕事では一難去ってまた一難で苦しんでるんだけど、それとは別に工場に入れるために新しい設備を作らないといけない。今日も1日天気が悪かったのでずっと家で仕事してた。
設備の方は、例によって手作り感満載のもの。その設備にもまたRaspberry Piを使おうとしていて、その基板むき出しなのが見た目が悪いと周りからは思われているようである。そして(前の会社ならいざ知らず、見た目にかける金なんかないはずなんだけど)見た目が悪いと信頼性がない、精度が低い、と思う人もいるようである。知ったことか、機能優先。それ以上のことを僕にやらすなよ。
ところでこれまで10台を超えるRaspberry Piを会社の設備に使ってきて、なんとなくパターンが決まってきた。
SPIバスやI2CバスにA/DやD/Aをぶら下げて、バスごとにスレッドを起こして、そのスレッドの中ではループを回してA/DやD/Aを叩いて、データはパイプ経由で本体ループに集めて、本体ループはクライアントであるmacOSとTCP/UDP経由でやりとりして、という感じ。
新しい設備ができるとRaspberry Piを買って、基板をはんだ付けして、ソフト書いて、ということをそのたびにやってる。似たような使い方とは言ってもそれぞれ必要な回路は違ってるので、毎回はんだ付けはしょうがない(僕がやると目がしょぼしょぼしてうまくいかないので、大きな会社にいるんだったら外注したり、若い奴がいたらそいつに振るんだろうけど)にしても、毎回ソフトを0から書くのはバカらしくなってきた.....
ということで、基板上の回路を記述するXMLファイルを作って、(記述は基板に固有になるので)それをI2C接続のEEPROMに書いて基板に乗せて、ソフトを立ち上げるとそこからXMLを読み込んで何がどう繋がっているかを知って、クライアントと通信を開始する、というような形にしようと思った。こないだからちまちまと書き始めた。
XMLの形式はほどんど自動的に決まってしまった。つまり、基本的にハードウェア接続のツリー構造と機能のツリー構造が表現できればいい。接続ツリーの一番下のドライバのレベルに名前をつけてそれで機能ツリーから呼び出すような形のXMLにした。具体的には
このXMLを読み込むのにlibxml2を使って書いた。libxml2はRaspbianでもmacOSでも動く。新しい開発環境のおかげで、ちょっと前にずいぶん苦労したライブラリ間の整合性の問題はあっさりとカタがついて、読み込む部分は書けた。
あとはいろいろあるデバイスやそれを駆動するドライバを書いていけばいいんだけど、例えばSPIバスにD/Aコンバータが1個だけだったりチップセレクトでいくつかを振り分けたりする。ソフトウェアとしてはマルチインスタンスな書き方ができた方がいい。具体的にはさっきのXMLファイルを読み込んで みたいなオブジェクトツリーを作るようにしたい。
C++で書けばmacOSでもRaspbianでも動くようにできる(開発環境の方もC++が動くようにして)んだけど、僕はどうもC++が苦手でまともなものが書けない。GObjectを使えばCで書けてオブジェクト指向風に書けるんだけど、CoreFoundationがあるのにさらにGObjectを持つのは冗長に思えて馴染めない。GTypeはCFTypeだし、GClosureはCFNotificationだし、GMainLoopはCFRunLoopだし、と思うとなんだか似たようなものがふたつあるとしか思えない。そして事実そうである。しかしまた、それを厭うのは単に僕の衝動的最適化癖と、あとは慣れの問題でしかない、というのはまたその通りであって、普通の人は気にもしないんだろう。さらにmacOSでは実行しなくてRaspbianだけなのに、それでもそう言うのが僕は気に入らないんだから仕方ない。偏屈ジジイだし。
そこでCを使ってCoreFoundationの超サブセットみたいな書き方をしはじめたんだけど、どうもいわゆるボイラープレートなコードをいっぱい書かないといけなくなってしまう。ようするに機能省略版のGObjectをいちから書くようなもの(例によって「車輪の再発明」である)で、それがめちゃめんどくさくて、なかなかはかどらない。GObjectのソースもボイラープレートだらけで、やっぱりyacc/lexとか使って自動生成するのかな。
仕事に使うためにやり始めたんだから、最後までやろうと思うんだけど、退屈してしまってつい他のことをやってしまう。というか、集中力があきらかに落ちてるな。まあ、歳だからしょうがないんだけど。
設備の方は、例によって手作り感満載のもの。その設備にもまたRaspberry Piを使おうとしていて、その基板むき出しなのが見た目が悪いと周りからは思われているようである。そして(前の会社ならいざ知らず、見た目にかける金なんかないはずなんだけど)見た目が悪いと信頼性がない、精度が低い、と思う人もいるようである。知ったことか、機能優先。それ以上のことを僕にやらすなよ。
ところでこれまで10台を超えるRaspberry Piを会社の設備に使ってきて、なんとなくパターンが決まってきた。
SPIバスやI2CバスにA/DやD/Aをぶら下げて、バスごとにスレッドを起こして、そのスレッドの中ではループを回してA/DやD/Aを叩いて、データはパイプ経由で本体ループに集めて、本体ループはクライアントであるmacOSとTCP/UDP経由でやりとりして、という感じ。
新しい設備ができるとRaspberry Piを買って、基板をはんだ付けして、ソフト書いて、ということをそのたびにやってる。似たような使い方とは言ってもそれぞれ必要な回路は違ってるので、毎回はんだ付けはしょうがない(僕がやると目がしょぼしょぼしてうまくいかないので、大きな会社にいるんだったら外注したり、若い奴がいたらそいつに振るんだろうけど)にしても、毎回ソフトを0から書くのはバカらしくなってきた.....
ということで、基板上の回路を記述するXMLファイルを作って、(記述は基板に固有になるので)それをI2C接続のEEPROMに書いて基板に乗せて、ソフトを立ち上げるとそこからXMLを読み込んで何がどう繋がっているかを知って、クライアントと通信を開始する、というような形にしようと思った。こないだからちまちまと書き始めた。
XMLの形式はほどんど自動的に決まってしまった。つまり、基本的にハードウェア接続のツリー構造と機能のツリー構造が表現できればいい。接続ツリーの一番下のドライバのレベルに名前をつけてそれで機能ツリーから呼び出すような形のXMLにした。具体的には
<?xml version="1.0" encoding="UTF-8"?> <hardwareDesription> <hardwareDesriptionVersion>1.0</hardwareDesriptionVersion> <name>Interferometer Laser Modulation Board</name> <portNumber>49152</portNumber> <circuitDescription> <busDescription> <spiBus> <name>standard spi</name> <busNumber>0</busNumber> <loopStyle>tight</loopStyle> <loopPeriod>0</loopPeriod> <commandCycle>0.001</commandCycle> <device> <name>D/A converter 0</name> <chipSelect>0</chipSelect> <type>DAC</type> <model>MCP4922</model> <mode>0</mode> <csPolarity>activeLow</csPolarity> <baudRate>2000000</baudRate> <driver> <name>current driver 0</name> <channel>0</channel> <vRatio>1.0</vRatio> <vOffset>2.0</vOffset> </driver> <driver> <name>current driver 1</name> <channel>1</channel> <vRatio>3.5</vRatio> <vOffset>4.1</vOffset> </driver> ........と言うような感じにしたい。機能側のツリーも全く同じ形で、例えば電圧を制御する機能ユニットはD/Aコンバータのひとつのドライバに入力を与えるコントローラとして書くようにしよう。機能ユニットは上位層からユニットの名前でアクセスできるようにして、上位コマンドから機能ユニットを呼び出すようにする。機能ユニットは同じように接続ツリーの末端にあるドライバを名前で指定して操作できるようにする。
このXMLを読み込むのにlibxml2を使って書いた。libxml2はRaspbianでもmacOSでも動く。新しい開発環境のおかげで、ちょっと前にずいぶん苦労したライブラリ間の整合性の問題はあっさりとカタがついて、読み込む部分は書けた。
あとはいろいろあるデバイスやそれを駆動するドライバを書いていけばいいんだけど、例えばSPIバスにD/Aコンバータが1個だけだったりチップセレクトでいくつかを振り分けたりする。ソフトウェアとしてはマルチインスタンスな書き方ができた方がいい。具体的にはさっきのXMLファイルを読み込んで みたいなオブジェクトツリーを作るようにしたい。
C++で書けばmacOSでもRaspbianでも動くようにできる(開発環境の方もC++が動くようにして)んだけど、僕はどうもC++が苦手でまともなものが書けない。GObjectを使えばCで書けてオブジェクト指向風に書けるんだけど、CoreFoundationがあるのにさらにGObjectを持つのは冗長に思えて馴染めない。GTypeはCFTypeだし、GClosureはCFNotificationだし、GMainLoopはCFRunLoopだし、と思うとなんだか似たようなものがふたつあるとしか思えない。そして事実そうである。しかしまた、それを厭うのは単に僕の衝動的最適化癖と、あとは慣れの問題でしかない、というのはまたその通りであって、普通の人は気にもしないんだろう。さらにmacOSでは実行しなくてRaspbianだけなのに、それでもそう言うのが僕は気に入らないんだから仕方ない。偏屈ジジイだし。
そこでCを使ってCoreFoundationの超サブセットみたいな書き方をしはじめたんだけど、どうもいわゆるボイラープレートなコードをいっぱい書かないといけなくなってしまう。ようするに機能省略版のGObjectをいちから書くようなもの(例によって「車輪の再発明」である)で、それがめちゃめんどくさくて、なかなかはかどらない。GObjectのソースもボイラープレートだらけで、やっぱりyacc/lexとか使って自動生成するのかな。
仕事に使うためにやり始めたんだから、最後までやろうと思うんだけど、退屈してしまってつい他のことをやってしまう。というか、集中力があきらかに落ちてるな。まあ、歳だからしょうがないんだけど。
2018-09-15 21:13
nice!(0)
コメント(0)
コメント 0