LLCPの資料をまだ読んでいる。
長いことやっているのに、まだわかってないのが哀しい・・・。
しかし、最近ようやくNFC-DEPの実装に着手するなど、まったく止まっているわけではないのだ。
そのNFC-DEP。
上位層にLLCPを載せる前提で実装しようとしている。
というのも、長いデータ長の扱いが面倒だからだ。
R/Wコマンド→エアプロトコル、という段階でパケットが複数に分かれる場合、R/WがMIフラグを管理してくれるようだ。
しかし、R/Wコマンドを複数回呼び出してパケットが複数になる場合、当然ならがMIフラグを上位層が管理しなくてはならない。
めんどくさい。。。。
どこかで複数データ分割は対応しないといけないけど、それはLLCP層でやってしまい、NFC-DEPではそれを省こうと考えているのだ。
それができるのは、LLCPの1パケット(1 PDU)がNFC-DEPのR/Wコマンドに渡すことができるデータ長以下に抑えることができる場合だけだ。
さて、どうだろう。
LLCPでは、1回の送受信で扱うPDUのサイズを「MIU (Max Information Unit)」という値で管理している。
デフォルトは、128byte。
これを拡張することもできる(MIUX)が、しないこともできる。
だから、128byte。
NFC-DEP関連のR/Wコマンドで扱えるデータ長は、252byte。
MIUデフォルト値=128byte < 252byte。
よってNFC-DEPでパケット分割をサポートしなくてもなんとかなる。
Q.E.D.
そういえば、nfc-smart-tagではどうなってたんだっけ?
うまいこと分割してるのかな?
そう思ってソースを見る。
nfc-smart-tagはターゲット専用なので、TgInitTargetのGeneral Bytesを見る。
なぜなら、LLCPはここでPAX PDUのデータを載せることになっているからだ。
firmware/nfc/llcp.c L.32に定義がある。
コメントを読む限り、VERSION、WKS、Timeoutの3種類だけで、MIUXは送っていない。
つまり、1回のPDUは最大128byteということになる。
では、128byte以上のデータをどこかで分割しているのか?
その答は、firmware/target.cにあった。
L.283のspバッファ定義。
これが128byteになっている。
コメントにも「タグデータは80byte以下がいいな~」といってるので、間違いなかろう。
nfc-smart-tagは1回のI PDUで送るようにできている。
うーむ、割り切ってるなあ。
とはいえ、SmartPosterなのでブックマーク代わりのテキストが入ったとしても、URLがそんなに長くなることはないと思う。
URLとしてはよくあるだろうけど、わざわざNFCで送りたいものがそんなに長たらしくなくてもよさそうだ。
組込機器ってのは、こうじゃないとね。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。