2011年2月27日

[nfc][dep]PFB

まだISO 18092を眺めている。
ようやく、DEPの章に入った。

前回、DIDとNADはPN533が自動でやってくれている、と書いた。
しかしDEPの場合は、アプリ側がやってやらなくてはならないようだ。

InDataExchange()は、パラメータをそのまま送るだけである。
受けとる方も、そのまま受けとるだけである。
このパラメータの中身が、プロトコルによって変わってくる。
私が見ているのはISO 18092のDEPで、おそらくNFC-DEPと同じ物だ。
しかし、ISO 14443にもDEPがあり、それはそれで別の物だろう。
どっちにしても、送るコマンドはInDataExchange()で済む、ということになる。


さて、ISO 18092のDEPでは、パケットの頭にPFBというデータがつく。
「Information」「ACK/NACK」「Supervisory」のどれかとなる。
そして、それらの使い方も書いてある。

基本ルールは3つ。

  • Initiatorから始める。
  • More Informationを受信したら、ACKを返す。
  • Supervisoryはペアで使う。REQとRES。

Initiatorルール

  • 不正なパケットだったら、NACKを返す。
  • NACK未送信でタイムアウトしたら、attentionコマンドを送信する。
  • NACK送信済みでタイムアウトしたら、NACKを再送する。
  • ACKを受信したら、データの続きを送信する。
  • DSL_REQに対するDSL_RESがなかったら、DSL_REQを再送するかターゲットを無視する。

Targetルール

  • Targetはdata pduの代わりにRTO pduを送信できる。
  • chainingを含まないパケットを受信したら、データだと認識する。
  • NAKを受信したら、再送する。
  • 不正なパケットを受信したら、返事はせずにそのまま待つ。
  • Supervisoryのattentionコマンドを受信したら、attension応答を返す。

いくつか、新しく用語が出てきた。

chaningは、連続しているデータのこと。
1回に254byteくらいまでしか送信できないので、何度かに分けてデータを小分けにして送ることになる。
その小分けした部分を送るとき「まだ続いてますよー」という意味を持つ。
それがPFBの「Multiple Information」なのだけど、ここで「More Information」と書いてあるのが気になる。
同じものと思いたいのだが、それなら同じ用語を使ってほしい。。。

そしてRTO。
これはいきなり出てきた上に、説明がない。
どうやらこれは、ネットワークの用語みたいだ。
Receive Time Out。受信タイムアウト。
Supervisoryにtimeoutビットがあるのだが、それを指しているのだろう。
Targetにのみ、Response timeout extensionというデータが載っていた。


さて、R/Wから見ると、この仕様はかなりシンプルである。
無線上はあれこれとパケットの種別が違うのだけど、有線コマンドとしてはそんなに種類がないからだ。

LLCPは、この上に載っかることになる。
ISO 14443であっても、同じことだ。
しかし・・・LLCPの上には何を載せたらいいんだろう?
OSI参照モデルでは、ネットワーク層が来る。
TCP/IP参照モデルでは、インターネット層にあたるらしい。IP、の部分。
たぶん最後はAndroidに載せるつもりなのだろうが、どうしたものか。。。

[nfc]DIDとNAD

ISO 18092を眺めている。

DEPでやりとりするとき、DIDとかNADとかいう用語がしばしば出てくる。

  • DID : Device ID
  • NAD : Node Address

InJumpForDEPの戻り値には出てくるのだが、TgInitAsTargetに出てこない。
なんだかわからなくなってきたので、ISO 18092をひもといているところ。


これは、属性要求であるATR_REQに出てくる。
何をするにしても、まずATR_REQ/ATR_RESのやりとりから始まると考えてよかろう。
(FeliCaの場合は、POL_REQ/RESのあとでATR_REQをやりとりする。)

シーケンスからすると、InJumpForDEPでInitiatorが送信して、TgInitAsTargetで受けとっている。
ってことはInJumpForDEPのパラメータにありそうなのだけど、ない。

どうなっているかというと、これはPN533が自動でやってくれているからのようだ。
使うかどうかは事前に設定しておくのだが、それにSetParameters()を使用する。
デフォルトはどちらも未使用なのだが、RC-S620/Sも同じかなあ。


他にも気になっていたパラメータがあるので、書いておこう。

  • BS, BR : 送信・受信のビットレート。847kbps以上が使えるなら、それぞれのビットを立てる
  • LR : PPのbit5-4。有効なデータ長。64byte, 128byte, 192byte, 256byteの4種類から選ぶ。

これらは、アプリ側が対処せんといかんのかな?
いかんのだろう。。

NFC Protocolでは、BSi, BRiは0000で、BSt, BRtは無視しろ、とある。
LRは、サイズが64byte, 128byte, 192byte, 254byteになっている。
なぜ微妙に異なるのだ・・・。

2011年2月26日

[nfc]まだこだわるActive/Passive

もうやめよう、もうやめようと思いつつ、なかなか終わらぬ、この不思議な感情(おもい)...

と、意味もなく短歌調で始めてみた。


さっき、朝方印刷したISO 18092のドキュメントを見てみた。
書いてあることは、今までと同じだ。
しかしここまでずっと同じような文章を見ていると、気になることがあった。

Passiveの場合、相手からの搬送波に自分のデータを載せてくる。
Activeの場合、自分から搬送波を出して電波を出せる。

よく考えると、携帯電話に載せた場合、チップ自身はかなりの電力を使うため、相手の搬送波くらいでは起動できない。
どうしても、自前の電源が必要だ。
もしかすると、単にそれだけのことを指しているのか?
つまり「カードに搭載しているチップはPassiveで通信できるけど、電源が必要となるチップはActiveでしか通信できんよ」、と。

でも、もしかするとさらに上を行っていて、チップを載せている携帯電話のような端末でも、Passiveで動くのかもしれん。
私の予想など、たかが知れているからな、ふっ。。。

[2.3.3-r1]パッチを当ててみたが、なかなかビルドできん

いやあ、久しぶりにAndroidを触っている。
NFCをやっているせいでもあるが、それよりも64bitでやるようになったのが大きい。
VMwareでは動かないのよねぇ。
動かせないことはないかもしれんが、わざわざ環境を作るのが面倒くさい。




それはともかく、なんとか2.3_r1に2.3.3_r1のパッチをあてようと苦労している。
苦労しているが、なかなかうまくいかん。
どうやったかというと、repoでandroid-2.3.3_r1をとってきて、それとandroid-2.3_r1の差分を取り、git diffを使って差分を取り、patch -p1でパッチを当てていったのだ。
手動でやろうとして前回諦めたのだが、今回はperlで何か作ってみた。
こんなのだ。

(あとではりつける)


自分で修正していたファイルにパッチが当たらないのは、まあわかる。
でも、なんか他のもうまくいってない。
これは、スクリプトの作り方が悪いのか、考え方が間違っているのか。。。

[nfc]RC-S620/S用のクラスを作ろう

解説コーナーではありません。。。
自分で「やろう」という気持ちを沸き立たせるためのものです。


今、自分のところでは、SONYさんのArduino向けライブラリを使っている。
ダウンロードするときに「改変する権利がある」と書いてあったので、Android向けに変更して公開してもいいんだろうなー、と思っていたが、それは別の話ということを教えてもらった。
公開しなくてよかった。。。

とはいえ、そこが公開できないということは、全体的に公開できないのと同じだ。
いや、そもそも公開していいんだかどうだか・・・。

そんなこんな思っていたら、最近のInterface誌には、RC-S620/Sの記事が載っていた。
RC-S620/Sへのパケット構成や、初期化コマンド、ポーリングコマンドまで出ている!
パケットの構成と、初期化の仕方が公開できるのであれば、あとはPN533のドキュメントを見ながらやっているので、RC-S620/Sの仕様書入手条件である「仕様書に書いてあることはネットとかに書いたらいかんよ」という制約から逃れることができる。

できる・・・よな?
まあ、当たり障りのないところでやってみよう。
怒られたら、そこは消そう。

基本的に、RC-S620/Sを買ったけどどうしよう、という人向け、くらいのもので。


まず、RC-S620/Sの「/S」は、シリアルのSだ。
だから、通信にはシリアルポートが必要となる。

なので、書き込みと読み込みのAPIを作ろう。
これは公開しなくてもよいだろう。
内部で使う以外のことは、まずない。

Linuxで普通に開くとブロックするから、NONブロック対応しておいた方がよかろう。
このNONブロック対応は、キャンセルできるようにするための意味が強い。
たぶん、たぶんだが、通常でアクセスしてデータ待ちになったとしても、そのコンテキストが止まるだけで、OSとしては問題なかろうと思うのだ。
マルチスレッドが使えるシステムなら、何もしなくていいかも。

でもまあ、世の中そんなにいいシステムばかりでもないから、コールバックできるようにもしておいた方がいいんだろうなぁ。


パケットのことは、いろいろなサイトに書かれているので、いまさらここで書くことはあるまい。
RC-S620/SへのパケットのことはInterface誌に書かれているし、カードへのパケットについてはISOなどに書かれている。

初めての方は、まずはパケットフォーマットに従ってRC-S620/Sへ書き込んでみてほしい。
反応があるか、エラーが返るか、反応がないか。
そのどれかであろう。

配線さえ間違えていなければ、恐れることはないのだ!

2011年2月25日

android2.3.3_r1が出ている

今朝、Android Platformの2.3.3_r1が出ていた。

NFC関係のところだけ落としてみてみたが・・・うーむ。
何をうなっているかというと、RC-S620/Sの対応をどうしようか迷っていたからだ。

できれば、APIもそろっているし、使えるAPIで構成されたアプリであれば動くようになるから対応させたいのだが・・・。
だが、気力がないし、できそうな気がしない。
自分がAndroid携帯電話を買うような気がしないので、ここでがんばってもなー、という気持ちがかなりしている。

なので、ここは自分に無理をしてAPI対応させようとするよりも、自前のAPIで動く物を作ることに邁進しよう。
今のところ、SONYさんから出ているArduino用ライブラリを改造した物を使っているけれども、今月のInterface誌にはRFConfigurationのパラメータ説明があったので、自前で作成できそうだ。

では、今週末は自前ライブラリへの置き換え作業にしよう。
といっても、オリジナルの部分はほとんど残ってないな・・・。

2011年2月24日

[nfc][dep]Active時はRF止める

調べるつもりはなかったが、見てしまった。

InitiatorがActive Modeを投げる場合、投げた後でRFを止めるらしい。
つまりこれが「あんたが(も?)Activeになるんだよ」という意思表示なのだろう。
RFが止まるから、受け取ったTargetもRFを出せるようになるのだ。
止めていないと、RFCAして、何もしないのだ。

まあ、それくらい知っておけばいいのかな。
もう力尽きて、文章が頭に浮かんできません。

2011年2月23日

[nfc][dep]InJumpでなくてもよい?

PN533の無線部シーケンスだけ見ていると、DEPするのにInJumpForDEPを使わずとも、ポーリングで使うInListPassiveTargetでいいんじゃないの、という気がした。

InListだと、対象は必ずPassiveに限定されてしまう。
が、それで困ることはないと思う。
DEPを自然な感じで行うとすれば、データを送る方がイニシエータ、データをもらう方がターゲットになるだろう。
そして「データくれー」と思ってる人は先に待ち受け状態にして・・・ってのはないのか。
イニシエータからの搬送波を検出して、Pushを受けるなり、ターゲットになるなり、カードとして振る舞うなりあるだろう。

まあ、実証が必要だろうが、気が向かないとやらんな。
今はまだ、その前段階だ。
知識が足りないので、どう実装していくか検討せんとね。

[nfc]能動と受動、もう一度

まだ続いている、このネタ。
いい加減終わらせたいのだが、自分が納得するまではやらんと。

前々回はNFC、前回はISO 18092。
そして今回は、PN533のドキュメントで見ていこう。


まず、整理しよう。

「Active」という考え方が出てくるのは、P2Pのときだけのはず。
ターゲットがカードであれば、自分でRFを作ることができないからだ。
「俺のデータを読め」というカードはなく、もしそういうことをやるならDEPになる、と思う。

そうすると、自分でRFを出せる=イニシエータ、になってしまう。
しかしP2Pは、イニシエータとターゲット間のHalf-duplexだ。
イニシエータとイニシエータのP2Pは、ないはず。

ということは、起動時にイニシエータ、ターゲットでそれぞれ起動し、イニシエータがターゲットに「お前がActiveになれよ」と命令するしかないのではなかろうか。
その線でドキュメントを見ていこう。


PN533によると、ホストから見るとActiveもPassiveも使うコマンドは同じとのこと。
RC-S620/Sはわからんが、同じ動きをすると考えておこう。

では、InJumpForDEPのパラメータにあるPassive/Activeは何を意味しているのだ?
このコマンド自体、自分がイニシエータであることを認めている。
イニシエータがDEPとして初めて使うコマンドが、これなのだ。

p.82から説明が載っていた。

ACTIVE MODE

  • Activeと通信速度を設定
  • ATR_REQにNFCID3iとGiを載せて送信。
  • ATR_RESの受信。NFCID3tと属性Tgを覚える。
  • ATR_RESの中身はホストにも渡す

PASSIVE MODE

こっちは、106kbpsと212/424kbpsで違うみたい。

if(106kbps) {

  • ターゲットを1つ選ぶ(SENS_REQ, SDD_REQ, SEL_REQ)
  • 後で使うためにNFCID1tを保存
  • ATR_REQにNFCID3iとGiを載せて送信。

} else if(212kbps || 424kbps || 847kbps) {

  • SDDを処理?
  • POL_REQにPassiveInitiatorDataを載せて送信。
  • ATR_REQにNFCID3iとGiを載せて送信。

}

  • ATR_RES受信に成功した場合、そのターゲットはTPEだ。
    NFCID3tと属性Tgを覚える。

※どっちのmodeにせよ、ターゲットをアクティベートする前にホストでコマンドを中断したら、RFもOFFになる。


「RF出せ」みたいなのは見当たらなかったな。
シーケンスだけ見ると、Activeの方が少なくて済むし、Passiveは普通のカードみたいにポーリングしてから始める、みたいなところしか違いがわからなかった。
このあたりは、18092にも同じようなことが書かれていたように思う(あんまり読んでないけど)。

いろいろとドキュメントを眺めてきたが、ActiveだのPassiveだのは、取り決めの問題だと思った。
「送信側はPassiveにしてね」とか、その程度。
実装する方からすると、Activeに対応するのは面倒だから、Passiveだけがいいなどとなるのかな。
だって、Passiveならカードとも同じなはずだし。

さて、そこがどうあるべきかは、LLCPドキュメントにはなかったと思う。
ということは、Digital ProtocolかActivityか。。。

Activityドキュメントはあんがい重要であることを昨日知ったばかりだ。
読まねば・・・。

2011年2月22日

[nfc]能動と受動、再び

何となく曖昧にしてきたが、DEPをやりはじめると気になって仕方がない。
PN533のシーケンスを見ると、能動でも受動でも、ほとんど一緒なのだ。
いったい、何が違うのだろう?


幸いなことに、ネットでISO 18092のPDFが手に入った。
これにはちと驚いた。
JIS X5211でもいいんだけど、なんか使いづらい。
PDFは英語なんだけど、NFCのドキュメントも英語だし、まあいいや。

Passive Communication Mode

イニシエータが、ターゲットに対してRFを供給する(電源用など)。
ターゲットは、供給されている間は動作する。

Active Communication Mode

イニシエータとターゲットは、それぞれRFを供給する。

そういうことなんだ。
さすがISO! さすが18092!!
これを読んでからNFCでの説明を見ると、確かに同じことが書かれていることがわかった。
でもなんか、18092の方が親しみを持てた。

将来的なものや特許なんかからの距離を置かないといかんから、汎用的な言葉を使ってわかりにくくなったというとこだろうね。


では、親子は?
これも18092がわかりやすい。

まず、みんな最初はターゲット。
ターゲットはRFを出さず、イニシエータからのコマンドを黙って待つ。

必要になれば、上位からの要求でイニシエータになる。
イニシエータになるとき、上位は「ActiveかPassiveか」と、通信速度を決定する。

イニシエータは自分でないRFの存在を確認する。
他のRFがあったら、自分のRFは出さない(でいいのかな?)。
なければ、自分のRFを出す。

ターゲットは、イニシエータからのRFでアクティブにされる。
Active Communication ModeだろうとPassive Communication Modeだろうと、イニシエータによるコマンド転送は選択した通信速度で行われる。
ターゲットからの応答も同様で、イニシエータの通信速度で行われる。

さて・・・ここでよくわからなくなってきた。
Active Communication Modeは、どっちもRFを出す、とある。
しかしここでは、ターゲットはRFを出さないように見える。
Activeなターゲットとか、Passiveなイニシエータって、どんな状態なの?

こんな記述があった。

Active Communication Modeの場合、イニシエータが出したRFは切られる。
Passive Communication Modeの場合、イニシエータが出したRFは切られない。

・・・わかるような、わからなくなってきたような。


なんかまた、手の中でするっと抜けていったような気分だ。

今日はもう遅いので、寝よう。
いつか近いうちに、再挑戦することになろう。