バックライトをつける

AitendoのNokia 5110基板にはバックライト用に青色LEDが４本載っているのですが、これまでは使っていませんでした。LED+端子に3.3Vかけてやれば点灯するようなので、FETでドライブすることとし、PWM端子につないで明るさ調整できるように配線してみました。

LEDはLCDの側面に配置されているので、横から照らすかっこうになるのだけども、その効果のほどはちょっとビミョーな感じ。特に画面中央あたりは、あまり見易くならないなぁ。

音声波形を表示してみる

先週はLCDへの表示を考えてセンサをつなげていたのですが、通話音声の波形を表示してみることを思いついて試しにコード書いて実験してみました。そこそこ見れる結果が得られたので、動画にしてみました。



Nokia 5110は84X48ドットですが、縦方向は8bitが6つ並んだ構成になっていることは以前の記事でも書きました。そこで、下部の縦方向32ドットを波形表示領域として使うことにしました。画面表示内容はマイコン側のフレームメモリに保持しているわけですが、波形表示領域は最後の84X4バイト分に相当することになります。画面の左スクロールは、このメモリ領域の内容を1バイトずらして、LCDにDMA転送することで再描画してやるだけでいいので、CPUにさほど負荷をかけずに実現できます。

波形はRTPの送信処理の中で描画することにし、1パケット分(すなわち20ms)の音声を横1ドットで表現することにしました。従い、画面上には20 X 84 = 1.68秒分の波形が表示できます。サンプリングは8000Hzですので、20ms分は160サンプルあるのですが、それを1ドット幅の振幅で表現することになります。具体的には、

1. 160サンプルをu-Law形式から16bitリニア形式に変換する
2. 160サンプルのうちの最大値と最小値を見つける
3. 最大/最小値を振幅とする縦線を引く

というような処理になるのですが、次のような最適化/簡単化を施しています。

• 音声の振幅なので、プラス方向とマイナス方向はほぼ同じでしょう。マイナス方向にだけ着目することにし、最小値しか求めない。
• 比較処理はu-Law形式の段階でおこない、求めた最小値だけをリニア形式に変換する
• 最大値は最小値の符号をかえるだけとし、求めた振幅の線を引く

波形としてはプラス/マイナス両方向があった方が、いかにもそれらしく見えるような気がしたので、今回は両方向に線を引いていますが、上記のように同じ振幅にしているだけです。表示領域が狭いので、今回は相手側からの音声だけを表示しています。波形表示をプラス方向だけにしてしまえば、自分側の波形も表示できますね。

ホントはPC側のX-Liteの操作とLCD画面の両方を並べた動画が撮れればいいのですが、そこまでやる気力も技量もありません。

温度センサと照度センサ

DTMF信号を使ってNokia 5110 LCDに表示する題材を何にしようか考えていたのですが、どうせならいかにもマイコンらしくということでセンサで拾った温度と照度を表示してみようかと思います。そういうわけで、近頃秋月に並んだふたつのセンサを買ってきてつなげてみました。



LM60
Make Controllerの左に配置されている黒いやつです。LM35は10mV/℃で出力するため、電圧測れば温度がぴたりとわかるという直読可能な温度センサでしたが、動作に4V以上が必要でした。LM60は6.25mV/℃なので変換が必要となりますが、3.3Vで動くしマイナス温度も測れるので試しに買ってみました。SAM7X256のAD4に直結して使う事にします。

S9705
明るさを出力パルスの周波数に変換してくれる照度センサです。LCDの上部の空きスペースに置いてみました。フォトトランジスタと比べると値段はちょっと高いですが、マイコンに直結できるので配線作業がラクなのが嬉しいです。こちらはタイマのTIOC2につなぎ、タイマのキャプチャ・モードを使ってパルス幅を測ることにします。

これまでAT91SAM7のタイマはWAVEモードを使ったことはありましたが、キャプチャ・モードを使うのは初めてです。そこで、まずはキャプチャ・モードの動作の確認から始めました。S9705の出力は50%デューティなので、下図のT1またはT2の時間を計れば周波数に応じた明るさがわかることになります。


AT91SAM7のキャプチャ・モードにはRAとRBのふたつのキャプチャ・レジスタがあり、RBへのロードとともにカウンタのクロックを停止することで、タイマ動作を止めることができます。また、タイマ動作の開始条件としてTIOA入力を外部トリガとして指定することもできます。そこで、下図に示すように

1. 立ち上がりを外部トリガとしてタイマを起動
2. 立下りでカウンタ値をRAにロード
3. 立ち上がりでカウンタ値をRBにロードするとともにクロック停止

という設定をしてやれば、T1とT2の時間を計った後にタイマが停止してくれるはずです。

この設定では自動的にカウントが始まって、T1とT2を計ると自動的にタイマが止まってくれますので、割り込み処理でタイマを止めたりする操作も無くなり助かります。ただし、外部トリガでの動作開始条件と動作停止条件が、どちらもTIOA2の立ち上がりになっているので、ちゃんと期待するような動作になるのかどうか疑問でした。停止条件とみなしてくれないと、再び外部トリガがかかったとして扱われ、カウンタが再スタートしてしまい、結果としていつまでも停止しないかもしれません。

実際に実験してみると、望んだように動作してくれました。カウンタが動作中の場合には、トリガ条件とみなさずに停止条件として扱ってくれるようです。助かるなぁ。実際に1秒間隔でRA, RBの値を読み出してから、タイマを設定する処理を実行してみると次のようになりました。



表示は

RB-RA (RA, RB)

という形式です。測定は日中、天気曇りの室内です。途中、RB-RAの値が185くらいから255位に増えている期間がありますが、この間はセンサを手の平でかざして少し陰にしてみています。試しに、懐中電灯で照らしてみるとRBの値は40位まで減ります。タイマのクロックは約24MHzですので、周波数は600KHz程度となりS9705の最大周波数(fmax)の300KHz～1000KHzの域に達しているのではないかと思われます。

一方、日が暮れてしまい、電灯もつけないでいると、16bitのカウンタはオーバフローしてしまいます。オーバフローの発生はフラグで検出できますので、タイマのクロックを下げていくように処理を組んでいます。

adc: 184 --> 59296 --> 270

という表示は、ADCで温度センサの値を読み出した結果です。184がADC 10bitでの直接の測定値ですが、これをVref 3.3Vで電圧に変換すると 592.96mV. さらに0℃でのオフセット424mVを引いて 6.25mV/℃で割ると 27.0℃となります。

MMnetSAM7x -- 無事届いた

出荷までずいぶんと時間のかかったMMnetSAM7xですが、昨日無事届きました。郵送は順調だったようです。結局、注文から到着までおよそ1か月かかってしまいました。新製品だったことと、夏休みにかかったことが原因で時間がかかったのかもしれません。ブルガリアのOLIMEXは良く名が知られていますが、ポーランドのPropoxはあまり知られていないと思うので、簡単にレポートすることにします。

今回注文したのは、MMnetSAM7xの1点のみです。注文はカートシステムですので簡単。支払もクレジットカードでらくらく。値段には税金が含まれていないので注意。カートに入れて送料選択してから、最後の段階で消費税計算されて上乗せされます。カード決済はリアルタイムでは連携していないので、いったん注文を入れてから紹介されるDotPayを使っておこないます。こちらも、リアルタイムではカード決済の承認がおりないようで、しばらくしてから承認されたかどうかの連絡がきます。イライラさせられたのはカードの承認が下りてから、出荷までに時間がかかったことだけです。出荷にはDHLも選べますがメチャクチャ高いので、迷わず郵送(The Polish Post)を選択です。送料は出荷先ゾーンによって異なりますが、アジア地域はZone 4のようです。出荷から1週間かからずに届いています。

ヘッダボードは下の写真のように発泡スチロールに挿したものをプチプチでくるんで、クッション付き封筒に入れた状態で送られてきました。SparkfunやOLIMEXのように段ボールの小箱には入っていませんでしたが、傷つくこともなく無事届いています。



表側にはAT91SAM7X256とPHYチップであるDM9161Aが載っています。裏側にあるのはAT45DB321Dで32Mb(4MB)のデータフラッシュです。Webページには64Mbのデータフラッシュが載っているようなことが書いてあるのですが、型番によってMCUとDataFlashの容量が異なっており、現在実際に販売されているのは32Mbのようです。



ボード以外にはCDが1枚同封されていました。内容はWebページに掲載されている資料一式という感じでARMならびにAVR関連商品の資料が全て入っていました。ダウンロード可能なものばかりですから、無くてもいいようなCDです。MMnetSAM7xは新しい商品のためか、CDには資料入っていませんでしたし。。



Make ControllerとMMnetSAM7xを並べてみると、上の写真のようにMMnetSAM7xの方がひとまわり小さくまとまっています。ただ、ボード上に実装されている部品に違いがあります。簡単に比べてみるとこんな感じです。

	Make Controller	MMnetSAM7x
MCU	AT91SAM7X256	AT91SAM7X256
PHY	DM9161A	DM9161A
RJ45	ナシ	アリ
3.3V Regulator	LM1117	ナシ
USB Filter	アリ	ナシ
USBプルアップ制御	アリ. PA11	アリ. PA1
記憶デバイス	AT25080A (1KB)	AT45DB321D (4MB)
CAN Transceiver	アリ	ナシ
ヘッダピン数	83	80

ヘッダのピン数だけでみるとMake Controllerの方が多いのですが、83ピンの中にはRJ45コネクタ接続のためのピンや3本の+3.3V, 10本のGNDが含まれています。実際に外に出ているPIOピンとしてはMMnetSAM7xの方が多くなっています。

RFC4733でDTMFを拾ってみる

W-SIMをつなげて、発信だけでなく着信も動作するようになってきました。かなりいい加減なSIPスタックで、限定的な状態遷移しかサポートしていないし、エラー処理もロクにしていないので、ときどきおかしくなることがあるのですが、そこそこ遊べるようになってきました。次のネタとしてDTMF音を検出して遊んでみることにします。

世の中には、テレフォンバンキングのように音声ガイダンスにDTMF音で応答することで、メニュー選択ができるサービスがたくさんあります。このようにDTMF音を判別して動作する簡易的なメニューをマイコン上に用意してやれば、X-Lite側からのDTMF入力に応じてマイコンにつながるI/Oを制御したりすることも可能でしょう。音声ガイダンスを用意するのはちょっと大変だし、制御するI/Oを追加製作するのも面倒なので、今あるLCD表示だけを使ってできることを考えようと思います。

こんな構想の第一歩としてDTMF音を検出してみることから始めました。まず最初に通話状態にするのですが、実際にPHS網に電話する必要もないので、発呼処理の開発途中と同じようにマイコン上で呼を終端してダミーのRTPを流すことにします。実際にPHS網へ発呼する動作とマイコン上で終端する場合の区別は電話番号でおこなうことにし、900番台の番号がダイアルされた場合には、マイコン上で終端することとします。

SIPを使う場合にはDTMF信号を送る方式にはいつくかの種類があるようです。

1. イン・バンドでの送信 DTMF音を音声信号として送る。
2. RFC4733(RFC2833)を使って送信 u-Law音声とは別のRTPペイロードとして、DTMF信号を送信
3. SIP INFOを使って送信 SIPのINFOメソッドを使って送信する
   

X-Liteの説明書によると、X-Liteは上記のすべての方式をサポートしているようですが、設定画面にはこれに係る設定は何もありません。どうやら、相手先のふるまいによって、どの方式を使うかを判断して動作するようです。イン・バンド方式では、音声信号のRTPの中からDTMF成分を検出する作業が必要なのでパス。INFO方式のためにはもう少しSIPスタックをまっとうにした方が良いように思えるので、RTP部分で処理できるRFC4733で行くことにしました。

発呼時にX-Liteが出すINVITEのSDPを調べてみると、
<quote>
m=audio 48684 RTP/AVP 0 101
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
</quote>
というようにRTPのペイロード・タイプとして101をサポートしていることを示しています。いままでは、X-LiteからのINVITEに対してVoIP GWからの応答に含まれるSDPでは
<quote>
m=audio 20002 RTP/AVP 0
a=rtpmap:0 PCMU/8000
</quote>
を返していましたので、DTMFはインバンドで送信されていました。応答SDPを
<quote>
m=audio 20002 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
</quote>
に変更してやったところ、次に示すようにRTP EVENTとしてDTMF信号が出力されるようになりました。



X-Lite上のDTMFボタンを押し続けている間、何度かに分けてRTP EVENTが出力されます。そして、ボタンを離すとendを示すイベントが同じ内容で3回出力されるようです。普通のボタンと同じように、ボタンが押されたことと離されたことの区別もできますから、VoIP GWには何のボタンも付けなくても、電話機のDTMFボタンを代わりに使って操作することができそうですね。

ようやく出荷されたらしい

先週出荷と聞いていたPropoxのMMnetSAM7xですが、結局先週中には出荷されず、今週火曜になってようやく出荷したとの連絡が入りました。これでようやくひと安心ですが、すでにMake Controllerで作業を進めてしまっているので、実際に使うのはしばらく先になりそうな気がしてきました。

それでも資料だけは確認しておきたいところなのですが、いまだに英文のマニュアルが準備できていません。リンクだけはあるのですが、"404 Not found"になってしまう状態。supportに問い合わせるも、3日経っても返答無しです。うーん、やはり応対は良くないですねぇ。とりあえず回路図はあるので、マニュアルはポーランド語のものを見てもなんとなく、何が書いてあるのか想像できそうな感じではあります。モノはちゃんとしていることを祈りましょう。

Nokia 5110を使ってみる

VoIP GWにつなげたNokia 5110の動作確認デモを作成してみました。このLCDは3.3Vで動作し、SPIでつなげられるので、AT91SAM7のようなマイコンで使うには非常に便利です。aitendoで販売されているものは、LCD自体は中古品ですが、2.54mmピッチのランドを持った基板が用意されているので、工作も容易で助かります。実際に使ってみると、外観に比して表示可能領域がちょっと狭いかなという印象でしたが、値段は安いし表示も見やすいので満足しています。(動画はピンボケになってしまっていますけど)




このNokia 5110は 84 X 48ドットを表示することができます。Nokia 6610のようなカラーLCDでは1ドットを描くにも12bitで色指定をする必要がありましたが、Nokia 5110はモノクロなので、1バイト書き込むだけで(画面縦方向に)8ドットを描画できてしまいます。逆の見方をすれば、1ドットだけを変更する操作はできないので、必要であれば画面表示内容をMCU側で覚えておく必要があります。全画面を覚えるには 84*48/8 =504バイトのRAMが必要となりますが、64KBのRAMを持つAT91SAM7X256にはさほどの負担ではありません。

コントローラであるPCD8544の使い方はいたって簡単なのですが、初期化のパラメータだけはどうすれば良いのかピンときません。Simさんの記事にトラ技2006年12月号の記事にこのコントローラの説明があり、プログラムもダウンロードできるとの記述があったので、そのプログラムの初期化パラメータを拝借しています。

デモではLCDへの描画ルーチンは、RAM上のバッファに描画した内容をDMAを使って全画面分LCDに書き出すというだけの処理しか使っていません。SPIのクロックは最大4MHzなので、全画面を書き換えても1msほどで終了します。スクロールの処理はRAM上の内容を左右あるいは上下にシフトして、全画面をLCDに書き出すことで実現しています。1ドットづつスクロールしていますが、毎回10msの間隔をおいています。

最後に使用しているフォントについて言及しておきます。英文フォントについては、Nokia 6610 LCDの頃から使用しているものを使っています。Sparkfunの同LCDのページで紹介されているJimboのサンプルに含まれていたフォントを使っています。デモでは6x8ドットのフォントを使っています。5110では一度に縦方向8ドットを書き込むわけですから、高さが8の倍数のビットマップが扱いやすいわけです。ただし、6610用のフォントは下の図に示すように横方向にスキャンしたビットマップになっています。そこで、これを5110用に縦方向にスキャンしなおしたものに変換して使用しています。



日本語のフォントについては、以前この記事やこの記事で書いたようにIPA GUIフォントを使用しています。以前作成したツールを改造して、5110用のビットマップに相当するC言語の配列定義を吐き出すプログラムをLinux上で作成しました。こんな感じで使っています。

% nokiaimg -10 ipagui.ttf "マイコン工作実験日記" > string_data.c

オプションの-10でサイズ(10ポイント)を指定して、TrueTypeフォントのipagui.ttfを使って指定された文字列を描画し、画面サイズ分のビットマップを作成しています。

発信できた

VoIP GWを使ってX-Liteから実際にW-SIMを使って発信できるようになりました。すでにSIP側で発信に最低限必要な処理は用意してあったので、W-SIM側でのモデム処理のコードを追加して、SSCでの送受信とRTPの送受信を結びつけてやった次第です。



117(時報)を呼んだ時の画面表示と、WireSharkのVoIP Calls解析でのPlayer表示です。Player表示では、上側の音声の18秒から23秒にかけての部分が、30秒間に1度の "プッ、プッ、プッ、ピーン"音に相当します。雰囲気ででますねぇ。



このようにPC側での画面やログを出しても、てんでマイコンを使っているという実感が湧きませんよね。ここは、やはり動画でも用意してAT91SAM7X256で動いていることを示しておきたいものです。しかしマイコン側には何の表示も無いし、音が出るわけでもないので、動画を撮る意味がありません。これでは悲しいので、実用上はさほど意味はないのですが、LCDを付けてみました。



動作状況に応じて表示するようにできたら、動画を撮ろうかと思います。使用しているLCDはaitendoで買ってきたNokia 5110ですが、このLCDについては別途記事を書くことにします。

DHCPを動かす

作成したVoIP GWボードでethernetが動作することは確認できたので、DHCPを載せてみました。もともとTINETではDHCP_CFGというコンフィギュレーション パラメータが用意されており、tinet_app_config.h等のファイルで指定することができます。しかしながら、このパラメータを指定してもDHCPのクライアント機能が組み込まれるわけではなく、UDP/IP層にてDHCPのパケットをエラーとせずに通すことができるようになるにすぎません。実際のDHCPクライアント機能は、ユーザが自分で組む必要があります。

そこで簡易的なDHCP機能をひとつのタスクとして実装してみました。起動後1秒ほどしてから、TINETが動き始めた頃を見計らってDHCPのDISOVERパケットを送信するようにしています。ほんとは、ethernetのリンク状態の変化も検出してやるべきなのですが、今のところはそこまでの機能は用意していません。

そういえばMACアドレスについての処理もインチキしています。もともとMake ControllerのファームではSPI EEPROMにシリアルナンバーが書き込まれているらしく、MACアドレスのOUI部分としてはAC-DE-48を使用し、下位の部分にシリアルナンバーを使用しているようです。ほんとは、同じように処理するようにTINETのethernetドライバを組むべきなのですが、現在はテキトウなアドレスをhard codedしてしまっています。

AC-DE-48というOUIも怪しそうです。IEEEのページで検索するとPRIVATEとなっており、Make用に割り当てられているわけではないようです。この番号はMACアドレスとしての使い方の説明のページでも使われている番号ですし。。そういうわけで、ちゃんとしたアドレスを使いたければ秋月のEEPROM買ってきた方が良いのでしょう。

返答あり

ちっとも連絡の無かったPropoxからようやくと返事がありました。催促すること3度めでの回答です。いいかげん電話した方が早いと思い定めていたところでした。

内容は、

　「遅くなってすみません。お問い合わせの注文の品は、今週中に発送予定です。」

との一行だけ。まぁ、ちゃんと受けてくれてはいるようなので、ひとまずは安心しました。こりゃ、品物が届くには あと10日くらいはかかりそうですね。どうやらPropoxと付き合うには、気長に構える必要があるようです。オンラインショップでは、在庫確認ができないし、リードタイムも不明なので困ったもんです。