2012/06/16

[llcp]MIUのデフォルト値は128byte

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 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。

注: コメントを投稿できるのは、このブログのメンバーだけです。