2009年11月23日月曜日

MTM04 珈琲あります。飲みにきてね。

みなさまご無沙汰しております。
hwhack では春に引き続き、今回もMake Tokyo Meetingに参加...の予定だったのですが、2名いる著者が両方とも出張とバッティングしたため、今回は代理の方に参加をお願いしています。

今回の出し物は都内の某研究所で毎日稼働している Twitter対応型コーヒーメーカー「青山みすず」です。このコーヒーメーカーは珈琲を沸かした量とついだ回数を計測することで、あとどれくらい珈琲が残っているかを計れるようになってます。仕掛けなどの秘密は大岡山の会場で。入れ立て珈琲大サービスでお待ちしています!

PS. 特派員からの報告によれば、MTMではTwitter対応コーヒーメーカー三つ巴の戦いが繰り広げられている模様です。

2009年7月2日木曜日

E-mobile H12HW

E-mobileの電話型端末H12HWを試す機会が会ったのでOpenBSDでのデータ通信を試してみた。H12HWは型番が示すようにHUAWEI社の製品で3.6MbpsのHSDPAに対応している。

結果を共有。

準備

以下のようにsys/dev/usb/usbdevsにProduct ID 0x1008を追加して、usbdevs.hとusbdevs_data.hを再生成しておく。
  • product HUAWEI Mobile 0x1008 HUAWEI Mobile
あとはsys/dev/usb/umsm.cのデバイス情報の構造体であるstruct umsm_type umsm_devs[]に
  • {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_Mobile}, DEV_HUAWEI},
を追加してkernelをリコンパイルする。

結果

普通にumsm(4)のデバイスとして認識されて、pppdでppp接続も確立できた。

いまはopenbsdの次のリリースに向けた作業が進んでいるので、それが落ち着いた頃にopenbsdにはコミットしておく予定。


2009年6月22日月曜日

自作arduinoのための breadboard hack

lilypadのブートローダをつかえば、ブレッドボードでarduinoを組み立てるのは非常に簡単である。これをさらにonechip arduinoにしてしまうとブレッドボード上のパーツも非常に少なくなるので、小さなブレッドボード上にもかなりの回路をのせることが可能になるだろう。

しかしここで問題になるのは、ブレッドボード上においた AVRのチップのピンと、Arduinoのピンの対応がすぐにわからなくなることだ。何度もやって覚えてしまえればいいのだろうが、間違っていてはあまり意味もないことからこんなhackをやってみた。
ブレッドボードの裏にネットでみつけた ATmega と Arduinoのピン配列の対応表をそのまま貼付けておくだけである。対応図はいろんなところにあるので探してほしいが、たとえばこういうのである。

Make: blog本体ではこんなのが出ていた。この場合チップ単体で使うのならいいのだが、1chip arduinoをつくって部品をチップ上に盛ってしまった場合には下の文字が読めない。

これは undocumented 情報としてMake Tokyo Meeting 03 で初お披露目したのだが、なかなかウケたのでエントリーにもしておくことにする。



UNIX系OS用UQ wimaxドライバの作成(1)

MTM3が終わってから、今度は2週間ちょっとの出張がはいってしまってなかなかblogを書く時間をとれなかったが、いつまでも「MTM3参加中」のエントリがトップなのも寂しいので、最近のwimax関係のアップデートを書いてみる。


UQ Wimax解析の状況

GCT720X系のチップセットを使っているインターフェイス(UD01SSとかUD01OK)の解析はほぼ完了した。要素としては大きく分けると、
  • データ通信系(Ethernetフレームを交換する部分)
  • 認証系(EAPパケットを処理して通信に必要な鍵を生成する部分)
  • ネットワークエントリ系(認証系に加えてwimaxネットワークに参加する部分)
  • データストア系(加入者識別子、パスワード、デバイスのX509証明書の処理)
  • 管理系(通信状態把握、パラメータ設定)
くらいに分類される。通信に必要なのは最初のデータ通信系の機能だけだが、そこに至るために残りの部分を攻略しなければならかった。「データストア系」はネットワークに接続するために必須の部分であるのに関わらずまったく仕様が公開されていないため、比較的時間を費やしてしまった。

動作検証コード

解析結果はすべてOpenBSD上で検証コードを作成して、実際の動作を確認した。
未知のデバイスのドライバをカーネルドライバとしていきなり実装するのは開発効率が悪すぎる。今回は、ずいぶん前に「ugenでラピッドプロトタイピング(*BSDでUSB)」で書いたようにugen(4)を利用してユーザーランドで実装してみた。さらに、ethernetインターフェイスへのアクセスにもtuntap仮想インターフェイス(tun(4))を用いてユーザランドドライバとして実現した。
ugen(4)を用いてUSBバスをユーザランドドライバに見せたうえで、データフレームをtun(4)でカーネルに挿入するアプリケーションをかけば、実質上ユーザーランドだけでデバイスドライバを書くことができる。
この「ユーザランド」ドライバの構造(概略)を右図に示す。簡略化のために一個のプロセスで全部入りでつくったが、検証用には十分だろう。
機能としては、Wimaxのネットワークをスキャンして、UQ Wimax決めうちで接続処理を行う。デバイスから必要な情報を引きずり出して、認証機構がEAP-TTLS/MSCHAPv2でWimax-PKMv2を処理してログイン&鍵対の生成を行っている。
うまくつながれば、あとはugen(4)とtun(4)をブリッジしてEthernetインターフェイスとして動いてくれる。普通にDHCPでアドレスをもらって通信できるところまでは動作確認済みだ。
あ、あと、Ethernetブリッジしているのにtapじゃないのは、OpenBSDではtapがtun(4)に統合されているから。tunをLayer2モードで駆動している。

ユーザランドドライバの副次的な効果として「移植性の高さ」がある。たぶん、ほとんど変更しなくてもbsd系のOSでは動くだろうし、ugen(4)をlibusbかなにかに置き換えればOSXやlinuxでも動いちゃうんじゃないかなと予想している。だれかやってみないかな。
ソースは公開する予定だけど、作業の優先順位は要望によって変わります。

今後の予定

ちょっと落ち着いてきたので、解析結果のまとめをつらつらとblogに書きながら、(途中になっている)kernelドライバの作成をやってみようとおもっている。
変なNDAに縛られちゃう前に、知っていることは公知にしておくといいよね?

2009年5月23日土曜日

Make Tokyo Meeting 03 参加中


表題のとおり 今日からはじまったMake Tokyo Meeting 03 に本blogはhwhack.blogspot.com というまんまの名前で参加しています。本日も多数の訪問者ありがとうございました。

blogでは語れないあんなことやこんなこと、中の人の素顔、途中経過がわからなくなったプロジェクトの進捗など知りたいことがあればぜひおこし下さい。
One Chip Arduinoや USB BlinkM などわかりやすい展示品も取り揃えてあります。

体育館はいってすぐ、blog同様のとってもカオスなブースでお待ちしています。

2009年5月14日木曜日

UQ Wi-Fi Gatewayのバッテリ駆動


(念のために書いておきますが本記述は無保証です。バッテリ系はいろいろと危険があるのでよい子・良い大人の方々はまねをしないでくださいね)

UQ WimaxのWi-FI GatewayのWifiアクセスポイント側(UG01OK)のバッテリを入れる場所を眺めていたら、手元にあったクティオのバッテリがぴったりはいるような気がしてきたので試しにいれてみた。なんかぴったりはいります。ふたも閉まります。ふむ。

おそるおそる電源をいれてみると、うごくっぽい。
電源LEDもつきます。ACアダプタをつなげると「battery」LEDも点灯。充電もしてくれるっぽい。

すぐに切ったのでどのくらい使えるかは調べていませんが、3.7V 1900mAHしかないのであんまり持たないと思います。



OpenBSDでSoftbank C01SWを使う

週末に海外の見知らぬ人から「(俺の)sierra wirelessのHSDPAモデムがopenbsdで使えないんだけど」というメールが届いた。ちょうど他の作業で煮詰まっていたので息抜きに何通かメールをやりとりして、OpenBSDのumsm(4)で動くパッチを作ってみた。先方曰く「ちゃんと動いた!」と報告してくれたが、手元に無いデバイスなので不安は残る。ふと思い立ってgoogleするとSoftBankモバイルのC01SWはSierra wirelessのOEM製品らしい。周りを少し見渡すと持っている人が見つかったので、実際にためしてみた。


Tru-install

C01SWはsierra wirelessの「Tru-install」という機能を搭載している。これは、他の3Gモデムでもよくある「普段はUSBマスストレージのデバイスとしてみえて、そこにデバイスドライバがはいってる。そのデバイスドライバをつかってモデムモードに切り替える」という機能だ。windows以外ではあんまり便利ではないし、自分でモードを切り替えてあげないといけない。

Tru-installのモード変更方法

もうこの手の話は何回もしているので、簡潔にモード変更方法を書いておく。
  • USB requestType = Write/Vendor/Device
  • USB request = 0x0b
  • USB request wValue, wIndex, wLength = 0x1, 0, 0
というコントロールリクエストをデバイスに送ると、デバイスがUSBバスから切り離されて再度認識されたときにはモデムデバイス+マスストレージデバイスの複合デバイスに変化している。上記に対応する関数を抜粋すると、こんな感じ。


#define TRUINSTALL_CHANGEMODE_REQUEST 0x0b
usbd_status
umsm_truinstall_changemode(usbd_device_handle dev)
{
usb_device_request_t req;
usbd_status err;
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
req.bRequest = TRUINSTALL_CHANGEMODE_REQUEST;
USETW(req.wValue, 0x1);
USETW(req.wIndex, 0);
USETW(req.wLength, 0);

err = usbd_do_request(dev, &req, 0);
if (err)
return (EIO);
return (0);
}


umsm.cに対する変更の全体はCVSで参照できる。

あと、OpenBSDではsys/dev/usb/usbdevsにこのデバイス用のProduct IDを追加しなければならなった。これは追ってコミットしておく。

C01SW概略

アタッチしてみてちょっと驚いたのはインターフェイスが7本出現したことだ。一般に3Gモデムは複数(2−3本)のインターフェイスを用意しているが7本出てきたのは初めてだった。
USBディスクリプタを見ると4-7本目のインターフェイスはインタラプトエンドポイントを含んでいるのでこれらのどれかが通信用のポートのはずだ。上から試してみたところ、4本目が通信用のポートだった。5−7本目のポートはエコーバックされないがATコマンドに反応しているので何らかの管理ポートだと推測される(詳細は見ていない)。

C01SWで通信する

OpenBSDのkernel ppp実装のpppdを使って通信を試みたところ、さっくりとつながった。
設定は昔「NetBSDでEmobile D02HWを使う(設定編)」で書いた物とほとんど同じで、
  • ifconfig ppp0 create でpppインターフェイスを作る
  • /etc/ppp/peers/に対応する設定ファイル(たとえばsoftbank )を作ってttyU3を通信ポートに設定する
  • ソフトバンク用のユーザIDとパスワードを/etc/ppp/chap-secretに書いておく
だけだった。pppd call softbankだけでpppがつながって通信できた。


2009年5月12日火曜日

E-mobile D12HWとD22HW

E-mobileの最近のモデムを触ってみる機会があったのですこし調べてみた。結果を共有。


触ったのはD12HWD22HWで両方ともHUAWEIのOEM製品だ。D22HWはHSUPAでアップリンクが最大1.4Mbpsまで使えるというのが特徴らしい。

OpenBSDで試してみる

HUAWEIの多くのモデムは同じUSBベンダIDとプロダクトIDを共有しているが、今回もその例に漏れず同じIDを利用していた。OpenBSDで試してみたところ、両者とも標準的なHUAWEIプロトコルでUSBマスストレージモードからモデムモードに遷移するようだ。umsm(4)としてデバイスは認識される。pppd経由でネットワーク接続もできたようなので何の工夫もせずに普通につかえる。

メモ:D12HW

D12HWに関してはUSBのディスクリプタの文字列が壊れている部分がある。利用する分には問題はないがUSBディスクリプタの文字列を信用してデバイス認識時に画面に出力してしまうとなんだかよくわからない文字列が表示されてしまうかもしれない。
しょうがないのでOpenBSDではディスクリプタ中の文字列を信用せずにusbdevsの中の文字列を利用するようにUSB_QUIRKS: UQ_NO_STRINGSを設定しておいた。本来はD12HWだけでこのquirksが使われるようにすべきだがみんな同じベンダIDとプロダクトIDを持っているのでほとんど全部のHUAWEIモデムにこのquriksが適用されてしまっている。


2009年5月10日日曜日

UQ WimaxのUD01SS解析 (4)

前回の続き。

一行まとめ「UD01SSの内部コンソールを取得する」話。

OKIネットワークスが出しているUD01OKの解析をしてみたところ、同じGCTセミコンダクタのGDM72XXを使っている製品なら、ほぼUD01SSと同様な構成になっているのではないかと予測を立てることができた。たぶんGCTセミコンダクタが提供するファームウェアおよびデバイスドライバのSDKがLinuxをベースとしたものになっているのだろう。ということで、今後もGDM72XXを使う製品が出るのなら今回の一連の解析も役に立つだろう、ということでよりディープなところもまとめてみたいと思う。

このエントリではUQのUD01SS(やUD01OKなどのGDM72XXベースのWimaxインターフェイス)内で動いている「Wimaxアプリケーション」の操作コンソールについて説明する。

UD01SSの内部ではLinuxが動いている、というのは(1)で 書いた。汎用OSであるLinuxをファームウェアとして利用している以上、カーネル内部だけではなくユーザランドでも何らかのアプリケーションが動いて いるのは当然だ。解析を進めている途中で、そのアプリケーションと対話的に通信していろいろな情報を取得できるようになった。右にWimaxアプリケーションのコマンド一覧(helpコマンドの出力)を載せる(長いので画面キャプチャ形式)


UD01SSの内部アプリケーション:/usr/wimax

UD01SSのユーザランドとしてWimax関連で動いているのは/usr/wimaxコマンドである。このコマンドがGDM72XXのいろいろな要素(内部の別プロセッサとかで動いているプロセスとか)と通信しながら、ホストインターフェイスを提供している。
ホストPC側にWimaxインターフェイスとしての機能をUSBバスを経由して見せているのもこのアプリケーションで、ホスト側からのコマンドはこのアプリケーションが処理している。さらに管理用の対話的コンソールも提供されている。対話的コンソールが受理するコマンド一覧を上の図に示した。使い方はまだわからないことも多いがUD01SS内部で処理しているWimax関連の機能の内部状態を見ることができるので大変便利だ。
右図の画面ダンプはparamコマンドの出力例(mac addressは隠してある)だ。paramコマンドはデバイスの設定パラメータをダンプしてくれる。Wimaxの物理層まで興味があれば役に立つこともあるかもしれない。
ヘルプ画面にあるshellコマンドは興味深い。/bin/shを立ち上げて(fork & exec)内部のlinuxに対するshellアクセスを提供してくれるはずだが、子プロセスとしてのshellはUSBバスに対する通信機構を持っていないのでこの方法でのアクセスでは使えない。大変残念だがUSB経由(wimaxアプリケーションを経由)のshell取得は原理上無理があるようだ。

Wimaxアプリケーションのコンソールでできること

できることは大体以下の通り。

  • 対話的にコマンドを発行してレスポンスを受け取る。たとえば「version」「param」「dump」コマンドはいろいろな内部状態を出力する。
  • 対話的にコマンドを発行して動作モードを変える。(詳細は不明)
  • メモリ状態などを読み込む(詳細は不明)。発行してもハングアップしてしまう場合が多い。
  • 「log on wimax」コマンドを発行すると、非同期メッセージを受け取れるようになる。たとえば、内部の状態遷移に付随して発生する様々なメッセージを受信できる。さらに「sc」「nds」コマンドでデバグメッセージを出力させることで、もっといろいろなことを教えてくれるようになる。
最後の機能は非常に強力だ。単純なUSBバス解析だとバイナリ列の{コマンド,レスポンス}の組を統計的に解析していって意味を抽出する作業が必要になるが、コマンドに対して人間が読める形のレスポンスや状態遷移のタイミングを取得できればシステマチックな解析が可能になる。

取得できる出力の例
2009/4月のファームウェアアップデート後のUD01SSのVersion

DM> version
version 0.3.8.0 (00030800)
DM> dump ver
FW : Rev=1.6.6.4, 2009/04/03 18:18:00 (build: 2009/04/06 16:58:33)
RF : srf72xx-081025(72050227,0), Default
CFG: PHY=0x602, SPEC=204, CPU=3, SD_AFC, UPT, DNT, ARQ2, IPC, FREQ2.5G, SAMSUNG
MAP: 2009-03-24-1613-WAVE2

ほかにも接続状況なども取得できるが、それらは今後対応した操作を説明するときに説明しようと思う。

アクセス方法(概略)

Wimaxアプリケーションのコンソールに対するアクセス方法の概略を載せておく。詳細はGDM72XX系のコマンド体系をまとめるときに補足する。

GDM72XXのコマンドは、大体
  • 2バイトのヘッダ(Command/Response Type)
  • 2バイトのペイロード長(データ部分だけ。ヘッダ部分は含まない)
  • データ
のTLV形式で定義されている。(USBなのでビッグエンディアン)
コンソールに対するデータ送信は、Type:0x030cで、送信したい文字列に"\n\0"文字をつけてデータとして送信する。
受信は非同期メッセージを扱う場合はちょっと複雑だが、普段はType:0x830dのデータの9バイト目から文字列として扱えばよい。継続行がある場合は文字列の最後が非NULL文字になるので、文字列の最後がNULL文字になるまで繰り返し読み込めば複数行のレスポンスも取得できる。

いまはとりあえずopenbsdのugenで書いたユーザランドアプリケーションで実験をしている。プログラムの長さで3-4KBくらい。もしUD01SSとかで遊びたい人がいたら適当に声をかけてほしい(一人だと飽きそう)。

次回

次回のエントリでは、GDM72XXのコマンド体系について説明しようとおもう。認証部分はそのあとになる予定。

2009年5月9日土曜日

ブレッドボード/arduino用のお手軽ケーブル加工



yuoがまたUSBデバイスの解析という大ネタを連載しているので、その合間にcueのほうは電子工作関連のコネタをひとつ。

パーツをブレッドボードやarduinoに刺すときに、しっかりとした足がついているLEDなどはよいが、センサーなどのようにケーブルを介して接続する必要がある場合には、そのケーブルをどうやってブレッドボードに刺すかを考える必要がある。

よくやる手としてはケーブルをピンヘッダにハンダ付けをするというのだが、これでは量産が効かないし、出来上がりが不揃いになってしまう。四角いピンのピンヘッダはブレッドボードへの刺さりがキツいし、丸ピンのヘッダはピンが細すぎてブレッドボードにはいいが、arduinoなどのピンソケットにはすこし緩い。

そこでちょうどいい太さで先端がピンに
なった圧着端子を探していた。なかなかちょうどよいものがなかったのだが、yuoとアキバを探し歩いた結果、VGAコネクタなどに使うシュリンクDSUB用のピンがちょうどいいのじゃないかという結論に達したので紹介しておく。
千石通商で売られているシュリンクDSUB用のコンタクトピンは5本単位で売られている。CUEは田舎に住んでいて交通費を考えると必要数だけ毎回買うの
も無駄なので100本パックを買っている。このとき 「シュリンク(細い方)」DSUBの「オス」を入手する必要がある。写真とおなじものを手にいれれば間違いないだろう。
千石通商の1Fにほかの端子とともにおいてあるはずだ。残念ながら通販ではシュリンクではないDSUB用のピンしか扱っていないようだ。ちなみにRS232Cなどに使う普通のDSUB用のピンは太すぎてブレッドボードに刺さらない。

これを1本づつ切り取ってケーブルに圧着するだけである。小信号用の圧着端子と同じで、エンジニア社の精密圧着ペンチで加工すればよい。ケーブルはAWG26より細いものがよいだろう。

そして圧着部の保護と絶縁のために熱収縮チューブでくるんで完成である。上手に圧着できれば、サンハヤトの高級なほうの柔らかいジャンパーケーブルのような出来映えになるはずだ。

arduinoとブレッドボードがカジュアル電子工作の主戦場になってきた今日この頃、このピンの価値は計り知れないと思う。ちなみに、arduino(FIO)に刺すとこんなかんじになる。

このピンの問題は、ちょうどいい100milピッチのハウジングがないところではあるが、1本単位でバラバラでもよい用途では非常に便利にかつ美しくケーブルを作ることが出来るのでおすすめである。

UQ WimaxのUD01OK(Wi-Fi Gateway)解析

UQ Wimaxが先日からモニターを開始したUQ Wi-Fi GatewayのWimax通信モジュールであるUD01OKを触る機会があったのでちょっと解析してみた。(モニタ募集は例によって外れた)
UQ WimaxのUD01SS解析 (1)も参照するといいかも。

このエントリの一行まとめ「UD01OKとUD01SSは98%くらい互換デバイス」。

UD01OKの概略

UQのモニタ(と少数の購入ユーザ)に対するWimaxの試験運用が始まってしばらくたつが、よく聞こえてくる感想が「屋外はいいけど、屋内じゃ通じない」「窓際ならいけるが、ちょっと遠ざかるとだめ」といった遮蔽物に対する弱さだ。というわけでこのWi-Fi Gatewayは「Wimaxがつながる窓際まではWimaxで、それ以降は802.11無線LANでつなげてやろう」という製品だ(ほかにも、複数クライアントで同時に利用とかもあるけど、まあどうでもいい)。株式会社OKIネットワークスが製造販売している。
Wi-Fi GatewayはUSB接続にWimax通信モジュールと、それをつなげる無線LANアクセスポイントで構成されていて、Wimax通信モジュール自体はWindowsPCに直接接続して利用することもできるようになっている。この通信モジュールがUD01OKだ。

UD01OKも、最近よくあるUSBの通信モジュールと同様に「ゼロインストール」機能が搭載されていて、最初はUSBマスストレージデバイス(CDROM)にみえてその中に必要なドライバが含まれている。Windowsで利用する際にはそのドライバとユーティリティアプリケーションが必要になる。

UD01OKのハードウェア仕様

USBのデバイスディスクリプタをダンプしてみたところ、UD01SSと同様にGCTセミコンダクタが開発した1チップのWimax SoCであるGDM7205を使っていた。また、Windowsドライバをインストールしてディレクトリを見たところ、ドライバもおおむねUD01SSと同じだった(UD01SSほど無防備かつフリーダムではなくて、ちゃんときれいに整理されていたが)。両社ともGCTから提供されたSDKを用いてドライバを書いていると推測される。

USBマスストレージデバイスからWimaxインターフェイスに動作モードを切り替えるコマンドも同じものが使えた。ざっと見ただけだが、その他USB上での操作コマンド群もUD01SSと同一だと思われる。

UD01OKとUD01SSのドライバは競合

ハードウェア構成がほぼ同一で、ドライバも同等のSDKによって構成されているためか、UD01SSをサポートするためのWindowsサービスとUD01OK用のサービスは競合してしまう。両方同時に使う人はほぼ皆無だと思うがUD01SSをインストールしてあったPCにUD01OKのドライバがインストールできずに一時間ほど悩んでしまった。

相違点・共通点

  • USBのベンダIDとプロダクトIDが異なることくらいでハードウェアとファームウェア構成は大体同じ
  • ユーザIDとパスワードを入れているNVRAMの中の情報がちょっと違う
  • NVRAMの中身のひねり方は共通
  • ドライバの見栄え的な出来や完成度はUD01OKのほうがよさそう
  • 無線デバイスとしての感度もUD01OKがよさそう
  • 大きさはUD01OKがUD01SSより体積比で2倍くらい
  • ファームウェアは両方ともLinux(version 2.6.12-uc0) 
まとめ

というわけで、UD01OKに関してもUD01SSの解析結果を参照するとよいはず。

あと、GCTのチップセット使っているWimaxモジュールは大体みんな一緒かもしれない、と予想できるので解析結果が無駄にならなさそうでほっとした。

2009年5月5日火曜日

UQ WimaxのUD01SS解析 (3)

(2009/5/7 認証フローの図を追加)

前回の続き。
UQのUSB型mobile wimaxインターフェイスであるUD01SSの解析メモ(3)。
今回は「どうやってWimaxネットワークに接続するか?」を説明。

  • 「Linuxとか*BSDでUQ Wimaxを使うのはちょっと敷居が高いので、どう越えるか?」
のバックグラウンドになるかな。

Mobile Wimaxの概略

Mobile Wimaxは下の仕様がIEEE802.16eおよびIEEE802.16-2004として規定され、運用などのルールがWimax Forumによって規定されている中・広域の無線アクセス技術である。802.11シリーズの無線LANと同様にIPベースの通信を前提としたアーキテクチャを持っており、高いコストパフォーマンスと相互運用性といった特徴を持っている。

ユーザからみると、「PCに挿せば動く家の外でも使える無線LAN」として動くことが期待されているわけだが、802.11よりも「セキュリティ」や「認証」といった点で気を使わなければならない点も多い。UQ wimax (Wimax forum Wave2)ではそのあたりをどのようにクリアしているのかをちょっとだけ説明しておく。

Mobile Wimaxネットワークへのログイン

カギとなるのは「認証」である。UQのネットワーク(もしくはUQからMVNOしたキャリアのネットワーク)を利用するためには以下の2つの認証を越えなければならない。
  1. デバイス認証(およびネットワーク認証)
  2. ユーザ認証
前者はそのデバイスがWimaxフォーラムの認証を通っているデバイスなのかを検証し、接続してもよいデバイスかを判断するために利用される。それぞれのMobile WimaxデバイスはX.509の証明書を持っている。証明書はデバイスのMACアドレスをWimaxフォーラムの認証局(CA)でサインしたもので、MACアドレスの詐称を防いでいる。これはWimaxフォーラムで規定されており、EAP-TLSを用いてX.509証明書を相互に交換することで相互認証を行う。

後者は課金のために必要な認証。契約者のIDと認証情報を使って、ネットワークにログインするために必要になる。Wimaxフォーラムでは前者のデバイス認証の結果でネットワークへのログイン処理を行うことも許容しているが、UQではMVNOの一部でAAA(認証)サーバ自体も外部にある設定を仮定しているので、ユーザ認証として独立した認証が必要になる。UQではEAP-TTLSを用いた暗号通信路の上にMS-CHAPv2を使ったuser/passwd認証を行っている。

UQの専用アプリケーションの役割

UQではネットワークに接続する際に専用のユーティリティソフトウェアが必要となるが、このソフトウェアの役割の一つは後者の「ユーザ認証」手続きだ。EAP-TTLS/MS-CHAPv2自体は標準化されたプロトコルなので、UQ全体で一つのアプリケーションで済むんじゃないか?みたいな話を聞いたこともあるが、実はそれは難しい。なぜかというと、各デバイス毎に「ユーザ情報(ID/Pass)」やWimaxの基地局からのEAPトランザクションを扱う方法が異なっているからだ。デバイス依存の差異を吸収する仕組みが存在しない現在では各ベンダ毎が自分のデバイスを扱うユーティリティを提供するしかない、という判断なんだろうと理解している。

UD01SSの認証関連機能

UD01SSでは、Wimaxデバイス認証を外部アプリケーションの助けを借りずに行える。つまりデバイス単体でEAP-TLSの確立および証明書の交換、検証、承認が可能で、外からコマンドを送るだけで自動的に進めてくれる。

ユーザ認証部分はちょっと複雑だ。
UQでは利用者にIDやパスワードを管理させずに「Wimaxインターフェイスをさすだけで使える」運用方法を採用している。そのため、UQネットワーク にログインするためのユーザIDおよびパスワードはデバイス内部のNVRAM領域に保存され、ユーザには見えないように隠ぺいされている。これが複雑さの原因だ。
ユーザ認証機構はWimaxデバイスの外部の「ユーティリティアプリケーション」に存在している。そのためUD01SSではユーザ認証のためのEAPトランザクションをUSBバスを通してホストPCにリレーすることでWimaxの認証サーバ(AAAサーバ)とホスト側の「ユーティリティアプリケーション」間の通信を確立させる。ホスト側のユーティリティアプリケーションはリレーされたEAPトランザクションを解釈してEAP-TTLSトンネルを確立したあとに、「ユーザIDとパスワード」を用いて認証を進める。デバイス証明書やユーザIDなどの情報はデバイス毎に異なるため、UD01SSではNVRAM領域に記録してあるらしい。ユーティリティアプリケーションはNVRAMからデータを読み取って処理を進めている。

認証がうまくいった後

EAPでの認証が成功すると、Wimaxネットワークはそのデバイスが網につながることを許可してくれる。
EAPトンネルはこの時点で破棄してもかまわない。WimaxのPKMの残りの部分はUD01SSの内部で処理されてユーザ側にはその成功・失敗しか通知されない(この辺はまだちゃんと実際に試したわけではないのでぬけがあるかも)。
(2009/5/13補足):ユーティリティアプリケーションのEAPセッションからUD01SS内部のPKMの処理に引き継ぐためにMSK(マスターセッションキー)をデバイス側に引き渡す必要がある。

あとはUD01SSは比較的簡単なEthernetインターフェイスに見える。EthernetフレームがUSBバス上に見えるようになるので、DHCPを行ってIPアドレスを取得して通信を進めることになる。Wimax特有の部分は全部UD01SS側でやってくれるので、ホスト側でやることはほとんどない。この辺はデバイスドライバを書いてみようと思うときには非常に都合がよいところだ。

なんか嬉しくない話

が、いい話ばかりではなかった。
UD01SSでは証明書やユーザIDなどはNVRAM領域に記録されている。が、読んでもすぐにはわからない形式でひねってあり、USBバス上でもその状態でデータが交換されるため、専用のユーティリティアプリケーションでなければ内容を確認することはできない。
つまり
  • NVRAM領域の読み方がわからなければ、正規に提供されているOS以外でのUQ Wimaxネットワークの(マットウな方法での)利用は絶望的
である。それはあんまり嬉しくない。
というわけで、そいつをどうやってやっつけようか?という話になるのだが、しばらくがんばってみたところなんとなく復元する方法を作り出すことに成功した。

次回は、その辺の解析の話につながる部分を書いてみる予定。

UQ WimaxのUD01SS解析 (2)

前回の続き。
UQのUSB型mobile wimaxインターフェイスであるUD01SSの解析メモ。

UD01SSのファームウェア(Linux)を覗く

UD01SSは前回も書いたようにLinux(正確にはuclinux)をファームウェアとして利用している。普通に使っていると「なんか認識まで時間がかかるなあ」と思うが、これも裏でlinuxがブートして頑張っていると思うとちょっとは許せてしまうかもしれない。

今回のエントリでは、FirmwareUpdateとして配布されているUD01SSの内部のファイルシステムを覗いてみる方法を紹介する。

Windowsの場合はProgram Files\UQ\UD01SS\FirmwareUpdate\というディレクトリの下にzImageとramdisk.jffs2が配置されている(OSXの場合はまた別の場所。適当に探してほしい)。zImageが圧縮されたlinuxカーネル本体で、ramdisk.jffs2がUD01SSのフラッシュメモリに書き込まれているルートファイルシステム以下のユーザランドファイルシステムだ。kernelの解析はまたにしておいて、わかりやすいramdisk.jffs2を見てみることにする。

jffs2はlinux(とくに組み込み系)で利用されているファイルシステム形式でフラッシメモリに対する書き込みイメージとして利用される。これを普通のPCで動いているLinuxでマウントして見るためには、以下のような手続きが必要だ。ここでは手元のlinuxはi386系で動いていることを仮定しておく。

問題はUD01SSがARMでファイルシステムのそれに合わせて構成されていることだ。エンディアンを変換してあげないとi386のPCではマウントできない。jffs2のイメージの操作にはmtd-toolsというユーティリティを使えばよい。適当に手順を書くと、


  1. linuxホストにramdisk.jffs2を持ってくる

  2. apt-get instlal mtd-toolsなどでmtd-toolsをインストールする

  3. インストールしたツールでエンディアンをリトルエンディアンに変換する。
    • jffs2dump -v -b -e ramdisk-le.jffs2 ramdisk.jffs2

  4. 必要なカーネルモジュールをロードする。
    • sudo modprobe jffs2
    • sudo modprobe mtdblock

  5. ループバックファイルシステムとしてマウントする。
    • sudo losetup /dev/loop0 ramdisk-le.jffs2

    • sudo modprobe block2mtd block2mtd=/dev/loop0,16384

    • sudo mount -t jffs2 -o ro /dev/mtdblock0 /mnt
これで/mntの下にUD01SSのファイルシステムが見えるようになる。

UD01SSのファイルシステム概略

細かいことまで見たい人はぜひ自分で覗いてみてほしいが、ざっくりとしたところをメモとして書いておく。
  • ユーザーはrootだけ(パスワードはちゃんと付いている)
  • ユーザランドバイナリはbusybox化されている。shもある。
  • メインアプリケーションは/usr/wimaxコマンドらしい。たぶんこれがもう一つのOSで動いているタスク群と通信している。


UD01SSのカーネルイメージ

本当はzImageもばらしたほうがいいが、だいぶめんどさいのでgzipで圧縮された場所を引っ張り出してstringsしたくらいで満足してしまった。だれか挑戦した人がいたら詳細を教えてくれるとうれしいかも。

次回のエントリではWimaxインターフェイスとしての基本動作を書いてみる予定。

2009年5月4日月曜日

UQ WimaxのUD01SS解析 (1)

すこし前だがUQ wimaxが関東圏で商業サービス開始を目前に利用モニターを募集していた。あいにく機材を含めた無料モニターには当たらなかったが、ちょっと興味があったので自前でwimaxインターフェイスを購入してしばらく遊んでみた。購入したのはUD01SSというUSBドングル型のインターフェイス。というわけで、その結果を備忘録としてまとめておこうと思う。

UD01SSの概略
UD01SSは韓国のMODACOM社の製品(日本ではシンセイコーポレーションがOEMで販売)で、韓国ではWibro用として販売されているもの(たぶんMW-U2500と一緒なんではないかと推測)だ。WimaxフォーラムのWave2に適応しているのでUQが提供するネットワークと互換性がある。中身はGCTセミコンダクタが開発した1チップのWimax SoCであるGDM7205が使われている。GDM7205はCPUとWimax Mac, PHYが集積されており1チップで必要な機能を全部提供できる、とのこと。

と、これくらいがWebで調べてみてわかることなんだが、あまり面白くない。わざわざ購入してまで調べてみようと思ったのはもう少し面白い特徴があったからだ。UD01SSで面白いと思ったのは、

  • GDM7205はARM926EJと補助CPU(アーキテクチャ不明)が搭載されている
  • UD01SSの内部OSはLinuxと補助CPUで動くリアルタイムOS(詳細不明)で動いている
  • ソフトウェアでUSBクライアントとして動いているのでUSBデバイスとしての構造は比較的簡単
といったあたりだ。とくに、「中身がLinuxで動いているUSBドングルタイプのARMのボード」が12800円っていうだけでなんかほしくなってしまったのでつい買ってしまった、というのが本音かもしれない。

UD01SSの動作モード

最近よくあるUSBのHSDPAモデムなどと同様に、UD01SSもデバイスドライバが存在しないOSでは自身をUSBマスストレージデバイス(CDROM)に見せかけるようになっている。専用のデバイスドライバがインストールされたあとには特別なコマンドを発行してデバイスのモードをWimaxインターフェイスに切り替える。
最初はUSBのVendor ID:0x1076, Product ID:0x7f40のデバイスとして見えているが、モードが変換されると、Vendor ID:0x1eb8, Product ID:0x1240に化ける。
モード変更コマンドは、右の図のようなUSBパケットを生成して送り込めばよい。デバイスがリセットされて新しいVID/PIDをもったデバイスとして再度バスに出現する。

UD01SSのLinuxファイルシステム

内部がLinuxということは別に隠されているわけではない(宣伝しているわけでもないようだけど)。UD01SSのアプリケーションがインストールされると、Windowsの場合はProgram Files\UQ\UD01SS\FirmwareUpdateというディレクトリが作成される。その中身は
  • ramdisk.jffs2
  • zImage
になっていて中身のカーネルとファイルシステムを覗くことができる。

次のエントリーでこれらを覗いてみる方法を書いてみる予定。

2009年4月26日日曜日

E-mobile D21LCをOpenBSDで使う

少し前の話だがE-mobileのD21LCをしばらく借りることができたので、少し解析してOpenBSDで使えるようにしてみた。その時の話をメモとして残しておくことにする。

D21LCは中国のLongcheer社製のHSDPAモデムだ。E-mobileでは最初はHuawei社のモデムを使っていたが、しばらく前から2社の製品を投入している。D21LCも他のE-mobileのモデムと同様に「ゼロインストール」機能が搭載されている。ゼロインストールとはドライバが入っていないOS(つまり初回挿入時)にはモデムをUSBマスストレージデバイスとして認識させて必要なドライバをモデムから直接インストールさせる仕組みである。ドライバが動き始めると、そのドライバがモデムのモードを変更してモデムとして動作するようになる。Windowsなどからは大変便利な機能であるが、ほかのOSで使うためにはちょっとおせっかいだ。

Huawei社のモデムはメモ:D02HW解析で昔書いたように特別なUSBコマンドを発行すると、USBマスストレージモードからモデムモードに動作モードが切り替わった。D21LCの場合はどうだろうか?

D21LC:モデムモードへの切り替え

USBアナライザでUSBトランザクションをモニタしてみると、あるタイミングでデバイスがリセットされるタイミングがあった。これがモデムモードへの切り替えコマンドだろうと推測してもう少し中身を眺めてみる。


D21LCのモード変更コマンドはUSBマスストレージデバイスに対するコマンドとして実装されていた。(コマンドパケットの先頭の0x55 0x53 0x42 0x43:USBCが規定のマジックナンバー)といっても、USBマスストレージデバイスの仕様には定義されていない独自コマンドを発行している。
さらにモデムの動作を眺めてみたが、それ以降は普通の3Gモデムと同様の動作をしているようだ。
というわけで、このシーケンスを発行するようにデバイスドライバを拡張してやれば、ほかのOSでもモデムとして利用できるはずだ。

シリアルポート


D21LCではシリアルポートが3本生成される。モデムポートは3本目(openbsdの場合はttyU2)だった。

OpenBSDのデバイスドライバの拡張

実はすでにOpenBSDのumsm(4): 3Gモデム用デバイスドライバでは、このようなUSBマスストレージ型のモード変更デバイスを扱うための機能をすでに実装してある( umsm_umass_changemode() @umsm.c)。 似たようなデバイスを扱うために実装しておいたものだが、今回はこの関数を少し拡張して利用することにした。
すでにOpenBSDのCVSへマージされている(差分)を参照すればわかるが、上でキャプチャしたコマンドをタイミングよく発行するだけだ。
コマンド発行部分の差分を以下に載せておく。いままで2種類の同様なコマンドがあったので、3種類目として拡張しておいた。










おまけ:D21LC雑感

実際に使ったのは短い期間だったが、D21LCを使って気がついたのは、「デバイスがサポートしていないコマンドを受理するとフリーズすることがある」ということだ。正式に使えるコマンドセットが公開されているわけでもないのでバグというのは言いすぎだが、ちょっとした動作確認でハングアップしてしまうことが多くて困ることが多かった。最初はデバイスドライバ側が悪いのかと思ったが、Windowsでも同じ操作で同じ状態に陥ることが確認されたのでデバイス側に問題があるんだと思っている。

2009年3月13日金曜日

arduino-13 と atmega88


秋月電子ではatmega88というチップを格安で売っている。このAtmega88は 168のメモリ容量が半分になったもので、海外ではあまり値段もかわらないことから arduinoの中でこれを使っているものはないようだ。しかし、日本ではチップが安いことから、これを使うためのハックがいくつかなされてきていたが、arduino-13が2月にリリースされたのでもう一度ハックをしなおす必要がある。そこでarduino-12 行ったのと同様の変更をしようとおもったら、案外簡単に対応できるように内部がかわっていたのでそれについて書いておこう。

まず、最初に私の手元で使っているライターはSTK500なのでそちらを使えるようにするところからはじめてみた。programmers.txt に以下の3行を追加すると、stk500を利用できるようになる。

##############################################################
stk500.name=STK500
stk500.communication=serial
stk500.protocol=stk500v2
##############################################################

そして、atmega88対応の本番は以下のとおりである。まず、ブートローダを用意する。これは自分で作ると大変なので kosakaさんが公開しているものを利用した。

このブートローダをarduinoのフォルダの中の hardware/bootloaders のフォルダの中に、 lilypad88 というフォルダをつくり LilyPadBOOT_88.hex という名前で保存する。
これでブートローダの準備はできあがった。

次に実際のコンパイルのパラメータになる boards.txt の変更が必要だ。lilypad をベースにAtmega 88対応したものなので、lilypad88 という名前で登録することとした。boards.txt への追加部分は以下のとおりになる。

arduino-12 までは cores の中のコードにあった ifdef を書き直す必要があったが、coresのコードが大幅に書き換えられたようで、現状では以下の部分だけで問題なくバイナリを作ることが出来るようだ。あまり話題になっていないが、coresを書き換えずにこれだけの手間で新しいチップがサポートできるようになっているのは、 arduino-13のもっとも変わった部分かもしれない。

##############################################################
lilypad88.name=LilyPad Arduino w/ ATmega88
lilypad88.upload.protocol=stk500
lilypad88.upload.maximum_size=7168
lilypad88.upload.speed=19200

lilypad88.bootloader.low_fuses=0xe2
lilypad88.bootloader.high_fuses=0xdd
lilypad88.bootloader.extended_fuses=0x00
lilypad88.bootloader.path=lilypad88
lilypad88.bootloader.file=LilyPadBOOT_88.hex
lilypad88.bootloader.unlock_bits=0x3F
lilypad88.bootloader.lock_bits=0x0F

lilypad88.build.mcu=atmega88
lilypad88.build.f_cpu=8000000L
lilypad88.build.core=arduino
##############################################################

これで、arduino-13  でも問題なく Atmega88が使えるようになったはずだ。
ちなみに最近の秋月電子でのAtmega88は Atmega88P というピコパワー対応のものにかわっている。こちらでの動作が同様に行えるかはまだ未確認なので、また報告しようとおもう。


2009年2月20日金曜日

BLINKM ICSPアダプタ

USB-BLINKMの実験をしている最中に、BLINKMのAVR Tiny45を書き換える作業が面倒になったので簡単なICSP用のアダプタを作ってみた。機能は最低限で、

  • AVR USBISP mkIIの6pinのコネクタ
  • BLINKM(ICSP用の補助ピンを2本増やしたもの)
  • 外部電源5V
をつなげるだけだ。最初はブレッドボードに挿して個別に配線していたのだが、これを作っただけでずいぶん作業が楽になった。

部品の配置図と配線図のメモを残しておく。これも秋月の16穴基板を2枚つかって作ったので、8x4穴に収まるようになっている。

USB-BLINKM

BLINKMはthingmが作成・販売しているインテリジェントフルカラーLEDだ。1cm角くらいの基板に、明るいRGB LEDとAVR Tiny45が載っていて、I2Cインターフェイスで外部に接続できる。I2Cはデイジーチェーンできるので、たくさんLEDを使うときには大変便利だ。Arduinoなどから簡単に扱えるので様々なメディア作品で利用されている。


先週からいきなり始めてみた「AVRを使ってみる」という活動だが、ふと机の横に転がっていたBLINKMを眺めるとAVR Tiny45が目についた。ちょうどAVR Tiny85で遊んでいたところだった(その話はまた今度)ので、「Blinkmを単純にLED付きのAVRとして使えるんじゃないか?」と思い立った。実際にやってみたのが今回のエントリの「USBに直接つながるBLINKM」だ。i2cのデイジーチェーンできるという利点は無くなってしまうけれど、USBならどんなPCにも大体ついているので、一個だけ使う場合には逆にお手軽になる(と期待している)。今回は、ハードウェア部分について書いてみることにする。








BLINKMの回路図

BLINKMを裏返して眺めてみると、実装されている部品はLEDと電流制限用の抵抗(x3)とAVR TINY45とデカップリング用のコンデンサくらいだ。とりあえずI2Cの接続用にでている4pinがどこにつながっているかと、LEDがどのIOにつながっているかがわかれば良いとおもって回路を追ってみた。というわけでわかったのが左の図に示す回路図。大変都合の良いことに、i2cのdata/clockの線がPB0/PB2につながっている。

あと実際のBLINKMには実装されていないけれど、ISCPに必要な信号線を出すためのパターンも実装されていて、reset/misoは簡単に外部に引き出せる。
AVRでソフトウェア的にUSBを実現するコードとしてobject development社が公開しているAVRUSBがあるが、USBの信号線の一本をINT0に接続することが推奨されている。PB0/PB2が出ているのがどうして都合が良いかというと、PB2はINT0だからだ。ちょうどTINY85でAVRUSBを試していたところだったので、すぐに「ほとんど外付け回路無しでUSB化できそうだ」という予想ができた。


BLINKM-USBブリッジ回路

というわけで、BLINKMの4pinコネクタからUSBのAコネクタに変換するための外部回路を書いてみる。基本的にAVRUSBのリファレンス回路のツェナーダイオードを使うやつと同じ。
USB1.1の仕様ではD-信号線を1.5Kオームでプルアップすると、low speed (1.5Mbps)デバイスだと認識する。そのためのプルアップ抵抗が一本、信号線の電圧をクリッピングするためのツェナーが2本、あと信号線のシリーズ抵抗(68オーム)が2本、だけの簡単な回路になる。実際にはVccラインに保護用に500mA以下(LEDだけだったら300mA程度で十分)のポリヒューズを一本と、0.1uF程度のセラミックコンデンサを実装しておけば良い。
ポリヒューズが無ければ直結するという方法もあるが、何か間違ったときにPC側のUSBポートやUSBホストコントローラを焼いちゃうかもしれないのでおすすめしない。デカップリング用コンデンサはなくてもいいから、過電流の保護はちゃんとやっておこう。

BLINKM-USBブリッジの実装

思い立ってから、最初の実験を含めて3つほど実装したけど、一番小さくなったやつを紹介しておく。USBもBLINKMも両方とも4pinのコネクタだったので、秋月の16穴スルーホール基板をつかって実装したくなった。10枚買えば一枚10円、100枚だと一枚5円というお手頃価格だし、基板を加工する手間も省ける。

右の図が実体配線図。部品面から見た図になっている。斜め配線&一つの穴に2本部品がはいっているというお行儀の悪い実装になっているけれどなんとか収まったので良しとしよう。


部品はだいたい秋葉原で揃う。3.6Vのツェナーダイオードは千石電商で100本入りをかった。これはどこでも売っているはず。68オームと2Kオームのチップ抵抗(1608)は鈴商で売っている。チップ抵抗なら千石でもあるはずなんだけど、68オームは置いていなかった。一番面倒なのが面実装のポリスイッチ(ポリヒューズ)だ。容量の小さいものなら秋月で扱っているらしいけど0.1Aは小さすぎる。探してもなかったのでチップワンストップで、Tyco Electronics Raychem PSR-27313-050を調達して使った。まあ、千石のB1で売っているポリスイッチを裏にがんばって貼り付けても大丈夫なのでそこまでしなくても平気だとはおもう。

実際に制作したものは右の写真のとおり。BLINKMはUSBコネクタ側にLEDが向くように差し込む。USBコネクタを差し込むと、ちょっと余裕が出るくらいの長さになるので、これがこの方法でつなげる場合に一番短くなる実装方法だろう。





USB-BLINKMのソフトウェア

もちろん、今回つくった回路で電気的にUSBコネクタにさせるようになったとしても、AVRのソフトウェアを書かないと動かない。I2C-USBブリッジではなく、BLINKMにのっているTINY45に直接USBを処理してもらわないといけないからだ。

次回のエントリでは、AVRUSBについて説明してみる予定。


2009年2月19日木曜日

ブレッドボードでArduino

「AVRのATMEGA168があればArduino互換ボードが作れる」ということだけを教えてもらって始めたところ、いくつかはまったのでメモ。

  • AVRISP MKIIでは外部電源が無いと書けない
  • 買ってきたばかりのATMEGA168は外部クロックで動くモードになっているので、クロックを供給してあげないと書けない
  • AVRにはヒューズというものがあって、クロックなどの動作モードはそこに書く。ヒューズのビットマップはチップごとに違うので仕様書を参照
とりあえずfirmware(bootloader)を書くまでに超えないといけなかったのはこのくらい。前のエントリーのarduino用シリアルアダプタ(2) を作っただけでは「ブレッドボードでArduino」には到達できなかった。とりあえずクロックを供給するために、その辺にあったセラロック(20MHz)をつなげてみた。DIPのATmega168のクロック周りのピン配置はGND-XTAL1-XTAL2の順番だが、セラロック(負荷容量内蔵)のピン配置はOSC0-GND-OSC1になっていてブレッドボードに挿すには都合が悪い。写真のようにGNDとOSC0のピンをひねって順番を入れ替えたものを作っておいた。これも今後たくさん使うようなものでは無いけれど、一個くらい持っていても損はしないだろう。

で、次にはまったのがこのいい加減に選んだ20MHzという速度だった。
  • Arduinoのブートローダーはクロック周波数によって違う
普通のArduinoは16MHzで動作するらしい。16MHz以外のクロックをつかって標準的なブートローダーを書き込んでもシリアル通信のタイミングが合わなくて通信できない。解決方法は2つで、
  • 供給しているクロックに対応したブートローダーを作成して書き込む
  • 内部クロック(8MHz)で動作する用にヒューズを書き換えて、8MHz用のブートローダー(lilypad 8MHz用)などを書き込む
のどちらかをやらないといけない。

とくにArduinoのknow-howが無い状態で始めてしまったので「こんなところではまるなよ」と言われそうだけど、しょうがない。おかげで最初にLEDの点滅プログラムを動かせた時には、すでにブートローダーのソースを読み終わっているというArduinoの思想とはちょっと離れたスタートになってしまった。

arduino 用シリアルアダプタ(2)

単に機会が無くていままでAVRを使うことは無かったのだが、共同執筆者のCUEと秋葉原で会ったときに「AVRつかったことないんだ」と言われてしまったので、その場の勢いでATMEGA168とATTINY85を購入してしまった。さて、帰ろうかとおもったときにふと違和感を感じた。「あれ?これってどうやってプログラムを書き込むんだ?」。今までAVRをさわったことのない私に何らかの開発環境があるわけがない。結局、さらにATMELのAVRISP MKIIを秋月で4000円で購入するはめになった。

というわけで、何となくAVRと戯れることになったで、最近の週末プロジェクトについて書いてみようと思う。

Arduino用シリアルアダプタ

右も左もわからなかったのだが、AVRといえばArduinoがはやっているらしいし、CUEもさわっているみたいだったのでその辺から攻めてみた。せっかくATMEGA168を買ってしまった手前Arduinoを更に買うのももったいなかったので、ブレッドボードで実験してみることにする。CUEがやっていたシリアルアダプタが便利そうだったので、こちらでも作ってみた。

たくさんつくるものでもないし、必要そうな機能は全部実装した。
  • USB-AVR間のシリアル通信
  • DTRを用いたオートリセット
  • 手動リセットスイッチ
  • シリアル通信のTX/RXのステータスLED
  • AVRISP MK2をAVRにつなげるためのICSPの6ピンコネクタ
AVRISP MKIIはターゲットとなるAVRに電源が供給されていないと書き込めないので、USB給電で全部書き込むためにはICSPコネクタが手元にあった方が、ブレッドボード上のAVRを扱うときに都合がよい。

これで、こんな感じにブレッドボード上にArduino互換の環境をすぐに準備できるようになった。AVRISP MKIIをつなげないといけないのはブートローダを書き込む最初の一回だけで、Arduinoを使うのならそれ以降に接続する必要はない。

まあ、Arduino以外でブレッド ボードにのったAVRを使うこともあるだろうから、つけて良かったと感じている。


とりあえず基板のレイアウトを書いておいた紙を記録用に載せておく。接続図とかは自明だからいらないよね。






(補足:2009/02/19 19:54)
自分でも忘れそうだから、配線図を書き下した。参考までに載せておく。RX/TXのLEDは割愛。




2009年1月29日木曜日

arduino 用シリアルアダプタ


arduinoの場合には作品制作にPCは必須ではない、というよりPCからコントロールする作品ならば、プログラムが一種類ですむgainerのほうがより簡単に扱えるし、PGAや静電容量センサーが使えて便利なことがおおい。arduinoの本領はgainerでは動作しないようなデバイスを動かす場合や、マイコン単体で動作する作品をつくる場合だろう。

そのため、gainerの時と違ってUSBシリアルをすべてのボードに同梱する必要はなく、プログラムの書き込みやデバッグ時のためだけに使えるようにすればよい。
そこで、USBシリアルアダプタを作品のブレッドボードに差し込みやすい形で作ることにした。まず最初に試作してみたのが、L型ヘッダをつかい、縦に基板を差し込む方法である。Decemiela についているリセット端子と同様の回路(抵抗とコンデンサ)をつけることで、自動リセットにも対応している。
上からみた配線図はこのよ
うになる。電源ラインの取り回しにモジュールの6ピンのところを通してあるが、ここはソケットのピンを抜いておいて、通電しないようにしてある。もちろん、ジャンパとして表面をまわしてもよいだろう。0.1uFのコンデンサと10KΩの抵抗で通信用のラインを横切っているので、裏面にはジャンパが飛ばないようになっている。

この方法ならブ
レッドボードに部品が少々のっていても大丈夫であるとおもったが思ったよりもL型コネクタに厚みがありほとんど部品がない状態でなければ刺せない。
よってこのままでは使えないので、ケーブルをつかってのばすことを考えた。よくやる手ではケーブルの先にピンヘッダをハンダ付けするのだが、今日はイマイチうまくいかなかったので新しい方法を試してみた。





もともと千石電商で売られているヘッダピンとブレッドボードを結ぶジャンパケーブルを分解する。これはエクステン
ションのようになっていて、1ピンのソケットと、1ピンのピンヘッダがそれぞれ圧着されている、簡単にいえばジャンパワイヤーの延長コード状のものだ。(図)ピンヘッダがついた部品をブレッドボードにさすのに利用するワイヤーだが、これを使ってシリアルのヘッダを延長することにした。

もちろん、そのまま5本のケーブルをさすのでもかまわないのだが、ここは専用ケーブルとするためにも、ヘッダを分解し、1x8列の枠を使って再構成することとした。一度ささっている圧着ヘッダを抜くためには、細いマイナスドライバを用いるのがいい。ソケットのプラスチックのひっかかりがある部分をすこしこじって、ひっぱればケーブルを抜くことが出来る。両側のケーブルを抜くと、このように金具だけになったケーブルが出来上がる。これを5本用意して8列ソケットの両側から、3本、2本とさす。延長なのでクロスする部分がないようにフラットに両側のソケットを実装すれば完成である。

これを使うことで1列の隙間があればブレッドボード上のarduinoに書き込みを行うことが出来る。
もちろん、延長ケーブルの配線でクロスさせるなら、もっと簡単にラインを引っ張りだせた、というのは言うまでもないが、直接させることを目標にしたというのが今回の工作の主眼なのでそこは問わないことにしよう。


なんにせよ、これで格安arduino環境が整い、ブレッドボード上に低コストで作品を作ることが出来るようになったわけだ。





2009年1月28日水曜日

ブレッドボードで arduino/88

one chip Arduino clone というのを Make blogなどで発見した。制作記事を読むとATMega88 をつかって 内部発振で動くらしい。ということで、何度か試したもののあまり巧くいってないarduino clone作りであるがこれはさっそく真似せねば!と思い、ブレッドボード上に実装してみた。これは速報のonechip arduinoの前に行った実験だが、報告の前後が逆になっている。
 
最近のArduinoは通常 Atmega168 を 16MHzで駆動しているが、one chip arduino は日本の誇る秋月電子で格安に販売されている Atmega 88 を使い、内部発振で駆動しているため発振子も必要なくなっている。このチップに最低限の回路としてステータス表示用のLEDと動作きりかえのためのリセットスイッチを実装したのがone chip arduino だ。実装部品は思ったよりも少なく、gainerと違い、シリアルポートもオプションなのでたしかにワンチップの上に載せられるくらいの部品しか存在しない。

これをベースにワンチップ化の前に、さらにシンプルになるように配慮しながらブレッドボードに組み立ててみることとした。

そのまえに、まずAVRをarduinoとして動作させるのに必要なブートローダをAtmega88に書き込んだ。
仕事でAVRを使っているグループがいるのもあり、手元にたまたま STK500が転がっていたので、kosakaさんのページ
を参考に STK500をarduinoに登録した。
さすが純正品ということで当たり前だが、なんのトラブルもなく書き込みを行えた。ブートローダは各チップに一度だけ書けばいいので、チップを買ってきたらまとめて作っておくのがよいだろう。


秋月電子で一番安いブレッドボードの上でこれを組み立てることとして、
配線を行った。この ブレッドボードでの最大の問題は、電源ラインが左右に分離しているところであり、このため通常はやらないパーツの上をとびこえる配線が1カ所だけ入っている。


なお、もう1つ大きいブレッドボードの場合には、電源ラインが2本づつ入っているので、左右をちゃんとつなぎ込めば、無様な真似をしなくても作ることが出来る。余白に回路を作ることを考えると、実はこちらのほうがよいのかもしれない。

実際に利用するスケッチを書き込むためには、USBシリアルの変換アダプタが必要だ。秋月のUSBシリアル変換モジュールにコンデンサと抵抗でリセット回路を組み合わせた書き込み用ボードを作成した。L字型のコネクタを使うことで、直接ブレッドボードにさせるのを狙ったが、微妙にスペースが足りずに干渉しやすいことが判ったので、延長ケーブルでつないでいる。
こちらに関してはのちほど別の記事でお伝えしようとおもう。

arduinoも思ったよりも簡単に作ることが出来たので、これでパソコンとの連携が必要ない作品を作る場合はarduinoを使ってもいいかもしれないと思えてきた。パソコンを使う場合で、機能が収まる場合には、arduinoよりもgainerのほうが開発コストが低いと思われるので、gainerの意味がなくなったという訳ではない。とくにgainerの派生物としてAVRと組み合わせた ginger/peper は秀逸で、USBをソフトウェア実装してあるため、USB接続をする先まで考えても、コストが安いことと、実装面積が小さくていいことの2つから便利に使えそうである。


実は先にAtmega168 をつかった Diecimila互換機もブレッドボード上に実装してみた。こちらはマルツで買ったAtmega168と秋月で買った16MHz のセラロック(セラミック発振子)を配線してあるだけでほかは大きな違いはない。高速処理が必要ならばこちらもやってみるといいだろう。ただし、本気で高速処理を考えるならば、普通にAVRGCCをつかってC言語でプログラムをかいたほうがいいのは言うまでももない。

2009年1月26日月曜日

速報 one chip arduinoを作ってみた

ちょっと時間ができたので one chip arduinoを真似してチップ上に無理矢理実装というのをやってみた。

コンデンサの数を減らし、書き込みはヘッダピンがなくてもブレッドボードでやればいいじゃないかということで、極力パーツを省略することで、さらにパーツの少ないすっきりとしたものが出来上がった。この先は表面実装用のパーツとシール基板を使えば、もっとすっきりしたものが出来上がるだろう。

ビフォーアフターは以下のとおり。














書き込みはこのように、USBシリアルアダプタを使ってブレッドボード上で行うこととした。このシリアルアダプタの話はまた今度しようとおもう。シリアルアダプタの中にリセット用の回路を組んであるので、リセットスイッチを押さなくても書き込みは可能である。

LEGO Duplo をケースに

携帯モノの工作をしたときには、そのケースに苦労することが多い。今回は本業で作っているzigbeeの携帯用ノードであるが、ちょうどいいケースを探していたときに 赤ちゃんむけのLego であるdupro シリーズがちょうどいいんでは?と思い当たり、試してみた。残念ながらレゴは単品売りが行われていないので、一番安くて普通のブロックが沢山入ってそうなものということで、緑のバケツというのを購入した。この中には通常サイズのブロックのほかに動物や人
形、車といったパーツが入っていたが、こちらは今回の用途には役に立たないので、最近激務な同僚の先生のお子さんに差し上げることにして、通常の8つ突起のあるブロックをそのまま削り込むことにした。
結果はこのように、あつらえたように申し分のないサイズとなった。今回の用途では大満足だ。

レゴの内側には噛み合わせのための形状がモールドされている。もちろん、中にモノを詰め込むためにはこのモールドは邪魔になるので切り刻むしかない。カッターとペンチと電動リュータを駆使して中身をくりぬいたところがこちら。

ブロックの内側の構造にカッターで切れ目をいれ、出来る限りペンチでもぎ取る。残った部分はリュータを使って削りこんでいって完成だ。レゴの素材はやわらかく、熱に強いので、ゆっくりカッターやリュータをつかえば思ったよりは簡単に削り込めるし、割れる心配もほとんどない。Oリングをつけるための金具はピンバイスであけた穴を拡張して利用している。こちらの金具はタカチのもので袋には70円と書いてあった。

あとは基盤の組み付けの問題は残っているが、現状では電池ケースを接着剤ではりつけ、基盤は電池に対して両面テープでとりつけた。今後はうすい普通サイズのレゴのパーツをつかい蓋をするなどといった案が考えられるだろう。

レゴを使ったケースは手間とコストはかかるものの見栄えとしても悪くないし、持ち歩きもの、インテリアものにはよいのではないだろうか。次はユニバーサル基板をいれてみようかとおもう。