第３世代

トラ技がLPC810特集だったので、この機会に久しぶりにLPC810がらみで記事を書いておくことにします。

昨年、LPC810とConnectEVEをつなげた記事を書きました。ブログ記事にはしていませんでしたが、その後FTDIの評価ボードを買ったこともあり、このボードと直接つなげられるLPC810のボードを製作して、昨年、飲み会でお披露目していました。それがこちらのボードです。





６ピンのヘッダはFTDIのシリアルケーブルを接続して、書き込みをおこなうためのものです。ジャンパは、ブートローダ起動時に使用するためのものです。

写真で見てもわかるように最低限のハードで簡単に作れるのは良いのですが、実際に使ってみるとリセットボタンを省略したためか、ブートローダがうまく起動できないことがしばしば発生しました。書き込み時に何度もシリアルケーブルを抜き差しないと、書き込みができないので、不便に感じていました。

そこで、新たにリセットスイッチを追加するとともに、ひと回り小型化したボードを製作しました。ジャンパも増えていますが、これは電源をシリアルケーブルとFT800ボードのどちらから取るかを選択するためのものです。こいつは、不要だったかな。





基板としては、第2世代ではタカチのTNF29-44を使っていましたが、第３世代ではTNF25-35を使用しています。ふたつを並べると、こんな感じ。



映り込みを避けるために、ちょっと斜めから写真を撮ってみたらLPC810が隠れて見えなくなってしまいました。

FRDM-KL25Z

Kinetisを使う仕事が入ったので、勉強のためにFRDM-KL25Zを購入。今後の動作試験とデバック用にヘッダソケットとSWDヘッダを半田づけ。最初に目についたUSBコネクタそばのSWDヘッダを取り付けたのですが、よく見ると、これはOpenSDA用の方のヘッダ。メインのマイコンであるMKL25Z128VLK4用のSWDヘッダは80ピンのご本尊のそばでした。

ここのところLPC810とかLPC11U37とかを使っていたので、Kinetis KLはずいぶんと複雑で機能的にもリッチに見えます。でも、クロックジェネレータの動作モードとチップのパワー・モードの種類が多くて、しかも相互に関連があるうえにペリフェラルの動作とも関連してくるので、どうやって使い分けるのか正しく理解するには時間がかかりそうです。理解できても、正しい手順で使うだけでも大変そう。

そのあたりの面倒な設定をできるだけ簡単に済ませたいこともあり、開発環境としてFreescaleが提供しているProcessor Expertを導入。手順についてはこの記事がとても参考になります。Processor ExpertはEclipse用のプラグインとしても提供されているので、Mac OS上にEclipseを入れて、プラグインを追加インストールしてみたのですが、途中でエラーになってしまいます。リリースノートを見ると、Mac OSは対象OSに入っていないので、動かないということなんでしょうか。しょうがないので、Win7上にバイナリのパッケージをダウンロードしてインストールして使うことにしました。うーん、残念。

SAM G50/53

ここしばらくブログ更新をできずにいたので、ちょっと時間が経ってしまいましたが、先週ATMELがSAMシリーズの新しい製品SAM GシリーズをCES 2014に合わせて発表しています。

SAM GシリーズはCortex-M4のFPU付きです。クロックは48MHzと抑え気味で、低消費電力の方を売り文句にしているようです。クロックやペリフェラルは従来のSAM3/SAM4シリーズとほぼ同等のようなので、SAM4Lのようなクセがなく使い易そうです。SAMG53の方はI2SやPDMインタフェースを持っているので、オーディオ指向という印象。目新しい機能としては、メモリ間のDMAをようやくとサポートするようです。

RAM容量が64KBとか96KBもあるのが嬉しいところですが、ペリフェラルにUSBが無いのが残念なところ。そしてTQFPだと100ピンパッケージのデバイスしかないのが痛い。自分としてはやはり48ピンか64ピンが好みだな。

TagInfo

自分で作ったHandover RequestのNDEFがTagWriteで読み出せずにいましたが、原因はTagWriteの方にありました。同じNXPからTagInfoというアプリが出ているので、こちらを使ってみたところすんなりと読めました。



これだけちゃんとデコードしてくれると、今後も便利に使えそうです。

さてこのHandover RequestをNexus 7で読んでみても、何のアクションも起こしてくれませんでした。どうやらTagにHandover Requestを書きておいても、それを読んだNexus 7がHandover Selectを返すことは無いようです。NFC ForumからHandoverの仕様書をダウンロードして読んでみると、Read/writeのできるデバイスからHandover Requestを送信しないとだめなようです。結局、RF430CL330HではHandover Selectを書いてStatic handoverはできてもNegotiated handoverはできないようです。DLP DesignからはDLP-RF430BPというボードも出ているので、こちらを使えばNegotiated handoverもできると思われます。

Static handoverでも、SSP OOBを使ってのBluetooth接続はできると思われるので、これを実験することを考えたいと思います。

Handover RequestのNDEFを作ってみたが...

NFCの続きです。RF430CL330Hを使ってのStatic Handoverの雰囲気はわかったので、今度はNegotiated Handoverに挑戦する段階に入ります。

まずはHandover RequestのNDEFを作らなくてはなりませんが、NXPのTag WriterはHandover SelectのNDEFは作れてもHandover Requestの方は作れないようです。そこで、自分で作ってみることにしました。そうは言ってもまだちゃんとNDEFについて勉強していないので、BTSSPに出ているサンプル・データを基にすることにします。BDADDRの部分とLocal name、そしてService UUIDの部分を変更してやれば、自分の環境で動作試験ができるはずです。データの頭の部分にType4タグのコンテナが必要ですが、この部分はHello Worldのサンプルと同じでかまわないハズです。

こうして用意したタグデータをNXPのTagWriter で読んでみると



ちゃんと読めていませんねー。122バイトあるはずのデータがどういうわけか22バイトしか拾ってません。ちなみにHrはHandover Requestを意味するタイプなのですが、ちゃんとデコードできていないんでしょうか？どこが間違っているのかわかりません。試しにHandover Selectのタグデータも作ってみましたが...




こちらはちゃんと読み出せました。と、いうわけで何が間違っているのか、まだ調査中です。

MRTではまる

年をまたがってようやくとバグを修正できたので、メモしておきます。

大晦日から久しぶりにLPC810をさわって、FTDI EVE用ソフトの修正に着手。これまではSystickタイマーを使って10ms毎の割り込みを生成し、それを使って時計の計時とディレイタイミングの生成を行っていました。少しはLPC810の機能を使ってみようと思い、これをMRT(Multi Rate Timer)を使うように変更することにしました。MRTは４チャネルのカウンタを持っており、繰り返し割り込みあるいはワンショットの割り込みをチャネル毎に生成することができます。この機能を使って、チャネル0では１秒毎の計時用割り込みを、チャネル1ではディレイ用のワンショット割り込みを生成することにしたのです。

MRTでは各チャネル毎のSTATレジスタにより割り込み要求の確認とクリヤができますが、これとは別に全チャネルの割り込み要求の確認とクリアができるIRQ_FLAGが用意されています。２つのチャネルからの割り込みを検出したいので、IRQ_FLAGレジスタを使うことにして、タイマの初期化ルーチンと、割り込みハンドラを作成。ところがちゃんと動いてくれません。割り込みを許可すると動かなくなるようなので、割り込み処理に問題があるようでした。何しろ８ピン全部を使っているので、JTAGも使えず机上デバックで試行錯誤してみることに。するとSTATレジスタを使って割り込み確認とクリヤをおこなえばちゃんと動くことが確認できました。結局、IRQ_FLAGレジスタを参照するように割り込みハンドラを作ると動かないことが判明。そこでNXPからダウンロードしてきたLPC8xx.hでMRTのレジスタ定義を確認してみると、

typedef struct {
__IO uint32_t INTVAL;
__IO uint32_t TIMER;
__IO uint32_t CTRL;
__IO uint32_t STAT;
} MRT_Channel_cfg_Type;

typedef struct {
  MRT_Channel_cfg_Type Channel[4];
   uint32_t Reserved0[1];
  __IO uint32_t IDLE_CH;
  __IO uint32_t IRQ_FLAG;
} LPC_MRT_TypeDef;

となっていました。あぁ。。。やられました。途中にあるReserved01の大きさが間違っています。ただしくは、

uint32_t Reserved0[45];

です。これが原因でIRQ_FLAGレジスタのアドレスが狂っていたのです。その結果、割り込みがかかりっぱなしになってしまっていたようです。