USB電話機をつなげてみたい

ふぇちゅいんさんのコメントにもあったように、現在のW-SIM電話機は製作費がそれなりにかかるのがネックかもしれません。少し安くする策はいくつかあります。

1. 各種モジュールを使わずに、部品から組み立てる。CPUボード、充電部、DC/DC部は、すべてできあいのモジュールを使っていますが、自分で個別部品から組めば安くできます。手間をかけるか、お金をかけるかの選択の問題です。
   
2. 電源部に電池を使わないでUSB給電とかACアダプタで動かす。電源関係だけで、$30くらいかかっているので。
   
3. LCDをモノクロにしてしまう。モノクロであれば、3.3Vで動かすこともできるので、安くできます。ただ、写真や地図の表示には不向きです。
   
4. CPUを変更する。わたしが使っているAT91SAM7S256は、CPUボードだけで5,000円以上します。そのかわり、メモリが豊富にあるので、PPPやTCP/IPも動かせます。音声通話だけでいいのであれば、こんな立派なCPUはいりません。もっと安いCPUや、AT91SAM7S64あたりでも用が足ります。

いくらかは安くすることができますが、ケースとかキーパッドの見栄えがさえません。見栄えを良くするには、やはりプリント基板をおこして、もう少しスマートなキーパッドが欲しいところですが、基板おこすのは作業も大変そうですし、費用もかかります。見栄えや操作性という観点からは、horichanさんのコメントに返答させていただいたように、USB電話機をつないで使うのがひとつの方策ではないかと思います。普通の電話機にはかないませんが、ボタンや受話器の操作性は遥かに向上できます。データ通信をあきらめてしまえば、少ない部品点数で小さくまとめあげることができそうです。

AT91SAM7S256は、USBのデバイス側機能をもっていますが、ホスト機能はありません。そのため、USBホスト機能を提供するには外部チップが必要となります。

インタフェース5月号の付録につくFR60にはUSBホスト機能が備わっています。これを使えば、USB電話機をつなぐことはできると思われますが、W-SIMのPCMを接続できるような同期式インタフェースは具備されていないように見受けられます。

ひき続きAT91SAM7S256を使うことを前提に、USB電話機をつなげる検討、実験を開始することにします。

LPC-2478STK

OLIMEXのARM開発ボードページに、LPC-2478STKのページが登場しました。これまで、長いことリンクだけでページ実体が無かったのですが、ようやくとどんなボードかうかがい知ることができるようになりました。しかし、まだ油断はできません。"Image to come soon"とか書いてありますが、同じ表示のあったSAM7-NRF24-64は、リストから姿を消したばかりです。

LPC-2478は、なんと言っても同期信号でTFT液晶を接続できるLCDコントローラを内蔵しているのが売り文句です。ARM9だとLCDコントローラを持ったチップはいくつもあるようですが、ARM7では、これまでほとんど無かったようです。

LPC-2478STKの液晶は320x200ドットと小さめですが、タッチスクリーンとMP3デコーダも搭載されているので、MP3プレーヤもソフトだけで作れそうです。ARM9だとどうしてもできあいのLinuxイメージに頼ってしまいますが、このSTKならドライバも全部自分で書いて楽しめそうなので、かなり誘われちゃいます。回路図とデータシートを読みながら、ピンコンフィグの初期設定からやらなきゃならないというのが、とっても楽しいんです。

3軸加速度センサを積んでいるので、画面の向きに応じて表示画像の向きを変えるiPod touchゴッコもできそうです。SSPを使ってW-SIMをつなげられれば、タッチパネルでダイアルできそうですが、残念ながらフレームのフォーマットが合わないようです。もしかして、ATコマンドでフレームのフォーマットを選択できる機能とか隠されていないでしょうかねぇ。

GoogleMapを表示する

基地局から取得した緯度/経度情報をもとに、GoogleMapから周辺の地図を取得して表示する機能を加えてみました。



GooleMapといえば、Ajaxの代表的なアプリとして知られていますが、こちらはJavascriptが使えるブラウザを載せているわけではありません。グリグリと、マウスで地図をドラッグしたいわけでもなくて、単に自分の居場所周辺の地図画像をダウンロードしたいだけです。Google APIとか勉強すればイロイロとわかるのでしょうが、面倒なことはしたくありません。緯度経度を指定してGETすると、画像を返してくれるインタフェースがあれば十分です。そう思いながら探してみたところ、こちらのページでmapprintというインタフェースを見つけました。そうです! わたしが欲しかったのは、まさにこの情報です！

Googleの提供してくれるインタフェースの使い方はわかりましたが、そのまま直接マイコンから使えるわけではありません。次のふたつの作業が必要でした。

1. 測地系の変換 W-SIMの返してくれる緯度経度は測地系としてTokyoを使用しているようですが、mapprintではWGS84を使用しているようです。また、W-SIMが返す座標は、"度:分:秒"形式になっていますが、mapprintでは度数を小数点以下6桁まで指定する形式になっています。
   
2. 画像形式の変換 mapprintでは出力の画像形式も指定できるようになっていますが、AT91SAM7Sマイコンで直接処理するには、GIF/JPG/PNGのいずれの形式も荷が重すぎます。

測地系の変換については、「表を使ってズレを求める簡便な方法」が紹介されていたので、この表のデータを使わせていただきました。画像形式については、自宅のLinuxマシンに変換をさせることにしました。マイコンからは、自宅マシンのサーバにアクセスし、自宅マシンが実際にGoogle Mapをアクセスしにいきます。Google Mapから得られた画像を、自宅マシンで12ビットBMP形式に変換してマイコンに返すわけです。

画像形式の変換作業は自宅サーバ側でおこなうことにしたので、マイコン側では位置座標と表示する縮尺を指定して自宅サーバにHTTPリクエストを送信すればいいだけになりました。位置座標はあらかじめ取得されているものを使用することにしていますので、デバック用コンソールから地図表示のコマンドを実行する際には、縮尺を指定すればいいだけになっています。

広域表示にした際の表示例も示しておきます。ちなみに、表示されている場所は前回の記事の緯度経度に基づいたものではありません。きょう見えた基地局が異なっていたのか、前回とは異なる緯度経度が取得できたので、表示場所も異なっています。

緯度/経度を表示する

ATコマンドを使って、緯度/経度を取得/表示する機能を加えました。ジョグダイルでメニューから位置取得を選択すると、AT@LBC1に続いてAT@LBC? コマンドを発行することで、緯度/経度を求めています。



とりあえずは、求めた緯度/経度を表示するところまでです。基地局に設定してある情報を取得して表示しているのでしょうが、複数の基地局が見える場合には、どのようにして緯度/経度を求めているのでしょう？　自宅で実行すると、ずいぶんと離れた位置を示すこともあるようです。取得できる緯度/経度は測地系としてTokyoを使っているようなのですが、そのことを考慮に入れてもずいぶんとずれていました。試験した居間から見通しの効く方向には、近くに基地局がないようなので、それが影響しているのかもしれません。居間の裏手方向には、近くに基地局があるので、こちらからの電波が拾えそうな窓際に近づくと、より近い位置が取得できるようです。



数字で緯度経度がわかってもさほど嬉しくないので、次の段階では取得した位置情報からGoogle Mapを利用して地図を画面に表示させることにします。

画像の描画 - その２

前回に続き、画像表示です。まずは実際にダウンロードして表示中の画面です。



ダウンロードが遅い原因を調べたところ、TCPの受信ウィンドウサイズが256バイトと小さいことが影響しているようでした。アプリケーション側での受信バッファのサイズ指定から受信ウィンドウサイズが決まるようなので、このサイズを大きくしてやったところ、3秒ほど短くなって7秒程度で表示できるようになりました。これなら待てるかなという程度の時間にはなりました。



現在のところ、メニュー操作で画像表示ができるわけではありません。上図に示したようにデバック用のコンソールからのhttpコマンド入力が必要です。指定しているのはファイルのパス名だけで、ホスト名は決め打ちで自宅のLinuxマシンです。通常のWebサイトを表示できるような機能を有しているわけはないので、これで困ることもありません。ファイル名の拡張子で b12 を指定していますが、これが12ビットのBMPフォーマットを示す自己流の拡張子です。http応答を解析し、Content-lengthを見つけると、そのサイズを表示しています。そして、ファイル本体のイメージの受信開始と、終了時の時刻を表示させています。

メニュー操作によるダウンロードについては、後ほど考えることにします。

画像の描画

画像をダウンロードして表示する機能を作成しています。画像表示をおこなうためには、大きく分けてふたつの処理が必要です。

ひとつは、LCDへのダウンロード画像の表示ルーチンの作成です。使用しているNokiaカラー液晶は、256色と4096色の2種類の表示モードをもっています。文字については、256色を使って表示してきましたが、画像には4096色を使うことにします。4096色はRGBそれぞれ4ビットづつの12ビットで表現されます。LCDにSPIで送る際にはLCDコントローラの仕様で、2ドット分のデータ24ビットを3バイトで送ることになっています。具体的には、次のようなビット列です。

RRRRGGGG BBBBRRRR GGGGBBBB

このような仕様のため、1ドットだけ書き換えたい場合には、隣接するドットのデータを読み出す必要が生じます。LCDのコントローラは、ドットの読み出し機能も持っているのですが、実際のLCDにはSPIでの読み出しデータ線が用意されていません。つまり、書き込みしかできないデバイスになってしまっています。このような制約があるため、常に偶数ドットを書き込むことにします。というか、どうせ横132ドットという狭い画面なので、画面幅いっぱいの画像しか表示しないことにしてしまいます。

上記のような2ドット分を3バイトにパックするのが、この液晶を使ううえでのお約束だったのですが、Sparkfunから最近出荷されているLCDでは、違うフォーマットをサポートできることを、先日Sparkfun経由でこのページで知りました。

0000RRRR GGGGBBBB

というように1ドットあたり16ビットを送るフォーマットをサポートしているとのことです。送るデータ量は増えますが、任意のドットの書き換えをするには好都合です。わたしも、先日実験してみたのですが、残念ながらわたしのLCDは、この機能をサポートするコントローラではないようです。

もうひとつ必要となる処理は、ダウンロード機能です。プロトコルとしては、HTTPを使うことにします。TCPポートをひとつしか使いませんし、画像ファイル名を指定してGET要求を送れば、その応答として画像ファイルのデータを送り返してくれるので、処理も簡単です。もっとも、HTTPの構文解析はトコトン手抜きして、エラー処理もほとんどしないことにしちゃいます。ブラウザを作るわけじゃなくて、画像表示に利用したいだけですので。

LCDの画面は3分割して使用していますが、画像は中央部分のメインスクリーンに表示することにします。ログ用のエリアとして4行分32ドットを使っていましたが、画像領域を広げるために、ログ領域は3行に減らすことにします。結果として、画像を表示する領域のサイズは132 X 96ドットとなります。AT91SAM7S256にはRAMは64Kしかありません。132X96ドット分の画像データとしては、132X96X1.5 = 19008バイトが必要となり、全部をメモリに保持しようとすると、全メモリの1/3近くが必要になってしまいます。そこで、ダウンロードしながら表示することとし、メモリを節約することにします。

通常Webページ上の画像には、JPGやPNG形式を用います。しかし、これらのフォーマットでは画像を圧縮していますので、展開作業のためにメモリやCPUパワーが必要となってしまいます。そこで、非圧縮の24ビットBMP形式を使うことにしました。これなら、ダウンロードしながら、24ビットを12ビットに落して表示すればいいだけです。

このような作業を終えて、どうにか画像を指定して表示できるようになりました。ところが、ダウンロードと表示にずいぶんと時間がかかります。当面の対処として、BMPとしては非標準になってしまいますが、色数を12ビットとし、LCDへ送りやすいフォーマットに変更することにしました。それでもまだ、1画面を表示するのに15秒くらいかかっていますので、まだまだ改善努力が必要です。

AVR-GSM

いつのまにかOLIMEXのARM製品の予告内容が変更になっているようです。昨年9月の発売予定だったものが、今年の6月とかにずれ込んでしまっているのはいいとして、いくつかリストから消えてしまったものがあるようです。

ATMELではSAM7-NRF24-64が、ページの実体は残っているものの、ARM製品のリストから消えてしまっています。USBドングル型になるということで、楽しみに待っていたのですが。nRF2401はSPIで接続できるので、通信相手にはこのモジュールでも使って遊ぼうと思っていたのですが。。

LPC2000関連では、いつの間にかLPC-E2468が登場しているのですが、代わりに名前だけがリストに載っていたLPC-GSM-2378が消えてしまいました。名前から察するにGSMのモジュールを搭載した、LPC-2378のボードのようだったのですが。。。ARMの方ばかりに気を取られていて気づくのが遅くなったのですが、AVR-GSMのページにGSMのモジュールを搭載した基板の回路図が出ていました。写真でもコンデンサマイクが載っていることからわかりますが、GSMのモジュールも音声サポートしているんですね。組み込み用途で、GPRSでのデータ通信しかできないだろうと勝手に想像していました。このモジュール、マイクやスピーカのアンプも内蔵していて、SPIで制御できるように思われます。

ファイル転送の方法がわからない

TINETを入れてDNSとSNTPを用意しましたが、これらはUDPベースですのでTINETもUDPだけをconfigしていました。次の段階ではTCPも入れて、待ち受け画面の画像でもダウンロードしようかと思っていました。ダウンロードしたら、その保存先が欲しくなります。W-SIMの仕様によると、電話帳にして700件相当の1Mbyteほどのユーザメモリが備わっているようです。この領域へのファイル転送の方法がわかれば、待ち受け画像の保存先として利用できそうです。

Wikiを探すとファイル転送に関するページが見つかりました。どうやら、これらのファイル転送コマンドを用いるには、通常のATコマンドモードからファイル転送モードに遷移する必要があるようです。参考資料として紹介されているAirH"PHONEの場合にはENQ(0x05)を送信することで、ファイル転送モードに移れるとのことでした。真似してENQを送ってみましたが、期待するACKは返ってきません。W-SIMの場合には、ファイル転送モードへの遷移方法が異なっているように思われます。うーん、残念。他の端末も持っていないので調べようもありませんし、ファイル転送機能の利用は断念することにします。

当面、ダウンロードした画像は表示するだけの使い方にして、保存は見送ることにします。保存したくなったら、I²C EEPROMを使うか、SPIでMicroSDカードをつなげることにしましょう。

今回は何が違うのか？

インタフェースに続いて、DWMでもオマケ基板の予告が始まったようですね。予告によると、「今回のARMボードは何かが違う」ということで、どうやらまたARM基板が付属するようなんですが、いったい何が違うというのでしょう。いくらなんでも、前回のように「配線が違っていた」というオチではないでしょうけど。来月号あたりの予告で、もう少し詳しく告知してくれるんでしょうか。しかし、インタフェースとほぼ同時期のオマケ基板になりますよね。特別定価になるんでしょうし、読者としてはどちらを買うか、はたまた両方買うか悩ましいんですけど。CQさんとしては、互いに食い合うことは心配していないんでしょうか？

以下、何が違って欲しいか、自分の願望を列挙してみます。

1. Coreが違う。個人的には、Cortex-M3を勉強してみたいです。もっとも、ほとんどC言語しか使わないので、どれだけ勉強するかは疑問ですが。。
   
2. メモリ容量が違う。前回のADuC-7026は、結構使いやすかったですが、Flash 64K + RAM 8Kとメモリ容量が少なめでした。128K+32Kくらいあれば、GCCでARM命令を使っても、TOPPERSに加えてTINETも入れられると思うのですが。ADuC-7026では、外部SRAMの接続をサポートしていたのでメモリ追加もできましたが、バスはアドレス/データが多重化されて、どうしてもアクセスは遅くなります。割り込みでの処理速度が重要な場合には、少ないSRAMにコードを配置してしのがねばなりませんでした。
   
3. USBが使える。デバイス側だけでいいので、やっぱりUSBが欲しいです。給電にも使えるし。コネクタは、ミニBを使ってあらかじめ基板に装着済みが望ましいです。
   
4. SDが使える。ヒロセあたりがスポンサー協力しており、ミニBとともにMicroSDカードのソケットを装着済みにして欲しい。いつもSparkfunで買ったボードつなげるので、最初から付いてると助かる。
   
5. 電池で動く。昇圧回路が載っており、乾電池での駆動が可能。携帯できることはもちろんなんですが、開発時にも助かります。JTAGとデバック用のシリアルにUSBを使っていると、USBが2ポートしかないノートPC環境ではUSB給電のためのポートが不足してしまいます。JTAGが仮想シリアルポート機能も持っているんですが、RS232Cコネクタなのでかえって不便なため使っていません。HUBつなげればいいだけのことですが、ただでさえ狭い作業机がさらに狭くなります。
   
6. RS232Cは無し。シリアルポートには、RS232Cコネクタを使わないで欲しい。場所食うだけで邪魔です。MAX232みたいなレベルシフタも不要です。TTLで出しておいてください。シリアルが使いたければ、秋月の変換モジュールをつなげて使います。
   

ざっと、こんなところでしょうか。「前回のARMボートとは何が違うのか」というよりは、同時期の「インタフェースのボードとは何が違うのか」の方が、購入選択が必要な読者にとってはより重要な気もします。

PPPの変更点

TINETを入れた際、ひとつ問題が生じました。TINETではppp_input_taskというタスクが入力の処理をおこなっており、モデムであるW-SIMへのアクセスも生じます。一方、音声通話処理ではmodem_reader_taskがやはりW-SIMからの入力を処理しています。このように、W-SIMからの入力を監視・処理するタスクが2つあるのです。

最初は音声通話(DTEモード)とデータ通信(アダプタモード)の変更をおこなう際に、担当タスクを起動し、他方は終了させることを考えました。しかし、ppp_input_taskはさらにnet_timer_taskやppp_output_taskタスクを起動する構造になっており、各タスクの管理する資源を正しく解放してやらないと、再起動がうまくできそうもありません。ppp_input_taskを調べてみると、modem_cntlという関数でATコマンド送受の処理をおこなっていることがわかりましたので、この関数にmodem_reader_taskの処理を吸収させることにしました。動作モードに応じて、従来のmodem_cntlの処理を行うか、modem_reader_task相当の処理を行うかを選択して処理します。

PPPのスタックには、接続と切断をphone_taskにデータ・キューを介して通知するコードを追加しました。これにより、PPPの状態変化でLCD表示のアイコンを変化させています。

電源を入れてすぐだと、W-SIMの準備も完全には整っていません。基地局を見つけて自局をPHS網に登録するにも、いくぶんかは時間がかかります。実際、ブート時には電界強度表示のアンテナアイコンも圏外表示で始まったり、安定しなかったりします。そのため、ブート直後のPPP接続は失敗することもあるようです。TINETではディフォルトで10秒間隔で2回　接続の再試行をおこなうようになっていました。この機能のおかげで、自宅で実験している限りにおいては、確実にPPP接続に成功して時刻を拾えるようです。