[dep]ATR_REQから見て行く

LLCP実装に手を染めよう。
手を染める、だと悪いことをするみたいだが、そんなことはないのだ。

持っているのが、PaSoRiとRC-S620/Sしかないので、基本的にRC-S956系のことしか考えずに書いていく。

---

参考資料

• NFCIP-1に相当するもの(ISO/IEC 18092とかJIS-X5211とか)
  私は、ECMA-340のが見やすいと思う。
• RC-S620/Sコマンドリファレンスマニュアル<簡易版> Version 2.0以降

なんでECMA-340にしたかというと、PDFの見出しが付いていて見やすいから。
ISO/IEC 18092やJIS-X5211も同じ章番号なので、気にしないでおくれ。

 

LLCPは、NFC-DEPを使う。
NFC-DEPは、ISO/IEC 18092で規定されているData Exchange Protocolである。
なので、そこから見て行くことになる。

 

RC-S620/Sコマンドリファレンスマニュアルの図8-3を見ると、DEPのトリガとなるのはATR_REQと書かれている。
つまり、InitiatorからATR_REQを送信しなくてはならないことになる。

これはECMA-340でいえば、Figure 24, 25の部分だろう。

Passive communication mode(InitiatorがRFを出し、Targetは出さない)の場合、InitiatorがSDD(Single Device Detection)でターゲットを１つだけ見つけ出し、ATR_REQを送信してATR_RESを受信。

Active communication mode(InitiatorとTargetが交互に入れ替わる)の場合、ATR_RESが取得できるまでATR_REQを送信している。

つまりATR_REQのタイミングでいえば、Passiveの場合はポーリングのようなSDDが挟まるが、Activeの場合はいきなりATR_REQが来ることになる。
それが図8-3で矢印が分かれている理由である。

 

ちなみに、Figure 13でATR_REQ送信かプロプライエタリコマンド処理するかの分岐は、SEL_RESを見て決めている。
NFCID1が完全で、Transport Protocolに対応しているかどうか(TPE)、になる。

---

こうやって細かく書くと非常に難しそうなのだが、実装してみるとそこまで大変なことにはならない。
これは、R/W側のチップが細かいエアプロトコルをうまいこと処理しているからだろうな。