posted by rerofumi

2015/12/6 日曜日 20:54:52

低気圧の到来時など気圧の変化で健康状態に影響を与えるとは良く言われる。
台風や爆弾低気圧の通過後はそうかもなー、とか思うのものの普段の生活で気圧というのは気温ほど気にしてはいなかったりする。そもそもで温度計は家電として入手しやすいものの気圧計はあまり身近では無い様に思う。
そういった体調と気圧変化を結びつけるには今現在の値が知れれば良いわけでもなく継続した変化、ロギングが重要ではないかとも思うのである。

そこで、マイコン(RaspberryPi2)で気圧や気温といった気象情報を計測し、サーバーにロギングする「デジタル百葉箱システム」を作ってみようかというのが今回のお話である。

ちなみに計測するのは自分の部屋である。
単に自分にとっての生活指針が欲しいだけなので外気の状況でなくて良い。

掲載予定としては

1. センサーでの計測部分
2. サーバーでのログ収集
3. ログデータの表示

の 3回になる見込み。

■ センサー

部品箱をほじくり返して以前買ってあったセンサーを掘り出す。
この計測自体は昔からやりたかったので、以前からぽちぽちセンサーだけは買ってあったのである。今になってやろうと思ったのは、自宅内サーバー環境が整ってきたところで、世間で流行の IoT 的フローを構築したくなったからに他ならない。

部品箱にあったセンサーは上の2つ。
青いパッケージで包まれているのが DHT11、温度と湿度を計測するモジュール。8pin DIP 変換基板に載っているのが LPS25H、大気圧を計測するモジュール。どちらも秋月電子通商で買った物。
ちなみに LPS25H は大気圧計測に必要なので温度センサーも載っていてその値を取ることもできる。2つのモジュールのどっちが正しい温度か分からないから両方取得することにする。

RaspberryPi2で値を読み取るテスト。
LPS25H は I2C での通信なので RaspberryPi2 でやりやすいのだけれども、DHT11 はワンワイヤーシリアルである。同様の型で I2C の温度湿度センサーもあるのになんでこれを買っちゃったかな、自分。

DHT11 を Raspberry PI で読むにはと調べたら下記の良い記事がヒットした
「温湿度センサDHT11をRaspberry Piに繋いでシリアル入力を学ぶ」
ソースコードを見ると delayMicroseconds() を使っていて、あーラズパイでこれできるんだとか思いつつ、これで良いかと上記ページにあるコードをそのまま利用させてもらうことにした。
ただ利用しやすい様にコンソール出力のフォーマットだけ手直しした次第。

LPS25H の方は I2C なので WiringPI の I2C メソッドを利用してシリアル通信を行う。
今回は基本的に ruby でコードを書く予定なので、WiringPI の ruby GEM を利用。

 # gem install wiringpi

でもって予め gem をインストールしておく。

I2C 経由で読み取る ruby コードは以下の通り。

require 'wiringpi'

class Lpc25h
  def initialize
    @io = WiringPi::I2C.new(0x5c)
  end

  def writeCommand(address, data)
    @io.write_reg_8(address, data)
  end

  def readCommand(address)
    @io.read_reg_8(address)
  end

  def init
    live = readCommand(0x0f)
    if (live != 0xbd) then
      return false
    end
    writeCommand(0x20, 0x90)
    sleep(1.5)
  end

  def pressure
    a = readCommand(0x2a)
    b = readCommand(0x29)
    c = readCommand(0x28)
    d = (a * 0x10000) + (b* 0x100) + c
    d = d / 4096.0
    return d
  end

  def temp
    a = readCommand(0x2c)
    b = readCommand(0x2b)
    c = (a * 0x100) + b
    if c > 0x7fff then
      c = c - 65536
    end
    d = 42.5 + (c / 480.0)
    return d
  end
end

sense = Lpc25h.new
sense.init
press = sense.pressure
printf("%f hPa\n", press)
temp = sense.temp
printf("%f *C\n", temp)

特に書くほどの事もないけど今回の回路。

行けそうなので基板にまとめた。

これで温度、湿度、気圧のセンサーから現在の部屋の状況を読み取る事ができた。
今回 RaspberryPi2 と ruby を選択したのは、センサーを読み取りつつ、その後ネットワークでよしなにするためなのでお手軽になるのはここから先のお話である。

追記：
あーそういえば RaspberryPi2 で I2C を使うために最初なんかインストールしたり設定したりする必要があった覚えがある。
ちょい前の話であまり覚えていないので省略。

posted by rerofumi

2009/8/27 木曜日 2:41:07

そういえばアナウンスするのを忘れていたけれども、GP2X Wiz のページを作っていた。
PSPやGP2Xでおなじみの TCGS−CAR をイニシャルタイトルとして置いてある。
ひとまず開発環境が整って、無事動かせるようになったという事ですな。
以前言っていたタイマー問題なども調べたので GP2X Wiz の雑多な情報を書いておくことにしよう。

■ タイマー問題
GP2X とか通常のシステムでは 1ms の単位で取れていたタイマーが Wiz では 10ms でしか取れない。何とかならんかと調べていたけれども、どうやら Wiz のカーネルでは clock() 関数が(数字の精度はともかく)10ms単位のカウンタで更新されているということらしい。なのでこれを見ている多くのタイマー系が全部 10ms 単位になってしまうという結果。
何で10ms じゃダメなのかというと、60fps という数字は約 16ms だから。
タイマーを使ってゲームを定速で動かすのはきついのでどうするかというと、ハードウェアレジスタにアクセスして V-Sync を取ることにした。
このへんレジスタへのアクセス方法(/dev/mem を mmap() してアドレスを直接読み書きする)は mame4all あたりのソースコードを参考にするのが良い。
mame4all は SDL とかを使用しておらず、キー入力と画面描画は直接ハードにアクセスして行っているから。(サウンドはカーネルドライバをつかっている)

■ インターレース問題
Wiz をちょいと弄るとわかるのだけれども、ELディスプレイがちょいと変わったインタレースで描かれている。この辺ディスプレイをインタレースにして半分ずつ描くというのは携帯の安いディスプレイでは珍しくはなく、PSPも3000番台になってLCDが綺麗になったら実はインタレースだということが見えるようになってしまいコームノイズがやり玉に挙げられている。
Wiz の EL も 60Hz で半分ずつ描かれているようなのだが、その Even と Odd が対角線で分かれている。つまり、画面を三角形2つに分割してその2つを交互に描いている。
これがどういうことかというと60FPSでゲームを動かすと斜めに絵がずれる。画面半分の三角形は今のフレームだが、もう半分は前のフレームが表示されているのだから。
じゃあ画面上部からの描画ラスタというタイミングはないかというとこれもちゃんとある。
なので画面swapを VBlank で行わないとラスタとインタレースの両方でフレームギャップを生じてしまうというとほほさ。
Wiz の次ロットから LCD になるという噂もあるけれども、それはこの奇妙なインタレースを改善するためなのかもしれない。

■ タッチパネル
GP2X-F200 ではタッチパネルが付いていたものの、デバイスファイルを直接読みとる方式だったと思う。
Wizではカーネルのマウスドライバとして扱われているらしく、SDLのマウスで読めるらしい。

■ ボリューム
相変わらずただのボタンで、音量はアプリが自前で音量をコントロールするソフトウェアボリューム。

■ OpenGL
lib だけ提供されて開発が GL Quake のソースしか手がかりがないという状態が長らく続いていた OpenGL だが、このへんのデベロップリーダーである Pickle 氏による開発パッケージがようやく提供開始となった。
wizGLES, nanoGL というインタフェースでアクセスするのだが、今はSDL1.3 への OpenGLES 組み込み対応が進められている。
しかし、Wiz に入っているSDLは 1.2 なのでそのあたりが将来的に提供されてもライブラリインストールをユーザーに強いることになるかもしれない。

■ カーネルソース問題
ここに来てゆるゆるといろんな開発が立ち上がっているけれども、GPH から提供されているものは何もない。SDK もなければドキュメントもカーネルソースもない。
この辺にコミュニティのいらだちが募ってきておりどうなっとんじゃという声も高くなっている。
そんななかついにカーネルソースがアップされる。おおとうとう、と思ったがどうやらこれは協力デベロッパーがGPHに業を煮やして独断でアップしたものらしい。
そんなこんなで、勝手にやるぜとコミュニティ手動でがんがん進んでいる状況なのだけれども、あまりやりすぎるとファームウェアのライブラリと剥離が進むかもしれない。

■ 良いところ
なんのかんので SDL レベルで開発はできるし、2Dのピクセルフィルレートはかなり早い部類にいるので、320×240 という画面サイズに目をつぶれば 2Dスプライトゲームが作り易いターミナルかもしれない。
フラッシュプレイヤーがあるので、Flashでカジュアルゲームを作ってねというのがGPHの思惑だったっぽいが、皆そのへんに興味はないあたり。

posted by rerofumi

2009/8/16 日曜日 18:43:17

前回の記事では、SDLとSDL_image,SDL_mixer をビルドする rake file を作った。
おかげで Cygwin 環境に自前 SDL ライブラリを導入するのが容易になって自分自身で満足していたり。

今度はこれを拡張して、本来の目的である arm-linux-gnu な環境へ対応したクロス開発ライブラリをビルドできるようにした。お目当ては GP2X wiz 用の開発環境構築だけれども、同じ arm-linux-gnu なターゲットである BeagleBoard や OpenPandora でも使う予定。
まあ、このへんをもにもに作成してクロス開発環境構築の経験値を積もうというのが一番の目的だったりするけれども。

てなわけで GP2X wiz の開発ができるところまで確認できたので Ver0.0.2 release
Download: fumi2_sdl_build-0.0.2.tar.gz (7kb, tar+gz)

前回の 0.0.1 では必要な patch や README がアーカイブから抜けていたので、あれ自体は動かしても最後まで動作しなかったかもしれない :-)

こいつでビルドするための toolchain は既に方々から提供されているものを使う。
このへんの gcc+glibc も同じような rakefile で提供してみたいものだが、最近は crosstools-ng を使うのが一般的だし、手応えとしてかなり難しそうだというのがあるので課題として積んでおくことにする。

今回ので GP2X wiz のクロス開発環境が構築できたのだけれども、その対応のために Ver0.0.2 ではいくつか変更を施している。一番大きいのが libjpeg を最新の v7 から v62 にダウングレードしているところ。
libjpeg v7 は 10年近くメンテナンスされていなかった(枯れていてメンテの必要がなかった) v62 の configure 周りを今時に合わせた待望の新版で 27-Jun-2009 にリリースされた。コレを使うと Darwin でも configure 一発だったりして楽ちんなんだけれども、GP2X の中に入っているのが v62 なので共有ライブラリ名に食い違いが発生してしまう。
なのでしぶしぶと v62 にダウングレードしているのだけれども、今 v62 のソースをダウンロードしようとすると地味に難しかったり、ビルドが難しかったり。
v62 の configure の問題は autoconf, automake が古すぎて libtool がちゃんと生成されないあたりにあるのだが、これは一緒にビルドする linpng に依存することにして libpng の configure で生成された libtool をコピーして使う事にした。
そいった面倒な手順を Rakefile に記述してあるよ、ということ。

ビルド手順を日本語でメモするかわりに rubyという言語でメモ。

posted by rerofumi

2009/7/28 火曜日 1:53:40

結局 GP2X wiz の方はまだなんにも触っていない状態。
なんでかというと、クロスコンパイル環境がまだ手元で確立していないからなんですな。
ここしばらくはずーっとクロスコンパイラのビルドに挑戦しまくっていたり、その他のライブラリ群のビルドに挑んでくじけていたりの繰り返し。まあ、Open2Xの成果を使えば良い話なんだけれども、cygwin上でのtoolchainが不完全だったり、自分で環境を作るのが色々修行になったりするのでやめられないとかそんなあたりで。

そうこうしているうちに MacOSX 向けの toolchain がリリースされてきた。ふむ、MacOSX 上で GP2x wiz の開発をするほうが手っ取り早いかもしれないなあ。
んがふと気がついてみると、手元のMacBook(白、けいおんモデルと同じ奴)に SDL が入っていない事に気がつく。昔の環境には入れていたけれども、こいつになってからはまだ一度もいれていなかったっけ？
そんなわけで SDL, SDL_image, SDL_mixer をインストールすることにしたのだけれども、周辺ライブラリもたくさんあって地味にめんどい。

ところで、最近は toolchain の提供はバイナリよりもインストールスクリプトによる方が主流っぽい。オープンソースなんでバイナリのみの配布だと波風たつのかね？
CrossTool や ct-ng なんかもこの類だねえ。これらは自動ビルドスクリプトではあるけれども、スクリプトを読むことで環境構築手順がわかる教材でもあったりする。
Open2X もそういったスクリプトを用意しているのだけれども、いまいち使い勝手が悪かったりターゲットが linux だけだったり。
うむ、自分で作るか。
どうせ、ちまちまインストールしていく途中で configure につけるスイッチをメモしたりするんだから、それをスクリプトにメモしていくと思えば同じことだろう。

で、そのスクリプトに ruby で書かれた make 代替コマンドである rake を採用する。
前々から使えるようになりたかったんだよね、rake。
shスクリプトとmakefileでなんでもできるというのは嘘じゃないけれども、いまいち自分で書こうとは思わない。どうせ書くなら楽しいコーディングしたいじゃない。
rake だと ruby そのままに make みたいな依存関係記述ができるので、今回の用途にはぴったりじゃないかと。

てなわけで今回作成したのがこちら

Download: fumi2_sdl_build-0.0.1.tar.gz (4kb, tar+gz形式)

SDL のインストールだけでなく rake に興味ある人もどぞ。
ターゲットは MacOSX/Cygwin/Linux の 3種類。一応手元で動作確認済み。
まーご利用に際しては as is ということで。

posted by rerofumi

2009/3/19 木曜日 2:00:16

OpenPandora が延期しまくりもうすぐ(4月末くらい?)完成……しそうなところで、同じ OMAP の BeagleBoard でアップを始めることにした。
Linux動かすだけでもコツがあったり、というかわかりそうでやってみないとわかってないところがあって苦戦してみたり。

ただいま格闘中。