PiNubの開発 [Raspberry Pi]
こないだちょっと書いたけど、Raspberry Piに書くソフトウェアをSwift化したい。まず真っ先に書きたいものがあるんだけど、まだ環境のSwift化ができていないので、そのベースとなるソフトウェアをCで今書きつつある。環境が整備できたらそれをSwift化するつもり。その真っ先に書きたいもので僕は何をしたいのか、をここでまとめておく。そのソフトウェアにPiNubという名前をつけた....
Raspberry Piを仕事に使い始めていつの間にか20台以上動いている。いくつかは工場の設備の一部として、残りは実験用のハードウェア制御用として裸の基板がごろごろしている。使い方は大きく分けて2通りで
準リアルタイムモニタ/制御というのは組み立てや実験の設備の一部として光強度測定と制御、ステッピングモータ駆動なんかに使っている。これはRaspberry Pi単体ではなく、必ずクライアントとしてホストコンピュータ(僕が書くので必ずMacになるけど)と通信しながら動作する。この場合ユーザインターフェイスはホスト側にあって、Raspberry Piにユーザが直接ログインすることはない。
どちらにしてもRaspberry Piの仕事はセンサやA/D、D/A変換、あるいはリレーなんかが接続されてそこからデータを取ったり、書いたり、オンオフしたり、という作業がほとんどである。GPIOのソケットに何もくっついていないRaspberry Piは存在していない。
それでも単純作業ではなく、たとえばA/D変換器はいわゆるオーバーサンプリング(といえばカッコいいけどつまりは必要帯域より高い周波数でデータをとって帯域内へ平均化して擬似的にS/Nを上げる)をしたり、D/A変換器は10kHzぐらいの周波数で変調をかけたり、単なるオンオフでもmsぐらいのタイミングを制御したり、とそれなりに忙しい。
最初のうち基板を作ってそれにRaspberry Piを繋いで、とそのときそのときで適当にやってた。基板上のレイアウトの関係で同じA/D変換のチップでもSPIのmain側に繋いだりauxiliary側にしたり、あるいはチップセレクトを取り換えたり、ということをしてしまって、ほとんど同じことをしているのに、基板を作るたびに書き換えないといけなかったりした。
そもそもどういう経緯を経てどう言う状態になっているかを改めてまとめると、
実際にはソフトウェアのやることはそれほど種類がたくさんあるわけではない。そこでソフトウェアを汎用化して統一し、接続された基板の情報をファイルから読んでそれに従って動作させるように考えた。これは誰でもそうしようと思うだろう。
汎用化したソフトウェアをPiNubという名前にして、こんな みたいな構造にする。GPIOを直接制御するのはpigpioライブラリを経由する。クライアントがある場合、LAN(たいてい構内WiFi)を経由して通信する。クライアント側にもPiNubがあるけど、その意味はあとで説明する。クライアントを持たない場合でも同じRaspberry Pi上にlocalhost経由で起動終了するためのプロセスを同じように立ち上げることにする。こうするとRaspberry PiにUIを作る場合でも変更する必要はない。
基板情報の記述ファイルはその基板自身にEE-PROMを乗せてそこに書いておく。こうするとRapberry Piを取り替えても動作するというわけである。Raspberry Piと基板のどちらもそれほど信頼性が高いわけではないので、故障したとき簡単に交換できるほうが便利である。EE-PROMは決まったバスの決まったアドレスに配置して、PiNubは起動するとそのEE-PROMを読み込むということにする。具体的にはI2Cのバス1側だろう。I2Cは遅いチップが多いので使用頻度は少ないし、アドレス空間も広く、40ピンヘッダの3番5番なので基板の端っこに実装できる。
記述ファイルの形式はやっぱりXMLだろうな。jsonのほうがmacOSのplistとよく似ていてわかりやすいけど、RaspbianとクライアントOSとで同じライブラリを使いたい。XMLならlibxml2があるのでやっぱりこっちだろう。
おおまかなソフトウェアの流れとしては
長くなったので続きは次回ということで。
Raspberry Piを仕事に使い始めていつの間にか20台以上動いている。いくつかは工場の設備の一部として、残りは実験用のハードウェア制御用として裸の基板がごろごろしている。使い方は大きく分けて2通りで
- データロガー
- 他のハードウェアの準リアルタイムモニタ/制御
準リアルタイムモニタ/制御というのは組み立てや実験の設備の一部として光強度測定と制御、ステッピングモータ駆動なんかに使っている。これはRaspberry Pi単体ではなく、必ずクライアントとしてホストコンピュータ(僕が書くので必ずMacになるけど)と通信しながら動作する。この場合ユーザインターフェイスはホスト側にあって、Raspberry Piにユーザが直接ログインすることはない。
どちらにしてもRaspberry Piの仕事はセンサやA/D、D/A変換、あるいはリレーなんかが接続されてそこからデータを取ったり、書いたり、オンオフしたり、という作業がほとんどである。GPIOのソケットに何もくっついていないRaspberry Piは存在していない。
それでも単純作業ではなく、たとえばA/D変換器はいわゆるオーバーサンプリング(といえばカッコいいけどつまりは必要帯域より高い周波数でデータをとって帯域内へ平均化して擬似的にS/Nを上げる)をしたり、D/A変換器は10kHzぐらいの周波数で変調をかけたり、単なるオンオフでもmsぐらいのタイミングを制御したり、とそれなりに忙しい。
最初のうち基板を作ってそれにRaspberry Piを繋いで、とそのときそのときで適当にやってた。基板上のレイアウトの関係で同じA/D変換のチップでもSPIのmain側に繋いだりauxiliary側にしたり、あるいはチップセレクトを取り換えたり、ということをしてしまって、ほとんど同じことをしているのに、基板を作るたびに書き換えないといけなかったりした。
そもそもどういう経緯を経てどう言う状態になっているかを改めてまとめると、
- Raspberry Piの使用目的は簡便な低レベルハードウェアの制御
- 用途ごとに異なる回路を設計して、自分ではんだ付けしてきた
- それに接続するソフトウェアを個別に作成してきた
- Raspberry Piの台数が増えると、ソフトウェアの種類も増えた
- ところがソフトウェアの大まかな動作はだいたい同じ
- 回路製作のたびにソフトウェアを作成し直すのは無駄で、管理も面倒
- ソフトウェアの共通部分の抜き出し
- 汎用化
- なるべくソフトウェアの新規作成を減らす
- すでにあるソフトウェアも順次置き換える
実際にはソフトウェアのやることはそれほど種類がたくさんあるわけではない。そこでソフトウェアを汎用化して統一し、接続された基板の情報をファイルから読んでそれに従って動作させるように考えた。これは誰でもそうしようと思うだろう。
汎用化したソフトウェアをPiNubという名前にして、こんな みたいな構造にする。GPIOを直接制御するのはpigpioライブラリを経由する。クライアントがある場合、LAN(たいてい構内WiFi)を経由して通信する。クライアント側にもPiNubがあるけど、その意味はあとで説明する。クライアントを持たない場合でも同じRaspberry Pi上にlocalhost経由で起動終了するためのプロセスを同じように立ち上げることにする。こうするとRaspberry PiにUIを作る場合でも変更する必要はない。
基板情報の記述ファイルはその基板自身にEE-PROMを乗せてそこに書いておく。こうするとRapberry Piを取り替えても動作するというわけである。Raspberry Piと基板のどちらもそれほど信頼性が高いわけではないので、故障したとき簡単に交換できるほうが便利である。EE-PROMは決まったバスの決まったアドレスに配置して、PiNubは起動するとそのEE-PROMを読み込むということにする。具体的にはI2Cのバス1側だろう。I2Cは遅いチップが多いので使用頻度は少ないし、アドレス空間も広く、40ピンヘッダの3番5番なので基板の端っこに実装できる。
記述ファイルの形式はやっぱりXMLだろうな。jsonのほうがmacOSのplistとよく似ていてわかりやすいけど、RaspbianとクライアントOSとで同じライブラリを使いたい。XMLならlibxml2があるのでやっぱりこっちだろう。
おおまかなソフトウェアの流れとしては
- systemdで制御されるdaemonプロセスとして起動
- 回路を記述したファイルを読み込み、それに従ってオブジェクトを構築
- ユーザインタフェイスからの接続を待つ
- 接続が確立するとコマンドを受け付け、それに従って結果を返す
- 接続切断とともにプロセス終了
- systemdによって再起動されて、接続を待つ
長くなったので続きは次回ということで。
2019-10-27 21:15
nice!(0)
コメント(0)
コメント 0