nRF24AP1

Nordic Semiconductorは、Nike+iPodでも使われているnRF24L01なんかで有名ですが、nRF24AP1についてはSparkfunの新製品紹介で初めて知りました。

nRF24L01はSPIで制御できるトランシーバでしたが、nRF24AP1はANTというプロトコルを内蔵しており、非同期/同期シリアル経由でホストと通信できるようになっています。nRF24L01では基本的な伝送制御手順から自分で設計して実装する必要がありましたが、nRF24AP1ではANTという仕様が開示されているプロトコルがあたかじめ内蔵のマイコンに実装されているので、ユーザはシリアル経由でANTプロトコルを利用できるようになっているようです。ネットワークトポロジーも各種サポートできるようになっているようだし、なんと言ってもシリアル経由で使えちゃうというのはお手軽ではないでしょうか。

上述のようにnRF24AP1は非同期と同期シリアルのどちらでも使える仕様になっていますが、このSparkfunのボードではPORTSEL信号がLOWで固定されており、非同期しか使えないようになっているようです。シリアルの通信速度は、ディフォルトで4800bps, ジャンパ設定で19200, 38400, 50000が選択できるようです。速度や距離を稼ぎたいのであれば、おそらくnRF24L01のモジュールを使って自分でプロトコルを実装する方が適しているのでしょうが、近接した距離でのちょっとした通信であれば、こちらのモジュールの方が安くて簡単に使えそうな気がします。

試しに使ってみたい誘惑にかられているのですが、問題は何を作るかだなぁ。。

GIFを展開するには

Google MapsからGIF形式で地図画像を取得して表示するために、GIF形式データをLCDのビットマップに展開する方法について調べています。自分で展開ルーチンをゼロから起こす必要も無いだろうということで、netpbmに含まれているgiftopnmというコマンドのソースを使おうとしています。GIF形式を展開する処理はすべてgiftopnm.cの中に含まれているようなので、このコードから必要な部分だけ抜き出して利用できそうです。

GIF形式についてもざっと勉強して、Google Mapsの返すデータの内容を確認。

• GIF バージョン89aを使用
• 24ビット色から256色(8ビット)を選択して表示するためのカラーマップを持つ
• 画像情報は画面左上側から順番に圧縮されて記録されているので、展開しながら順次表示していける
• 展開の結果得られるのは、各ピクセルの色情報、すなわちカラーマップへのインデックス。

なるほど、頭からシーケンシャルに読みながら展開して表示していけるのですね。カラーマップは、Image Blockの中にImage Dataに先立って記録されています。カラーマップを読み込む際に、256のインデックスから16ビット色への変換表を作っておけば、あとはイメージデータを展開しながら、簡単に色データへ変換して表示できそうです。

こんどはEthernetらしい

Interfaceを本屋で眺めてビックリ。またもやオマケ基板が付くようです。9月号でしたっけ？なにしろ、買ってないのでうろ覚えです。

こんどはEthernet付きとのことですが、どんなチップでしょうか。MACだけでなくPHYも内蔵しているんだろうかとかちょっと興味ありますが、おそらく死蔵コレクションが増えることになるでしょう。

アマチュアにとっては、RTL8019に代表されるNE2000系ethernetから脱却できるだけでも、チョットいい話ではあります。

地図表示での問題

LCDとメモリの動作確認はひととおりできたので、LCDの下にW-SIMを配置してモデム信号だけ配線しました。PCM関連信号はいまだ未接続です。いつもの手順でTOPPERS用のTCP/IPスタックであるTINETを追加して、試しにGoogle Mapsの画像をダウンロードして画面いっぱいに表示してみました。



このLCDはQVGA(240X320ドット)サイズで16ビット色で表示することができますので、画面のデータ量は240X320X2 = およそ150KBに達してしまいます。このビットマップを実際にダウンロード/表示するのに、だいたい15秒から20秒程度を要してしまっています。データ量が増えてしまったので、ダウンロード時間がかかるようになってしまったのですが、やはりこれでは長すぎです。量がかさばるビットマップ形式ではなく、もともとGoogle Mapsが返してくれるGIF形式でダウンロードするように改めるべきですね。以前は、AT91SAM7S256を使っていて、使えるRAMも残り少なかったのでビットマップ形式でダウンロードする方式を選択しましたが、今回はRAMを512KB積んでいますので、GIF形式でダウンロードして、展開しながら表示する方式を実装してみようかと思います。

写真の地図データは、GIF形式であればおよそ32KBでした。このサイズならば、3秒から4秒でダウンロードして表示できてもいいはずです。

大きなフォントも要りそうだ

Nokia LCDで使っていた文字表示ルーチンをちょっと変更して使えるようにしてみました。



Nokia LCDで同じ画面を表示した時の様子はこんな↓でした。画面が広くなったのは嬉しいのですが、画面の広さに比べて文字が小すぎですね。いつものようにRTCも載せたのですが、今のままじゃ時刻表示も小さすぎて情けないです。このフォントは確かSparkfunのサンプルプログラムに含まれていたものを拝借して使っているのですが、サイズは幅8ドットの高さ16ドットです。倍くらいの大きさがあってもいいですね。適当なフォントを探してくる必要ありです。

SRAM動作の再確認

以前の記事で簡単なSRAMの動作確認はしてあったのですが、最初の256バイトのR/Wくらいしか確認していなかったので、512K全部のR/Wを確認してみました。すると、32Kバイト毎にイメージが出ていることが判明。A15が怪しいようです。配線を確認してみるも、問題なし。マサカと思い、ピン設定を確認してみると、どういうわけかA15を出力するPB15の設定だけが抜け落ちていました。

AT91SAM7のピン設定は、LPC2000と比べると素直に表現できてわかりやすいと思うのですが、それでもやはりソースコードを手書きで作成/修正していると、こういう間違いを時たまやらかしてしまいます。こういう時はKeilのようなIDEでピン設定ができるのは、やっぱり便利だなぁと感じてしまいます。

タッチパネルで圧力を感知する

TechToysのLCDボードで使用されているタッチパネルは4線の抵抗膜方式と呼ばれる種類のもので、安価で入手しやすいものです。最近話題のiPhoneなんかは静電容量方式という方式のようです。以前にも書いたように、このタッチパネルはちょっと指が触れたくらいでは感知してくれなくて、ある程度の圧力がかからないと感知してくれません。2枚の電極膜が接触するために、ある程度の圧力が必要なためでしょう。そのため、指の腹で軽く触っての操作はうまくできません。タッチペンを使うか、指の爪先で触ることで必要な圧力がかかるようにしてやる必要があります。指の腹でタッチする場合には、ちょっと押し込むくらいに意識してやれば、感知してくれます。

LCDボードに搭載されているタッチパネルコントローラADS7846のデータシートを読んで知ったのですが、このコントローラではタッチによって生じる2枚の電極間の抵抗を調べることができます。この抵抗はタッチされる際にかかった圧力や、圧力のかかった部分の面積によって変化するので、タッチ圧力のかかり具合を識別することができるようです。Linuxのドライバに含まれるADS7846のコードでも、この機能を利用できるようです。

こんな芸当ができるとは知らなかったので、この機能を実際に実験してみることにしました。以前の表示デモにちょっと手を加えて、圧力のかかり具合に応じてプロットする四角形の大きさを変化させるようにしただけです。指の腹で押しこんだり、ペン先の面積を広くして操作した場合には、軌跡が太くなっていることがわかります。



普通のタッチパネルの使い方だとマウスのエミュレーションだったりしますので、ペンダウン、ペンアップ、そして座標変化のイベントを拾うような使い方です。このように圧力のかかりかたの違いを検出できるとは思ってもいなかったので、いい勉強になりました。

NANDフラッシュへのアクセス (その2)

引き続きLCDボード上のNANDフラッシュへのアクセスに挑戦です。

前回は、回路図を確認して、DB0～DB7がフラッシュにはつながっていなかったという事実を知ってガクゼンとしました。配線直すとLCDアクセスがいやらしくなるので、やりたくありません。フラッシュにはDB8～DB15の8ビットはつながっているのですから、16ビットアクセスで使ってみればどうだろうかと思いつきました。

実際のNANDフラッシュは8bitデバイスですが、SAM7SE256上の設定では16ビットデバイスとしてSMC (Static Memory Controller)を設定してやります。そうすれば、マイコンが書き込むデータの上位8ビットだけが実際にNANDフラッシュに伝わります。つまり書き込み時には、本来書き込みたいデータを8ビット左シフトして16ビットでの書き込みをすれば良いことになります。同様に読みだした16ビットデータは、上位8ビットしか意味を持たないことになるので、8ビット右シフトして扱ってやればいいはずです。この方針でソフトを変更して実験してみると、めでたくデバイスIDが正しく読み取れるようになりました。

続いて、ページデータの読み込みの実験です。本来は8ビット幅で、1ページ512バイト+スペア16バイトのデバイスなのですが、あたかも16ビット幅で、1ページ512ワード+スペア16ワードのデバイスであるかのようにアクセスしてやります。そして、読み取った16ビットデータのうち上位8ビットだけを集めてやります。すると、0ページ目のデータとして0x54が512バイト書き込まれている様子が読み出せました。どうやら他のページは全部イレーズされた状態のようで、0xffとなっているようです。0ページ目の0x54はTechToysのQAで書き込まれたデータではないかと思われます。

HY27US08561Aは、32ページ/ブロックで、全2048ブロックのNANDフラッシュです。Bad blockを確認するために、いちおう全ページのスペア領域を読み出してみましたが、すべて0xffになっていました。どうやらBad blockは登録されていないようです。

試しに1ページ(メイン領域にだけ)書き込み(プログラム)してみて、読み出してみると正しく書き込んだデータパターンが読み出せます。16ビットデバイスとしてアクセスしてやることで、読み書きは問題なくおこなえるようです。

AT91SAM7SE256には、NANDフラッシュ用の機能としてECCコントローラを持っており、2ビットのエラー検出と1ビットの訂正を行える4バイトのECCを計算/検算することができます。しかしながら、上述のようにだまして16ビットでアクセスしているので、このECC機能はさすがに正しく動作させることはできません。

LCDボードのパターンも確認してみましたが、フラッシュのデータ線を入れ替えるのは無理そうでした。残念ですが、ECC機能の利用はあきらめて、16ビットアクセスで使うしかなさそうです。現状は、ページの読み書きができただけの、最も低レベルでの操作ではありますが、NANDの使い方の理解の勉強にはなりました。

NANDフラッシュへのアクセス

TechToysから購入したLCDには32MBのNANDフラッシュも搭載されていますので、こいつの読み書きに挑戦してみました。搭載されているのはHYNIXのHY27US08561Aという8ビット幅のものです。NANDをマイコンで使うのは初めてなので、データシートを最初からよみながらつなげてみました。

AT91SAM7SE256にはNANDフラッシュを接続するための信号として、NANDALE, NANDCLE, NANDWE, NANDOEが用意されています。SRAMやLCDをR/Wする際にはNWE/NOEが使われるのに対して、NAND用にはNANDWE/NANDOEが独立して用意されているのです。ところが、LCDボードではLCDとNANDのR/W信号は区別されておらず、共通となっています。そこで、セレクターとして74HC157を追加して、CE信号によりNANDWE/NANDOE と NWE/NOEのどちらをLCDボードにつなぐかを選択してやるようにしました。

その他のNANDフラッシュ関連信号としては、WPをプルアップしてやり、CEとR/Bを空いているGPIOで制御してやるように配線してやることで、ハードウェアの準備は完了。続いて、ソフトの準備です。サンプルのページ読み書きプログラムは、ATMELからもTechToysからも提供されていますので、それらを参照すれば簡単に試験準備は整います。まず最初にRESETコマンドを送り、続いてREAD IDコマンドを送って、正しくデバイスIDが読み出せることを確認しようとしました。ところが、これがちゃんと動いてくれません。

正しくIDが読み出せれば、0xAD, 0x75の2バイトのIDが返ってくるはずなのに、0x00, 0x00という結果になってしまいます。正しくNANDにアクセスできていないようです。ソフトは単純で間違えようが無いので、マイコンとLCDボード間の配線を確認してみますが、これも間違ってはいません。改めてLCDボードの回路図を見てみるとスグに原因がわかりました。なんと、LCDにつなげたデータバス16ビット(D0～D15)のうち、NANDフラッシュにつながっている8bitはD8～D15の上位8bitだったのです。SAM7SE256のNANDフラッシュインタフェースでは、8bit NANDアクセスの場合にはD0～D7の8bitでアクセスするので、実際には全くNANDフラッシュにアクセスできていなかったのです。

データ16ビットの上位と下位を入れ替えて配線しなおせば、NANDフラッシュへはアクセスできるようになります。しかし、そうしてしまうとLCDにアクセスする際には、座標や色データの16ビットをスワップしてやる必要が生じてしまいます。

SRAMとLCDの動作確認

AT91SAM7SE256実験ボードに搭載したSRAMとLCDの動作確認までできました。



SAM7SE256では外部メモリとしてCS0-CS7の空間が用意されており、それぞれにデバイスの種類に応じた動作やアクセスタイミングが設定できるようになっています。今回、外部メモリとして接続したいデバイスには次の3つがあります。

1. SRAM. 18bitアドレス、16bitデータ
2. LCD. 1bitアドレス、16bitデータ
3. NAND FLASH. 8bitデータ

これら3つを、8つのアドレス空間のいずれかに配置するわけですが、NAND FLASHについてはCS3にしか置けないという制限があります。SRAMとLCDを配置する空間を決めるために、それぞれのCS信号が出力されるピンを確認してみると、いずれのCS信号も次のように出力ピンは１つしかないうえに機能が多重化されています。

I/O Line	Peripheral A	Peripheral B
PA19	RK	NCS4
PA20	RF	NCS2
PA21	RXD1	NCS6
PA22	TXD1	NCS5
PA26	DCD1	NCS1
PC15	D15	NCS3
PC20	NANDCLE	NCS7
PC23	CFRNW	NCS0

NAND FLASH用のNCS3はD15と重なっているので、このCS信号は使えません。しょうがないので、NAND FLASHのアクセス時には空いているGPIOをソフトで制御してCS信号として使うことにします。NCS7は、NAND FLASHアクセスに必要なNANDCLE信号と重なっているので、これも使うことはできません。NCS0はCFRNWと重なっていますが、この信号はCompact FLASHの場合にだけ必要な信号なので、NCS0は利用可能。

残った5本のCS信号から、もうひとつ選択したいのですが、残りの信号はいずれもSSCまたはUSART1と重なってしまっています。どちらも後でW-SIMをつなぐのに使いたいデバイスです。CODECチップを使ってSSCは使わないことにしてしまおうかとも思いましたが、キャリア信号変化はCONNECT/DISCメッセージでソフト的に検出することもできますので、NCS1をを使うことにします。

結果として、NCS0をLCDアクセス、NCS1をSRAMアクセスに使用することにしましたが、デバイスとの競合による制約はけっこう厳しいなというのが感想です。

さて、これでLCDには16bitでアクセスできるようになりました。アドレスA2をRS信号として使い、コマンドの書き込みとデータの書き込みを区別させています。8bitの時の動作と比べてみると、20%～30%表示速度が向上したようです。