hwhack

林檎最中を立てよう

2010-04-24T14:04:00.006+09:00

新年および新年度あけましておめでとうございます。MTM以来なのでそろそろ化石になるかとおもったhwhack ですが春のコネタとともに復活です。

最近話題の林檎最中ことiPad にはBTのキーボードが繋がります。最近のimacについてくるキーボードがつながるので文字を打ち込む場合には便利なのですが、こういう体制の場合には画面は立ってて欲しいものです。dock兼スタンドはちょい高いのと縦置きしか想定されていません。そこで、「ティンときた」ということで転がっていたLEGOを使って台を作りました。

作り方の解説は必要ないかとおもいます。パーツは「緑のバケツ」を探ればトップの丸みのあるパーツ以外は２セットそろいます。

使ってみると非常に快適で、自宅、オフィスと２つ作ってしまいました。角があたるのを嫌ってトップには丸みのあるパーツを使いましたが、ふつうのブロックでもよいかもしれませんが、そのときは高さの調整が必要かもしれません。

気を良くしたのでついでに余っているパーツを使ってiphone用のスタンドも作ってみました。これもなかなか快適です。こちらはもうひとつ小さい板を使ったスタンドで、ipadは重心が板の上にこないので倒れてしまいます。もう一こま狭くして角度を立てるとなんとか使えますので持ち歩きにはいいかもしれません。

ＭＴＭ０４　珈琲あります。飲みにきてね。

2009-11-23T00:13:00.004+09:00

みなさまご無沙汰しております。

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

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

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

E-mobile H12HW

2009-07-02T14:50:00.003+09:00

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にはコミットしておく予定。

自作arduinoのための breadboard hack

2009-06-22T20:48:00.003+09:00

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

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

ブレッドボードの裏にネットでみつけた ATmega と Arduinoのピン配列の対応表をそのまま貼付けておくだけである。対応図はいろんなところにあるので探してほしいが、たとえばこういうのである。

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

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

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

2009-06-22T17:00:00.011+09:00

MTM３が終わってから、今度は２週間ちょっとの出張がはいってしまってなかなか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に縛られちゃう前に、知っていることは公知にしておくといいよね？

Make Tokyo Meeting 03 参加中

2009-05-23T23:20:00.005+09:00

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

blogでは語れないあんなことやこんなこと、中の人の素顔、途中経過がわからなくなったプロジェクトの進捗など知りたいことがあればぜひおこし下さい。

One Chip Arduinoや USB BlinkM などわかりやすい展示品も取り揃えてあります。

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

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

2009-05-14T21:33:00.006+09:00

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

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

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

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

OpenBSDでSoftbank C01SWを使う

2009-05-14T16:25:00.003+09:00

週末に海外の見知らぬ人から「（俺の）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概略

アタッチしてみてちょっと驚いたのはインターフェイスが７本出現したことだ。一般に3Gモデムは複数（２−３本）のインターフェイスを用意しているが７本出てきたのは初めてだった。

USBディスクリプタを見ると4-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がつながって通信できた。

E-mobile D12HWとD22HW

2009-05-12T13:35:00.003+09:00

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

触ったのはD12HWとD22HWで両方とも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が適用されてしまっている。

UQ WimaxのUD01SS解析 (4)

2009-05-10T13:48:00.010+09:00

前回の続き。

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

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

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

UD01SSの内部ではLinuxが動いている、というのは（１）で書いた。汎用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のコマンドは、大体

２バイトのヘッダ(Command/Response Type)
２バイトのペイロード長（データ部分だけ。ヘッダ部分は含まない）
データ

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

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

次回

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

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

2009-05-09T15:38:00.006+09:00

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

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

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

そこでちょうどいい太さで先端がピンに

なった圧着端子を探していた。なかなかちょうどよいものがなかったのだが、yuoとアキバを探し歩いた結果、VGAコネクタなどに使うシュリンクDSUB用のピンがちょうどいいのじゃないかという結論に達したので紹介しておく。

千石通商で売られているシュリンクDSUB用のコンタクトピンは5本単位で売られている。CUEは田舎に住んでいて交通費を考えると必要数だけ毎回買うの

も無駄なので100本パックを買っている。このとき「シュリンク(細い方）」DSUBの「オス」を入手する必要がある。写真とおなじものを手にいれれば間違いないだろう。

千石通商の1Fにほかの端子とともにおいてあるはずだ。残念ながら通販ではシュリンクではないDSUB用のピンしか扱っていないようだ。ちなみにRS232Cなどに使う普通のDSUB用のピンは太すぎてブレッドボードに刺さらない。

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

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

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

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

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

2009-05-09T02:29:00.004+09:00

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セミコンダクタが開発した１チップの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より体積比で２倍くらい
ファームウェアは両方ともLinux(version 2.6.12-uc0)

まとめ

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

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

UQ WimaxのUD01SS解析 (3)

2009-05-05T16:22:00.006+09:00

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

前回の続き。
UQのUSB型mobile wimaxインターフェイスであるUD01SSの解析メモ（３）。
今回は「どうやって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したキャリアのネットワーク）を利用するためには以下の２つの認証を越えなければならない。

デバイス認証（およびネットワーク認証）
ユーザ認証

前者はそのデバイスが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)

2009-05-05T12:27:00.003+09:00

前回の続き。
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というユーティリティを使えばよい。適当に手順を書くと、

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

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

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

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

ループバックファイルシステムとしてマウントする。
- 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インターフェイスとしての基本動作を書いてみる予定。

UQ WimaxのUD01SS解析 (1)

2009-05-04T22:19:00.006+09:00

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

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

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

GDM7205はARM926EJと補助CPU(アーキテクチャ不明）が搭載されている
UD01SSの内部OSはLinuxと補助CPUで動くリアルタイムOS（詳細不明）で動いている
ソフトウェアでUSBクライアントとして動いているのでUSBデバイスとしての構造は比較的簡単

といったあたりだ。とくに、「中身がLinuxで動いているUSBドングルタイプのARMのボード」が１２８００円っていうだけでなんかほしくなってしまったのでつい買ってしまった、というのが本音かもしれない。

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

になっていて中身のカーネルとファイルシステムを覗くことができる。

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

E-mobile D21LCをOpenBSDで使う

2009-04-26T22:49:00.007+09:00

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

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

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

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

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

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

シリアルポート

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

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

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

おまけ：D21LC雑感

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

arduino-13 と atmega88

2009-03-13T01:00:00.005+09:00

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

まず、最初に私の手元で使っているライターはSTK500なのでそちらを使えるようにするところからはじめてみた。programmers.txt に以下の３行を追加すると、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 というピコパワー対応のものにかわっている。こちらでの動作が同様に行えるかはまだ未確認なので、また報告しようとおもう。

BLINKM ICSPアダプタ

2009-02-20T20:27:00.005+09:00

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

AVR USBISP mkIIの6pinのコネクタ
BLINKM（ICSP用の補助ピンを2本増やしたもの）
外部電源５V

をつなげるだけだ。最初はブレッドボードに挿して個別に配線していたのだが、これを作っただけでずいぶん作業が楽になった。

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

USB-BLINKM

2009-02-20T17:22:00.014+09:00

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について説明してみる予定。

ブレッドボードでArduino

2009-02-19T20:27:00.006+09:00

「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つで、

供給しているクロックに対応したブートローダーを作成して書き込む
内部クロック（８MHｚ）で動作する用にヒューズを書き換えて、8MHz用のブートローダー（lilypad 8MHz用）などを書き込む

のどちらかをやらないといけない。

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

arduino 用シリアルアダプタ（２）

2009-02-19T17:41:00.009+09:00

単に機会が無くていままで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は割愛。

arduino 用シリアルアダプタ

2009-01-29T14:50:00.007+09:00

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

そのため、gainerの時と違ってUSBシリアルをすべてのボードに同梱する必要はなく、プログラムの書き込みやデバッグ時のためだけに使えるようにすればよい。

そこで、USBシリアルアダプタを作品のブレッドボードに差し込みやすい形で作ることにした。まず最初に試作してみたのが、L型ヘッダをつかい、縦に基板を差し込む方法である。Decemiela についているリセット端子と同様の回路（抵抗とコンデンサ）をつけることで、自動リセットにも対応している。

上からみた配線図はこのよ

うになる。電源ラインの取り回しにモジュールの６ピンのところを通してあるが、ここはソケットのピンを抜いておいて、通電しないようにしてある。もちろん、ジャンパとして表面をまわしてもよいだろう。0.1uFのコンデンサと10KΩの抵抗で通信用のラインを横切っているので、裏面にはジャンパが飛ばないようになっている。

この方法ならブ

レッドボードに部品が少々のっていても大丈夫であるとおもったが思ったよりもL型コネクタに厚みがありほとんど部品がない状態でなければ刺せない。

よってこのままでは使えないので、ケーブルをつかってのばすことを考えた。よくやる手ではケーブルの先にピンヘッダをハンダ付けするのだが、今日はイマイチうまくいかなかったので新しい方法を試してみた。

もともと千石電商で売られているヘッダピンとブレッドボードを結ぶジャンパケーブルを分解する。これはエクステン

ションのようになっていて、１ピンのソケットと、１ピンのピンヘッダがそれぞれ圧着されている、簡単にいえばジャンパワイヤーの延長コード状のものだ。(図)ピンヘッダがついた部品をブレッドボードにさすのに利用するワイヤーだが、これを使ってシリアルのヘッダを延長することにした。

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

これを使うことで１列の隙間があればブレッドボード上のarduinoに書き込みを行うことが出来る。

もちろん、延長ケーブルの配線でクロスさせるなら、もっと簡単にラインを引っ張りだせた、というのは言うまでもないが、直接させることを目標にしたというのが今回の工作の主眼なのでそこは問わないことにしよう。

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

ブレッドボードで arduino/88

2009-01-28T18:48:00.003+09:00

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に登録した。

さすが純正品ということで当たり前だが、なんのトラブルもなく書き込みを行えた。ブートローダは各チップに一度だけ書けばいいので、チップを買ってきたらまとめて作っておくのがよいだろう。

秋月電子で一番安いブレッドボードの上でこれを組み立てることとして、

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

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

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

こちらに関してはのちほど別の記事でお伝えしようとおもう。

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

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

速報　one chip arduinoを作ってみた

2009-01-26T19:24:00.004+09:00

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

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

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

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

LEGO Duplo をケースに

2009-01-26T14:01:00.004+09:00

携帯モノの工作をしたときには、そのケースに苦労することが多い。今回は本業で作っているzigbeeの携帯用ノードであるが、ちょうどいいケースを探していたときに赤ちゃんむけのLego であるdupro シリーズがちょうどいいんでは？と思い当たり、試してみた。残念ながらレゴは単品売りが行われていないので、一番安くて普通のブロックが沢山入ってそうなものということで、緑のバケツというのを購入した。この中には通常サイズのブロックのほかに動物や人

形、車といったパーツが入っていたが、こちらは今回の用途には役に立たないので、最近激務な同僚の先生のお子さんに差し上げることにして、通常の８つ突起のあるブロックをそのまま削り込むことにした。

結果はこのように、あつらえたように申し分のないサイズとなった。今回の用途では大満足だ。

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

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

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

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

OSX でTCPウインドウ制御

2008-12-22T17:08:00.002+09:00

ある種の Firewallと MacOSX の rfc1323実装の相性が悪いらしく、

職場の環境では大きいファイルのダウンロードをやっているとかならずストールしてしまう。

そんなとき以下のようにすればいいと教わった。

sudo sysctl -w net.inet.tcp.rfc1323=0

これを毎回打つのもなんだかなーと思っていたら、

/etc/sysctl.conf というファイルに以下の１行書いておけばいいらしい。

net.inet.tcp.rfc1323=0

実績はリブートしてのお楽しみ。

Gainer の PGA設定

2008-12-15T11:17:00.004+09:00

Gainer(というよりPSoCの)PGAの倍率設定は0-15を指定すると、それに対応した倍率になる。

これがまた微妙な間隔で、覚えるのも大変なので覚え書きとして書いておく。

6,10,12 あたりが２x、４x、８xとなって判りやすいのでよく使うと思う。

指定値倍率

0 1.00

1 1.14

2 1.33

3 1.46

4 1.60

5 1.78

6 2.00

7 2.27

8 2.67

9 3.20

10 4.00

11 5.33

12 8.00

13 16.0

14 24.0

15 48.0

gainer-rubyを NetBSDの箱で動かす

2008-11-04T21:39:00.004+09:00

gainer-rubyは rubyで作られたgainerのライブラリであり、rubyを知っていれば非常に簡単にgainerを使うことが出来るのが特徴だ。GUIを使った作品作りとは異なるが、本blogでも twitterとgainerをつなげるなどのエントリで活躍している。ruby自体にさまざまなライブラリが豊富なので twitterやIMなどとの連携を行いやすく、グラフィカルなインスタレーションではないような用途では非常に重宝する。

個人的には温度計を接続し、activerecord経由でDBと連携させて一定時間おきにtwitterに投稿するといった使い方をしている。

個人的なgainer-rubyの問題としては NetBSDをいれた小さい箱で動かなかった点がある。これはシリアルポートのtermiosの設定がうまくいっていないようなので、ここを修正することとした。また、ダウンロードできるgainer-rubyのソースには PGAのゲイン調整のコードが入っていないのでこれも追加したものを作ってみた。動作を確認したNetBSDは 4.0R のi386版である。

PGAのほうは作者にも送ってあるので次のバージョンには反映されるかもしれない。

コードの差分をリンクしておくので、試してみたい方はsvnで checkoutした gainer-ruby にあててみてほしい。PGAのゲインコントロール関数は amp_gain_agnd/amp_gain_dgnd でprocessing のライブラリと対応させてある。シリアルポートはtermiosの設定を変更したが、NetBSDの他にOSX(10.5) でも動作することは確認済みである。

gainer-ruby用 NetBSD対応、PGAゲイン調整対応のdiff

これをつかった作品の全容はまた後ほど

ベリーショートなACタップ

2008-10-14T16:49:00.004+09:00

テーブルタップのコードがからまるという問題は、古今東西あらゆる現代人が直面している問題のようで、さまざまなツールや解決案が提案されている。また、別のテーブルタップの問題としてはコンセントの口が少ないということがよくあげられる。総計1500Wの3つ口テーブルタップに、昔なら数百ワットを使うテレビやこたつといったものをつなぐのが普通だったのが、最近ではたった100W以下しか使わないゲーム機やパソコンのACアダプタを数多くつなぎたいという要求のほうが多い。

これを解決するには多口のタップを使うのが簡単だが、そう多いものは売られていない。そのため、タップは基本的にたこ足になってしまうのが一般的だが、その場合には長いコードのやり場に困る。

そこで個人的によくやっているのが、タップのコンセントを短く切断してしまう方法だ。とくにオフィスのデスクの下に転がすタップなどはデスクに磁石で取り付けることもあり、あまり長いと邪魔なだけなので、20cmくらいの長さになるようにコードを切断したものを用意している。

高級品のタップの場合にはタップ側を分解するとケーブルがねじ留めされているので、その場合にはねじを外して、コードを短く切り、もう一度ねじ止めする。普通のタップの場合には、ケーブルがハンダ付けされていたり分解できないようなネジや、接着といった方法でとめられていたりするのでその場合にはコンセント側を捨てることにして、新しいコンセントの部品をホームセンターで買ってくればいい。このときにコンセントを90度に曲がるものや回転するものなど、自分のさしたい場所にあわせてやるといいだろう。

写真は筆者のオフィスのテーブルに張り付いているタップである。真ん中が床下から生えてきているタップでそれを左右２つのタップに分岐して使っている。ただでさえ、イーサネットケーブルと電源ケーブルで混乱している机の下だが、このタップのケーブルが３mもある場合とは雲泥の差であるのは判ってもらえるだろう。

既製品を切り刻むのは抵抗があるのだろう。簡単にできる割にあまりやった話を聞かないのだが、自分の足下がおどろくほど快適になるのでぜひ試してみてほしい。

ちなみに切ってしまうと模様替えなどで長いケーブルが必要になると使えないじゃないか！と言う人もいるとおもうが、自分の手元に必要なテーブルタップの口数がかわらない以上は手元まで引っ張るものと手元でバラすものが必要なわけで、大きな問題にならないはずだ。

passenger(mod_rails) でバーチャルホストを使わない複数アプリケーション動作

2008-10-01T18:20:00.005+09:00

railsの実行環境としてこの春あたりから話題騒然のpassengerを試してみた。このとき、普通にアプリケーションを立ち上げるのはみんながやっているが複数のアプリケーションをディレクトリで切り替えるというのはあまり見なかったので簡単にまとめておく。

まず、apache + passenger のインストールだが、どこのblogにも書いてあるので省略する。

passengerのための設定までは終了したとして、この後にそれぞれのアプリケーションを動かすための設定を行う。アプリケーションを動かすために設定しないといけない項目はシンボリックリンクを含めると合計４カ所だ。

まず最初にやるべきことはrails のアプリケーションのシンボリックリンクを作ることである。rails アプリケーションそのものが存在するディレクトリはapacheを動かしているユーザで

アクセスできれば、documentrootの中にある必要はないようだ。さすがアプリケーション。

railsアプリの名前が tasklist だとするとtasklistの中のpublic をシンボリックリンクで

Documentroot内の適当な場所にリンクする。だいたいこんな感じになるだろう。

---

cd /WWWROOT/rails/

ln -s /home/name/tasklist/public tasklist

---

次に設定するべきところは railsアプリの routingだ。ここでアプリの中でindexを開いたときに動くべきコントローラが taskであり、最初にアクセスされるべきアクションがindexだとして設定をおこなう。ここでは railsのアプリケーションの中の config/route.rb に以下の行を追加する。

map.connect '', :controller => "task", :action => 'index'

そして、public内のindex.htmlファイルにアクセスされないように index.htmlを

削除ないし名前変更する必要がある。これをやらないとindex.htmlをアクセスしていつまでたってもアプリケーションにたどり着かないことになってしまう。

これだけの設定でrailsアプリ側の準備ができた。

最後は httpd.confに railsのアプリケーションのrootを伝える設定を書き加える。passenger の設定の下に以下のような行を加えよう。

---

RailsBaseURI /rails/tasklist

---

このあと apacheをリスタートした後ブラウザから、 http://hostname/rails/tasklist とアクセスすると無事にアプリケーションが立ち上がっていることが確認できるだろう。

今回のポイントはこの最後の操作で、 RailsBaseURI の行を増やすと複数のアプリケーションに対応できるということにある。railsアプリを設定し、シンボリックリンクを作り、httpd.confに RailsBaseURIを書き加えれば、同時に複数のアプリケーションを立ち上げることが可能になる点がポイントだ。

以上、簡単だが主に自分でまた半年後にやるときの参考になればとおもい記録しておこう。

gainer clone で「かざぐるま」あるいは PWMによるモーターの駆動 (2)

2008-07-08T01:00:00.007+09:00

前回のあらすじ
Gainerモジュールにトランジスタアレイでかざぐるまを駆動することに成功したCUE。
しかし、そのモーターからは脳を直撃する怪音が無限に鳴り響く！

すこし時間があいてしまったが、前回の最後で述べたとおり、怪音をなくすためにはPWMの周波数を変更するのがもっとも一般的かつ効果的な手法である。しかしながらgainerの配布されているファームウェアでは、PGAのゲインはコマンドで変更できてもPWMの周波数は変更できない。ということで、「Gainerのファームウェアを改造してノイズが出ないモータを実現するぞ」プロジェクトを決行した。

当方ではファームウェアの不具合について感知しないのはもちろん、ファームウェアの焼き込みサービスも行ってないのであしからず。秋月電子などから PSOC miniProg を手に入れて各自で焼き込んでもらいたい。どのように作業したかは以下のとおりである。

1. ファームウェアの入手
firmware はgainer.cc のページからダウンロードできる。以下のページからファームウェアのソースファイルをダウンロードする。ダウンロードできたらこれを unzipして展開しておく。

2. ファームウェアの展開
ファームウェアはzipなので適当なツールを使って展開する。このとき置き場所は日本語の入っていないディレクトリでなければ、PSoCデザイナでmakeするときに不具合がでることがあるので注意したほうがよい。僕は C:\ に直接展開したフォルダをそのまま移動した。

3. 設定画面をながめる
書き換えポイントを探るためにコンフィグとソースをよく見て考える。
config_a にPWMモジュールが8つ発見できたので、これが出力用のPWMに違いないとあたりをつける。そのときに、PWMのクロックをどこからもらってるかを配線からながめると１６ビットのカウンタを使ってブロードキャストバスに信号を流し込み、そのバスの信号をクロックとして使っているということがわかった。

その後で、ソースコードをかるく読んでみるとまさしく config-a の PWMモジュールの山がそのままPWMとして出力されることがわかる。これでconfig-a のPWMモジュールのクロックを書き換えるという方針が決定した。

4. 使えそうなクロックを探す
使えそうな clockとして Gainerの生の設定でPSoCモジュールが供給しているのは、24MHzの生クロックのほかこれを分周して作っている VC1,2,3 のそれぞれさらに専用のcounterにより作りだされているもともとのPWMの信号がある。それぞれのクロックはどれくらいの周期かというとPWMでは 256クロックで１周期ということなのでCPUCLK 24MHz がおよそ 100KHzとなるがこれはすこし早すぎるようだ。

VC1は　24/3 = 8MHz VC2は 8/4 = 2MHz であり、これをさらに 1/256したものが周波数になる。よって VC1でおよそ 32KHz VC2では 8KHz となる。超音波領域に突入することが目標なので、 VC1のほうを採用することとした。

これをそのまま PWMのクロックに入れればいいのだが8つある設定を書き換えるのは大変なので大本となっている PWM用のカウンタであるCounter16に入力することにした。

このままでは counter16のソースが 8MHzとなったはいいがカウンタをつかってさらにスピードを落としているので、それをカウントしている部分を探すこれはソースコードのほうで発見した。
クロックの比は 1:1 なので226行目(あたり）のところの Counter16_A_PWMClk_WritePeriod(0); を 0に書き換える。これで毎回カウントアップのたびにCounterがあふれているはずだ。
実際のところcounter16など使わなくても、直接配線をVC1に変更しまくればそれでもOKなのだが、その場合には書き換えるポイントが8つになってしまうので、間違い等があると大変である。そこで今回はCounterはそのまま使って、そのカウンタの周期を修正したのである。修正ポイントのコードは以下のとおりである。

--ここから
// start analog outputs
// Counter16_A_PWMClk_WritePeriod(157); // 50Hz (i.e. 20ms)
　 Counter16_A_PWMClk_WritePeriod(0); // 10KHz (i.e. 1ms)
Counter16_A_PWMClk_WriteCompareValue(0);
Counter16_A_PWMClk_Start();
--ここまで

この２つをやってからbuild を行う。今回はHitechC のフリー版つかってmakeを行った。Gainer自体はもともとimage-craftのコンパイラで作られていたはずだが、何の問題もなくコンパイルもおわったのでこれを miniprogを使って書き込んで完成である。

これで動作させればPWMでモータを駆動させても音がならないGainerが完成である。モータが動かなくなるくらい低いPWM値の場合にモータからの異音がしなくなるのがわかるはずだ。

改変した後のHEXファイルはこちらにおいておく。そのままmini-progで焼き込めば動くはずだ。

gainer clone で「かざぐるま」あるいは PWMによるモーターの駆動

2008-06-25T12:05:00.015+09:00

Gainerは設定にもよるが 4ないし8本のアナログ出力(PWM)を使うことが出来る。前に作成した power gainer は電源にもよるがトランジスタアレイにより小型のモータを回転させるには十分な電力を供給することができる。そこで、前からやってみたかったアンビエントディスプレイである「かざぐるま」を作ってみた。

これは MITのメディアラボで行われているタンジブルコンピューティングの象徴的なアンビエントデバイスの一つである。(詳しくは Media LabのTangible Media Group を参照。)　

使ったのは前に作成したTD62083をワンボードに組み込んだGainer(Power gainer)とタミヤのプーリー基本キットである。これらをささえる土台となっているのは、100円ショップで買ってきたアクリルのメニュー立てだ。プラスチックのプーリーをゴムベルト（ゴムバンド）で回転させるプーリーキットは回転時に音がほとんどしないので、ギアボックスと違い常時動かしておくアンビエントディスプレイに適している。これに、ケント紙で作った風車を両面テープで貼付けてハードウェアのほうは完成である。

gainerのconfiguration3ならばPWM出力が8ch仕様ということで作成した風車のセットを同時に8つコントロールできるが、今回はサンプルということもあり１つの風車だけで満足しておくこととする。8ch同時で動かすにはUSBに寄生するだけではなくターゲットボードにACアダプタ等の外部電源が必要だろう。

このgainerをコントロールするプログラムはまず、テスト用ということで簡単なものを用意した。マウスカーソルを動かすとそれに従ってアナログ値が変化するものだ。これで、ウインドウ上をマウスを左右に動かすだけで回転を変化させることが出来るので動作確認には十分だろう。このプログラムはPWMで動かすデバイスの試験にいつも使っているものでもある。

以上のように風車は簡単に動くところまではきたのだが、ひとつ大きな問題が残ってしまった。ほとんど動いていないときもピーピーとモーターから音がする。これは Gainerの PWMの周波数が1KHzであるため、 1KHz周期でモータが振動してしまっている音であり、PWMでモータを動かす場合に起きる現象だ。このノイズを解決するためにはモータを駆動するPWMの周期を25KHz以上に上げる方法がよく使われる。こうなると、モーターの振動音が超音波の領域に入るため人間には聞こえなくなるのである。もちろんノイズがなくなるわけではないので、コウモリやイルカには迷惑なのかもしれないが、そこは気にしないことにして、ファームウェアを改造しPWMの周波数を上げる対策をとることとした。

（つづく）

PWMテスターのソースコードは以下のとおり。


----------
import processing.gainer.*;

Gainer gainer ;


void setup() {
  size(500,100) ;
  gainer = new Gainer(this) ;
}

void draw() { 
  int i ;
  background(mouseX/4) ;
  
  for ( i = 0; i<500;i+=100) {
    stroke(255,0,0) ;
    line(i ,0,i,100) ;
  }

  gainer.analogOutput(1,mouseX/2) ;
  stroke(0,0,255);
  line(mouseX,0,mouseX,100) ;
  println("NOW: " + mouseX/2  + "*" ) ;
}
----------

Processingでtwitterと http認証 (basic auth)

2008-06-24T19:56:00.005+09:00

Processingをつかって、httpをしゃべらせることは難しくはない。ただ通信してページを取ってくるだけならば、loadStrings() の引数にURLを指定してやれば、自動的にJavaのURLクラスを使ってStringsの配列として格納できる。これをつかって、twitterのデータを読み込もうとおもったのだが、twitterではbasic authを使わなければ自分のfriends timelineを取り出すことが出来ない。そこで basic authを processingでやってる例をさがしたのだが、発見できなかったので生のjavaでのbasic authの方法をそのまま取り込んで実現してみた。

さまざまなページによると javaでのhttp認証では java.net.authenticator とjava.net.PasswordAuthentication の２つのクラスを使い、Authenticator クラスを継承した認証クラスを作ってハンドラを設定する、というのが正解らしい。つまり、以下のようなコードとなるわけだ。



import java.net.Authenticator;
import java.net.PasswordAuthentication;

//public
class BasicAuth extends java.net.Authenticator{
 private String user;
 private String pass;
 public BasicAuth(String user, String pass)
 {
   this.user = user;
   this.pass = pass;
 }

 protected PasswordAuthentication getPasswordAuthentication()
 {
   return new PasswordAuthentication(user,pass.toCharArray());
 }
}

このクラスの利用方法は、user名とpasswordを設定して作成したクラスのインスタンスを生成し、そのあとで、Authenticator の setDefaultを呼び出す。前処理としてこの作業を行うと以降の http通信で認証が必要とされる場合には設定した情報をベースに自動的に認証が行われる。これをそのまま、processingに追加して使った。Processingは基本的にjavaそのものなので、このような場合の拡張は非常に簡単ですばらしい。
本当はpackage化してライブラリとするといいのだろうがそれはまた今後の課題ということにしておこう。

さて、現実にtwitterの出力するXMLの解析には、simlpeMLというライブラリを使うことにした。simpleMLはdaniel shiffman(http://www.shiffman.net/) の開発したライブラリであり彼のページからダウンロードできる。loadStrings()を使うよりもよい点は、後で XMLライブラリを使ってエレメントを取り出すよりも簡単なことと thread をつかって非同期にhttpリクエストを発生させて、ページを取得できたときにイベントを発生させることが出来る点である。とくに後者は、一定時間ごとにページを取得して書き換えるような動作を行いたい場合には、非常に有効であろう。

timelineの twitterAPI呼び出しを行うにはBasic認証付きでAPIで定められたURLを呼びだせばよい。受信形式はいろいろ見比べた結果、後処理がもっともやりやすそうなRSS形式を指定した。これらをまとめるとコードは以下のようになる。あとは、数分おきにreloadをするとか、スクロールするとかのフィーチャーを盛り込めば、twitter viewerとしての機能は十分だろう。
ちなみに書き込みは post method が必要なのだが、こちらも processingで使えるモジュールはなさそうなのとすこし複雑な処理が必要そうなのでもう一工夫必要なようなので今後の課題としておこう。
動作させるためには、フォントを作成する必要がある。Processingのメニューから Tools-->Create Fontを選択すると次のような画面が出るので Osakaフォントの16pointを指定する。日本語表示には日本語のフォントも必要なので All Fontのチェックボックスにもチェックをいれておく必要があるだろう。こうやってフォントを作成した後、コードの中の user と pass を自分のものに入れ替えれば動作させてみることができる。

-------------------------------- import simpleML.*; import java.net.Authenticator; import java.net.PasswordAuthentication; // configration String user = "uname" ; String pass = "xxxxx" ; // request url String url = "http://twitter.com/statuses/friends_timeline.rss" ; //public class BasicAuth extends java.net.Authenticator{ private String user; private String pass; public BasicAuth(String user, String pass) { this.user = user; this.pass = pass; } protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication(user,pass.toCharArray()); } } XMLRequest xmlRequest; void setup() { size(screen.width/2,screen.height/2); BasicAuth tw_authenticator = new BasicAuth(user, pass); Authenticator.setDefault(tw_authenticator); // Creating and starting the request xmlRequest = new XMLRequest(this,url); xmlRequest.makeRequest(); } void draw() { // background(frameCount % 255); } // When the request is complete void netEvent(XMLRequest ml) { PFont fontA = loadFont("Osaka-16.vlw"); textFont(fontA, 16); // Retrieving an array of all XML elements inside "" tags String[] titles = ml.getElementArray("title"); for (int i = 0; i < titles.length ; i++) { println(titles[i].replaceAll("\n","")); fill(10*i,0,0) ; text( titles[i].replaceAll("\n",""),5,18*(i+1)) ; } } --------------------------------

ここまで。

戦利品

2008-05-22T15:38:00.003+09:00

昨日のTIのセミナーでもらったお土産。
２．４Gの無線つき MSP430のモジュール。たくさんあると
スター型になれるらしいのですが２個入りでした。残念w

Xbeeの開発環境

2008-05-15T18:11:00.002+09:00

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

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

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

OpenBSDでEmobile D02HWを使う(1)

2008-05-13T12:44:00.005+09:00

縁あって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のモード遷移のための関数の統合について書く予定。

背の低いUSBシリアル

2008-05-12T21:25:00.003+09:00

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

ピンをはがしてワイヤハンダ付けして結線しなおし。

どうせ、設定決めたらいじらないし。

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

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

2008-04-28T21:43:00.007+09:00

何度でもやるぞというくらいこのblogで出てくるネタとしてPSoCの書き込み方法がある。　mini-eval の丸ピンソケットをZIFにしてやれば書き込み器として使えるよねというアイデアは多くの人が提唱しているところではあるが、検索してみるとそれほど難しくなさそうだったのでやってみた。

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

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

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

2008-04-12T18:58:00.004+09:00

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

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

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

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

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

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

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

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

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

2008-04-11T21:04:00.006+09:00

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

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

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

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

2008-04-11T01:34:00.009+09:00

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

、processingとの違いであろう。

processingを使うとグラフィックを簡単に表示できるので画面をつかったインタラクションを作るのには非常に向いているのであるが、今回のようなネットワークをつかったフロントエンドで、画面を必要としないようなものの場合には、rubyのほうがよいであろう。さらに、 C++のライブラリというのも見つけたので、組み込みマシンを使うならばそちらのほうがいいかもしれない。恐るべしgainer。

まあ、それはおいといて作ったものがこれ。ボタンをおすと twitterに「コーヒー飲みたい」みたいなメッセージを書き込む。ボタン２はランダムにfollowerを選択して「スゲー」と書き込む。

ruby-twitter のライブラリと gaine r-rubyのおかげでとても簡単に書き上がった。回路はブレッドボードの上につくったがコンフィグレーション１のまま 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

gainer clone (互換機）でサーボを動かす

2008-03-31T23:52:00.003+09:00

LEDばかりでは面白くないのでgainer を使ってラジコン用のサーボを動かしてみることにした。このサーボモータはもともとはラジコン自動車、飛行機などでつかわれていたが、最近ではロボコンブームのおかげでその基幹パーツとして多種大量に供給されるようになってきている。

一般的なラジコン用サーボモータはアナログのPWM信号によって移動角を制御している。基準として 1msecから2msecのパルス幅を投入すると、その幅に応じた角度にサーボモータの軸が回転する。これを周期的に与えてやることでその角度を維持したり、動作角度を変更したりすることが出来る。ロボットの場合には、この周期をどこまで早められるか、応答速度や、トルクといったメカトロてきな要素が非常に重要になるのだが、インタラクションデザインのためのサーボにはそこまでの精度は要求されないのが一般的だ。今回はgainerのアナログ出力が実際には電圧変化ではなく、PWM信号を用いていることを利用し、サーボモータの駆動を試してみることとする。

アナログサーボには個体差があるので、両端のぎりぎりの部分を使うためには、それぞれのサーボに応じたパルス幅を調べる必要がある。Aout(0) にサーボの信号線を繋ぎ込んで利用する前提で作成したコードは以下のとおり。
　
コントロールなしのダイアモンドカーソルでサーボの稼働角を調整できる。 E/X で 5ステップづつS/D で1ステップずつの稼働となっている。

コンソールに現在の数字が出るので幅を記録していこう。一般的な安いサーボモータは最大と最小で180度前後の回転角を得ることができる。Analogoutが最大で8ch までとることが出来るので、8個のサーボなら同時に動かすことが出来るはずだ。ただしその場合には、電力が足りなくなると思われるので、サーボ駆動の電源を別途用意する必要があるだろう。

手元のサーボで試したところパルス幅が 8から30程度ということで 180度を20分割程度にはできるようだ。回転角がシビアな用途でない、見せるための作品であれば十分に実用的な範囲だと考えられる。



import processing.gainer.*;
Gainer gainer ;
int i ;

void setup() {
 gainer = new Gainer(this) ;
 frameRate(5) ;
 i = 20 ;
}

void keyPressed() {

 switch(key) {  
   case 'x':
     i -=5 ;
     break ;
    
   case 'e':
     i +=5 ;
     break ;
    
   case 's':
     i -- ;
     break ;
    
   case 'd':
     i ++ ;
     break ;
   default:
 }
}

void draw() {
  gainer.analogOutput(0,i) ;
   println("NOW: " + i + "..." ) ;
}

Gainer Clone でwebcamを操作する

2008-03-12T19:49:00.002+09:00

前回はハードウェアをブレッドボード上にならべて満足したので次は簡単な実装としてgainer備え付けのボタンを押すとシャッターが切れてwebcamから写真がとれる、というものをつくってみた。基本的にはボタンだけでは面白くないがこのボタンを光電センサやドアの開け閉めに連動させればパソコンのキーボードを押してwebcamを操るのとは違うことができるはずだ。単純にボタンだけであっても長いUSBケーブルさえ用意すれば、レリーズのように遠隔でシャッターをおすことも可能だ。玄関のドアやブースの外側といったところにカメラをむけてセンサーをおけば、監視カメラとしての役割くらいは十分にこなせる。

コードは非常に簡単で写真を撮るためのcaptureオブジェクトの read をボタンが押されたときのハンドラに登録し画面に表示するだけだ。ほとんど何の処理もしていないが、サンプルコードは以下に示す。撮られた画像は画面に表示するだけなので、セーブが必要ならばそのようなルーチンを書き足す必要がある。
動作確認は OSX10.5 で内蔵の isight をつかって行った。カメラとgainerがうごけばwindowsでも動作するだろう。

この発展であるセンサーのアナログ値を使ったカメラの駆動はまた後ほどということで。


/*
  capture by button 
 
 */

import processing.gainer.*;
import processing.video.*;

Gainer gainer ;
Capture cam ;

void setup() {

  size(320,240) ;
  frameRate(24) ;
  background(0) ;
 
  cam = new Capture(this,320,240) ;
  gainer = new Gainer(this) ;
  delay(100) ;
  cam.read() ;
 
}

void draw() {

  if ( gainer.buttonPressed ) {
    cam.read() ;
  }
    image(cam,0,0) ;
}

Gainer clone on BreadBoard

2008-02-28T00:45:00.005+09:00

基板をつくる前にはブレッドボードである程度試作するのが最近の一般的な？流儀だとおもうが、ブレッドボード遊びに興じてしまったのでそちらの結果を先に。

PSoC を使った製品といえば、 iPod やGameboy microが有名だが、PSoCを使った「作品」となると gainer だろう。gainerはメディアアーティストのためのフィジカルコンピューティングデバイスとして設計されており、 Processing Flash MAX/MSPといった作品作りによく使われる環境に適応するためのライブラリが提供されており、親和性が非常に高い。

このキットオープンソースなHWであるが、焼かれた基板にパーツをつけて8500円という価格で売られている。8500円という値段は、ほとんど手作りに近い状態で作られて会社で売られるにはまっとうな値段だと思うが、ちょっと一瞬遊んでみるには一瞬躊躇する値段かもしれない。

どうせブレッドボードで使うのなら、最初っからパーツをブレッドボード上にくんでしまったら安上がりでは？とおもったので手持ちのパーツを使ってやってみた。回路図を見る限り USB-UARTに PSoCがつながれて、 LEDとSwitchが１つづつオマケにつながっているだけだ。LEDはアクティブハイにドライブされており、SWは内部 pulldownでVCCに直結されている。回路図をみながらとりあえずそのままボード上で再現してみた。

なにも難しいところはないけど、パズルのように配線をおこなって、まあ、これでいいんじゃないか？というところまではたどりついたので晒しておこうとおもう。

モジュールが秋月なのですべて秋月電子でそろえるとして、トータルコストとしては、
AKI-UM232R 950円
CY8C29466 500円
ブレッドボード EIC-102BJ 700円

とまあブレッドボードをいれても２０００円強といったところ。

ブレッドボードには余分があるのでこの上に簡単な回路なら足すことはもちろん可能だ。そのためにベースは片側に寄せてくみ上げてある。

互換とするにはさらに電流制限抵抗とLEDとタクトスイッチが必要だが、電子工作をするものならこれくらいはパーツ箱から出てくるであろうということで、コストには加算していない。

これで合計2150円である。PSoCライターがない場合は PSOCのライターであるCY3210-MiniProg1 4000円が必要となるが、この場合にはminiprogにサンプルとして29466がついてくる。

とりあえずサンプルプログラムが動いたので、満足して作品として完成させるのはまた次回ということで。

（メモ）DoCoMo A2502の制御ポートアクセス

2008-02-27T00:08:00.003+09:00

ずいぶん間があいてしまったけど「NetBSDでDoCoMo A2502をつかう」の続き。

DoCoMoのA2502は、正しくアタッチするとシリアルポートが３本生成される、ということは前回のエントリーで書いた。最初の一本は通信するためのモデムポートだが、残りの２本は通信以外に利用されている。

３本目のシリアルポートは通信制御や各種情報を取得するために利用されているようなので、少し中身を見ていたが、まとまったのでメモとしてここに書いておくことにする。

３本目のシリアルポートの使い方

D02HWなどと違って、atコマンドを受理したりはしてくれない。バイナリを送るとバイナリで返事をくれる、という仕様になっているようだ。（コマンドを全部解析したわけではないが、とりあえずアンテナレベルの取得くらいははできる。）

処理シーケンス

シリアルポートをオープンする
｛0xcf, 0x18, 0x00, 0xc0, 0xdd, 0x7e｝を書き込む。
12バイトの返事がくるので読む（解析していない）
｛0xcf, 0x00, 0x00, 0x91, 0x86, 0x7e｝を書き込む
14バイトの返事がくるので読む（解析していない）

ここまでで準備はおしまい。その後に適切なコマンドを送ると、いろいろな情報を取れる。

｛0xcf, 0x07, 0x00, 0x99, 0xcb, 0x7e｝を送ると、自分の電話番号などが含まれた51バイトの情報が返ってくる。（電話番号は5から16バイトの間）
｛0xcf, 0x01, 0x00, 0x49, 0x9f, 0x7e｝を送ると、シグナルレベルや、つながっているネットワークのIDが含まれた58バイトの情報が返ってくる（シグナルレベルは7バイト目、ネットワークIDは26から40バイト目）

みたいな感じ。ほかにもショートメッセージサービスへのアクセスができたりするようだが、そこはまだ見ていない。

rubyを用いたサンプルコード

というわけで、アンテナレベルと繋がっているネットワークの名前を出力するサンプルコードを載せておく。今回はrubyで書いてみた。シリアルポートのサポートライブラリにruby-serialを使っているので動かす場合にはインストールしておくこと。


require "serialport"

# open control serial port 38400/N81
sp = SerialPort.new("/dev/ttyU2", 38400, 8, 1, SerialPort::NONE)
sp.flow_control= SerialPort::NONE

cmd0   = [0xcf, 0x18, 0x00, 0xc0, 0xdd, 0x7e].pack('C*')
cmd1   = [0xcf, 0x00, 0x00, 0x91, 0x86, 0x7e].pack('C*')
telno  = [0xcf, 0x07, 0x00, 0x99, 0xcb, 0x7e].pack('C*')
antcmd = [0xcf, 0x01, 0x00, 0x49, 0x9f, 0x7e].pack('C*')
cnt = 0

sp.write(cmd0)
buf = sp.read(12)
sp.write(cmd1)
buf = sp.read(14)

sp.write(telno)
buf = sp.read(51)
data = buf.unpack('C*')
telno = data[5..16].map!{|c| c.chr}.join
print "tel no:" , telno, "\n"

while (cnt < 20)
  sp.write(antcmd)
  buf = sp.read(58)
  data = buf.unpack('C*')
  network = data[26..40].map!{|c| c.chr }.join
  print "signal level:" , data[17], " [network:" , network , "]\n"
  cnt+=1
  sleep 1
end

出力は


$ ruby a2502ant.rb
tel no:080XXXXXXX
signal level:20 [network:]
signal level:20 [network:]
signal level:20 [network:]
signal level:20 [network:]
signal level:20 [network:]
signal level:18 [network:]
signal level:18 [network:NTT DoCoMo]
signal level:19 [network:NTT DoCoMo]
[省略]

のようになる。アプリケーションを作る場合などにそれなりに使えるかな。

（メモ）DUS01まとめ

2008-02-17T20:59:00.009+09:00

忘れる前にワンセグチューナーDUS-01の挙動についてメモしておく。半分は自分のため、あとの半分は「２４時間ワンセグコミュニティ（？）」のため。Linuxやwindowsで使うときにどうぞ。

ハードウェア

CPU: Silicon Laboratories C8051F342
チューナー： sharp VA1A5JZ9902A (参考リンク：ascii24)
アンテナ：ロッドアンテナ
インターフェイス： USB1.1

シャープの9902Aは１－２世代前のワンセグモジュール。最新版には及ばないが感度が-107dbmは優秀なんじゃないかと思う。googleで探したけど仕様書等は見つからなかった。残念。

USBデバイス情報
USBデバイスとしては、こんな感じ。ほかに何をかけばいいのかな。

Vendor ID:0x1bc8 , Product ID:0x0001
endpointは0,1,2,3の４本。
EP1は制御用のバルク転送エンドポイント（読み書き可能）。
EP3はMPEG2TS転送用のアイソクロナス転送エンドポイント（読み込み専用）
EP2は使っているのを見たことないけど、ファームウェアアップデートなどに使うのじゃないかと推測
起動時にファームウェアロードなどは発生しない。電源を入れれば動く。

さらに詳しく知りたい人のためにNetBSDのusbgenの出力を載せておく。

CONFIGURATION descriptor index 0:
bLength=9 bDescriptorType=2 wTotalLength=46 bNumInterface=1
bConfigurationValue=1 iConfiguration=0 bmAttributes=80 bMaxPower=150 mA

INTERFACE descriptor index 0, alt index 0:
bLength=9 bDescriptorType=4 bInterfaceNumber=0 bAlternateSetting=0
bNumEndpoints=4 bInterfaceClass=0 bInterfaceSubClass=0
bInterfaceProtocol=0 iInterface=0

ENDPOINT descriptor index 0:
bLength=7 bDescriptorType=5 bEndpointAddress=1-out
bmAttributes=2 wMaxPacketSize=64 bInterval=5

ENDPOINT descriptor index 1:
bLength=7 bDescriptorType=5 bEndpointAddress=1-in
bmAttributes=2 wMaxPacketSize=64 bInterval=5

ENDPOINT descriptor index 2:
bLength=7 bDescriptorType=5 bEndpointAddress=2-out
bmAttributes=2 wMaxPacketSize=64 bInterval=5

ENDPOINT descriptor index 3:
bLength=7 bDescriptorType=5 bEndpointAddress=3-in
bmAttributes=1 wMaxPacketSize=188 bInterval=1

制御コマンド
制御コマンドはEP１をつかってやりとりする。今のところ分かっているコマンドはこれだけ。全部推測なので正しいかはわからないけど。

ファームウェアバージョンチェック　(0x9f) - 現在のファームウェアのバージョン（1.0.0）が返ってくる。
チャネル設定 (0x10) - これに加えてKHz単位の周波数をくべるとチューナーが設定される。
入力検出(0x11) - 電波が受信できていたら0x1、受信できなければ0x0が返ってくる。
ストリームモードチェック（0x12)　- たぶんMPEG2TSストリームを出しているかしないかをチェック。
ストリームスタート (0x20) - EP3へのMPEG2TS出力を開始する。
ストリームストップ(0x21) - EP3へのMPEG2TS出力を停止する。
シリアル番号チェック(0x43) - デバイス固有のシリアル番号を返す。

（2008/2/18 1:30修正：miroさんありがとうございました。)

それぞれのコマンドは10byte長で、先頭にコマンドを、引数がないものは0x0で埋めて送る。
チャネルを変えるときのシーケンスは

ストリームが出ていたら止める
止まったかモードをチェックする
チャネル変更リクエストを出す
ちょっと待つ
入力検出リクエストを出す
返り値をチェックして0x0だったら「ちょっと待つまで戻る」。0x1が出るまでがんばる。（もしくはタイムアウトする）
ストリームを出力する

って感じ。チャネル設定コマンドは、{0x10, 0x04, 0x00, A, B, C, 0x00, 0x00, 0x00, 0x00}　というフォーマットで、A,B,CにKHz単位の周波数を指定する。たとえば、521.43MHz(チャンネル21)なら{0x07, 0xf3, 0xb7}を埋め込めば良い。
(2008/2/19修正：チャネル設定コマンドの例の先頭バイトをtypoしていたので修正）

出力ストリーム
EP3からはMPEG2TSもどきが出力される。先頭はMPEG2TSで規定された同期ビット列（0x47）でかつ、パケット長が１８８Byteというのは良いのだが、MPEG2TSとして解釈すると全部エラーになる、という変な状態。きっと、プログラムミスでこうなってしまっているのだろうとおもう。あまりにも不憫なので正しいストリームに治してあげよう。
「先頭の0x47を除いて、他のバイト列に対して0xb5を排他的論理和を取る。」
すると、普通のMPEG2TSになる。

まとめ
USB的には、「USBデバイスとしてのJ200への不満」、はほぼ解決されているようなデバイスだった。最初はストリームが見えるか少しどきどきしたが、まあすぐにわかってよかった。
まだ入手性もよいみたいだし、ここにある情報を使えば他にも対応ソフトを作れそうな人がいると思うので、いけているデバイスじゃないかと思う。明日もう少し補充を（自分用に）買っておこう。。

NetBSDで「24時間ワンセグ野郎」(新デバイス)(3)

2008-02-17T19:39:00.006+09:00

新デバイスさらに続き。

バイトストリームを眺め続ける人生にもちょっとだけ疲れたので、ここらで絵（と音）でも見てみたい、という願望が大きくなってきた。というわけで、ちょっと真面目に絵と音声を見る部分を書いてみることにした。もし絵とか音声が見えたら、それがちゃんとしたMPEG2TSストリームとして扱えているか？っていう検証になるし。（バイトストリームを検証するためにはちゃんとパーサーと表示系をいちいち書かないといけないから、すぐには対応できないし）
というわけで、新デバイスでも生TSをキャプチャして録画までできることを確認できた。（絵は今とったらこれだった、てだけ、意味はないです）。ワンセグチューナさわっていて初めてまともに絵を見たよ。

下手に書いちゃって動かないのに買っちゃう人がいたら災難だから「新デバイス」とだけ書いていたけど、これで今まで伏せていた製品名をかける。写真のRockridgesoundのDitune(DUS-01)が最近触っていたデバイス。秋葉原だと３０００円弱で買える＆結構店頭に並んでいるので見たことがある人も多いかもしれない。
外部アンテナはつながらないけど、選択肢の一つとしてはいいかな、と思っている。

NetBSDで「24時間ワンセグ野郎」(新デバイス)(2)

2008-02-17T17:49:00.003+09:00

新デバイスの話再び。

前回のエントリー（NetBSDで「24時間ワンセグ野郎」(新デバイス)）に、生TSっぽいのが出ているとかいてしまったが、ちょっと寝てから冷静に見直してみると、なんか変だということに気がついた。

簡単にいえば、「先頭の0x47以降は本来受信したはずのデータ列と異なっている」ようだ。キャプチャされたTSの解析結果も載せてあったので、鋭い人なら一目で気がつくような気もするけど、異様にフラグが多かったり、アダプテーションフィールド長が255だったり、（あそこには含まれていないけど、PIDが0x1fffを超えていたり）、していた。

また、

だいぶ感度が悪そう。ちょっと、置き場所を変えるだけで、MPEG2TSのパケットでTS_ERRORフラグが立ってしまう。あんまり頻度が高いと、TS_ERROR付きでも眺めてみる、みたいな処理に変えないといけないかもしれない。

とも書いていたが、これもTS_ERRORビットの値がずれているのが問題だったようだ。値を読み替えてからみてみると、感度はそんなに問題ないみたい。

幸いにもMPEG2TSヘッダは固定長で単純かつ、特定の部分に決まった情報が出やすいという特徴があるので、しばらく眺めていると変換のパターンは見えてくる。もう少し解析しないとだめだけど、今のところ、「各バイト単位で特定の値で排他的論理和をとる」っていう単純なルールでもとに戻るようだ。（コンティニュティカウンタの値が1->0->3->2->5と進むところで、XORじゃないか、って推測できたのが決め手だった）。

というわけで、今度こそ生TSだと思われる出力。それっぽくなった。
これで、MPEG2TSパーサーに戻れる。

NetBSDで「24時間ワンセグ野郎」(新デバイス)

2008-02-16T14:02:00.005+09:00

このエントリーの一行まとめ：　使えるUSBワンセグチューナーは、実はたくさんある、かも？

本家の昨晩のエントリーでふれられていた「一部で非常に不評なLOG-J200のUSB（笑）」をおもに専門に扱っている：）わけですが、そこに非常に気になる記述があった。

ちゃんとエンドポイントは分かれてるしTSのデータはアイソクロナスで送ってきているし ^^; なんといってもコントロールコマンドがシンプル簡単で使いやすい！(笑) それこそ他OSでいじるベースとしては便利そうな感触ですよ。USBXPressではなく今度はEZ-USBベース、そして実売価格は3000円。探せばいろいろあるものです。

しかも入手性がいいようなので注目に値する情報だ。これで、２４時間ワンセグ野郎コミュニティ（？）もさらに盛り上がるに違いない。
と、そのエントリーを読んだのが午前２時半すぎ。それまでは、ARIBの資料を眺めながらワンセグのMPEG2TSストリームの制御情報を処理する部分をつらつらと書いていたのだが、デバイスを触りたい気分がいきなり盛り上がってしまった。私も実は、その辺でみかけるたびにUSBデバイスを買ってあって、そろそろ家があふれそうだったりしているので、そのなかでまだ開けていなかった箱をいくつか取り出してUSBストリームを眺める、という作業に従事してみた。

2-3種類眺めてみると、やっぱりいろいろと特徴が見えてくる、その辺の話はまた今度まとめる機会を探すとして、また新しく「188byte単位の情報転送 & 先頭バイトが0x47」のストリームを吐くチューナーを見つけてしまった。俄然盛り上がったので、NetBSD用のデバイスドライバも書いてみた。（おかげで眠い）

このデバイスは、

CPUは8051ベース(シリコンラボラトリC8051F342)
チューナーはシャープ製
アンテナはロッドアンテナのみ
眩しく光る青色LED付き
３０００円台のお得な値段で入手可能かも

というハードウェアで、基板を眺める限り、J200よりは出来がよさそう。挙動としては、

コマンド用のEndpoingとデータ用のEndpointがわかれている
データ用Endpointはアイソクロナス転送で188Byte単位で送ってくる
初期化コマンド等はほとんどいらない。お行儀よくチャネル切り替えをすれば動く
電波が安定するまではストリームを出力しない。チューナーがセットアップされたかどうかを問い合わせてみて0x1がかえってきたら、転送開始、みたいな処理をする。

というかんじで、この前のエントリに書いた不満はおおむね解消されているようだ。

ただ、気になるのが、まだソフトウェアが悪い可能性もあるので何ともいえないけど、だいぶ感度が悪そう。ちょっと、置き場所を変えるだけで、MPEG2TSのパケットでTS_ERRORフラグが立ってしまう。あんまり頻度が高いと、TS_ERROR付きでも眺めてみる、みたいな処理に変えないといけないかもしれない。付属のソフトではそんなに画像が乱れるみたいなことが頻発するわけではないので、もう少し調査が必要。
MPEG2TSのストリームはとれているみたいなので、もう少し調査して詳細をお知らせしたいとおもいます。というわけで、MPEG2TSストリームが出ている証拠も載せておきます。先頭バイトが0x47だけ、ってわけではないので安心。

基板CADと基板加工機

2008-02-15T04:05:00.006+09:00

回路・基板CADとして制限はあるもののフリーで使える Eagleは非常によくできたツールである。
しかし、なぜか操作性があまりにも普通のGUIソフトと違うところは非常に残念だ。

とはいえダウンロードするだけでサイズ制限はあるものの２層基板をオートルートしてくれるというのは非常に便利である。さらにこの手のソフトに珍しくWindowsのほかに MacOSとLinuxもサポートしている。

このEagleも新しいバージョンのテストがおこなわれておりメジャーバージョンアップが近いようだ。次のバージョンからは Mac版がX11に依存しなくなるのでそれに期待しつつ、今日は現行の 4.16とベータ版の 4.92のアイコンが微妙に違うという写真をのせておこう。

これからしばらくはマイコンと同時に基板CADとそれを使ったプリント基板の作成方法の備忘録も載せていこうとおもう。

（ワンセグ）電波時計（の特性）

2008-02-15T00:19:00.006+09:00

一発芸のつもりだった「ワンセグ電波時計」だったが、もう少し詳しく特性を調べてみることにした。
ARIBの仕様書では時刻情報（TOT)のデフォルト送出間隔は５秒と決まっているらしいが、その５秒刻みというのがどのくらい正確なのか？というあたりを知りたくなったからだ。

前回のエントリーではNTPで同期しているNetBSDの時刻情報と並べて表示していたが、今回はgettimeofday()を使ってマイクロ秒単位でTOTとTOTの間隔を計測してみた。108個（つまり540秒ほど）連続して受信したTOTの間隔の統計的な値を表に示しておく。

思っていたよりも精度が高いようで、うまくつかえば結構便利かもしれないな、と別の野望も妄想中。簡単な機材で大域時刻同期ができるって結構すごいことなんだよね。

（ワンセグ）電波時計

2008-02-14T16:13:00.003+09:00

ワンセグのストリームを眺めていてふと思いついたので、つくってみた。
「ワンセグのストリームだけを使う時計」略称「ワンセグ電波時計」。

どのくらいの精度がでるのかな、とおもってNTPで同期しているシステム時間も同時に表示してみたけれど、少なくとも秒単位では合っているみたいだ。更新頻度は5秒おきなので、それくらいの精度しか出ないと思うけど、なんか使えないかしら？

NetBSDで「24時間ワンセグ野郎」(2)

2008-02-14T03:21:00.007+09:00

さすがに平日はあまり時間が取れないので、あっと驚くような進捗があるわけではないけど、進んでいないというわけでもないので、メモがてらに書いてみることにした。Log-J200のUSBデバイスとしての感想など。

USBデバイスとしてのLog-J200
ざっくりいうとLog-J100もUOT-100も同じなんだが、どれもこれもUSBデバイスとしてみたときにはあまりいけているデバイスだとは言い難い。一言でいうなら、

USBデバイスのファーム設計のセオリーを見直してこい！

と、受け側のソフトを書きながら思わずデバイスに突っ込みをいれてしまうような、そんな仕様がいくつもある。たとえば、

機能とエンドポイントの分離がうまくできてない、とか
コマンドを受理しても返答しない、という動作をするコマンドがある
なぜかbulk転送になっているMPEG2TSストリームの転送モード、とか
なぜか64Byte長で細切れな転送

とか。最初の「エンドポイントの使い方」は、endpoint０でやればよいようなデバイスの制御が、なぜかMPEG2TSストリームをやりとりしているendpoint2にのっている、とか、そのあたりが顕著な例。２つめも問題で、USBのホストコントローラ的には受理したならackを返してほしいと思っているのに、黙ってしまうのでコマンドがストールしたように見えてしまう。必ず受理される、と信じて送らないといけないのはどうかとおもう。
で、性能上問題になるのは３つめと４つめ。MPEG2TSのパケット長は188Byteで、空から約380KBps程度の速度でどんどんと情報が降ってきている。これを受け取るそばからUSBバスの上に流してあげる、というのがUSBワンセグチューナデバイスのお仕事。（たぶん）普通はこんな特性の情報を扱うためには、USBではアイソクロナス転送モードというのを使うことになっている。アイソクロナス転送にするとハンドシェイクやリトライをしないので時間制約に即した転送ができる、ので、次々に発生する事象（音とか映像とか電波とか）を扱うのに向いている。Log-J200（とその仲間たち）はなぜかMPEG2TSストリームの転送にBulkエンドポイントを採用している。Bulkエンドポイントでは転送サイズは64byteまでなので、188Byteの転送をするために少なくとも３回（J200の場合は４回）の転送要求発行しないといけない。

ちょっと計算してみるとわかるのだが、ワンセグのパケットは約1.2msくらいに一回の周期で受信される。つまり、1.2ms以内に４回のトランザクションを必ず発行するような動作をしていないと取りこぼしてしまう。
いまどきの速いコンピュータにとっては1msなんて無限な時間にみえるかもしれないが、実時間動作が苦手なUNIX系のOSではちゃんとやらないと実際に取りこぼしてしまう場合があった。

特に今回はugenをつかったユーザーランドアプリケーションとして書いてみているので、そのあたりは結構シビアだなあ、というのが感想。eggmanさんのlinuxデバイスドライバの話をみて、「やっぱりカーネルデバイスドライバのほうがかっこいいし、オーバーヘッド少なくなるからよいだろうなあ。」と思ったのは内緒だ。いつか気が向いたらkernelのデバイスドライバも書いてみよう。
でも、アイソクロナス転送のしてくれていれば、ユーザランドからさわってもこんなことは起こらないので、やっぱり設計に難がある、っていう気がしている。

ちなみに、内部バッファとかも持っていない設計になっているようで、USBデバイスへのポーリングが遅れるとデータの一部が化ける（nバイトシフトしているように見える＆nバイト足りない）。最初は何で先頭にMPEG2TSの先頭バイト（0x47）が現れない場合があるんだろうか？と悩んでしまったが、USBアナライザの時間計測モードをつかってみたら、アクセス間隔がWindowsでみた場合とくらべて長いかった。
複数のkerenlへのリクエストをまとめるとか、小技を使って解決している。

Log-J200の受信感度
外付けアンテナがつくのであんまり問題にならないんだけど、受信したMPEG2TSストリームを数字で眺めていると、数パーセントの割合でエラーが出ているみたい。エラーとしては以下の３パターン。

そもそも受信できていない。MPEG2TSのカウンターを計測していると取れなかったことがわかる
MPEG2TSのトランスポートエラーインジケーターの値が1になっている。つまり、受信時に「このデータ使わないほうがいいじゃない？」と言ってきている
先頭バイトが0x47じゃない。タイミング制約は満たしているはずだとは思うけど、たまに発生する

特にトランスポートエラーインジケーターは受信を開始してから２００パケットくらいに全部ついているので、受信機が設定されてから正しいデータ出すまでに300msくらいはかかるってことかな？

NetBSDの24時間ワンセグ野郎の現状
とまあ、USBレベルでは取りこぼしもなく普通に受信情報を取り出せている。とりあえず受信データMPEG2TSの状態でファイルに書き出すこともできる。とまあ、そのくらい。いまは画像を眺めるというよりは、受信したストリームを数字で見ながら、ヘッダとかペイロードとかのいろいろな部分のパーサーとダンプ関数を書いてみて、「ほほー」とか言いながらにやけている状態。今日の参考資料はARIB-TR-B14（英語版）とかARIB-STD-B10(英語版）。なぜ英語かというと無料で公開されているから。（ARIBの英語版配布サイト）

というわけで、外堀はほとんど埋まっているような感じですが、本家みたいな作りこみをできるまでには、まだしばらくかかりそうです。

最後に色気はないけど、動作中のテキスト出力など。ワンセグっていうことでPID=0x1fc8のパケット情報。本当になんかプログラムを書いている、ってい証拠に（なるかな？）。


== MPEG2TS header (PID:0x1fc8) -:P == Cont count:08, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:09, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:10, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:11, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:12, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:13, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:14, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:15, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:00, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:01, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:02, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:03, Flags PUSTART TRANSPRIO
== MPEG2TS header (PID:0x1fc8) -:P == Cont count:04, Flags PUSTART TRANSPRIO

NetBSDで「24時間ワンセグ野郎」(1)

2008-02-12T01:23:00.000+09:00

MobileHackerz再起動日記で開発が進められている「24時間ワンセグ野郎」だが、ひと月ほど前のエントリーを見たときから「すげえ」素直に感嘆していた。「これはいけてる！」とおもって、その場でUOT-100を６本ほど買ってあった、ということからも（今はすでに入手困難だということを考えて）本当にぐっときたことは推測してもらえると思う。
ちょっと忙しくしていたので出遅れてしまったのだが、これができるということは、別のOS、たとえばNetBSDでも同じようなアプリケーションを構築できるんじゃないかとおもってやってみた、というのがこのエントリーの内容。
この３連休の時間で始めたことなので、本家の完成度には到底およばないけれど、最近一部でブームも盛り上がってきているようなのでちょっと参戦してみようと思う。

UOT-100を持っているから、といってもそれをそのまま使うのは二番煎じすぎる。本家にもなにか貢献できないかなーとおもって最近どこかで安いワンセグチューナを見かけるたびいくつかを購入してみていた。分解したり、USBのデータストリームを眺めていたりもしたのだが、まだ「これは！」という機種には出会えていない。
今回は、Log-J200をつかってワンセグ野郎をしてみることにする。
Log-J200はUOT-100と似たデバイスで、UOT-100と同様に「生TSをバス上に流している」ので、扱いが簡単だから、というのと、「まだ入手できるから」というのが理由。

いきなりkernelドライバを書いてもいいのだが、「ugenでラピッドプロトタイピング」という話も書いていたし、今回は

NetBSD ugenをつかったユーザランドアプリケーションで実装
ハードウェア改修なしに複数デバイスに対応
（できればネットワークサーバ化）

という感じでいってみている。

先に、現状を書いておくと、昨晩から２４時間（当然途中では寝ているしごはんもたべてる）くらい経過したところで、

NetBSDで複数デバイス同時に認識
Windowsデバイスドライバには非依存
とりあえずチャネルは２チャンネルくらいは変更可能
生TSだと思われるファイルを書きだしている（けど、まだみえない）
MPEG2TSの簡単なヘッダパーサを書いて、それなりにエラーハンドリングをできるようになりつつある

くらい。パケットダンプを見ている限り、それなりに正しくMPEG2TSのキャプチャはできているようにみえるので、あともう少しで画像がみえるか？という期待でここまで来ている、というところ。Log-J200は分解が大変（というか分解するとたぶん復元できない）ので、ハードウェアを触らなくてもいいというのは大きな利点じゃなかなと(個人的には）おもっている。

というわけで、現状報告を先にしておく。ソースをまとめたら公開予定（BSDライセンス）。
次のエントリーで解析した内容を書く予定。

週末の娯楽としては大変楽しめたし、これからもちょっと楽しめそう。がんばろう。

NetBSDでDoCoMo A2502をつかう(-currentにマージ）

2008-02-11T11:31:00.000+09:00

「NetBSDでDoCoMo A2502をつかう」で書いたようにNTT DoCoMoの3G/HSDPAモデムFOMA A2502をNetBSDで使えるようにして、patchを本家に送っておいた。
今日（2/11）無事に-currentにマージされたようだ。

D02HWにつづいてA2502も今日以降のNetBSD-currentを入れれば使えるようになる。
A2502もちょっと解析（アンテナレベルの取得とか）を進めていたので、もう少し進んだらまとめてみようとおもっている。

今日はお知らせだけで。

NetBSDでSONY GPS-CS1Kを使う

2008-02-07T03:00:00.000+09:00

SONYはGPS-CS1KというGPSロガーを発売している。ずいぶん前（発売直後）に買ってあったのだけど、実はあまり使わずに棚の上のオブジェと化していた。一緒にblogをかいているCUEICHIがGoogle Mapと位置情報で遊んでいたのをみてGPSを持っていることを思い出しGPSを使おうと盛り上がった。
が、なぜかNetBSDでは動かない（OSXでも動かない。。）ので原因を調べてみた。
kerenlからのメッセージと、USBバスアナライザの出力を見る限り

UR_BBB_GET_MAX_LUNリクエスト受け取ったあとデバイスの挙動がどうも怪しい
しばらくリトライすると復帰する

ようだ。リトライのコードを入れてもいいのだが、他のデバイスへの影響が大きそう。あまり美しくはないがNetBSDのumassの例外コード(umass_quirks)を拡張してUR_BBB_GET_MAX_LUNを発行せずに決め打ちでLUNを指定する、というロジックを導入してみることにした。

その結果、sd０ on umass０として認識されるようになって、mount -t msdos /dev/sd0a /mntでディスクとしてマウントできるようになった。とりあえずpatchはsend-prしてある(kern/37948)。

NetBSDで動くようにはなったが、GPSロガーをどんなふうに使うかはまだ思案中。

こんなデバイスをみるたびに、「Windowsで動けばいい、みたいなデバイスの作り方はしないでほしいなー」と思う。で、同時に「Windowsのホストドライバってなにかあってもあきらめずに頑張るなー」とこっそり感心する。ここは純粋に評価してもいいね。

NetBSDでDoCoMo A2502をつかう

2008-02-07T01:23:00.000+09:00

別に３Gモデムを攻略するのが趣味ってわけではないが、近くにNTT DoCoMoのHSDPAモデム A2502 (製品情報）があったのでどんなものか眺めてみた。結構あっさりとNetBSDで動くようになったので方法を書いておく。

A2502はAnyData社の製品とのことだが、イーモバイルのD02HW(HAUWEIのE220)みたいにメジャーな製品のOEMというわけではなさそう。検索してもあまり素性がわからないので、とりあえずUSBバスを観測してみたところ、コマンドの系列がこの前書いたD02HWと互換性がありそうだ。というわけで、とりあえずモデムモードになったあとのD02HWと同じように扱ってみたところ通信ができることを確認。

モデムとしては、

comポートが３本でてくる。ATコマンドを受理するのは最初の１つだけ。２つめは不明。３つめは網の情報がでているっぽいけど、特に処理するコードは書いていないので見えない。
D02HWみたいにUSBマスストレージがついていたりはしない、普通のモデム
変なコマンドを送らなくても、最初からモデムとして動く

なので、D02HWよりは扱いやすい。ただ、不明なvendor specific requestがいくつもあるのでそれがなにかわからないのはちょっと気持ちわるい。

コード的には、いくつか初期化シーケンスを書いて、uhmodemをD02HWとA2502両用になるようにさらに汎用的なドライバとして整理しておいた。やったことは

deviceのvendor id, product idの構造体にいくつかの補足情報（comデバイスの数、デバイス種類のフラグ）を持つようにした
シリアルデバイスになるインターフェイスごとにちゃんとendpoint haltをかけるようにした。
いままで決め打ちだったendpoint 番号をusbフレームワーク的に解決するようにした
いままで決め打ちだったデバイス依存リクエストを整理して両方でつかえるようにした

というあたり。見直した結果コードは少しきれいになった。新しいデバイスに対応するのがもっと簡単になりそう。もう少しつかってみてから、NetBSD本家にsend-prしておく予定。寝る前にだせるかな。(追記：　done)

とりあえずpppでつなげてみたところ、DoCoMoの網の挙動はイーモバイルの網とは違うことがわかった。
たとえばRTTの変化。イーモバイルはしばらくパケットを投げているとある段階で急にRTTが短くなるが、DoCoMoの場合はステップ的に減っていく。最終的は二つとも同じくらい(70ms-100ms)で収束するが、途中経過が違うのがおもしろかった。
（追記：　emobileでもう一度RTTを計ってみたところ500ms → ２００ｍｓ程度までしか変化しなかった。挙動がかわったのかもしれない。そういう意味ではDoCoMoの網のほうが良い特性かも？）

速度は追いこんでいないけど、SSHでscpして10MBくらいのファイルを転送したところ200KB/secくらいでていた。そんなに悪い数字じゃないね。

追記：　NetBSD-pr kern/37978 すぐに試してみたい人はこれを見て手でパッチあててください。最近のcurrentには当たるはず。

ugenでラピッドプロトタイピング(*BSDでUSB）

2008-01-28T20:39:00.000+09:00

*BSDにはugen（usb generic device）という汎用のUSBデバイスドライバが実装されていて、USBデバイスを刺したときに適切なデバイスドライバが見つからなかったときには、ugenデバイスしてアタッチするようになっている。普通は「なんだugenかよ」と思って「サポートされてないじゃんか」となる（普通じゃない人は「しょうがないからデバイスドライバ書くか」となる）のだが、実はugenとして見えるのはそれはそれで大変意味があることだ。
というわけで、ugenを使ったrapid prototypingについて書いてみようと思う。

ugenが出来ることは、

/dev/ugenN.MMというスペシャルファイルを介したUSBデバイスとのエンドポイントとの通信

で、read(), write(), ioctl()をつかって、USBデバイスの概ねほとんどの機能にアクセスできる。USBは「ユニバーサルシリアルバス」なのでread(), write()できれば、適切なアクセス方法をプログラムできれば大体なんでもできるはずだ。
もちろん、ugenもデバイスドライバなので、あるデバイスに適切なデバイスドライバが実装されていてkernelにコンフィグされているときはugenとしてアクセスすることは出来ない。(kernelコンフィグによっては強制的にugenにすることもできる。man ugen参照のこと）。

ugenで実装することとkernelで実装することの利点・欠点をまとめると、

ugen利用の利点：

kernelで実装しなくてもいいので、開発が楽
kernelに実装しなくていいので、配布や利用が楽
APIがあまり変わらないので、kernelバージョンがあがっても追従しやすい
ugenっぽいデバイスドライバがあるOSなら移植しやすい（かも）

ugen利用の欠点：

参考になる実装や文書が少ない
kernelに取り込まれることは無いので、マージはされない
kernelスペースとuserlandのやりとりが多いのでパフォーマンスは期待できないかも
kernel内のほかのフレームワークとの連携は難しい

という感じだと理解している。本質的にはkernelで書こうがugen経由で書こうがUSB的にはやることはほとんど変わらないので、kernelをかける人もプロトタイプツールとしてugenというのは検討しても良いんじゃないだろうか。

というわけで簡単な使い方から。基本的なステップは

usbctlなどのツールでUSB device descriptorを取得して、エンドポイントの構造をざっくりと理解する。D02HWみたいに何かしたら化けるデバイスもあるので、ugenの-Dオプションを使って全部のconfigurationをdumpしておくと便利。何回もみるので、ファイルに出しておいたり、印刷して脇に置いたりしても良い。usbctlとかusbgenコマンドはpkgsrcのusbutilを入れれば入るはず。
デバイスを刺したときにでたugenのデバイスのugenN.00をO_RDWRでopen()する。これがコントロールエンドポイント(EP0)になる。
開いたEP0に対して、ioctlでUSB_GET_DEVICEINFOを送りつけると、device descriptorが取得できる。取得したusb_device_info構造体にvendor IDとproduct IDが入っているのでこれでデバイスの認識をする。複数のデバイスをサポートしていないなら、お目当てのデバイスがみつからなければexitしてしまえばよい。
お目当てのデバイスがみつかったら、最初に調べておいたエンドポイントを必要な数だけopen()する。openするファイル名は/dev/ugenN.MMのMMがendpoint番号。endpointがINだったらO_RDONLY、OUTだったらO_WRONLYにするのを忘れずに。IN/OUTだったらO_RDWRで良い。
後は開いたファイルディスクリプタに対して、書き込んだり、ioctlを発行すれば、usbのバスに必要なトランザクションが生成される

と、こんな感じ。

デバイスを探索するコードのサンプルを書いてみると、


#include </dev/usb/usb.h>
int
XXX_match(int fd) {
  struct usb_device_info udi;

  /* get device information */
  if (ioctl (fd, USB_GET_DEVICEINFO, &udi) < 0) {
        perror("can't get device information");
        return -1;      
  }
  fprintf(stderr, "device info: VID:%#.4x PID:%#.4x\n", 
        udi.udi_vendorNo, udi.udi_productNo);
  /* check the device is XXX */
  if (udi.udi_vendorNo != XXX_VID || udi.udi_productNo != XXX_PID){
        fprintf(stderr, "can't find any NM30 on %s\n", dc->dev);
        return -1;      
  }
  printf("==== Found a XXX  ====\n");
  return 0;
}

のようになる。

使ってみていて注意しないといけない点は、

結構kernelの奥深くをさわっているらしく、お行儀が悪いとすぐにkernelパニックを引き起こす

ということ。openしたファイルディスクリプタの始末や、書き込むメッセージのサニタライズは最初からそれなりにお行儀よくしておいたほうがいい。

長くなったので続きは次回。

NetBSDでEmobile D02HWを使う(-currentにマージ）

2008-01-22T00:12:00.000+09:00

何回かにわたってD02HWをNetBSDで使う話を書いていたが、1/21付けでNetBSD(-current)にマージされた。
基本的に「NetBSDでEmobile D02HWを使う(新デバイスドライバ）」でsend-prしたものがおおむねそのままマージされたかんじ。cvsで吸い出すだけで使えるようになったはず。

使う人が出てきたら潜在的な問題とかが出てくるかもしれないけど、一段落。

Ruby on Rails で googlemapをかっこよく

2008-01-13T01:29:00.000+09:00

今回はいつものハードウェアとは趣が違って web サービスのテクニックの話である。

ruby on rails上でgooglemapをつかった表示を行うときにすこし気の利いたインタラクティブな動作をさせるところがトピックである。

ruby on rails で googlemapを扱うのに使われる pluginとしてym4r/gm というのがある。geocodingもふくめ非常に簡単に使えるのだが、逆に細かいところに手がとどかない。

事の発端はgooglemapの地図上のマーカをクリックすると吹き出し形式でメッセージが見られるインターフェースを実装したのだが、マウスオーバーで見られるほうがいいのではないかという意見をこのblogの共著のYUO氏から貰ったことであった。

そこでこの機能を実現するためにgoogleを何時間かしらべたが、googlemapの使い方はわかったものの、railsでの ym4rを使った例は英語サイトもふくめて直接的な回答にはいきあたらず、ym4r開発者のサポートBBSでもほぼ１年ほど放置プレイだったので備忘録もふくめて書いておく。

googlemap上でマウスをつかった特別なアクションを使うためにはaddListenerによってリスナを設定する必要がある。しかしながら、 ym4r/gm のコードをそのまま使ってマーカを設定するだけではこのような設定ができない。リスナを設定するためにはリスナになるオブジェクトを変数として代入し、バインドしてやる必要があるためだ。

declare_init をつかってオブジェクトを変数として宣言しなおしてやる必要がある。そしてこの後で、宣言された変数を使ってリスナを設定するのだが、このときに既存のメソッドは役に立たない。汎用につかえるrecord_initメソッドを使うことにより、 initializeのルーチンの中に自分で設定したjavascriptをそのまま書き込むことができるのでそれを利用することになる。

書き上げたコードの一部を切り出しておくと以下のようになる。

ポイントは markerを変数化するときに#{x.id} をつけることによりすべてのマーカで違う変数名を持つようにすることが１つ目である。もう１つのポイントとしては record_init をつかって直接 googlemapを動かすjavascriptのGEvent.addListener メソッドを記述するところである。また、変数 pで生成している htmlの終端に改行がはいっていると地図のjavascriptのレンダリングがうまくいかないようなのでちゃんと partialなレンダリングをした後にchompすることを忘れないことが大切なようだ。

さらに今回はlistenerとして mouseover のほかに mouseout を設定することで、マウスがはずれると即座にウインドウが自動で閉じる処理を行っている。

実装例


marker = GMarker.new([x.lat,x.lon],
       :title => " #{x.created_at.strftime("%m/%d-%H:%M")}" )
p = render_to_string(:partial => 'msg',
             :locals => { :tag => tag , :pm => x  }).chomp

@map.declare_init(marker,"marker#{x.id}")
@map.overlay_init(marker)
@map.record_init "GEvent.addListener(marker#{x.id},
  'mouseover',
  function(){marker#{x.id}.openInfoWindowHtml(\"#{p}\")}); "
@map.record_init "GEvent.addListener(marker#{x.id},
  'mouseout',
  function(){map.disableInfoWindow();
             map.enableInfoWindow();}); "

NetBSDでWatchdog timerを使う（CS5535/CS5536)

2008-01-09T23:04:00.000+09:00

ちょっと前にNetBSDでWatchdog timerを使う（for ALIX) (1) という一連のエントリーを書いたけれど、年が明けたころからNetBSD-currentへの統合作業をやっていた。手元にあるALIXでは普通に動くのだけど、ほかのボードではどうもうまく動かない（watchdog timerをenableすると一瞬でリブートされてしまう）と言うレポートが担当となったcommiterの人からあがってきてその理由を追ってみたので、メモがてらに何が起こっていたかを書いてみることにする。

元々のコードの仮定：CS5536のMFGPT0はNetBSD kernel以外では使っていない。だから、watchdog timer用のtimerとしてMFGPT0を決めうちで使っても問題無い

動かないといわれても動かないボードは手元に無いので、debugの出力をてんこ盛りにしたテスト用のドライバをつくって、何回かやりとりをしてみた。その結果

何者かがNetBSD kernelがアクセスする前に、MFGPT0を設定して（たぶん、何かの用途に使って）いる。

ことがわかった。MFGPTのsetupレジスタはほとんどのビットフィールドがwrite onceレジスタになっていて、一度設定されるとリセットするまで再設定はできない設計になっている。だから誰かが設定してしまうと、その後は必要な設定を上書きすることができないので事実上watchdog timerとしては利用できない。特に問題なのはタイマーの分周器の設定で、分周比が低すぎるとあっというまにタイマーがまわってしまって、watchdogが動く値に到達してしまう、というのがリブートされる理由だった。たぶん問題になったボードではBIOSなどが何かの用途に設定してしまっているのではないかと推測している。

この問題に対応するためにやったことは、

gcscpcib_attach()のwatchdog timerを設定するところで、gcscpcib_scan_mfgpt()という関数（とりあえず書いた）を使って、その時点で使われていないMFGPTを探して使うことにした
必要なら決めうちで利用するMFGPTを指定できるようにした

というあたり。更にマージする前に、もう少しお行儀の良いコードにしようと思って

MFGPT関連のレジスタの更新ロジックを、仕様書に指定されている「前準備」−「更新」-「後始末」というシーケンスでやるようにした。

前準備ではカウンタを止めたり、割り込みを禁止したりする必要があり、後始末では関連フラグをクリアしたりしなければならないらしい。手元のALIXではそんなことをしなくても動いていたんだけど、debugする過程で書いてしまったので正式採用した。更に

watchdogの間隔を最低値（1秒）にすると運が悪い時にリブートしちゃう問題、が起こらないようにタイマーの精度を1Hzから4Hzにあげた。
define一つでタイマーの精度を指定できるようにした
まともなdebug messageを埋めた

あたりを入れ込んだ。

元々はAMD CS5536用のコードとしてsend-prしたが、CS5536とCS5535はほとんど一緒、ということもあって共用のドライバーとして扱うことにした。で、名前もOpenBSDのglxpcibからgcscpcibという名前に変更。

というわけでHEADにマージされました。cvswebでは明日以降ならみえるんじゃないかな。

NetBSDでEmobile D02HWを使う(新デバイスドライバ）

2008-01-05T02:13:00.000+09:00

NetBSDでD02HWを使うためにいろいろとやった結果、前回のubsaデバイスドライバへのパッチというアプローチではどうも差分が大きくなりすぎる、という結論に達した。新しく別のデバイスドライバとしたほうがなにかと都合がよいので、uhmodem (USB huawei modem)という名前の新しいデバイスドライバをつくってみた。と、いってもubsaとの共有部分も多いのでそのままコピーして変更するのもいまいちな気がしたので、ubsa.cをubsavar.h, ubsa_common.c, ubsa.cの3つに分解して、uhmodem.cからはubsa_common.cを介してubsaの関数を使うことにした。

とりあえずdmesgを載せておく。


uhmodem0 at uhub0 port 1 configuration 1 interface 0
uhmodem0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
uhmodem0: mass storage only mode, reattach to enable modem
uhmodem0: at uhub0 port 1 (addr 2) disconnected
uhmodem0 detached
uhmodem0 at uhub0 port 1 configuration 1 interface 0
uhmodem0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
ucom0 at uhmodem0 portno 0: modem
ucom1 at uhmodem0 portno 1: monitor
umass0 at uhub0 port 1 configuration 1 interface 2
umass0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
cd0 at scsibus0 target 0 lun 0:  cdrom removable

attach時のメッセージを見てわかるように、uhmodemではD02HW(E220)が提供しているすべての機能(com *2, umass *1)を同時につかえるようになっている。
現状ではumassがつながっても、windowsのデバイスドライバが見えるだけだが、海外のほうでは、あの領域に好きなものを入れれるようなアクティビティもあるようなのでその時に役にたつかもなーくらいな気持ちでいれてみた。
ucom0, ucom1は前者が通信用のttyで、後者がモデムの状況や通信状況をモニターするための監視用ttyだ。ucom0を使っているときでもucom1を同時にアクセスできるので、メモ：D02HW解析に書いたDSFLOWRPTメッセージとか電波状態問い合わせ（^ANQUERY）の回答などを受け取れる。ユーザーインターフェイスアプリケーションを書くときには便利なはず。

というわけで、patchは大きくなったのでここに乗せるのは割愛しておく。すでにNetBSDにはsend-prしてある（kern/37692)ので急ぐ場合はそちらを参照すると良いかも。

とりあえずやることはおわったかなーーー。。

メモ：D02HW解析

2008-01-04T03:52:00.000+09:00

イーモバイルのD02HW (Huawei E220のOEM)をNetBSDから使えるように触っている過程で調べたことをメモしておく。

マスストレージモード(電源投入時)
普通に認識すると、USB mass strageデバイスに見える。USB class 8(umass), subclass 6(SCSI), proto 80(BBB)。Interface 0: endpoint: 3(in)-4(out)。マウントするとCDROMにみえて、中身にwindows用のユーティリティとデバイスドライバが入っている。役立たず。

モデムモードへの変換
Host-to-DeviceでSet Future: DEVICE_REMOTE_WAKEUP, wIndex=0x2で送りつける。すると同じvender ID, product IDのままで別のデバイスに化ける。
(wIndex=0x1にしてdataに0x1を入れて送っても同じ結果になるが、違いは不明）

モデムモード（変換後）
モードがモデムモードになると、インターフェイスが３つに増える。

インターフェイス１： USB class 255, subclass 255, proto 255。完璧なベンダースペシフィックだが実はシリアル。シリアルデバイスはBELKINのとほとんど同じにみえる（NetBSDだとubsaドライバ）。これがモデムの主インターフェイス。endpoint: 1(intr)-2(in)-2(out)。
インターフェイス２：USB class 255, subclass 255, proto 255。インターフェイス１と同様にシリアルデバイス。モデムの観測用インターフェイス。endpoint: 5(in)-5(out)。通信しないからか割り込みが無い。
インターフェイス3: USB class 8, subclass 6, proto 80。マスストレージモードのときにインターフェイス１に見えていたUSB mass storage。

モデムの観測用インターフェイス
つなげるとATコマンドを受理する。ステートは主インターフェイスの設定を継承している（たとえばate0と主インターフェイスで打ち込んであるとATコマンドにエコーバックしない）。使い道は２つ。

主インターフェイスで通信をしているときにもATコマンドを受理するので、AT^ANQUERY?（電波強度問い合わせ）などで状態を取得できる
主インターフェイスで通信しているときは定期的（２秒に一回）、^DSFLORRPTという行が出力される。

DSFLORRPT
DSFLORRPTはこんな感じに出力される。（一行で）


^DSFLOWRPT:0000007C, 00000000, 00000000, 000000000001B1AE, 00000000004DD9D2, 0000AA50, 000EBA40

ざっくりと眺めたところ、意味は最初から[通信時間（秒)], [送信スループット(byte/s)], [受信スループット(byte/s)], [総送信量(byte/s)], [総受信量(byte/s)], [なんかのID], [なんかのID]となっているようだ。時間とデータ量は16進数で表現されている。

謎のコマンド
windows PCとD02HWの間のUSBトランザクションを眺めていると、標準的ではない制御トランザクションが観測される。何やっているか不明。

（準備１）Endpoint:2-inにCLEAR_FEATUREリクエスト、ENDPOINT_HALTを送る
（準備２）Endpoint:2-outにCLEAR_FEATUREリクエスト、ENDPOINT_HALTを送る。
InterfaceにType:Class, bRequest=0x02, wValue=0x1, wIndex=0x0, wLength=0x2, Data[]={0x0, 0x0}を送る
InterfaceにType:Class, bRequest=0x22, wValue=0x1, wIndex=0x0, wLength=0x0を送る
InterfaceからType:Class, bRequest=0x21, wValue=0x0, wIndex=0x0で7byte読み込む。普通は｛0x0, 0x96, 0x0, 0x0, 0x0, 0x0, 0x8}が見える。
前のリクエストで取得したバッファの2-3byteを{0x8, 0x7}にして書き戻す。bRequest=0x20
InterfaceにType:Class, bRequest=0x22, wValue=0x3, wIndex=0x0, wLength=0x0を送る

たぶん、

bRequest=0x20: E220_CLASS_WRITE
ｂRequest=0x21: E220_CLASS_READ
bRequest=0x22: E220_CLASS_SETUP (or CMD)。ｂVlaue=0x1でstart, bValue=0x3でcommitみたいな感じ？

じゃないかと推測している。問題は読み書きする7byteの意味がわからない点。NetBSDで適当に実装して発行してみているが、何が変わったかはわからない。

通信時のUSBトランザクション
USBのendpointのデータ単位は64byte。TCP/IPで通信をしていると、大体46-48USBパケットがバースト的に送られてくる。モデム側のバッファサイズは3-4KBじゃないかと推測。

（おまけ）イーモバイル網の挙動
PPPで接続して普通にpingをうつと、RTTが300-400msくらいでガッカリする。しかし中身ではいろいろと複雑な制御をしているようで、5pps以上の頻度で同一ホストにパケットを送信すると、10-20パケットくらい経過してからRTTが70ms-100msに変化する。
しばらく通信がないとまたリセットされるので、フローごとに細かい制御をしているようだ。カットスルー？でもしてるんかいな。

とりあえずこのくらい。

NetBSDでEmobile D02HWを使う(スループット改善）(2)

2008-01-04T02:52:00.000+09:00

しばらくsys/dev/usbの下を眺めていたが、USB的な律速が他にあるとしても触るにはおおごとになりそうなので、別の部分から攻めることにした。

「Windowsなら速い」という話でふと思いついたのが「TCPの動作の違い」だった。Windowsはいろいろなパラメータ調整でTCPの挙動を変えているが、それがイーモバイルの網の挙動とうまくあっているのかもしれない。または、専用ドライバがWindowsのパラメータを自分好みに変えているのかも。というわけで、NetBSDのネットワーク部分のパラメータを調整してみることにした。これはkernelにpatchを当てるとかいう話ではなく、sysctlで変えれる範囲でおこなった。

とりあえず今のところの/etc/sysctl.confを以下に示す。


net.inet.tcp.mss_ifmtu=1
net.inet.tcp.init_win=8
net.inet.tcp.sack.maxholes=64
net.inet.tcp.sendspace=65536
net.inet.tcp.recvspace=128000
net.inet.udp.recvspace=65536
kern.sbmax=2048000

この中で一番意味があるのがtcp.recvspaceだ。emobile網を使っていて思うのは、

遅延はある程度大きいけど、そんなに落ちない。

ということだ。そんなネットワークではtcpのバッファサイズをある程度大きくしておかないと性能がでない。主記憶の量とどのくらいのセッション数をさばくつもりなのか？というあたりと要相談だが、たぶんいまのemobile網では128KBくらいあれば良いようにみえる。主記憶に余裕があればもう少し増やしておいてもよいかもしれない。recvspaceの大きさはkern.sbmaxに制限されるのでこちらも大きくしておくべき。

ここまでで、調子がよければ300KB/sを超えるようになる。気休めに/etc/ppp/peers/emobileの設定を２行ほど変えた。


# disable compressions
novj
##noccp
##nobsdcomp

実は並列して他にもいろいろな作業をしていたので、ここに書いただけで性能がそこまで上がるかはちょっと自信がないのだが、結果的には200KB/s - 440KB/sくらいは出るようになった。
調子の良い時はwgetで27MBくらいのmp4ファイルを転送して平均で390KB/sくらい、とそこそこの安定したスループットを見せてくれる。
ただ、現状ではWindowsなら300KB/sでているときにNetBSDでは200KB/sしかでない、という現象が発生する。まだ隠れている設定があるのかもしれない。

NetBSDでEmobile D02HWを使う(スループット改善）(1)

2008-01-03T13:20:00.000+09:00

このエントリーの一行まとめ：HTTP/TCPで29KB/sしかでなかったけど440KB/s(3.4Mbps)まで改善した。うれしい。

最近のエントリーに結構話題にしたように、いろいろとごにょごにょとして、イーモバイルのD02HW(E220)をNetBSDでも普通に使えるようになった。使えないデバイスが使えるようにする作業をしていると、「使えるようになった！」時点でだいぶ達成感がでてしまってそこでゴールに着いてしまった気になりがちだ。今回もデバイスとして認識できない段階から、まがりなりにもPPPでセッションを張って通信できるようになったわけだから、まあそれでいいや、考えてしまっていた。

ちょっと間をおいて、実際に使ってみようとおもうと、どうも変な感じがする。windowsのNote PCにつなげて使っているときはすぐに見えるwebサイトなどが見えるのがだいぶ遅い。やっぱりスループットを計測してみるか、と重い腰を上げてやってみるた。

wgetコマンドをつかってHTTP/TCPで、ファイルを転送するときの速度を測ってみると………。（プロトコルオーバヘッドがあるので下部層ではあと10%くらい速いはず）。

Windows (Panasonic Let's Note R5): 1.8Mbps-2.5MBps (230KB/s-320KB/s)くらい
NetBSD (ALIX 3C): コンスタントに0.225Mbps (29KB/s)

うーん、軽く1/10? と少しショックを感じながら改善作業に取り組むことにした。

2つの計測系で同一なのは「同じD02HWを使っている」「同じ場所で計測」「ほとんど同じ時間に計測」というところ。あとの計算機環境やソフトウェアは全部違っている。本当はできるだけそろえるべきなんだけど、Let's noteにNetBSDを入れるのもめんどくさいので実作業にうつることにした。とりあえず疑うべきは

D02HWの設定
D02HW用のデバイスドライバ
OSのUSBサブシステム
PPPの設定
PCの性能

あたり。ターゲットとしているALIX3は小さな組み込みボードといえども、500MHz駆動のAMD LX800で動いている。主記憶も256MBある。経験上これくらいの性能でたかだか数Mbpsのトラフィックを裁けないわけがない。USBホストのチップの問題もなさそう。というわけで、5つ目の「PCの性能」は「ほとんどなさそう」だ。

簡単なところが疑っていこうとおもって、次は「D02HW」の設定を追ってみることにした。といってもモデムとして見えるATコマンドでは無くUSBレベルでの話。USBバスアナライザでトランザクションを眺めていると、ベンダ独自のコマンドを使って設定用のレジスタをさわっているようにみえる。仕様書が無いのでこれが何を意味しているかはわからないが、設定しているということは意味があるのかもしれない？とおもってNetBSDからも同じ操作をする関数を実装してみた（どんな風にするかは後日別のエントリーで書く予定）。うーん？別に変わらない様子。

次は「デバイスドライバ」と「OSのUSBサブシステム」。一緒にみた方が良さそうなので同時に始末することにする。たぶん今回の問題の肝は「いつも同じ29KB/sである」ということだろう。windowsで見ていると、結構短い間隔でスループットが大きく変動しているのを観測できるが、NetBSDだとずっときっちりと29KB/sしかでない。つまりある層までは十分な性能があるのにかかわらずどこかに律速（ボトルネック）となる部分があってそれが原因でこんな状況になっている、と推測できる。こんなときにどこをさわればいいか？というのは、そのデータがデバイスからOSの上(tty)までどうやって流れてくるのかを理解して調べていかないといけない。幸いにも今回はD02HW対応でしばらくUSBのデバイスドライバをさわっていたので、ずいぶん勘がはたらくようになっていた。じーっとコードを眺めていると、USBのデータ処理単位とデバイスの単一のパケットサイズを同じ大きさ扱うようになっていた。たとえばUSB_ATTACH()のなかのエンドポイントディスクリプタを読んで上位のucomデバイスの送受信バッファサイズを設定するところ。


 if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN &&
      UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) {
           uca.bulkin = ed->bEndpointAddress;
           uca.ibufsize = UGETW(ed->wMaxPacketSize);
 } else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_OUT &&
      UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) {
            uca.bulkout = ed->bEndpointAddress;
            uca.obufsize = UGETW(ed->wMaxPacketSize);
 }

単なるシリアルラインならともなく、D02HWは7.2Mbpsの高速シリアルデバイスなのでこれじゃだめだろうという気がする。というわけでその辺のコードをさわる。具体的には、uca（ucom attach arg構造体）のuca.ibufsize / uca.obufsizeをD02HWのパケットサイズ(64Byte)とは独立した大きさにする。試行錯誤の結果、4096Byteくらいがちょうど良い大きさだと判断した。uca構造体を設定する場所で決め打ちで4096を設定しておく。ucomとか関連する関数をチェックしたがそれで問題は無い。

ここまでの作業で、29KB/sec -> 12oKB/secくらいに劇的に改善した。1Mbpsくらいでている計算になる。でもwindowsの1/3くらいでしかないので更に解析と作業を進める。

（続く）

Emobile-Wifiルータ

2007-12-26T20:09:00.000+09:00

せっかくそれなりに速い速度のアップリンクを持つイーモバイルのD02HWが使えるようになったので、イーモバイルをアップリンクにする無線アクセスポイントをつくってみた。OSはNetBSD。とりあえず手元にあったusb無線LANアダプタ（バッファローのWLI-U2-SG54HP)をつかっている。ボードはALIX.3C

やることは普通のルータの設定と大体同じ。

ルータなのでkernelでipフォワードをenableする。kernelコンフィグレーションファイルでoptions GATEWAYと書いておくか、sysctl -w net.inet.ip.forwarding=1としておく。
ipfilterかpfでNATをできるように設定する。pfを使うときはkernelのコンフィグレーションファイルでpseudo-device pfとpseudo-device pflogと書いておく。ipfilterはdisableした記憶がなければ使えるはず。あとは/etc/ipf.confとか/etc/pf.confをかいておく。/etc/rc.confにpf=YESなどを書くのを忘れないように。
dhcpdをあげる。/etc/dhcpd.confを設定して、/etc/rc.confにdhcpd=YES dhcpd_flags="無線インターフェイス名"を書いておく。nameserverは自分のwifiインターフェイスのアドレスにしておくとよい。
namedをあげる。/etc/rc.confにnamed=YESとかいておく
pppの設定をする。前のエントリーを参照のこと。
無線インターフェイスの設定をする。/etc/ifconfig.インターフェイス名というファイルに書いておくと便利。たとえば、rum0を使う場合は、ifconfig rum0 media autoselect mode 11g mediaopt hostapなどと打ち込んで、hostapモードで動かす。IPアドレス、SSIDの設定も忘れずに。

最低限これだけ設定すると、ルータとして動き出す。実用に使うにはもっといろいろと作り込んでいかないといけないが、この辺からスタートするとよいんじゃないかな。
もう少し時間と（切実な必要性）ができたらがんばる予定。

PSOC miniprog用コネクタ

2007-12-26T19:02:00.000+09:00

PSOCをつかった回路をつくるときに、miniprogとの接続をどうしようか？っていうのはちょっとだけ悩ましい。普通の5pinのシングルラインのヘッダピンでも用は足りるけれど差し込みが安定しないし、ぼーっとしていると逆差ししてしまうかもしれない。Cypressが指定している純正の受け側のコネクタが手に入れば良いのだが秋葉原をちょっと回った感じでは難しそう。

最近気に入っているのは、molexのこのコネクタ。秋葉原の「ネジの西川」こと西川電子部品の２階のコネクタ売り場で探しているときに見つけたのだが、純正のコネクタとだいぶ近い形をしている。
型番は

Molex 5045-05A (ストレート)
Molex 5046-05A (L字)

とのこと。

このままでは右の写真のようにロック部分が長くてMiniprogと干渉してしまうのだが、

適当に切断すると

ぴたりとはまるようになる。

というわけで、秋葉原にアクセスできる人はこーいう方法もある、ということで。写真ではストレートコネクタを例につかったが、L字型のほうが使うことは多いかな。

NetBSDでEmobile D02HWを使う(設定編)

2007-12-26T18:19:00.000+09:00

NetBSDのpppdのemobileにつなげる方法を教えてもらったので設定してみた。設定をまとめておく。
(まだ最適化はされていないので冗長な記述などがあるかもしれない）

設定するファイルは以下の5つ

/etc/ppp/peers/emobile
/etc/ppp/chat-emobile
/etc/ppp/ip-up
/etc/ppp/ip-down
/etc/ppp/chap-secret

これらを設定して、ppp call emobile を実行すればいい感じにPPPセッションが確立してくれる。

/etc/ppp/peers/emobile


dtyU0 460800 crtscts
lock
nodetach
hide-password
local
noauth
# dns routing
usepeerdns
defaultroute
noipdefault
# disable compressions
novj
noccp
nobsdcomp
# auth
user "em"
# misc? (xxx)
ipcp-restart 8
ipcp-max-configure 50
ipcp-accept-local
ipcp-accept-remote
# connect script
connect '/usr/sbin/chat -v -f /etc/ppp/chat-emobile -T *99***1#'

/etc/ppp/chat-emobile


ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
ABORT "BUSY"
ECHO ON
SAY "Connecting"
TIMEOUT 15
"" "\d\d\dat\r\dat"
TIMEOUT 5
"OK-\Kat-OK" "at"
OK "at&FE1V1X1&D2&C1S0=0"
OK "at+ipr=230400"
SAY "Let's go"
OK "atdt\T"
CONNECT ''

/etc/ppp/ip-up　(chmod 0755 /etc/ppp/ip-upしておくこと)


#!/bin/sh
~
f [ -f /etc/ppp/resolv.conf ]; then
      chmod 644 /etc/ppp/resolv.conf
      cp /etc/resolv.conf /etc/resolv.conf-
      if [ ${USEPEERDNS:-0} -eq 1 ]; then
              cp /etc/ppp/resolv.conf /etc/resolv.conf
              chmod 644 /etc/resolv.conf
      fi
fi

/etc/ppp/ip-down (chmod 0755 /etc/ppp/ip-downしておくこと）


#!/bin/sh
#
if [ -f /etc/resolv.conf- -a ${USEPEERDNS:-0} -eq 1 ]; then
      mv /etc/resolv.conf /etc/resolv.conf.old
      cp /etc/resolv.conf- /etc/resolv.conf
      chmod 644 /etc/resolv.conf
fi

if [ -f /etc/ppp/resolv.conf ]; then
      mv /etc/ppp/resolv.conf /etc/ppp/resolv.conf-
fi

/etc/ppp/chap-secret (chmod 0600 /etc/ppp/chap-secretしておくこと）


em     *     em

USBアナライザとD02HW

2007-12-26T02:12:00.000+09:00

「NetBSDでD02HWをつかう」では比較的（というかほぼ全部）試行錯誤でデバイスの設定に必要な条件を推測してデバイスドライバへのパッチを作成した。ハードウェアを触るときによく感じることは「見えないものはわからない」ということだ。当たり前のことだが、電気信号は眼にはみえないので、推測するしかなくそれはいつまでも推測のままで推移してしまう。電圧を測るのにテスターが必要で、時間ドメインの波形をみるのにオシロスコープが必要なように、扱う事象を見るための専用の「アナライザ」が必要になることは多い。実はとある目的のためにUSBバスアナライザが手元にあったので、D02HWのデバイスドライバ作成作業を検証してみることにした。

手元にあるのはellisysのUSB Explorer 200だ。これは、USB2.0のHighSpeed(480Mbps)に対応したアナライザで、Windowsソフトウェアと組み合わせることでだいたいすべてのUSBイベントを表示してくれる、という便利な逸品である。ソフトウェアは誰でもダウンロードできるようになっていて、USBバスのキャプチャファイルを入手したときに誰でも表示できるのがうれしい（ちなみにキャプチャファイルの拡張子はUFOだ）。
写真でわかるように、アナライザを解析ソフトが入っているPCにつなげて、デバイスとデバイスをつなげるホストの間にはさむようにアナライザを配置する。これで、デバイスとホスト間のデータをインターセプトするという仕組みになっている。
まず、Windowsで動かしてみたときにUSBバスにどんなトランザクションが発生しているかを見てみた。
「NetBSDでEmobile D02HWを使う(3)」にあるUSBのインターフェイスとエンドポイントの情報を見ながら、どのエンドポイントとホストがどんな通信をしているかを眺めてみる。アナライザは、

たとえばこんな情報が表示されて、トランザクションのタイプと中身のデコード結果をだしてくれるので、それとUSB2.0の仕様書(このへんにある）を眺めながら追っていく。赤裸々にどんなトランザクションをやりとりしているかを見ていてわかったことは以下の３つ。

NetBSDにつくったパッチは正しい。
ATコマンドいろいろ
D02HWは実はさらに別のインターフェイスをもっている。

最初のは、結局あのシーケンスを送らないとデバイスは言うことをきいてくれないみたいだ、ということを追認できたということだ。ちゃんとUSB2.0の仕様書を読み込むと、あのメッセージは

デバイスへのスタンダードのリクエスト（SET_FEATURE)でHost→Device
リクエストタイプはDEVICE_REMOTE_WAKEUP
wIndexの0x2はendpoint2を意味する

ということだった。アナライザでの結果をみるとendpoint２はモデムの主通信用のパイプなので、これで意味がわかってすっきりした。
２つめのATコマンドいろいろはたぶんWindowsとかのモデム定義ファイルをみればわかる情報なので大した追加情報ではない。問題は３つめで、確かに「NetBSDでEmobile D02HWを使う(3)」では、モデムとして認識されるようになると3つのインターフェイスディスクリプタが見えている。ひとつはモデムでひとつはUSBストレージデバイスだ、ということもわかっていたが、実はなぜもうひとつみえるのか、は謎のまま残っていた。まだ実際にコードを書いて叩いてみたわけではないのだが、USBのBUSトランザクションを見る限り、


INTERFACE descriptor 1:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=1 bAlternateSetting=0
bNumEndpoints=2 bInterfaceClass=255 bInterfaceSubClass=255
bInterfaceProtocol=255 iInterface=3(Data Interface)

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=5-in
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=5-out
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

のendpoint5はもう一本のモデム制御用のパイプらしい。まだ憶測だが、endpoint2でデータ通信しながらでもモデムが管理しているHSDPA由来の制御情報などを並列してとれるのではないかと予想している。これを扱うデバイスドライバかくのはどうしたもんか、と悩みがふえてしまった（しばらくはきっとやらないけどね）。

(12/28追記：実験してみたらモデムモードに入った後は３本ともシリアルらしい。２本目をはやすハックをしてみた、あとで詳しく書く予定）
(12/30追記：やっぱり３本目はusb mass strageだとおもうなあ。コードかいてみるか。。）
(1/4追記：usb mass strageでした。）

というわけで、アナライザを使うとみたいことも見えるけど、まったく気が付いていなかったようなことも見えてしまう、ってことで。今回はおしまい。

NetBSDでEmobile D02HWを使う(4)

2007-12-25T16:39:00.001+09:00

Windowsやmacのドライバでは抜き差しせずとも使えるということは、なんらかの方法でこの２つのモードの切り替えができるはずだ。機能の切り替え、はデバイス毎の特有の操作なので一般的な方法は存在しない。USBのバスアナライザとかがあれば、windowsのドライバの挙動などを観察して切り替えるための魔法の言葉を見つけることもできるのだが、休日に家で作業をしていたので手元にそんな便利なものはなかった。
というわけでいろいろと試行錯誤してみることにする。

試行１：D02HW(E220)のファームウェアの立ち上がりが遅くてうまく処理ができていないのでは無いかと思って、attachルーチンのあちこちにdelayを入れてみる。あちこちにusbd_delay_ms(dev, 500); などと書いてみて、挙動がどう変わるか地道な作業をがんばる（２時間くらい）。


   /* Find the endpoints */
   usbd_delay_ms(dev, 2000);
   id = usbd_get_interface_descriptor(sc->sc_iface);
   sc->sc_iface_number = id->bInterfaceNumber;

あたりに2000msくらいのdelayをいれると、認識しない→差し直すと認識→次に刺し直すと認識しない→また差し直すと認識、と安定してツンとデレを繰り返すようになった。しかしディレイを入れるだけではどうもこれ以上は進まないようだ。次の方法を考えないといけない、ネットワークで識者（USBシリアルの偉い人）と相談するととりあえずVENDORリクエストなどで適当な値をおくってデバイスをつつくかくすぐるかしてやるのがいい、と助言をうけた。設計している人も人の子なので別に難しい値ではなく0とか1とか2とかそんな値を送ると動き出すことがあるらしい。

というわけで、sys/dev/usb/uplcom.cを参考にして実験用にubsa_reset()という関数をでっちあげてみた。


static  usbd_status
ubsa_reset(struct ubsa_softc *sc)
{
    usb_device_request_t req;
    usbd_status err;
#define UBSA_SET_REQUEST 0x1

    req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
    req.bRequest = UBSA_SET_REQUEST;
    USETW(req.wValue, 0);
    USETW(req.wIndex, sc->sc_iface_number);
    USETW(req.wLength, 0);

    err = usbd_do_request(sc->sc_udev, &req, 0);
    if (err) {
            printf("%s: send reset fail\n", __func__);
            return (EIO);
    }

    return (0);
}

試行2: ubsa_reset()関数をattachの適当な場所においてみて挙動を見る。が、デバイスからお断りのエラーが返ってくるのでどうもうまくいかないらしい。
試行3: bmRequestType を UT_WRITE_DEVICEにしてbRequest = UR_SET_FEATUREにしてやってみることにする。これはUSBの標準機能なので失敗することはないはず。コードは適当に改変する。

ここで変化が起こった。なんとリクエストを送りつけると、抜き差ししてもモードの変換が発生せずに常にモデムとして見えない状態になる。「逆行してるじゃん」と思うのは素人だ。なにかアクションが返ってきたと言うことは、その近くに正解が隠れている可能性が高い。試行錯誤を繰り返して問題を追い込んでいくことにする。ここまで７時間近く作業をしていてどうもだれぎみだったのが、ちょっとテンションがあがってきた記憶がある。脳内麻薬でもでていたんじゃないかな。しばらくするとリクエストのwIndexの値を0x2にすると、デバイス側がUSBリセットをかけてきて一度デタッチされ、再度OSがアタッチするときにはモデムに化けている、という挙動をするということが判明。ようやくつねにデレにするマジックワードをゲットできた。

あとはコードをまとめるだけだが、最終的には、


/*
* Hauwei E220 needs special request to enable modem function
* XXX: is there more smart methods?
*/
Static  usbd_status
ubsa_e220_modechange_request(struct ubsa_softc *sc)
{
#define UBSA_E220_MODE_CHANGE_REQUEST 0x2
      usb_device_request_t req;
      usbd_status err;

      req.bmRequestType = UT_WRITE_DEVICE;
      req.bRequest = UR_SET_FEATURE;
      USETW(req.wValue, 0x1);
      USETW(req.wIndex, UBSA_E220_MODE_CHANGE_REQUEST);
      USETW(req.wLength, 0);

      DPRINTF(("%s: send e220 mode change request\n", __func__));
      err = usbd_do_request(sc->sc_udev, &req, 0);
      if (err) {
              DPRINTF(("%s: E220 mode change fail\n", __func__));
              return (EIO);
      }

      return (0);
#undef UBSA_E220_MODE_CHANGE_REQUEST
}

みたいな呼び出しをUBSA_ATTACH()の中で


      /* Find the endpoints */
      /* Hauwei E220 need special request to change its mode to modem */
      if (sc->sc_devtype_e220) {
              err = ubsa_e220_modechange_request(sc);
              if (err) {
                      printf("%s: failed to change mode: %s\n",
                              devname, usbd_errstr(err));
                      sc->sc_dying = 1;
                      goto error;
              }
      }

      id = usbd_get_interface_descriptor(sc->sc_iface);
      sc->sc_iface_number = id->bInterfaceNumber;

こんなふうに呼び出す実装にしてみた。このカーネルでは、


ubsa0 at uhub0 port 2
ubsa0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
ubsa0: HUAWEI E220 need to re-attach to enable modem function
ubsa0: at uhub0 port 2 (addr 2) disconnected
ubsa0 detached
ubsa0 at uhub0 port 2
ubsa0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
ucom0 at ubsa0

みたいに自動的にucom0がアタッチされるようになる。いったんdettachされるのが美しいか？みたいな議論をするともめそうだけど、デバイスの仕様ってことで許してくれないかなーとコッソリ期待している。

tipでucom0につなげてみると、こんな感じにみえる。userland-PPPでemにもつながったので、たぶんこれでサポートのためのハックは完了。実はまだNetBSDのkernel ppp(pppd)の設定がうまくいかないので、設定方法を教えてくれる人も募集中。


#tip dtyU0
connected
at
OK
atI
Manufacturer: huawei
Model: D02HW
Revision: 11.005.08.00.168
IMEI: 3560600XXXXXXXX
+GCAP: +CGSM,+DS,+ES

OK

というわけで、D02HWを動かせるようになるまでに実際にどんな作業をしたかを書いてみた。この手の情報はできた後のコード解説程度が多いが、作業をした過程とか、どんな事を考えて作業したかとか、どんな失敗をしたか、って情報の方が、自分で同じような作業をするときに役に立つ気がしている。
あと、半年たつと自分でも何やったのか忘れることがあるので備忘録にもなることを期待しながら、できる限りこんな感じの作業記録をとってみたいなあーと考えている。

NetBSDでEmobile D02HWを使う(3)

2007-12-24T16:52:00.000+09:00

インスタントに「NetBSDでイーモバイルを使う方法」が書いてあるかというとそうでもなくて残念だと思う人もいるかもしれない。今回書いたpatchはすでにNetBSDには送ってあるのだがこれが採用されるかどうかはまだ不明なので、最近の-currentをCVSチェックアウトしただけでは現状では使えない。今回も「どうやってUSBデバイスを動かすようにしたか」というネタが続いているのでその辺に興味があるならおつきあい頂きたい。

現状のubsaドライバではどうもうまくD02HW(E220)をアタッチできないので、もう少し先人達の知恵を借りることにした。FreeBSD系のメーリングリストを眺めるとこんな記述があった：「いったん接続して認識に失敗してから、ゆっくりとUSBコネクタを引き抜いてデタッチされた瞬間にもう一度指し直せば認識する（かも）」（意訳）、最初みたときは何のおまじないかと思っていたのだが、再度好意的に解釈し直すと「電気的な接続を切らずに信号線だけ切りはなして再接続するといんじゃない？」と言っているようにも思える。というわけでやってみた。数回トライすると、本当に認識してucom0が生えてきた。なんで？と思うとこの状態ではさっきまで見えなかったエンドポイントが複数見えるようになっており、その中にインタラプトエンドポイントが含まれている。

usbctlというコマンドでUSBのデバイスの情報を取得してみると、差し直しの前後で全然別物のデバイスになってしまったようにみえる。長いけど抜粋してみるとこんな感じ。

元々の情報


DEVICE addr 2
DEVICE descriptor:
bLength=18 bDescriptorType=device(1) bcdUSB=1.10 bDeviceClass=0 bDeviceSubClass=
0
bDeviceProtocol=0 bMaxPacketSize=64 idVendor=0x12d1 idProduct=0x1003 bcdDevice=0
iManufacturer=1(HUAWEI Technologies) iProduct=2(HUAWEI Mobile) iSerialNumber=0()
 bNumConfigurations=1

CONFIGURATION descriptor 0:
bLength=9 bDescriptorType=config(2) wTotalLength=32 bNumInterface=1
bConfigurationValue=1 iConfiguration=0() bmAttributes=a0 bMaxPower=500 mA

INTERFACE descriptor 0:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0
bNumEndpoints=2 bInterfaceClass=8 bInterfaceSubClass=6
bInterfaceProtocol=80 iInterface=0()

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=3-in
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=4-out
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

current configuration 1

差しなおした後の情報


DEVICE addr 2
DEVICE descriptor:
bLength=18 bDescriptorType=device(1) bcdUSB=1.10 bDeviceClass=0 bDeviceSubClass=
0
bDeviceProtocol=0 bMaxPacketSize=64 idVendor=0x12d1 idProduct=0x1003 bcdDevice=0
iManufacturer=1(HUAWEI Technologies) iProduct=2(HUAWEI Mobile) iSerialNumber=0()
 bNumConfigurations=1

CONFIGURATION descriptor 0:
bLength=9 bDescriptorType=config(2) wTotalLength=85 bNumInterface=3
bConfigurationValue=1 iConfiguration=0() bmAttributes=a0 bMaxPower=500 mA

INTERFACE descriptor 0:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0
bNumEndpoints=3 bInterfaceClass=255 bInterfaceSubClass=255
bInterfaceProtocol=255 iInterface=3(Data Interface)

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in
bmAttributes=interrupt wMaxPacketSize=16 bInterval=128

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-in
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-out
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

INTERFACE descriptor 1:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=1 bAlternateSetting=0
bNumEndpoints=2 bInterfaceClass=255 bInterfaceSubClass=255
bInterfaceProtocol=255 iInterface=3(Data Interface)

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=5-in
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=5-out
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

INTERFACE descriptor 2:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=2 bAlternateSetting=0
bNumEndpoints=2 bInterfaceClass=8 bInterfaceSubClass=6
bInterfaceProtocol=80 iInterface=0()

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=3-in
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=4-out
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

current configuration 1

つまり、差しなおしたあとのデバイスには元々見えなかったインターフェイスが生成されていて、それがみえると今回の目的であるモデムとして利用できるようになる、ということらしい。裏技みたいな「ゆっくりやさしくぬいて、素早くさす」みたいなことを何回もやるのは大変なので、USBのプロトコル的にうまくできないか？という方針のまま作業をすすめていくことにする。

続く

NetBSDでEmobile D02HWを使う(2)

2007-12-24T04:38:00.000+09:00

CS5536を扱った時は十分に詳しい仕様書が入手できて先がみえる作業（つまり作ればできる）だったが、今回のD02HW(E220)に関しては外部の仕様書が存在しないため、いろいろと試行錯誤が必要となる。幸いにも、「ごにょごにょすると動く」とか「不十分だけど動くかも」といった情報があるし、Linuxでは動いているらしいのであまり深刻にならずにやってみることにしよう（ま、楽しみでやっているわけだし）。
前回のエントリでも出したが、この段階では接続するとこんなメッセージがkernelから出力される。


ubsa0 at uhub0 port 2
ubsa0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
usbd_set_config_index: illegal index
ubsa0: failed to set configuration: INVAL

問題となっている部分として目につくのが"usbd_set_condig_index: illegal index"の部分だ。ベースとなるsys/dev/usb/ubsa.cを開くと、その部分はUSB_ATTACH(ubsa)の中のこんなコードだった。


 /* Move the device into the configured state. */
 err = usbd_set_config_index(dev, UBSA_CONFIG_INDEX, 1);
 if (err) {
     printf("%s: failed to set configuration: %s\n",
        devname, usbd_errstr(err));
        sc->sc_dying = 1;
        goto error;
 }

usbd_set_config_index()の実体はsys/deb/usb/usb_subr.cにあるので見てみると、USBのデバイス的に「そんなINDEXはないよ」ということを意味している。ここでデバイスに頑張れといっても無い袖を振ってくれるわけでもないので、ここはUBSA_CONFIG_INDEXの値があっていないのだろうと考えるのが正しそう。もともとの値は1だったので、とりあえず0にしたkernelを作って試してみる。

すると別のメッセージが出るようになる。ubsa.cをみると、それなりにコードの先のほうまで進んでいるようだ。


ubsa0 at uhub1 port 2
ubsa0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
ubsa0: Could not find interrupt in

該当部分のコードは、さっきと同じUSB_ATTACH(ubsa)の中の、


if (sc->sc_intr_number == -1) {
 printf("%s: Could not find interrupt in\n", devname);
 sc->sc_dying = 1;
 goto error;
}

である。ちょっと前の方にもどって追ってみると、USBデバイス(D02HW)からエンドポイントを取得してみたけど必要な割り込み用のエンドポイントをもらえなかった、のであきらめちゃう、ということらしい。割り込み用のエンドポイントがもらえないのは一大事なのでデバイスドライバとしてはあきらめるのは当然だとは思うが、動かしたい人としてはそれでは困る。
可能性としては、

このデバイスは割り込みエンドポイントがない変なシリアルデバイスである
本来は割り込みポイントがあるが何らかの問題で見えていない

のどちらかだが、「ガシガシさしなおしていたら見えたことがある」とかいうWebなどでの報告を信じる限り、どちらかというと後者の可能性が高い。もし前者だったとしたらシリアル通信のドライバとして全然別のロジックが必要になるから偶然で動くなんて考えづらいからだ。つまり、

残りのコードはおおむねあっていて、うまくデバイスとしてコンフィグレーションできていない

じゃないかと予測して次のステップに進むことにした。

続く

NetBSDでEmobile D02HWを使う(1)

2007-12-22T15:15:00.000+09:00

イーモバイルのD02HWが手元に来たので、NetBSDで動かせるようにしてみた。今回はそのあたりの話を書いてみることにする。
D02HWはD01HWとほとんど同じハードウェアで、HUAWEIのE220のOEM製品である。今回も手をつける前にとりあえずgoogleとかしてみると、動いたとか動かないとかどうも歯切れがわるい。NetBSDの場合ではcurrent-usersという最新版の開発ブランチのkernelに関する話題を扱うメーリングリストがあるのだが、いくつかのスレッドがあった割には実際のコードには反映されていない状態だった。
まあ、手元に実際のデバイスがあるから、と手をつけてみることにした。

D02HWはUSBのHSDPAモデムだが、モデムの機能の前にデフォルトではUSBストレージデバイスとして認識されるようになっている。たとえば、なんの設定もしていないNetBSDではumassデバイスとして認識・アタッチされて、CDROMとして中身をmountできるようになる。中身はwindows用のデバイスドライバ群で、NetBSDでモデムとして使おうとして思っているときには何の役にもたたない。差し込みのたびにumassとして認識されるのもうるさかったので、まずそのへんをdisableする。umassのdevice driverはsys/dev/usb/umass.cあたりにある。中身をざっと見てみると特定のデバイス毎の特別な設定を書くためのhookが用意されていて、sys/dev/usb/umass_quirks.cに追加できるようになっている。今回は単純にattachされないようにするだけなので、Static const struct umass_quirk umass_quirks[] = {の中に


{ { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E220 },
   0, 0, 0, 0, 0, NULL, NULL
},

というエントリーを追加した。これで、USBのベンダIDがHUAWEIでプロダクトIDがE220のデバイスはUSBストレージデバイスとして認識されなくなる。NetBSDでは、専用のドライバが存在しないデバイスはugen（汎用USBデバイス）としてattachされるので、umassをdisableすると次からはD02HW(E220)はugenとして認識されるようになる。

このあたりでugenとして認識されたD02HWをユーザーランドからlibusbをつかってなんか操作できないかと、数時間時間を費やしてみたが、得たものは

NetBSDのlibusbはugenとして認識されたデバイスしか触れないということを認識
libusbを使った基本的なプログラムの書き方と経験

だけで、今回のデバイスドライバつくりに特に役に立つことは（その時点では）なかった。今思えば、あの段階でうまくugen&libusbを使うことで不明なUSBのコマンドを探すような場合に役にたつかも、と思えるようになったので、まあ費やした時間は無駄ではなかった（ことにした）。

と、ここからが本題となる。まずは先人達が到達したところまで追い付かなければならない。ベースとなっているUSBシリアルドライバはubsaドライバ(sys/dev/usb/ubsa.c)なので、このドライバがD02HWのドライバとなるように、Static const struct usb_devno ubsa_devs[] = {に


    /* HUAWEI E220 / Emobile D0[12]HW */
    { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E220 }

と追加する。この段階でkernelをつくってD02HWを接続すると


ubsa0 at uhub0 port 2
ubsa0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
usbd_set_config_index: illegal index
ubsa0: failed to set configuration: INVAL

と表示される。確かに問題がある、というところで概ねこのデバイスを触る準備が整った気になる。ちょっと一休み。

具体的な料理の方法は次のエントリーで説明する予定。

ALIXとNetBSD（補足）

2007-12-22T04:01:00.000+09:00

そういえば、ALIXボードでNetBSDを動かしているときに不可解なハングアップに陥る状況があった。カーネルを触っている時期だったので、ずいぶん「自分のコードがわるい」んだとおもって問題点を探すために時間をつかってしまった。
ハングアップするのは、「CS5536のMFGPTのIO空間にアクセスしてなにかを書き込んだとき」であったが、どう考えてもそれだけで落ちるとは考えられない、と思えるようになるまでデバグを続けて最後に確認したのが、BIOSの設定。
ALIXのTinybiosには [MFGPT workaround] というメニューがある。これはCS5536のアクセスでマシンがハングアップ＊しないように＊ある機能らしいので、役に立つことはあっても害にはならないだろうと思っていたのが、この機能をdisableすると問題なくMFGPTの空間への書き込みができるようになった。

もしかしてはまる人がいるかもしれないので、メモとして残しておく。

NetBSDでWatchdog timerを使う（for ALIX) (4)

2007-12-22T03:17:00.000+09:00

Watchdogタイマとして動かすためにsysmonフレームワークから呼び出される関数は、

int glxpcib_wdog_setmode(struct sysmon_wdog *smw);
int glxpcib_wdog_tickle(struct sysmon_wdog *smw);

の２つ。glxpcib_wdog_setmode()はWatchdogタイマのenable/disableや、最大時間を設定の際に呼び出される関数。glxpcib_wdog_tickle()は正常動作時に定期的に呼び出される関数だ。ちなみにsrc/sys/dev/sysmon/sysmon_wdog.cをみると、


/*
* sysmon_wdog_ktickle:
*
* Kernel watchdog tickle routine.
*/
void
sysmon_wdog_ktickle(void *arg)
{
    [中略]
       callout_reset(&sysmon_wdog_callout,
           WDOG_PERIOD_TO_TICKS(smw->smw_period) / 2,
           sysmon_wdog_ktickle, NULL);
    }
    mutex_exit(&sysmon_wdog_mtx);
}

と書いてあって、基本的には（カーネルモードのwatchdogの場合は）設定した時間の半分の周期でタイマを更新することになっていた。

今回はこれらの２つの関数を書くにあたって、共通的な要素を行う基本関数として

glxpcib_wdog_disable（）
glxpcib_wdog_enable()
glxpcib_wdog_reset()

の３つを用意した。最初の２つはタイマーの動作を止めたり、動かしたり、カウンターが回りきったときのアクション（この場合はシステムリセット）を止めたり、動かしたりするために利用する。３つめカウンターを０にリセットするために利用する。これらを組み合わせると、

glxpcib_wdog_setmode()はdisable(), enable(),reset()の組み合わせとタイマ値の設定
glxpcib_wdog_tickle()はreset()を呼び出す

ことで実現できる。sysmon_wdogの時間しては秒単位で、カウンターに設定する値も秒単位なので特に変換のための計算も必要ない。参考までにglxpcib_wdog_setmode()をつけておく。


int
glxpcib_wdog_setmode(struct sysmon_wdog *smw)
{
      struct glxpcib_softc *sc = smw->smw_cookie;

      if ((smw->smw_mode & WDOG_MODE_MASK) == WDOG_MODE_DISARMED) {
              mutex_enter(&sc->sc_mtx);
              glxpcib_wdog_disable(sc);
              mutex_exit(&sc->sc_mtx);
              return 0;
      }

      if (smw->smw_period == WDOG_PERIOD_DEFAULT)
              smw->smw_period = 32;
      else if (smw->smw_period > 0xffff) /* too big */
              return EINVAL;

      mutex_enter(&sc->sc_mtx);
      glxpcib_wdog_enable(sc);
      glxpcib_wdog_reset(sc);
      mutex_exit(&sc->sc_mtx);

      return 0;
}

ここまでで、デバイスドライバ部分は全部できあがったのだが、ここではたと気がついたことがある。「これってどうやって正しく動いていることを検証すればいいんだろうか？」と。
Watchdogタイマはシステムが動かなかったときにリセットするために使われるわけだが、任意にシステムを止めたりする方法はあまりしらない（別のHWのデバイスドライバをごにょごにょすればできないこともないがめんどくさい）。しょうがないから、

printfをいれて関数の呼び出し状態をみてみる
ユーザランドで指定した値と独立してある特定の時間（１０秒）までカウントが進めばリセットするカーネルを作ってみる

の２つで対処してみた。（１）で１０秒と設定した場合に５秒ごとに_tickle()が呼び出されて、カウンタが０になっていることがわかる。また（２）では１８秒と設定して９秒後に_tickle()が動けばリセットされないが、２０秒と設定して１０秒後まで_tickle（）が動かないようにするとリセットがかかる、といったようにタイマが正しく動いていてかつリセット動作までつながる、ことを検証できる。

というわけで、CS5536のMFGPTをつかってWatchdogタイマを動かすデバイスドライバは書けて、正しく動いているっぽいことが分かった。最後に、NetBSDでWatchdogタイマを使うように設定する方法を書いておく。
使うコマンドは、

wdogctl

である。詳しいオプションはman wdogctlで見ることをお勧めするが、


# wdogctl 
Available watchdog timers:
        cs5536wdt, 32 second period
# wdogctl -k -p 10 cs5536wdt
# wdogctl
Available watchdog timers:
        cs5536wdt, 10 second period [armed, kernel tickle]
# wdogctl -d
# wdogctl
Available watchdog timers:
        cs5536wdt, 10 second period

のように使う。引数なしでwdogctlを呼ぶと使えるタイマの名前とwatchdogが起動する長さが表示される。２行目は10秒でwatchdogがかかるようにkernelがタイマを更新するモードでcs5536wdt(今回つくったタイマ）を用いてwatchdogを実行するように指示する。もう一度引数なしwdogctlを呼ぶと、設定が反映されて動いていることがわかる。
途中でwatchdogタイマを止めたいときは-dオプションをつけてwdogctlを実行すればよい。

もし、起動時に設定したい場合は/etc/rc.confにwdogctl=YES wdogctl_flags="-k -p 10 cs5536wdt"などとと書いておけば動く。wdogctl_flagsの中身はwdogctlに渡す引数と同じでよい。

というわけで、PC EnginesのALIXボードが届いてから、2日ほど楽しくカーネル遊びをする時間をとれた。いままでGPIOとかWatchdogとかを使ったことがなかったが、動くようにするために結構深い理解ができたような気がする。でも、次にこの知識が役にたつのはいつだろう（とちょっとだけ不安）。

さて、次は一番ほしい機能であるI2Cバスのサポートに手をつけたいなーと思っている。
が、まだ何もやっていないので本当にできるのか？いつになるかは？は不明。とりあえずこの３連休は手元にI2Cデバイスもロジックアナライザもないので難しそうだ。

NetBSDでWatchdog timerを使う（for ALIX) (3)

2007-12-22T01:27:00.000+09:00

なんだかデバイスドライバ作成講座みたいになってきて、UNIX系雑誌の原稿を書いているみたいな気分になってきた。まあいいか。もし変なところとか、質問があったらコメントしてもらえれば対応できることもあるかもしれない、ところが雑誌とは違うと納得することにした。あと、タイマのデバイスドライバは操作する場所もすくないし、滅多なことで変なこともおこらないので入門用としてはちょうどいいネタかもしれないので、一度書いておくとあとあと便利かも。

とりあえず、今回の話は手元にCS5536のデータブックを置いておくと少しはわかるかもしれない。６５０ページもあるドキュメントであんまり画面上で参照したい大きさじゃない。昔みたいに印刷物でくばってくれないかなあ、とこのデバイスを触っている最中よく思った。MFGPTの仕様はあちこちに分散されているけど、今回一番必要になるのは制御用のレジスタマップと書き込むべき内容が書いてある「6.17 Multi-Function General Purpose Timer Register Descriptions」（ｐ５２７）あたりだ。タイマにしてはできることが多いのでたくさん設定できることがあるけれど、今回つかうのは

6.17.2.4 MFGPT[x] Setup (MFGPT[x]_SETUP)　（ｐ５２２）
6.17.2.3 MFGPT[x] Up Counter (MFGPT[x]_CNT)　（p521)
6.17.2.2 MFGPT[x] Comparator 2 (MFGPT[x]_CMP2) (p520)

の３つだけ。上から、タイマのカウンターの動作設定、カウンターの値、カウンターの上限値をそれぞれ設定するレジスタになる。
6.17.2.4をじーっと眺めると、MFGPT0_SETUPレジスタのビット構造の図がある。
このレジスタは16bitで各ビットの値を設定するとタイマのカウンタの動作を定義できる。注意しないといけないのは、いくつかのビットは最初の一回しか書き込みできない点で、それ以降はそのビットへの変更は反映されない。たとえば、bit0-3のMFGPT_SCALEはカウンタのプリスケーラーの値を設定するビットフィールドだが一度設定すると途中でプリスケーラーの値を変更できない（らしい）。MFGPT_CLKSELはカウンタのクロックを32KHzか14.328MHzか選択するために使うがこれも同様に最初に設定したら変更できない。
Watchdogタイマはms単位ではあまり使わないだろうということと、比較的長い周期が設定できたほうがいいだろう、という判断でCLKSELでは32KHzを、プリスケーラは32K分周を選択することにした。つまり32KHzを32K分周するためカウンタは1Hzで駆動される。プログラムも簡単になるし、１６ビットカウンタの最大値の６５５３５秒＝約18.2時間までの長周期を設定できる、ようになる。

初期設定は、glxpcib_attach()の中で行う。レジスタの値を変更するためには、PCIのアドレス空間をアクセスできるようにしておかないといけない、GPIOの時と同様にbus_space_map()を使ってio handleを取得しておく。該当部分のコードはこんな感じ。


 /* Attach the watchdog timer */
 wdtbase = rdmsr(MSR_LBAR_MFGPT) & 0xffff;
 if (bus_space_map(sc->sc_iot, wdtbase, 64, 0, &sc->sc_ioh)) {
         aprint_error("%s: can't map memory space for WDT",
                       sc->sc_dev.dv_xname);
 } else {
         mutex_init(&sc->sc_mtx, MUTEX_DEFAULT, IPL_HIGH);
         bus_space_write_2(sc->sc_iot, sc->sc_ioh,
             AMD5536_MFGPT0_SETUP,
             AMD5536_MFGPT_CNT_EN | AMD5536_MFGPT_CMP2EV |
             AMD5536_MFGPT_CMP2 | AMD5536_MFGPT_DIV_MASK);

ここでは、IO空間をマップしてから、MFGPT0_SETUPレジスタに「カウンタを動かす+フルカウンタになったらリセットをする+入力クロック=32KHz+プリスケーラー=32K」を設定するところまでが含まれている。
その後は、


         sc->sc_smw.smw_name = "cs5536wdt";
         sc->sc_smw.smw_cookie = sc;
         sc->sc_smw.smw_setmode = glxpcib_wdog_setmode;
         sc->sc_smw.smw_tickle = glxpcib_wdog_tickle;
         sc->sc_smw.smw_period = 32;
         aprint_normal("%s:  watchdog", sc->sc_dev.dv_xname);
         wdt = 1;
 }
 /* Register Watchdog timer to SMW */
 if (wdt) {
     if (sysmon_wdog_register(&sc->sc_smw) != 0)
            aprint_error("%s: can not register wdog\n",
                          sc->sc_dev.dv_xname);
 }

sysmonのフレームワークに必要な設定(smw構造体にいろいろと書く）をして、sysmon_wdog_register()でMFGPT0タイマをsysmonのwatchdogタイマとして登録すれば、attach処理は完了する。

あとは、sysmonのwdogフレームワークがMFGPT0タイマを制御するための制御関数を記述すれば完了である。記述していないうちは、関数ポインタとしてNULLをいれておけば、カーネルの作成して連携部分のチェックまではできるはず。実際に開発しているときは、周りだけ作って中身がない状態から、すこしづつ中身を埋めていってつくっていた。

次は、watchdogタイマとしてMFGPTを動かすため操作関数について書いてみる予定。

NetBSDでWatchdog timerを使う（for ALIX) (2)

2007-12-21T23:33:00.000+09:00

今回扱うWatchdogタイマはハードウェアサポートを前提としたものだ。ハードウェアサポートのWatchdogタイマは、CPUの演算やプログラムとは独立して動いているタイマと、そのタイマが一定の値になるとCPUを強制的にリセットできる機構が組み合わさって実現される。
つまり、今回CS5536でWatchdogタイマを実装するためには、CS5536のMFGPTがある一定の値になるとシステムをリセットするように設定し、かつカーネルやユーザランドが正しく動いている限り一定間隔でタイマの更新を続けるソフトウェアを書くこと、と等価である。
NetBSDのWatchdogタイマサポートは、

デバイスドライバ部分（glxpcib.c)はタイマーの設定と更新のためのデバイス依存の部分
カーネルのsysmonフレームワークがその他残りのデバイス非依存の部分

の２層にわかれている。これはハードウェアを扱うデバイスドライバとOSのサービスが協調して動作する機構の一般的な構造だ。ユーザランドへのAPIやサービスの共通的な手続きはデバイスが提供する機能を一般化・抽象化して扱っておき、具体的なデバイスの処理はその抽象的なアクションから呼び出されるデバイス依存のデバイスドライバ部分のコードが対応することになる。基本的にハードウェアデバイスはデバイス毎に設計も扱い方も違うけれど、共通部分をうまく切り出しておけばデバイス依存・非依存部分をきれいに分離できる、というわけだ。

今回つかうデバイス非依存のサービスはsysmonフレームワークによって提供されている。これはsrc/sys/dev/sysmon/以下で実装されているフレームワークでコンピュータのハードウェアの電源やセンサなどを扱うための一般的な機能を提供している。Watchdogタイマもsysmon/sysmon_wdog.cをつかえば、他の実装のwatchdogと同じユーザランドプログラムと協調できるようになっている。

と、ここまでで全体の大雑把に構造を理解し（たつもりになっ）てから、デバイス依存の部分をやっつけてしまうことにする。glxpcib.cの中には、デバイス依存つまりCS5536特有な操作を扱う

MFGPTの初期設定（周波数やプリスケーラーの値）する関数
MFGPTの動作を制御するための関数
sysmon_wdogとインターフェイスするための関数群

を実装をしなければならない。sysmon_wdogから呼び出される関数はsysmon/sysmonvar.hの中のsysmon_wdog構造体を参照するとわかる。


struct sysmon_wdog {
    const char *smw_name;  /* watchdog device name */

    LIST_ENTRY(sysmon_wdog) smw_list;

    void *smw_cookie;  /* for watchdog back-end */
    int (*smw_setmode)(struct sysmon_wdog *);
    int (*smw_tickle)(struct sysmon_wdog *);
    u_int smw_period;  /* timer period (in seconds) */
    int smw_mode;   /* timer mode */
    u_int smw_refcnt;  /* references */
    pid_t smw_tickler;  /* last process to tickle */
};

関数ポインタであるsmw_setmode（）とsmw_tickle（）を実装してやれば、sysmon-wdogで扱えるwatchdogタイマになるだろう、という見通しを立てて進めていく。

次のエントリーでデバイス操作について説明してみる予定。

NetBSDでWatchdog timerを使う（for ALIX) (1)

2007-12-21T19:53:00.000+09:00

Watchdogタイマはシステムがハングアップしたときに自動的に復帰するための監視機構だ。原理は簡単で、独立したタイマが動いていて、そのタイマが設定した値に到達するとシステムリセットがかかるようにしておく。システムが正しく動いているときはそのタイマの値を定期的に０にもどし、リセットがかからないように管理する、というものだ。
ALIXで動かすNetBSDでGPIOをサポートするコードを書くついでにwatchdogタイマも生かしてみることにした。最近は組込機器っぽい用途でNetBSDを使うこともあっていつか機会があればwatchdogタイマを使ってみようと思っていたので、ちょうどよい。
AMDのCS5536には、MFGPT（Multi Function General Purpose Timer)というすごい名前のタイマ群が実装されている。そのうちの一つMFGPT0をWatchdogタイマとして使う、というのが元々のOpenBSDのglxpcib.cでの実装だ。問題はNetBSDとOpenBSDではwatchdogタイマを使うためのフレームワークが異なっている点で、そのままでは動かない。そこで、NetBSDが使っているsysmonフレームワークに合わせて書き直すことにした。というわけで、やるべきことは、

AMD CS5536のMFGPTの仕組みを理解
NetBSD sysmonフレームワークを理解＆sysmon wdogtimerの使い方を理解
コードを書く

ということになる。MFGPT自体はGPIOと同様にCS5536のPCI-ISAブリッジデバイスの一部として実装されているため、glppcib.cの一部として扱えばmatch/attachルーチンは特に必要ない。純粋にデバイスの設定とsysmonフレームワークとの連携がうまくかければ動くだろう、ということでやってみた。

具体的な話は次のエントリーで。

NetBSDでGPIOを使う（for ALIX) (4)

2007-12-21T18:55:00.000+09:00

実はNetBSDでgpioを使おうと思ったのは今回が初めてだったので、どうやればアクセスできるのか？というあたりから調べないといけなかった。Unixということで、とりあえず man -k gpioなどと打ち込んでみると、

gpio (4) - General Porpose Input/Output
gpioctl (8) - control GPIO device
gpioow (4) - 1-Wire bus bit-banging through GPIO pin

が引っかかった。取り急ぎ動作確認のためのコマンドがほしかったのでgpioctlのmanを読んでみると、これでgpioの各pinの値を制御できるらしい。ALIX.2/3のマニュアルをみるとLED D1-3あたりがGPIOで制御されているとのこと。
LED2,3を操作して点灯すれば、GPIOはまあ動いていることにしても良いだろう、ということでやってみた。


# gpioctl
/dev/gpio0: 32pin
# gpioctl -d /dev/gpio0 25 0
pin 25: state 1 -> 0
# gpioctl -d /dev/gpio0 27 0
pin 27: state 1 -> 0

無事に両方ついてくれた。あとは、必要に応じてgpio(4)のAPIをつかって制御すれば動くだろう、ということで、GPIOサポートは一通り終了。本当はLPCポートに配線されているgpioポートを利用できるか？というあたりを試してみないといけないのだが、実際にgpioを使う気になるまでは放置しておくことにしよう。

NetBSDでGPIOを使う（for ALIX) (3)

2007-12-21T17:29:00.000+09:00

カーネル関係の移植作業は、カーネルの大きな構造を理解していれば、あとは単純な作業になる。が、「カーネルの大きな構造の理解」は短期間に取得することは比較的難しい気がする。なんか長い間小さい作業を進めているといつかわかっている、みたいな理解の仕方をする人が多いのではないだろうか。少なくとも私はそうだった。
細かい作業の履歴はとっていないので、ここではglxpcib.cの変更点の要点を列挙して注釈をつけてみることにする。もし、万が一カーネルに手を出そうとする人の参考になればうれしいな。ちなみにNetBSDにsend-prしたglxpcib.cとOpenBSDのglxpcib.cとの差分はdiff -uでみたところ393行だった。OpenBSDが383行、NetBSDが484行になったので、純増で101行。結構差分が大きかったことに調べてびっくり。

やらないといけないことは、大きく分けると

PCI deviceとして検出してアタッチできるようにする
カーネルの既存のフレームワークと協調できるようする
デバイスとして動くようにする

という感じ。１ができるようになるためには、コンパイルが通ってkernelを作成できるようになっていないといけないので、とりあえず中身は空でもいいからkernelを作成できるように外側から攻めていく方が楽だと思う。

PCIバスは昔のISAなどと比べて、デバイスの検出、リソース管理の部分がよくできているので、OS側で扱うのも非常に簡単だ。PCIデバイスにはPCIコンフィグレーションレジスタがかならず実装されていて、そこにグローバルユニークなベンダーID、プロダクトID、デバイスクラスなどが記録されているのでそれを読めば大体そのPCI空間にいるデバイスがなにかを判断できる。OSではその値を比較して具体的な処理を進めれば間違いは無い。NetBSDでは、hogehoge_match()とhogehoge_attach()という関数を使うのが普通なので、いろいろなPCIデバイスのドライバのコードをみればすぐに理解できると思う。CS5536のデバイス検出のコードは以下のようになる。


int
glxpcib_match(struct device *parent, struct cfdata *match, void *aux)
{
     struct pci_attach_args *pa = aux;

     if (PCI_CLASS(pa->pa_class) != PCI_CLASS_BRIDGE ||
         PCI_SUBCLASS(pa->pa_class) != PCI_SUBCLASS_BRIDGE_ISA)
             return (0);

     if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
         PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_CS5536_PCIB)
             return (2);     /* supersede pcib(4) */

     return 0;
}

PCI_VENDOR,PCI_PRODUCTなどをみて適切なデバイスを認識できれば処理が進む。NetBSDではベンダーコードなどはsrc/sys/dev/pci/pcidevsというファイルに列挙されている。新しいデバイスを登録するときはそこにエントリーを追加してmake -f Makefile.pcidevsでデータベースを生成しなければならない。

*_match, *_attachをカーネルのデバイスコンフィギュレーションフェーズに登録するためのマクロとして、


CFATTACH_DECL(glxpcib, sizeof(struct glxpcib_softc),
     glxpcib_match, glxpcib_attach, NULL, NULL);

を使う。最初は、おまじないだとおもってコードの最初の方にかいておくと良いだろう。この辺はPCIデバイスなら全部同じなので特に悩むことはない。デバイス依存のコードは実際にデバイスをアタッチするところから始まる。デバイス毎の情報を保存するsoftc構造体（今回はstruce glxpcib_softc)を設定し、デバイスをアクセスするためのPCI空間の調整やメモリーへのマップを設定して、具体的なデバイスの初期化を行わなければならない。
glxpcib_attach()の中を全部説明すると大変なので、PCIデバイス一般な説明をしておく。OSがPCIのバスの管理をしてくれているので、デバイスドライバは自分が使うメモリ空間にだけ気をつけておけばそれなりに使える。bus_space_map()をつかってそのPCIデバイスのIO空間をメモリにマップし、bus_space_write/read_*()でその空間の読み書きを行うというイメージでデバイスにアクセスできる。
あとは仕様書をみて、必要な機能のレジスタを読んだり書いたりする方法を実装すればいい。

CS5536はたくさんの機能が１チップにまとまっている。これは物理的な１チップに複数のPCIデバイスが含まれている＝複数のデバイスIDがある、ということを意味しているのだが、各PCIデバイスにも複数の機能が含まれてもいる。今扱っているPCI-ISAブリッジにもPCI-ISAブリッジ以外にGPIOやMFGPT(Multi function General Purpose Timer)などの機能がある。PCI-ISAブリッジとしてmatch/attachをする際にGPIOやMFGPTをつかったWatchdog timerも設定してあげなければ使えるようにならない。
たとえば、GPIOの空間は以下に示す用に、GPIOのIO空間のベースアドレスなどをつかってio handleを取得してそのio handoleをつかって読み書きをする、という感じ。うまく設定できればconfig_found_ioをつかって、gpioバスができたことをOSに通知してあげると、OSのGPIOフレームワークがそれ以降の処理を引き取ってくれる。


/* map GPIO I/O space */
sc->sc_gpio_iot = pa->pa_iot;
gpiobase = rdmsr(MSR_LBAR_GPIO) & 0xffff;
if (!bus_space_map(sc->sc_gpio_iot, gpiobase, 0xff, 0,
     &sc->sc_gpio_ioh)) {
       aprint_normal(", gpio\n");
    [このへんでいろいろ設定]
    gpio = 1;
}
/* Attach GPIO framework */
if (gpio)
  config_found_ia(&sc->sc_dev, "gpiobus", &gba, gpiobus_print);

全部うまく動くと、NetBSDがブートするときに


glxpcib0 at pci0 dev 15 function 0
glxpcib0: Advanced Micro Devices CS5536 PCI-ISA Bridge (rev. 0x03)
timecounter: Timecounter "CS5536" frequency 3579545 Hz quality 1000
glxpcib0:  watchdog, gpio
gpio0 at glxpcib0: 32 pins
gpioow0 at gpio0 pins 6: DATA[6] open-drain pull-up
onewire0 at gpioow0

という表示が拝めて、うれしい気分になる、というのがこの作業の最初の到達点だ。
パッチはすでにNetBSDにsend-prしてある。kern/37577に全ソースがついているので興味があったら参照してほしい。（ある程度時間がたっていればNetBSDにマージされていることを期待）

使い方は次回のエントリーで。

NetBSDでGPIOを使う（for ALIX) (2)

2007-12-21T16:18:00.000+09:00

今回はベースとなるファイルがあるので気を楽にして取り組むことにする。とりあえず手元に用意するものは、

OpenBSDのglxpcib.c
NetBSD-currentのhead tree
OpenBSDのsys source tree
AMD CS5536のデータシート
実機(ALIX)

だけ。NetBSD-currentのhead tree、おもむろにopenbsdのglxpcib.cをNetBSDのソースツリーのsrc/sys/arch/i386/pciの下にコピーする。このあたりに新しいファイルを追加したときには、src/sys/arch/i386/conf/files.i386にエントリーを追加する。これをしないとconfigしたときに認識してくれないし依存関係を記述することができない。とりあえず今回は


# AMD Geode CS5536 PCI-ISA bridge
device glxpcib: isabus, sysmon_wdog, gpiobus
attach glxpcib at pci
file   arch/i386/pci/glxpcib.c         glxpcib

と追加。デバイス名はopenbsdと同じglxpcib。sysmon_wdog, gpiobusは後で説明するけれど、NetBSDのwatchdogおよびgpio busの共通部分のフレームワークを使うことを意味している。glxpcibはpciバス上にアタッチされて、ドライバの実体はglxpcib.cである、という意味になる。

これで、kernelのconfigurationファイルにglxpcibという名前が出てきてもconfigコマンドが処理できるようになる。configファイルには、


glxpcib* at pci? dev ? function ?      # AMD CS5536 PCI-ISA bridge w/ GPIO and WDT support
gpio* at glxpcib?
isa0    at glxpcib?

を追加。pciバス上にglxpcibを生成して、その上にisaバスとgpioバスを生やす、という意味になる。
今回はALIXというconfigファイルをつくってそれで作業することにする。
で、おもむろにsrc/sys/arch/i386/confの下でconfig ALIX; cd ../compile/ALIX; make depend; makeなどと打ち込むとエラーメッセージがばりばりと出てくるので（あたりまえ）、それを見ながら今後の方針を考えて作業をする、というのが移植作業の一般的な進み方（だとおもう）。

というわけで、glxpcib.cをどうやって調理するかは続きで。

NetBSDでGPIOを使う（for ALIX) (1)

2007-12-21T15:33:00.000+09:00

PC EnginesのALIXを使いこなすためにNetBSD kernelを触っている。ALIXのハードウェア的には実装されているけれどNetBSD-current (4.99.42: 2007/12/20)ではまだ扱えない機能がいくつかあってとりあえずそいつらを見えるようにしよう、とこの２日間ほど作業をしてみた。

まだ扱えない機能でサポートしたいなあ、と強く思ったのは、とりあえず

GPIO
Watchdog timer
I2C bus

の3つだ。カーネルからGPIOが使えたら外付けの回路を触る場合に大変便利だし、watchdogタイマーは組込用途のシステムでは便利だ。I2Cは普通のI2Cセンサーをつなげたり、PSOCなどのマイコンと協調して動くシステムを作る際にきっと役に立つだろう。

カーネルを触るときにはまず先人達の知恵を検索してみるところから始まる。OpenBSDのグループはAMD Geode/LXシリーズに愛があるので、とりあえずその辺で動いているものが無いかと探してみると案の定src/sys/arch/i386/glxpcib.cというファイルがあるのを発見した。中身をざっとみると、ALIXで使われているAMD CS5536のPCI-ISA host bridgeのドライバで、GPIOとWatchdog timerをサポートするコードがはいっている。OpenBSDとNetBSDは比較的カーネルのコンパチビリティが高い（部分が多い）ので、とりあえずこのコードをベースに作業を進めることにした。I2Cはそれらが動いてからでいいだろう。

具体的な作業は次のエントリーで。

ALIX3C.2 (PC Engines)

2007-12-20T17:14:00.000+09:00

PC EnginesのALIX3C.2をYTWから買ってみた。これは、AMDのLX800+CS5536が乗った160mm*100mmくらいのワンボードPCで、拡張性が高い（MiniPCI*2, USB2.0*2）割に大変お安い（18000円くらい）というお得なボードだ。

最近LX800ベースの機材をつかっていたので、試しに買ってみたのだがなかなかいい感じにうごくので気に入っている。単にOSを入れるだけなら一瞬で動くし、ハードウェア素材として使おうとしてもCS5536などの資料は完璧なものがWebで入手できるので扱い易い。今はNetBSD-current(4.99.42）のカーネルを拡張して遊んでいる。

1チップマイコンも便利だけど、たとえばネットワークスタックを動かそうとすると大変すぎるのでこのくらいのボードも使えるようになっていると便利。

PSoC SMP(Switch Mode Pomp)

2007-12-20T17:04:00.000+09:00

電源電圧を自分で昇圧してくれるSMPの実験をしてみました。
ところでこれって、MCUの機能なのに MCUのための電源作れるって面白い回路だな。

あまりにも簡単なサンプルそのままの回路で動いたので回路図は無しですが、一瞬はまったところが1箇所だけ。
VCCをSMP経由で与えるので引き回さないんですが、書き込み器はもちろん普通にMiniProgの電源を与えないといけないので、その配線がなくて、なんで書き込めないんだ！と3分ほどはまりました。配線は極力短くとか言われてましたが、思ったよりも動くもんですね。

キャラクタ型液晶モジュールの電源配線

2007-12-12T12:16:00.000+09:00

秋月などで売られているキャラクタ型液晶モジュールの電源は、なぜか1番、2番でVccとGNDが逆になっているタイプがあります。完成品つくる場合には採用する液晶モジュールによって電源を配置すればいいんですが、実験用の汎用基板だと両方に対応させられたら便利だよなーと思って、どうすればいいか考えてたんですがこれがたぶん一番簡単な方法じゃないかと思います。ピンヘッダ2x3とジャンパを２つ使って組み替えられるようにしました。いつもの手書きの配線図です。クロスしている部分はラップ線などでクロスにジャンプさせておきます。
縦と横でVCC/GNDのピンを入れ替えられます。変則的にジャンパを入れるとショートするので注意しましょう。できあがりはこんな感じになりました。それぞれ、縦・横に使うことで、2種類の液晶を使い分けられます。

USB加速度レコーダ(1)

2007-12-11T11:34:00.001+09:00

まずは回路図です。今回使ったのはstrawberry-linuxのUSB PSOCモジュールです。チップは24794でUSBのFull-speedに対応しています。
簡単にUSBでシリアルやHIDが作れるこころが特徴です。
加速度センサーは秋月電子の KMX52を使った8pinの3軸加速度センサーモジュールです。たぶん簡単に素人が手にはいる3軸加速度センサーとしては最安値だと思います。
あとは、加速度とは関係ないのですがいつもの温度センサーLM35DZも準備します。

Port０にはアナログ入力の切り替えスイッチがつながっているので、こちらにセンサーを配置します。0,1,2でz,y,x 軸を配置しました。これは加速度センサーモジュールのピン配置を考えて、ジャンプしない配線を実現するためにZ,Y,Xの順番になっています。
さらに、Port0-3に温度センサをつなぎます。

センサーとしては以上なのですが、動作状況がわかりにくかったのでPort2-7にLEDを配置して、インジケータとして利用します。

電源は、USB-PSoCのモジュールから取り出せますのでそちらを使います。
あとはデカップリング用コンデンサなどは適時配置するとよいでしょう。
最近のお気に入りは 2012サイズのチップコンデンサで、これを裏のランド面にランド間をまたぐように
貼り付けています。
http://akizukidenshi.com/catalog/items2.php?q=%22P-00355%22&s=popularity&p=1&r=&page=

以上でハードウェアの準備が終了です。

追記：　回路図が貼れてなかったので追加しました orz...

マルチチャンネルレコーダー

2007-12-08T00:02:00.000+09:00

3軸加速度センサと温度センサからのデータを収集するために、USB PSoCを使ってシリアルからデータが流れてくるシステムを作ってみました。

とくに変わった所はないのですが、サンプリングレートを向上させるためにインクリメンタル型ではなく、sigma-delta 型のADコンバータを使っています。
1ポイント4回サンプリングで4chのデータを 32Hzの割り込みで取り出しています。サンプルレートだけなら、128Hzあたりはとれてもおかしくないんですけど、アナログスイッチの切り替えやシリアル通信があるからなのかできても64Hzでそれ以上はちょっと無理な感じですね。

今日は気力がないので完成品の写真だけですが、また元気なときにプロジェクトともどもアップしていきます。

PSoC温度計を作ってみた（その４）

2007-11-30T02:49:00.000+09:00

コードも載せときます。
プロジェクト全部は
こちらから。


//---------------------------------------------------
// C main line
//---------------------------------------------------
#include <m8c.h>        // part specific constants and macros
#include "PSoCAPI.h"    // PSoC API definitions for all User Modules

#include <stdlib.h>

#define ADC    4096.0
#define PGAGAIN   4.0
#define VREF   2.6
#define SUM      50


void main()
{
   // Insert your main routine code here.
  
   int data , i, j;
   float temp ;
   char  *ostr ;
  
   LCD_1_Init() ;
   LCD_1_Position(0,0) ;
   LCD_1_PrCString("PSoC Thermometer") ;
   M8C_EnableGInt ; // global interrupt enabling macro

   PGA_1_SetGain(PGA_1_G4_00) ;
   PGA_1_Start(PGA_1_HIGHPOWER) ;
   ADCINC_1_Start(ADCINC_1_HIGHPOWER) ;
   ADCINC_1_GetSamples(0) ;  // read AD convert continuously
   for(;;) {
    temp = 0 ;
    for( i=0; i<SUM; i++) {
     while(ADCINC_1_fIsDataAvailable() == 0 ) ;
     ADCINC_1_iClearFlagGetData() ;
     data = ADCINC_1_iGetData() ;
     temp += (data * VREF * 100 ) / ( ADC * PGAGAIN) ; //calculate AD --> temp
    }
    temp /= SUM ;
   
    ostr = ftoa(temp,&j) ;
    ostr[5] = '\0' ;
   
    LCD_1_Position(1,2) ;
    LCD_1_PrHexInt(data) ;
    LCD_1_Position(1,7) ;
    LCD_1_PrString(ostr) ;  
   }   
}

PSoC温度計を作ってみた（その３）

2007-11-30T01:45:00.000+09:00

コーディングと動作確認、そして完成へ

プロジェクトファイルをおいておくのでそちらを参照してください。moduleのイニシャライズをしたら、ADコンバータのデータを読み込み計算結果を合計して、平均値を出して表示します。これを繰り返すだけですね。

ADCINC_1_Start() と PGA_1_Start()でパワー指定をするときに、 HIGH以外を選ぶとAD変換や増幅時の直線性に問題が出て、データがおかしくなることがあるので注意。特に LOWPOWERはわかっていない限り選ばないほうがいいです。

書き込んだら通電してみてください。液晶の濃さは半固定抵抗でかえられるので、見やすいように調整してください。僕が最初につくったモジュールは動かない！とおもったらとても薄くなっていただけでした。

あとは、電池駆動するなり、5VのACアダプタを刺せるようにすればそのまま使えます。リファレンスをバンドギャップ電源からとっているので、電源電圧が安定していなくてもかなり正確な温度が出るはずです。
必要パーツがコネクタ類をのぞけば、液晶表示機と半固定抵抗、温度センサ、PSOCだけというのは面白いとおもいませんか？

まあ、実際にはこの基板は共著のYUO氏からデカップリングコンデンサが足りないという厳しい突っ込みをうけてしまったわけですが、いちおうこのまま作ってもよほどのことがないかぎり動くとは思います。