試しに買ってみた - キーパッド

次はSIP端末を作るつもりですが、自作するうえでの大きな問題のひとつがキーボードをどうするかです。初代W-SIMジャケットでは電話用テンキーパッドとジョグダイアルを使ってみましたが、使い勝手にかかわるものなので、やはりキーの数、操作性共にすぐれたものが欲しいところです。

そんなことを思ってた折、Sparkfunで電話用のキーパッドを扱い始めたので、試しに買ってみました。結論から先に言ってしまうと、ダメです。キーの数としては27個あるので、満足できるものなのですが、とにかく使いづらいです。



シート状で薄いのはいいのですが、とてもキーが押しにくいのです。ちょっと指の腹で押したくらいではキーが反応してくれず、かなり強く押さないといけません。思わず、ツメを立てて押したくなるくらいです。力を加えないといけないので、シート自体もしっかりしたケースなりボードの上にきっちりと固定しないと使いものにならないでしょう。ちょっとわたしの工作能力ではうまく使いこなせそうもありません。残念ですが、おクラ入りです。

次の記事では、もうひとつの買い物を紹介する予定です。

天気予報を文字情報で表示する

前回はDTMFを使ってLCDに表示する情報を切り換えてみましたが、表示する情報はマイコンが持っている情報が主でした。日付/時刻についてはSNTPを使って取得したものを元にしていましたが、このようにネットワークから取得した情報を表示するデバイスとしてLCDを使い、情報の選択に電話番号やDTMFを使うことができます。今回は、この考え方をちょこっと発展させて、天気予報と地震情報をインターネットから取得して表示するデモを作成してみました。



まず、前回と同様にW-SIMへの発呼を伴わない特別な電話番号を用意します。前回は900番を使いましたので、900番代すべての番号はすべてVoIP GWで終端することにして、イベント通知をサーバに対して送出することとしました。実際に使用している番号は901と902のふたつです。

ダイアル番号	サービス内容
901	天気予報
902	地震情報

それぞれの番号に接続すると簡単なメニューが表示されます。DTMFを入力するとメニューに応じて、情報が表示/変化します。天気予報の場合では "0" で今日の天気、"1" で明日、"2" で明後日の予報が表示されます。地震情報では、最新のものから番号順に従って表示されます。

情報源はlivedoorのRSSフィードです。RSSを直接読んできて、XMLを解釈するのはメモリ的に無理なので、発信者名の表示の時と同じように、サーバ側にいったん要求を出して、その応答として画面イメージをもらっています。そのため、SIP GW側の処理は発信者名の表示の場合と大差ありません。シーケンスは次のようになります。



サーバ側には、着信番号とイベント種別が渡されますので、着信番号によって提供するサービスを選択し、RSSフィードの取得と解析を行います。そして、結果の文字列をビットマップに変換してVoIP GWに応答として返します。VoIP GWは単に受け取ったビットマップをそのまま表示しているだけです。実際のサービスを提供しているのはLinux サーバであり、901とか902という番号もVoIP GWでは区別しておらず、901～999の番号であればVoIP GWのふるまいは全く同じです。たとえば、910がダイアルされた場合には、サーバ側に通知されるCALLEDの番号が910に変化するだけです。この場合、サーバ側では対応するサービスが用意されていないので、何の応答もなく、結果としてLCD画面は変化しないこととなります。

そろそろ次の計画を

VoIP GWもそれなりに動いたので、そろそろ次の計画を考えようかと思い始めています。VoIP GWは、着信時の動作におかしな部分があったので、SIPのバグを見つけて修正したりしていたのですが、依然としてパケットの再送すらしていないという手抜きぶりです。そのため、クライアントのPCが重かったりすると、呼が正しく切断できなくなったりする可能性があります。再送機能を追加実装するのは、それほど難しくはないのですが、それを試験する環境を作ったりする方が面倒くさくて気分が萎えてしまっています。何よりも、W-SIMつかって通話実験していると通信費がかさみますし、いつもPCでX-Liteを使うというのもいまひとつです。

そんなこともあって、次なる中期計画における目標を設定しようというわけです。今回のVoIP GWとの関連性を持たせて、SIP端末を作ろうかと思っています。自宅ではNTTのひかり電話を使っているので、その端末として利用することも可能にしようかと。具体的な形態としてはいくつかのバリエーションが考えられますので、その選択も悩みどころです。これまでのW-SIMジャケットのW-SIM部分をVoIPに置き換えればいいわけですから、これまでの経験/成果を生かせば次のようなSIP端末を作れてもいいはずです。

1. 初代ジャケットのように、テンキーとジョグ、LCDを持つ構成。受話器がヘッドフォンというのがイマイチ。
2. 2代目ジャケットのように、USB電話機を使ったSIP端末。やはり実用性としては受話器が使える点が便利。
3. 3代目ジャケットのようにタッチパネルを使う端末。可搬型にするためには、小さく作らなきゃならないし、無線使わないと。。

いっそのこと、普通の電話機をつなげられるSIP TAを作るのもいいのではないかとも思っているのですが、そうするとアナログ電話とSLICの勉強をすることになりそうです。その点では、USB電話機を使うのが手軽でいいのですが、USBホスト機能のためにMAX3421Eを使うよりも、USBホストとEthernetの両方を持ったMCUを使った方が良さそうです。しかし、AT91SAM7には、そのような石が無いんですよね。いっそのこと、AT91SAM9を使うか、あるいはLPC2388とかLPC2468あたりに鞍替えしようかとか、いろいろ思い悩んでいる次第です。調査がてら部品の手配を進めているものもあるので、順次記事で取り上げていくつもりです。

FMチューナモジュール - その2

FMチューナモジュールの動作試験する基板を新たに作成するのも面倒なので、以前TechToysのLCD動作試験に使用したボードを流用することにしました。たかが、動作試験なのでYukiさんみたいにAVRとブレッドボードとかでできれば便利なのですが、AT91SAM7のヘッダボードはピン数が多いので2列になってしまっているためブレッドボードが使えません。

当初、SPIでつなぐつもりでしたが資料を見ると26bitという半端な数字のコマンドデータを送る必要があります。おまけに書き込みと読み出しでタイミングが違っているので扱いが面倒そうです。なんだか、変わった仕様に感じるのですがSilabsのSi4702も同じタイミングになっているようです。そんなわけで、Yukiさんと同じくI²C(TWI)を使うことにしました。



単にモジュールをTWI端子につないで、アンテナ用に約1mのビニル線(紫色)を付けただけです。アンプもスピーカも無いので音は出ませんが、レジスタ見れば選局動作の確認くらいはできますから、音が出ているイメージを妄想で補いながら遊ぶことにしました。



もともとTWIの端子はLCDをつなぐのに使っていたピンなので、LCDは付けずに使います。LCD制御に使うピンを配線しなおしてやればいいんですが、まずはFMチューナの動作確認です。いつものようにUSB CDCを使ってPCと接続、最初にレジスタが読み出せることの確認です。

＃ 以下の説明は、AR1000の資料があることを前提で書いています。



レジスタの初期値は、資料に記載されているディフォルト値とは違っている箇所もあるようですが、不定になる箇所があるのかもしれません。しかし、チップのバージョンを示すRead Onlyのレジスタの値が資料の記述と違っています。資料が古くて、実際にモジュールで使われているチップのバージョンの方が新しいようにも読みとれます。しかし、資料の初期値説明の箇所もバージョン表記があいまいで、RevFについて説明しているのかRevEについて説明しているのかはっきりしません。うーん、いかにも台湾/中国的?!

資料の初期値を書き込んで、Yukiさんのコードにならって選局操作(TUNE)を実行してみます。選局の際には周波数を指定してやりますが、ここでは80.0MHz(TOKYO FM)を指定しています。



選局の結果としては受信信号の強さを示すRSSIという値とIF_CNTという値が返ってきます。なんでもIF_CNTは250近辺の数字が出ていれば良いようです。上に示したように、わざと周波数をずらして指定すると、RSSIの値はさほど変わらないのにIF_CNTは大きくはずれていることがわかります。

続いて自動選局(SEEK)の試験です。自動選局ではRSSIの閾値を指定してやります。現在選局している周波数から始めて、閾値以上の受信信号がある局をサーチしていきます。次の例ではRSSIが50以上の局だけがSEEKの結果、見つかっていることが確認できます。閾値を小さくすれば、信号の弱い局もつかまえるようになります。なお、サーチしている最中に定期的にRCHANの値を表示してやることで、どのあたりをサーチしているかを確認することができます。



上の例では82.5の次は、108.0まで探しも見つからないので76.0に戻って探した結果、77.1をつかまえています。R3のB15を反転してやるとサーチする方向が逆になります。



R10のB3を0にすると、上限/下限周波数に達したところでサーチを中止し、FAILのステータスが返ります。



これまでに動作確認できたのは、こんなところです。次はちゃんと音が出るようにしたいのですが、LCDとスピーカつけるためにはちゃんとケースに入れることを考えた方が良さそうです。

FMチューナモジュール

以前から気になっていたSparkfunのFMチューナモジュールを買ってみました。このモージュール、当初はNXPのTEA5767を使ったものだったのですが、現在はAirohaのAR1000というチップが使われています。ところが、このチップの資料が貧弱で、資料に書かれている情報だけでは使うことができません。このあたりの経緯や、実際に使うためのサンプルコードについてはYukiさんが電子工作室の記事にまとめれています。おかげさまで、どうやら簡単に使うことができそうです。わたしも、ボチボチ実験を進めているので、結果についてはまた次回の記事でまとめようと思います。

AR1000の資料が貧弱なので、他のチップのデータシートを参考にしようと調べてみたところ、SilabsのSi4702/03に良く似ていることに気が付きました。レジスタのビットのネーミングが同じものがありますし、3線式での読み書きの仕方もとても良く似ています。Si4702/03の仕様を参考にしてAR1000が作られているのだろうと推測されます。

Si4702/03は、ユーザ登録すればデータシートがダウンロードできますが、同じSilabsでもSi4704/05やSi4708/09についてはデータシートのダウンロードはできません。主力商品の情報については、公開しないということなのでしょうね。

DTMFでLCD表示内容を変化させる

W-SIMを使って発着信する機能を実装するのは、実際に電話がつながるので楽しいことは楽しいのですが、通信料金が発生してしまうのが痛いところです。端末をもう一台契約すれば通話料はタダにできますが、基本料金はかかってしまいます。そこで、SIPは使うけれども、W-SIMは使わないで遊んでみることにしました。X-Liteは、わたしの持っているYealinkのUSB電話機をサポートしているようなので、今回はこの電話機から操作をおこなっています。



以前、DTMFの検出実験をしましたが、その機能をチョコット強化して、DTMFを使ってLCDに表示するデータを変化させるようにしてみました。X-Liteからは、普通にSIPを使って発信するのですが、特別な番号(900)がダイアルされた場合には、VoIP GWが呼を終端してしまい、W-SIMへは中継しないようにします。そして、X-LiteからのDTMF信号によって、LCDに表示される情報を変化させるようにしてみました。実際に表示される情報は次のとおりです。

• 自局のIPアドレスとDNSサーバアドレス(DTMF 0)
• 日付と時刻 (DTMF 1)
• 温度と明るさ(DTMF 2)

DTMFを検出すると、表示項目が切り替わります。日付時刻については、DTMF 1を検出した時点でSNTPを使って時刻を取得し、その後はSAM7のクロックでカウントしています。USB電話機側にも日付/時刻表示がありますが、こちらはPCの時計を使って表示しています。PCの設定時刻がずれているので、VoIP GWの時刻表示とズレが生じでしまいました。

温度と明るさはこの記事で書いたセンサーの値を表示しています。温度については摂氏での表示ですが、明るさはタイマー値をそのまま表示しているだけであり、ルクスへの変換はおこなっていません。温度センサLM60はAT91SAM7X256のADへ直結しているのですが、ADが10bitしかないこともあり、値がバタついています。OPアンプで2～3倍にしてやった方が良かったようです。

今回はDTMFでLCDの表示内容を変化させてみましたが、マイコン側にSSRとかつけてやれば、DTMFでコンセントの電源制御とかもできますね。ブラウザ経由で制御するよりも、電話機で制御できればリモコン並みに手軽に使えるんじゃないかとも思ったりしますが、X-Liteのようなソフトフォンに頼っていたのではPCが必要になってしまいます。ここは、手軽に使えるワイヤレスのSIP端末とか欲しいような気もしてきました。

LPC1700

NXPがCortex M3対応MCUとしてLPC1700シリーズを発表しました。クロックも早くなるし、これからは本格的にARM7TDMIからCortex M3への移行が進んでいくのでしょうね。今回のNXPの発表では、LPC1700シリーズを構成するMCUの品番とその概要が具体的に述べられており、DRAFTではありますがすでにデータシート(簡易版)もダウンロードできるようになっています。これはいいですねぇ。自分ならどれを使おうかと勝手な妄想を膨らますことができて楽しめます。

ATMELもすでに6月にCortex-M3対応を表明しており、今年Q4から出荷開始と言っていますが、どんなチップが出てくるのかはまだ明らかになっていません。NXPみたいにそろそろ概要を示してもらえないでしょうかねぇ。NXPも12月からESでの出荷開始と言っています。我々、庶民がボードとして買えるのはどちらが先になるのでしょうか。来年が楽しみです。

久し振りにNXPのLPCのページを見て、ARM7系の品種の多さに改めて驚きました。シャープから部門を買収したとはいえ60を超える品揃えです。値段的にもだいたいSAM7よりLPC2000シリーズの方が安いし、人気高いのでしょうか。個人的には、DMAが使えるのが便利でSAM7を使ってきましたが、最近のLPC23xx/LPC24xxではDMAも使えるようだし、ちょっと使ってみようかなぁという気がしてきました。

発信者名の表示

久し振りにVoIP GWネタです。前回は通話時に音声波形を表示するようにしてみましたが、今回は着信時の機能です。着信時には発信者の電話番号を表示しますが、携帯電話のように電話帳機能があれば、漢字で表示することができます。これまでの自作ジャケットには電話帳機能がありませんでしたので、発信者名の表示はできませんでした。それに漢字フォントをジャケット側に準備するのも面倒です。

今回はEthernetがあるので、この通信機能を使って、サーバ側に電話番号から名前への変換機能を用意することで、発信者名の表示を可能とすることにしました。仕掛けはいたって単純で、下図に示したようにサーバ側に発信者番号情報を渡すと、サーバが発信者名への変換をおこないその漢字表記のビットマップを返すというものです。ビットマップの生成にはいつものようにIPA GUIフォントを使っています。


サーバ側には発信者番号だけでなく、イベントの種別も渡しています。これは、今後、着信以外のイベントを渡して処理することを想定しているためです。プロトコルとしては、UDPで簡易的なもので実験しています。本来であれば、TCPでHTTPとか使って、データの送受もXML形式を使うとかすればWebアプリ的になるのですが、TCP載せるとRAM容量がキツクなってきそうな状況なので、パスすることに。サーバからの応答は、縦40ドット分の画像イメージということに決めつけてしまい、生データを返すだけにしています。そのため、受信処理ではLCDのフレームバッファに応答を読み込むだけで済ましています。そうすると、定期的な画面更新処理が走った時点でLCD画面に表示が現れるというわけです。

シーケンス図に示したように、発信者名が表示される前に短時間ですが、発信者番号が表示されている期間もあります。動画をコマ送りすれば、わかるかもしれません。ただし番号は一部Xでつぶしてあります。また、今回の動画ならびに写真では青色LEDのバックライトを点灯させています。

サーバ側処理も極めて単純化して実験しています。ビットマップ生成は以前 フォントデータ生成に使っていたものをNokia 5110用の生データを出力するように変更したものをひとつのコマンドとして用意しておき、それをPerlで書いたサーバから呼び出して使っています。電話帳データは、いまのところPerlの連想配列としてサーバコードに埋め込んであるだけです。



発信者番号が非通知の場合にはID=には何も番号が載らないので、この場合にはanonymousという名前にVoIP GW上で変換しています。これをサーバ側で漢字表記に変換する際に非通知という文字列に変換することにしました。プロトコル自体はUDPベースで、サーバからの返答内容をビットマップととして、そのままLCDに送っているだけの処理です。

フォントはスケーラブルですので、表示する文字数に応じて適宜フォントのサイズを変更してビットマップイメージを作成しています。これもサーバ側の機能ですので、マイコン側では何にもせずに単に表示しているだけなのですけど。

ATMELは買収されちゃうのか？

ATMELのHPを訪ねて、今頃になって、Microchip(NASDAQ: MHCP)とOn Semi(NASDAQ: ONNN)からのATMEL(NASDAQ: ATML)に対する買収提案を知りました。すでにいしかわさんも日記にかかれていますが、やはりATMEL/AVRファンにとっては心配ですよね、ATMEL製品の行く末が。。。PIC/AVRともに8bitから32bitまで、ファミリーが揃ってますもんね。

秋月の品揃えをみても、PICばかりがドンドンと増えてくるのが、気になっていました。趣味の世界だけでなく、実際の製品組み込み分野でもそれだけ、PICのマーケットシェアが強いということなのでしょうか？　Arduino人気をきっかけに大学や専門学校での専門教育において、AVRを使った実験/研究が増えていけば、製品分野でのATMEL採用が増えていくきっかけのひとつになるかもしれないと思っていたのですが。

わたしは、"あまのじゃく"な性分のため、あまりにもポピュラーなPICは全く使ったことがありませんし、データシートを読んだこともありません。とは言え、実はAVRも一度MEGA8を使って実験工作した経験があるだけで、AVRファンを名乗るほどの者でもないのですが。。。

とりあえず、買収提案の発表によって、MHCPとONNNの株価は下落してATMLは値上がりしていますね。この調子が続けば$5での提案は安いということになってもいいような気がしますが、そんなことよりもやはりATMELの名前と製品は残って欲しいです。モトローラがフリースケールになったり、フィリップスがNXPになった時も驚きはしましたが、これらは分社化ととらえて、時代の流れで名前は変わっても製品は継続しているので受け入れやすかったと思います。今度の発表は、やっぱりショックだな。