2008年5月15日木曜日

Xbeeの開発環境

東京ビックサイトで5/14-16で行われているESEC2008(組込システム開発技術展)にちょっとだけ用事があったので行ってきた。名前の通り、様々な組込系のボードや技術に関係しているベンダーがいろいろな製品やサービスを展示する展示会なんだが、いくつかのブースでは展示&会場限定で即売、みたいな事もやっていることがある。


Digiインターナショナルのブースをみてみたら、Xbeeの開発環境が会場限定で10000円とか書いてあったのでちょっと考えてから買ってしまった。Xbeeのモジュールが5枚と、Xbeeを刺すドーターボードが5枚、電源、ソフトウェアなど一式はいっているお大尽仕様だった。


普段は40000円(300USD)くらい。明日までやっているのでほしい人はいいチャンスかも!

2008年5月13日火曜日

OpenBSDでEmobile D02HWを使う(1)

縁あってOpenBSDの開発者の人たちと一緒にhackする機会があったので、なにかコントリビューションできることはないかなと考えたところ、OpenBSDの3Gモデムのサポートを拡張することにした。
特にD02HWは、本当の名前はE220といって世界各地で使われているメジャーなモデムなので、これがまともに使えるようになるとうれしい人がそれなりにいるだろうから、ちょうど良い。

OpenBSDもNetBSDと同様に、FreeBSD由来のUSBサブシステムを採用しているので、usbデバイスドライバは大きな差異は存在しない。NetBSD用につくったuhmodem(4)をそのまま移植するという手もあったのだけど、OpenBSDにはHSDPAモデム用のドライバとしてumsm(4)がすでに存在していたので、それを拡張する形で実装してみることにした。

umsm(4)(拡張前)
dev/usb/umsm.c(rev.1.21)を眺めてみると、非常にシンプルなドライバになっていた。具体的に言うと、

struct ucom_methods umsm_methods = {
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
};

となっていた。struct ucom_methods は、上位ドライバとなるucom(4)のopen/closeなどの各処理におけるデバイス依存コードへの関数ポインタを渡すための構造体なので、この状態ではシリアルに関する処理はucomでのデフォルト動作だけで実行されることを意味している。

どうしてこれで他のドライバが動作しているのだろうか?と「???」と思いながらざっくりとコードを追ってみたところ、シリアルデバイスのinterrupt endpointに関する処理がざっくりと抜け落ちていることに気がついた。単なるin/out endpointを処理するだけなら、確かにucom(4)における特別な処理は必要ないが、モデムで通信を行う際には自分から始めるだけではなく割り込み処理が必要である。
近くにいたOpenBSD開発者に聞いてみたら「おれが使っているE220で昔だれかが作ったパッチで試した見たところ、たしかにPPPまでは張れることもあるがうまく動かなかった。つながるけど切れたり通信できなかったりしてね。それから使ってない」と言われた。さもありなん、ということでinterrupt endpointの処理を拡張するところから始めることにする。D02HW(E220)以外でも役にたつだろう。

interrupt endpoint処理の追加

endpointの割り当て処理はumsm_attach()の中で行われる。data用のbulk in/out endpointしか処理していなかった部分を、以下のように変更する。また、struct umsm_softcにもinterrupt endpoint周りの状態を保持するための変数を拡張しておく。

if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN &&
UE_GET_XFERTYPE(ed->bmAttributes) == UE_INTERRUPT) {
sc->sc_intr_number = ed->bEndpointAddress;
sc->sc_isize = UGETW(ed->wMaxPacketSize);
DPRINTF(("%s: find interrupt endpoint for %s\n",
__func__, sc->sc_dev.dv_xname));
} else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN &&
UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK)
uca.bulkin = ed->bEndpointAddress;
else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_OUT &&
UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK)
uca.bulkout = ed->bEndpointAddress;


これで、interrupt endpointを持っているinterfaceがあったら、interrupt endpointを正しく扱うための準備ができる。

次に、ucomをopenしたときに検出したinterrupt endpointをucom割り込みとして利用するためのコードを追加しなければならない。まずucomをopenしたときにusb的にinterrupt endpointを登録するコード(usbd_open_pipe_intr()を呼ぶ)と、closeしたときに後始末(usbd_about_pipe() & usbd_close_pipe()を呼ぶ)をするデバイス依存の関数を追加する。それぞれubsa(4)から持ってきて、umsm_open(), umsm_close()ということにしておく。ucomがopen/closeされるタイミングで呼ばれるデバイス依存関数は、前述のstruct ucom_methodsで指定しておけばよい。

さらに割り込み発生時に呼び出されるデバイス依存関数とその補助関数として、同じくubsa(4)からumsm_intr(), umsm_get_status()を持ってくる。同様にstruct ucom_methodsに指定する。

これで、interrupt endpoint周りの処理は完了。普通のHSDPAモデムのDoCoMo A2502をつなげて試してPPPセッションが正しく張れるようになっていることを確認。とりあえずここまでで半分くらい終了。

ここまでのコードの差分は、OpenBSD CVSwebで確認できる。

次回のエントリーでは、D02HWのモード遷移のための関数の統合について書く予定。

2008年5月12日月曜日

背の低いUSBシリアル

ということで、ジャンパピンがでっぱってケースに入らないことがあるので、

ピンをはがしてワイヤハンダ付けして結線しなおし。
どうせ、設定決めたらいじらないし。

最近どうもコネタばかりだ。


2008年4月28日月曜日

PSoC書き込み器またまたあらわる

何度でもやるぞというくらいこのblogで出てくるネタとしてPSoCの書き込み方法がある。 mini-eval の丸ピンソケットをZIFにしてやれば書き込み器として使えるよねというアイデアは多くの人が提唱しているところではあるが、検索してみるとそれほど難しくなさそうだったのでやってみた。
簡単にいえば、秋月の28ピンZIFソケットをバラして、細いほうに組み直すという作業を行えばよい。ソケットをよく裏をみると内側にも2列穴があいていることに気づくはずだ。こちらにあわせてやればよいのだが、ソケットはナットではなくピンでとまっているのでこじあけなければならない。先の細い精密ドライバか割り箸のようなものをあてて、上からプラスチックハンマーで叩いてピンを外す。これで組み替えができるようになるので金具を左右いれかえてやる。そうすれば、無事に内側の穴から足のはえたZIFソケットができあがる。次の難関はどうやって元にもどすかだが、筒状のおさえがあれば、リングをささえて押し込むことが出来る。私が使ったのはノベルティのボールペンの先っぽ部分。分解して軸のほうの先をあて、穴のあいたところにピンの軸が入るようにしてやり、上からやはりプラハンで叩いて押し込む。


これで無事もとどおりになって、しかもスリム28pinのソケットに入るZIFが出来上がる。注意点としては、組み替えるときに上下逆さまではなく、金具を左右をいれかえなければひっかかりができずに使えないということだろう。参考となるページは多数あるようなので、詳しい写真などは他の人のブログを参考にして試してみればよいとおもう。これにより、先に書き込む中身が決まっているPSoCならストレスなしに書き込みが行える。簡単にいえばGainer互換チップを作るのに非常に重宝したというわけだ。

2008年4月12日土曜日

100ccで100g (転載というか移動)

知人がやっていたデジカメ連射があまりにも面白かったので、新しいデジカメとして EXILIM Z1080というすこし型落ちのモデルを手に入れた。連射性能と値段を考慮するとこれがベストの選択だろうということだ。

それまでは借り物の Cybershot DSC-T9という薄型ででっぱらないレンズのカメラを使っていたので最初の印象は「分厚いな」であり、手に持つと「軽いな」であった。二つをはかりにのせてみるとどちらもメモリとバッテリをいれて153gと159g だったので体感できるほどの差があるとは思えない。この差はなんだ?と思って思い出したのが10年以上前の学生時代に先生から聞いた一言だった。曰く「携帯電話ってのは 100g 100cc というのが一つの目標なんだよ」という言葉である。人間の体はほとんどが水分なので比重が1に達すると持ったときの違和感が薄れるということだそうだ。

この言葉を思い出してから、カタログを見ながら電卓をたたいてみるとまさにその通りの結果であった。

Casio Z1080  125cc 153g に対して Sony DSC-T9 は 159gで 85cc しかない。凝縮されている分だけ重く感じてしまうわけだ。

同じことを、以前使っていたレッツノートYシリーズから macbook air にかえたときにも思ったので、こちらも電卓をたたいてみることにした。ちなみに、重いと感じる macbook air が 1370g に対してLets note Y7 は 1510g なので140g すなわちケータイ1個分くらいはairのほうが軽い。それでもairを持った後にYを持つと「軽い!」と思う。

計算結果はというと macbook air はもっとも厚い部分がそのままスクエアで角をおとしていないという想定でもおよそ 1400ccであり、実質丸みをおびた分で8割程度しかないのではないだろうかと思われる。こうなると比重として 1をすこし超える程度となる。ある意味、重さと体積の黄金比でもあるわけで持ちあるくという意味での十分な比率にはなっていると思う。これに対して、レッツノートは十分に分厚い筐体のためか、最薄部分で考えても2100cc と、700ccも多く、比重を計算すると0.7程度と1を大きく下回っている。これが軽さを感じさせる理由であることは間違いなさそうだ。

重さを感じるのは最終的には脳なので、見た目も重さのうちということがよくわかる計算結果となった。それにしても、まだアナログ携帯電話の時代から比重の重要性を実感していた人たちはすごい。

--
(もともと別のblogに書いたものですが転載しました。)

2008年4月11日金曜日

Power Gainer  (またまたGainer 互換機)

Gainerを使ってブレッドボードで作品をつくると作品をブレッドボードのまま保存しないといけない。しかしながら、ブレッドボードだとパーツはともかく、配線がもげたりして、動かなくなりがちである。1作品に1個gainerを消費するのは耐えられないという貧乏性なのもありサーボのときもユニバーサル基板で簡単な回路を起こしたが、今度はトランジスタアレイを駆動することにしたボードを作ってみた。

このトランジスタアレイつきGainerならば小型モータくらいならそのまま動かすことができるので、power gainer と名付けてみた。こうやって作ってみた基板がこちら。これをコンフィグレーション3、4を使えば8ポートのアナログ出力をトランジスタでドライブした形で使うことができる。シンクドライバなのだが、論理の反転はトランジスタアレイがやるのでそのまま出力すれば問題なく、出力を変化させることができる。

実際には多チャンネルを外部から同時に利用するためには、トランジスタアレイに別途電源を用意しなければ、USB給電の限界が先にくることになるとはおもう。何に使うかはまだ決めていないが、最近のマイブームでは振動モータが熱いのでそれをPWMで複数駆動してみる予定である。

Gainerとrubyとtwitter (あるいはタンジブルなtwitter)

Gainerをコントロールするためのライブラリを探すと processingや Flashといった作者から提供されているものだけではないさまざまなライブラリが存在する。その中でも個人的に普段使う言語であるrubyのライブラリを発見したので、それを使ってみることにした。gainerでよく使っていたprocessingは基本的にディスプレイと一体化しているのでデーモンを作るのは困難であるが(とおもう)rubyならば簡単にバックグラウンドタスクで動かすことが出来る。さらにrubyの他のライブラリと同時に使うことでさまざまな処理を簡単に行うことができることも
、processingとの違いであろう。

processingを使うとグラフィックを簡単に表示できるので画面をつかったインタラクションを作るのには非常に向いているのであるが、今回のようなネットワークをつかったフロントエンドで、画面を必要としないようなものの場合には、rubyのほうがよいであろう。さらに、 C++のライブラリというのも見つけたので、組み込みマシンを使うならばそちらのほうがいいかもしれない。恐るべしgainer。
まあ、それはおいといて作ったものがこれ。ボタンをおすと twitterに「コーヒー飲みたい」みたいなメッセージを書き込む。ボタン2はランダムにfollowerを選択して「スゲー」と書き込む。
ruby-twitter のライブラリと gainer-rubyのおかげでとても簡単に書き上がった。回路はブレッドボードの上につくったがコンフィグレーション1のまま Din の4ポートにスイッチをつないだだけである。
一度かきこんだら1分以上たたないと書き込まないといった処理は追加してボタンの押し過ぎに対応しておく。こうやっておかないと無限にボタンを押して大変なことになることがある。

これだと単なるキーボードでよさそうだが、このままスイッチを人感センサーに変更すれば「部屋にひとがきた!」みたいなことをしゃべるtwitterを作ることも簡単だ。もちろん、コードを修正してアナログの入力をつかえば「部屋があついです」とかもね。

今回のコードは以下のとおり。動作環境は intel imac の leopard 上でデフォルトのrubyを使っている。gem で twitter (twitter4rではない) と gainer-ruby をインストールしておく必要があるので試してみる前にお忘れなく。ちなみに twitterは gemでそのまま入るが、 gainer-rubyは URLを指定してやる必要がある。



#!/usr/bin/ruby
#
# Twitter Button
#

require 'rubygems'

gem 'twitter'
require 'twitter'
gem 'gainer'
require 'gainer'

## setting for User account
id = "UserName"
pass = "password"

tc0 = Time.now - 80
tc1 = tc0
tc2 = tc0
tc3 = tc0
tcb = tc0

twit = Twitter::Base.new(id,pass)
gainer = Gainer::Serial.new(ARGV.shift)

puts "Ready.\n waiting buttun..."

gainer.on_pressed = proc do
puts 'Button pressed'
if (Time.now - tcb > 60 ) then
tcb = Time.now
fri = twit.followers()
fnum = fri.size
friend = fri[rand(fnum)].screen_name

puts "#{friend} SUGOI..."
twit.update("@#{friend} スゲー!w by XXX ")
end

end

loop do
sleep(0.1)
gainer.peek_digital_input

case gainer.digital_input[0]
when 1
puts "GET 1"
if (Time.now - tc0 > 60 ) then
tc0 = Time.now
puts "Give me COFFEE..."
twit.update("珈琲プリーズ だれかプリーズ")
end
when 2
puts "GET 2"
if (Time.now - tc1 > 60 ) then
tc1 = Time.now
# fri = twit.friends()
fri = twit.followers()
fnum = fri.size
friend = fri[rand(fnum)].screen_name

puts "#{friend} SUGOI..."
twit.update("@#{friend} スゲーョ!")
end
when 4
puts "GET 3"
if (Time.now - tc2 > 60 ) then
tc2 = Time.now
puts "I'm Sleepy..."
twit.update("ねむい中")
end
when 8
puts "GET 4"
if (Time.now - tc3 > 60 ) then
tc3 = Time.now
puts "Give me FOOODDDD..."
twit.update("はらへり、ヘリハラ")
end
else
## puts "NODATA"
end
end