[nrf52]NFCのところを見ていく (2)

nRF52832ですが、今回もBLEは出てこない。
いいのだろうか、これで・・・。
ともかく、前回に続き、NFCを見ていく。

---

とっかかりはここだろう。
Experimental: NFC URL Record Application
NDEFのURIレコードを実現するアプリだ。

main.cだけしかなく、コメントを含めても100行程度だ。
呼んでいる関数は、

• nfcSetup()
• nfc_uri_msg_create()
• nfcSetPayload()
• nfcStartEmulation()

だけ。

そしてですな、nfc_uri_msg_create()以外はライブラリになっていて、SDKにしては珍しくlibファイルでの提供になっているのだ。
普段はだいたいソースが置いてあって、ないのはSoftDeviceのソースくらい(擬似コード？は置いてあるが)なので、珍しいのだ。
stringsコマンドで見てみるとarmccとか出てきたのだが、GCCでも使えるのかな？
でも、その近所にあるhal_nfc.cはソースがある。
状況からすると、nfc_lib.libにある処理がhal_nfc.cの処理を呼び、hal_nfc.cがハードをたたいているのだろう。
まあ、細かいことはいいや。

ただ、hal_nfc.cに定義してある値が、Type 2 Tagのブロック0～2までの内容になっているようだ。
つまり、NFCID1に相当する部分ですな。
ようなのだけど、ソースコメントは「TODO」って書いてあり、FICRからNFCIDを作るんですよ、みたいに書いてあるので、実はPreview DKだからソースと同じ値のFICRが書込まれているだけかもしれん。
じゃないと・・・ちょっとね・・・・。

でも、FICRの説明を読むと「Default header for NFC Tag」としか書かれていない。
なので、デフォルトではない値を使ってもよい、というように読めるが、それでよいのかな？
なんとなく、NFC-AはNFCIDを動的に更新させたり、更新できても全桁はさせないだろうと思い込んでいたのだ。
まあ、FeliCaのIDmと同じようなものだから、それを気にするようなシステムを作っちゃいかんのだが。

---

唯一、読んで意味がわかりやすいnfc_uri_msg_create()を見ておこう。

staticで25byte(ヘッダ4byte + メッセージ長1byte + メッセージ20byte)確保し、引数で与えられたデータをNDEFのURI形式にしていくだけだ。
つまり、単にNDEFのデータを作るだけの関数なので、自分でやってしまってもよい。
自分のstaticで確保したバッファアドレスを上位に渡すのはあまり行儀よくないが、まあ、全体的にお試しで作った、という感じがするから気にしても仕方なかろう。

まだこの辺の整備をどうするか、決めかねてるのですかね。

---

で、これだけ見るとデータ長も少ないのだが、実際に動作させて読込むと、256ブロック×4byteで1KBも読めることになる。
これが時間かかるんだな・・・。
もともとNFC-Aは106kbpsと遅いので、処理がもたついているのか通信が遅いのかはわからないが、3～4秒くらいかかっているようだ(心の中で数えたので、かなり曖昧だが)。

どこで制御するのか知らないが、製品になるときには全長の指定もできるようになってほしいものだ。