適当に応答を返してみるFNの情報を待つ忘れる2と3は近いのだが、進む意志を見せる2に対し、3は忘却の彼方だ。1もいいんだけど、LLCPのときにめんどくさくなったことを思い出した。わかっているコマンドですら面倒なのに、知らないコマンドなどどうやればいいというのだ。総当たりしてまで調べたいものでもないし。別のことをしてみるか。Androidで動くようにする、というのは面白いかもしれん。BeagleBoard+RC-S620/Sで動かしても、あまり楽しくない。SmartQ5で動かすのはいいかもしれないけど、使い道無いしなぁ。長い文字列を受信してみる画像を受信してみる似たようなものなんだけど、どちらもやってみたほうがいいだろう。FALP受信の資料は出てくるのかなぁ。nfc2011/03/14[falp]サンプルソースFALPのサンプルを作っている。下の方に「initAsFalp()」という関数がある。ここら辺で、今まで書いてきたことを実際にやっている。書いてないこともたくさんある。あまりにもわからんからだ。そのうちFNさんから資料が出るらしいので、期待しておこう。コメントは日本語だけど、日本語EUCで書いているのでgithubでは化けてるようだ。UTF-8でコンパイル通るかわからんのやもん。サンプルは、RC-S620/S+cygwinで確認している。PaSoRiでもいけた。確認した相手は、ドコモのP906iのみである。他でうまくいくかは、わからんです。中身がわかればいいんだけど、今はマジックナンバーばかり。ここら辺も、FNさんの資料に期待しよう。見たところ、FALPは以下の順で行っていると推測している。推測に沿って見ていく。FeliCaコマンド0xaaがFALP開始で、終了が0xaeだ。わからないが、FALPコマンド0x07(BYE)をつけることで終わるみたいである。この0xaeコマンドは、レスポンスがない。レスポンスがないことがFALPの終わりなのかもしれない。最後に、こちらからACKを送信している。ACKのみの送信は、キャンセル動作に当たるんだったと思う。あとは、RFConfigurationで無線を停止させるだけだ。disconnect見たところ、FALPは以下の順で行っていると推測している。推測に沿って見ていく。disconnectDISCONNECTは一番簡単。0x81を投げると、0xa0が返ってきて、おしまい。put見たところ、FALPは以下の順で行っていると推測している。推測に沿って見ていく。PUTは、そんなに語ることがない。CONNECTも本来はそんなに語ることはなかったはずなのだが、FALPの転送についての推測を長々と書いてしまった。PUTで送っているのは、vNOTE形式のテキストデータ。CATEGORIES:END:VNOTE赤文字が、文字列として送ったもの。connect見たところ、FALPは以下の順で行っていると推測している。推測に沿って見ていく。connectこっから先は、実はFALPとはあまり関係がない。FALP転送コマンドでOBEXパケットをやりとりするところだ。FeliCaコマンド0xbcで送る。このコマンドはいつものと少し違う。普段、コマンドを投げるとレスポンスとして+1した値が返ってくる。この0xbcは、レスポンスがない。あるのかもしれないが、少なくとも返ってきているのは確認できなかった。するかというと、相手も0xbcで返してくる。足を止めてのインファイトだ(意味不明)。CONNECT(0x80)PUT(0x82)DISCONNECT(0x81)だけである。後ろに書いた値は、コマンド値だ。CONNECTがFALPとして渡す最初のデータだからか、シーケンス番号が0x0000だった。0xbcはレスポンスがないと書いたが、R/Wのコマンドに対するレスポンスはある。これが・・・いつもの戻り値と違うのだ。R/Wに直接データを渡す系統のコマンドは、だいたい「結果」が1byteある。0x00なら成功で、それ以外はエラーというのが一般的だ。ここでは、普通に0x01が返ってくる場合が多い。うまくいっていないわけではない。いう応答みたいなのだ。0x00の場合もある。そのときは、0xbcに続けてデータがやってくる。0x01で返るときは、相手から送るデータがない場合0x00で返るときは、相手からのデータがある場合ではこちらはどう動いているかというと、これがまたよくわからない。あれをデータ長無しで送っているのだ。これが相手に渡ると、さっきの0x01になるのだろうか?そして困るのが、パラメータが毎回異なること。同じ値であれば、わからないなりに同じ値を使うのだが・・・。そこで私が得た結論は、こうだ。例のコマンドの第1、第2パラメータは、やはりタイムアウトで正しいタイムアウト値はランダムそうでないと、説明が付かない。RFConfigurationでタイムアウト値を設定するところがあるのだが、この範囲内でやっているのかもしれないし、FALPのHELLOでパラメータがたくさんあったから、その範囲でやっているのかもしれない。そこのところは、よくわからん。わからんが、ランダム値だろう。今回の実装では、めんどくさいので固定値にした。CONNECTは、0x00が正しい。OBEXは複数回パケットをやりとりすることを想定していて、最後に送るコマンド値は最上位ビットを立てるようになっている。CONNECTを受け付けると、相手から0xa0が返ってくる。これも、0x20の最上位ビットがついたものかもしれん。CONNECTを行うと、相手のバッファサイズなどがわかるので、小さい方に合わせてやりとりをするのかな。いや、FALPはFALPコマンドの中で同じようなことを最初にやっているはずだ。ここのところは、FALPの仕様書レベルものがないとわからんだろう。準備2(OBEX準備?)見たところ、FALPは以下の順で行っていると推測している。推測に沿って見ていく。準備2(OBEX準備?)OBEX準備と書いたが、FALPはここから始まると見てよいのではなかろうか。ここから先はFeliCaコマンドだけなので、例のコマンドで送信する。例のコマンドにはタイムアウト値がパラメータとしてあると思うのだが、この辺りからそうではなくなってきているような気がする。FeliCaコマンドは0xbc。データがあって、おそらくFALPコマンドとシーケンス番号が続く。それがここ数日間、値を眺めていた結論だ。FALP終了(BYE)だと考えている。あ、アルファベットのやつはライブラリソースに書いている名称だ。正式なものでもなんでもない。最初はHELLOを投げると、相手からHEYが返ってくる。したらFALP転送のやりとりが続くことになる。HELLOの中身は、さっぱりわからない。「DCMI20」という文字があったが、文字列らしきものはそれくらいだ。これはOBEXかなんかの準備なんじゃないかな、と思った次第だ。DCM、はたぶんDoCoMoだな。準備1見たところ、FALPは以下の順で行っていると推測している。推測に沿って見ていく。準備1はい、もう具体的な説明ができないところになりました。ここでは0xaaというFeliCaコマンドを使っている。サブコマンドではなく、FeliCaのコマンド。R/Wへは例のコマンドを使って送る(コマンド名はRC-S620/Sのドキュメントに書いてあるので、私は書けない)。パラメータは、IDmと、2byteのUIDらしきもの、それと4byteの何かわからない値。この「UID」としたものは、セッションIDみたいなものみたい。このUIDをFALP中はずっと使うことになる。4byteのわからない値は、何回やっても同じ値なので、わからないまま使っている。見たところ、FALPは以下の順で行っていると推測している。推測に沿って見ていく。R/Wの準備いつもの初期化に加え、RFConfigurationが2つ行われていた。0x0bは、PN533ではアナログ関係の設定らしい。それに、これが役立っているのかどうかもわからないし、調べてない。まねしてやったというレベル。いつものようにポーリングも行う。424kbpsであることの確認をしている。私の携帯電話は424kbpsで対応しているからいいだろう。Faver1.5とかだと212kbpsなんじゃないかな。1.5にはFALPないけど。やっているのはそのくらいだ。nfc[falp]推測過多FALPを使って携帯電話に転送できると思われるアプリがあった。これができるのはFALPしかない、と。このアプリの動向を調べれば、FALPもわかるはず。その推測で、パケットを取得し、解析した。取得方法はそんなに種類がないので、省略しよう。