DEPをやろうと、いろいろRC-S620/SのコマンドをPN533の仕様書やISOやらJISやらを見ながらやってきた。
が、なんだ、この無駄な作業は？と思ってしまった。
普通は部品を買うと、仕様書が入手できるはずだ。
汎用部品ならともかく、RC-S620/Sはけっこうなデバイスだ。
仕様書が別売りといっても、一般人の入手ルートはない。
なら、なぜRC-S620/Sは一般人が入手できるのだ？
というようなことを思いついてしまった。
考えなければよかったんだけどねぇ。
いま持っている資料だけあれば、たぶんLLCPとかまで実装はできると思う。
だからといって、うちにあるP906iのiC通信(だっけ？)ができるわけではない。
これは、FALPの仕様書がないからだ。
そんなこんな考えると、FeliCaのカードが読みたいわけでもなかった私としては、買わなければよかったかも、という気がした。
買ってしまっただけに、使いこなそうとして、あれこれやってしまう。
まあ、NFCの仕様にはかなり詳しくなったような気はするが。。。本来の目的が果たせそうにない。
そういうわけで、土曜日の夜中なのに私は非常にお怒りである。
もう少し権力があれば、数社つぶすくらいのお怒りだ(意味不明)。
私が怒ったからといって何が変わるわけでもないだろうけど、それでもねぇ。
2011年3月6日
2011年3月5日
[nfc][dep]私は考え違いをしていたように思う
私は・・・DEPについて考え違いをしていたのではなかろうか。
まず、PFBの件。
これは前回も書いたが、InDataExchange()の引数にする必要はないと思う。
PN533・・・もそうだが、きっとRC-S620/Sもそうだと思いたい。
ということは、だ。
PN533は、ISO-14443のDEPもサポートしている。
それもInDataExchange()で自動的にやってくれていることになる。
つまり、ISO-DEPとNFC-DEPを使い分けるのは、ホスト側が作るパケットというよりも、コントローラ側が現状を把握して使い分けているということになろう。
私も今、DEP_REQ/RESで通信できていると書いているが、実は既にNFC-DEPかISO-DEPで通信しているのではないか？ということである。
しかし、それがどうなのかを確認するのは難しい。
リファレンス機というか対抗機というか、相手がいないからわからないのだ。
せめて、PN533ではどこを見て使い分けているのかを調べておこう。
ドキュメントp.102に、PN533からターゲットに渡すパケットが書かれている。
ターゲットに応じてパケットの中身が変わってきている。
p.153をみると、ISO-DEPの場合はSEL_REQの戻り値で区別しているように見える。
しかししかし、Type-AはISO-DEPもNFC-DEPもどっちもいける。
だから、相手からの応答だけで判断できないはずだ。
どっちでやるかの意志をどこかで示しているはず。
私にわかるのは、ISO-DEPの場合はInListPassiveTargetから始まり、NFC-DEPの場合はInJumpForPSLから始まっているということ。
InJumpForPSLは、ほとんどInJumpForDEPと同じはず。
PSLだから、通信速度も変更するのかな？
それくらいしか、違いがわからない。
なので、今はいきなりInDataExchangeをしているから、NFC-DEPになっていると思う。。。
その認識でいいのかなぁ。
[nfc][dep]PFBはホストからは不要な気がしてきた
PFBの仕様を読みながら、どう実装しようかと考えていたのだが、不要な気がしてきた。
コントローラがうまいことやってくれるんじゃなかろうか。
だって、MIビットの有無は引数として指定するのよ。
PN533のドキュメントで見ていなかったのだが、SecureなDEPのところで、Secureじゃないのとも比較しながらシーケンスが書かれているのだが、ホストからはPFBを指定してないのに、エアプロトコルになってからはPFBが出てきているのだ。
InDataExchangeのところにもあった。
ホストからPN533へはペイロードだけ渡しているのに、PN533からターゲットになるとDEPヘッダが付加されているのだ。
もうこれは、間違いなかろう。
PN533は、PFBを制御している。
RC-S620/Sはどうなのだ？
これはわからない・・・。
わからないが、私は何もしてないのに通信できているのだから、RC-S620/Sは何もしていないのでうまくいっているか、ちゃんと制御しているからうまくいっているのかのどちらかだ。
そうなると、後者である可能性が高いな。
私は男らしく、ライブラリからPFBの実装を削った。。。
[nfc][dep]中断後にエラー
DEP_REQ/RESレベルでの送受信はできている。
まあ、これはコマンドを投げれば返ってくるので、そんなに難しいことではない。
こんな感じでDEPをやっている。
今のところシングルスレッドでやっていて、ユーザ操作はほとんどできない。
なので、DEPでデータをやりとりしているのを中断させるのに、お互いを引き離す、という方法でやっている。
このときの動きがそれぞれ違う。
InitiatorにしているPaSoRiは、しばらくしてからタイムアウトしている。
まだタイムアウト処理など組み込んでいないので、PaSoRiがしばらくすると返事をしてくれていることになる。
Statusは0x13だ。
TargetにしているRC-S620/Sは、すぐに終了する。
TgSetDataがStatus=0x31で返ってくる。
それはいいのだが、困っているのはその次。
終了させようとしてコマンドを投げるのだが、エラーフレームと認識されてしまう。
リセットコマンドは大丈夫なのだが、その次に投げているRFConfigurationがそうなる。
あー、でも搬送波は出てなさそうだな。P906iが反応してない。
エラーフレームはパケットの文法エラーなので、中身が間違っていることになる。
しかし普段は大丈夫なコマンドなので、少なくともそこの実装に間違いはない。
もしかすると、タイムアウトしてから送ったコマンドが残っているとか・・・とも思ったが、RC-S620/Sはタイムアウト時間を持っていて、それ以上経つと受信したパケットを破棄する。
だから、そんなことはない。
うーむ。。。
待ち受けているコマンドが決まっているのだが、それが来てないのでエラーにしている、という筋書きを考えた。
しかし・・・それはなぁ。
情報がないのだ。。。
InReleaseしてみたが、やはりだめだ。Status=0x31が返ってくる。
Statusの意味がわからんな。。。情報がないのだ。。。
まあ、InReleaseはInitiatorのコマンドだから動かんのが当たり前か。
もう少しFeliCaのことを強く考えながらでないとうまくいかないのだろうか。
[nfc][dep]ISO18092とJIS X5211
前回、ISO 18092を読みながらDEPを解釈していった。
しかし私の英語には不安がある・・・。
そこで、今日はJIS X5211を読んでみることにした。
全部はきついので、関係あるところだけ。
自分の誤訳がいくつも見つかった。
ターゲットの「RTOしか送ることができん」は「代わりにRTO pduを送ることもできる」とか。
Initiatorのタイムアウトに関するところも間違えていた。
ここら辺は、こそっと修正しておこう。
それはいいのだが、用語として困っているものがある。
「data pdu」だ。
X5211は「情報pdu」と訳している(pduは、Protocol Data Unit)。
しかし、情報pduは「Information pdu」という用語が既にある。
これはまずいのではないか？
それに、こんな文もあった。
(前略)情報pduによって、確認応答しなければならない。
ちょっと待て。
確認応答にはACK/NACK pduというものがあるだろう。
英文も「shall be acknowledged by an ACK pdu」となっている。
私が持っているISO 18092が古いか何かなのか？
NFC Forumのドキュメントも合わせて読んでみた。
こちらは、書き方がちょっと違う。
連鎖ビットが立ってないInformation PDUを受信したら、Information PDUかRTOX要求のどちらかだ。
そんな意味になるか。
これはわかりやすい。
わかりやすいのだが、ISO 18092ともJIS X5211とも解釈が違うように思う。
なにがなんだか、わからなくなってきた。。。
[nfc]副作用
いい情報をいただいた。
PaSoRiはFeliCa以外の規格に対応したための副作用がごにょごにょあって、電気的にターゲットになりにくいらしい。
た、確かに・・・。
確かに私は、昨日ターゲットでPaSoRiを動かそうとしていたのだ。
以前「ターゲットになれないようだ」と書いていたけど動いたので、今日は訂正文を書こうかと思ったくらいだ。
まったく動かないわけでもなかったから、不安定ということかな。
とにかく、動作させる環境の不安定要素がわかったのは大きい。
2011年3月4日
[nfc]うまく動かないときは、動かない
よくわからん。
DEP関係のコマンドが、うまく動くときと動かないときがある。
理由がさっぱりわからない。
まあそもそも、コマンドがRC-956でどう動くのかわかっていないのが一番の問題なのだが。
PN533マニュアルでは、さすがに限界がある。
かといって、正式なマニュアルは入手できない。
ここらへんが、個人で(遊びではあるが)開発するのに不便なところだ。
なんとかしてくれー
2011年3月3日
[nfc]RC-S620/Sの終わらせ方
DEPを中断させると、それ以降RC-S620/Sへアクセスできなくなった。
アプリエラーが返ってくる。
もちろん、電源を落とせば大丈夫なのだが、それはめんどくさい。
よくわからないリセットコマンドを使ってみると、なんかよさそうな気がする。
もしかすると、RFを停止させたのがよかったのかもしれんが、確認してない。
Ctrl+Cでだめになるのは、しかたがない。
シリアルはつなぎっぱなしだろうし、電源も供給されたままなので、RC-S620/SはCtrl+Cされたことすら知らないだろう。
ステージが初期化されないといかんだろう。
なので「もう使い終わりましたよー」を通知しないと行かんと思うのだが、そのあたりがよくわからん。
リセットコマンドでよいような気がするけど、アプリエラーが返ってきてるような。。。
あるいはその手前に投げているコマンドがよくないのか。。。
冷静な判断と情報がほしいところである。
あ、冷静な判断は私がやらんといかんところだな。。。
2011年3月2日
[nfc][dep]どう非同期にしたものか
DEP関係のコマンドは、相手が何かしないとレスポンスが返ってこない。
いずれは、タイムアウトやユーザからのキャンセルにも対応せねば。
そう考えると、今のうちに非同期APIにしておいたほうが無難だ。
しかし、私は楽をしたい。
どんなプラットフォームでも使えるライブラリがいいんだろうけど、そんな労力を裂くのは嫌だ。
できるだけ簡単に非同期化したい。
思いつくのは、
- POSIXなどのスレッドで使われることを前提にしてしまう
- コールバックで返してやる
まあ、コールバックにしておくのがいいんだろうけど、じゃあ受信はどうやってさせるんだ？ということになってしまう。
ポーリングするAPIを用意して定期的に呼んでもらうくらいしかないなぁ。
Androidでやるなら、バックグラウンドでサービスを回しっぱなしにして、そこで定期的に呼んでもらうという手がある。
まあ、今がそんな感じだ。
携帯電話向けの実装なら、割り込みにするなどして消費電力を抑えないといかんけど、RC-S620/Sだからそこまで考えなくていいだろう。
搬送波だって、みっともないけど出しっぱなしだ。
(Nexux Sって、確か画面が点いている間は搬送波出しっぱなしだし、FeliCaロックみたいな形の止め方がないような気もするし、電池の減りが早そうだなぁ。)
まあ、それはそれとして。
受信側をポーリングにすると、全体的に非同期にしなくてはやりづらい。
かといって、なんもかんも非同期にすると、アプリがめんどくさくなりそうな。
通常のコマンドくらいなら、同期でも十分間に合うと思うのだよ。
そうなると、同期APIの場合は、ユーザからのコンテキストで待たせておいて、サービスからのコンテキストで受信結果が返るまで待たせる、ということになる。
そんな実装くらいしか思いつかない。
そうしてしまうと・・・cygwinで簡単に実装して動かす、というわけにはいかなくなる。
ちゃんとpthreadかなんかで動かす部分も一緒に作らなくてはならない。
ほら、めんどくさい。。。
2011年3月1日
[nfc]ライブラリをgithubに置いてみた
置いた、と断言せず、置いてみた、と言葉を弱くするのは、いかん癖だな。
永遠のβ版、みたいな雰囲気をかもし出してしまう。
とにかくまあ、githubにこそこそと作っていたNFCのライブラリを置いた。
大半は、PN533から。次いでSONYさんのライブラリとJISから。あとはネットから。
そんな情報を寄せ集めて作っているので、完全には動かない物もありそうだ。
特に、パラメータについてはPN533を信用しきっている。
違ってたら、ごめん・・・。
基本的に、FeliCaカードへアクセスするAPIは少ない。
なぜかというと、私にとって使い道がないからだ。
もう少し充実してきて、FeliCa Liteなんかも買ったりして、遊べるようになったらがんばるかも。
それまでは、NFC-DEPの学習用になっている。
doxygen対応しているつもりなので、あればどうぞ。
使い方は、test/とtestp/を見ていただきたい。
あ、使うためには環境設定が必要。
READMEにも書いているが、NFCPCD_DEVを直接書き換えねばならない。
これがねぇ。。。Makefileでやりたかったのだけど、うまくできなかったのだ。
ダブルクォーテーションが消されてしまうみたいでね。
\"とかすればいいのかもしれんが、まあいいや。
libpafeを使えば、PaSoRiからもいけるつもり。
うちのRC-S370は動いている。
ここに感謝の意を示したい。
ありがとうございます。
でもまあ、FeliCaさんに「消して！」といわれたら、消すつもり。
今回公開したのは、規約が整理されたため。
これもまた、感謝である。
このライブラリを作ることができたのは、そもそもSONYさんのライブラリがあって動作確認ができたからだ。
それがないと、何もできなかっただろう。
必要となるコマンドはだいたいわかったとはいえ、下地となっているのはSONYさんのライブラリだ。
大半は書き換えたつもりではあるが、見る人が見ればわかるのかも。
ソースの解説などは、しません。
そんなに難しいことはしていないし。
あるとすれば「このコマンドは何？」がほとんどだろうから、それは調べていただきたい。
PN533のドキュメントにたいがい載ってるし、JISにも載ってるのは多い。
ああ、一週間分の仕事をした気持ちだが、まだ月曜日が終わったばかりなんだよな。
まあいいや。
２月の作業が終わった、ということで。
３月はNFC-DEPをがんばろう。
登録:
投稿 (Atom)