PlugのDATAって、SELによって方向が変わるのだけど、MOSIにしかつなげてない。やってんだ?ソースを見ると、ソフトウェアでSPIやっているみたいだった。私が別のARM基板を使ったときは、MOSIがHi-Zにできるようになっていたので、MOSIもMISOもDATAに接続し、受信したいときはMOSIをHi-Zにしていたのだ。hwSWPは結構速いSIMと通信するとき、9600bpsくらいだったよなあ、でも覚えてないなあ、と思って少し調べることにした。最大1.6Mbpsまでは出せそう、とは・・・。すんません、甘く見すぎてました。そこまで出さないにしても、9600bpsなんてことはないだろう。SEをSIMに置くと遅い、という記事があったのだが、1Mbpsくらい出せるんだったら、SAM(でいいのかな?)に置くのとそんなに違いが出るのかしら。ハード結線だったら通信速度とかなきに等しいだろうし、FeliCaは高速にするためにいろいろとやってる。SWPがいくら速くても、戦略的に高速化をめざして作られているFeliCaにはかなわんのだろう。NFCは、携帯電話に載らないと広まらないだろう。携帯電話に載せるとなると決済機能抜きということはありえんと思う(キャリアやメーカーのメリットがないので)。決済機能がつくなら、セキュアエレメントを何とかせんといかん。今のモバイルFeliCaチップには、FeliCaのSAMしかつながらないようになっているから、ひとまずSWPでのルートを確保し、最後はSIMにFeliCaのメモリを持っていこう、という図になっている。http://wirelesswire.jp/special/201101/01/report/201102170455.htmlってことは、SWPを使っても高速にやる算段は付いてるってことか?あるいは、SWP経由の場合は高速にできないけど、海外端末でもFeliCaがつかえる、という方なのかな。なんとなく後者のような気がする。いう時代になったら、私もスマートフォンとか使うようになってるのかな。壊れるまで買い替えるつもりはないし、壊れたら修理するつもりだから、しばらくはこのままだな。nfcSNEPは、できないわけではなかった昨日は、福岡のNFC勉強会に行ってきた。PUTの動作確認ができた。うん、できないわけではなかった。TEXTを送信したのだが、受信できるものとできないものがあったのだ。TEXTじゃなくて、URIにしておけばわかりやすかったか。自分でもどういう文字列を送信しているか忘れていたし、受信したらAndroidがどう動くかもよく知らないし。URIだったら、きっとブラウザとかが起動するようになってるんじゃないかな。「SNEPはできないわけではなかった」ということで、よしとしよう。Emulationモードもやったし、送信のみではあるがP2Pモードもやったし、一通りはやったことになる。簡単なのは、やはりR/Wモードだった。Initiatorになって要求を出せばいいだけだからだ。Emulationモードはそれほど深入りしていないが、ちゃんとやるなら面倒だ。メモリを持たないカードとして振る舞うなら、それほど難しくはない。Liteのように振る舞う」となると、それなりにコマンドに対して応答するような実装をしてやらんといかんだろう。最後にやったP2Pモードは、DEPだけなら簡単、LLCPは面倒、SNEPはそこそこ、という印象をうけた。今回はSNEPで送信できるサイズが小さなものしかできないようにしているが、それでも全体としては面倒だった。いえば、SNEPはサーバとクライアントがあるが、今回はクライアントのみの実装だった。Emulationモードでいいやん、という気はする。Plugだと簡単にできるし、こっちの方が電力的には消費が少なくてよい。考えていくと、わざわざP2Pモードでやらなくてもいいやん、という気持ちにはなってくる。最近、LLCPS、というセキュアなLLCPってのを考えているところがあるみたいだ。IETFってなんじゃ、とおもったら、wikipediaにあった。ドラフトドキュメントは、こちら。"TLS"というワーキンググループが公開してるらしい。Security"(RFC-2246)の略とのこと。LLCP」とあるから、LLCPはそのままで、その上にTLSを載せようとしているのかな。ドラフトなので読まないが、どのドキュメントのLLCPSシーケンスはわかりやすい。>LLCPのドキュメント。14443のドキュメントを読み始めた。X6322なので、少しは違うところがあるかもしれん。最初に「特許には自分で注意してね」と書いてあって心配したが、私はカードを読みたいだけだから大丈夫だろう。読むつもりはなく、またTypeBのところだけ読めばよい。思ったが、TypeAのところも興味深かった。UID(NFCID1)のシングル(4byte)の説明。MIFAREのカード仕様書なんか読んでいると、UIDの取得に何回か分けて読み込んでいる。これが「カスケード」というやつ。カスケードになっている目的は、PICCの衝突を起こしやすくするためらしい(よくわからない...)。シングルUIDの先頭バイトには、意味があるらしい。0x08の場合は、残り3byteは動的に発生された乱数、という意味らしい。そこでようやく、RC-S620/Sの動きに納得がいった。ターゲットになるときUIDの後ろ3byteを指定できるようになっているのだが、「先頭は自動的に0x08になります」という動作になっているのだ。当時は何気なく見過ごしていたけれども、そういう意味があったんだねぇ。(手書きのコメントには「TPEの場合は0x08」と書いていた。)というところで満足したので、今日はここまで。SDをなんとかせんとなぁ私がNFCを家でやる前くらいにつくったAndroidアプリがある。当時は円高だったので(今もだけど)、登録料も安いと思って作ったのだ。インストールされてもだいたい消されてしまうアプリの中では、がんばっている。これ以外には残ってるのが少ないってだけだがね・・・。このアプリは、Widgetになってて、SDカードのマウントとアンマウントをするだけのやつ。AcerのA500を買ったときに、抜き取りができなかったんだかメニューが深いんだったか忘れたが、なんか作ったのだ。今でも千人くらいはインストールしてもらっていてありがたい。4.0には対応していないのだ。調べてないけど、アンマウントするAPIの引数が増えたみたいだ。この辺の事情は、たまにブログに書いていたような気がする。放置している理由は、うちに4.0の環境がないから。エミュレータでやるってのもあるだろうけど、めんどくさい。それにこのアプリの特徴は、標準以外のSDドライブをアンマウントすることを目的にしているところだと思っている。APIから取得したパスはexternalではあるんだけど、removableじゃない方を指していることが多いではないか。環境変数を見て候補を選ばせ、どうしようもない場合にはパスを入力できるようにしている、というところだ。さっき見たら、まだアプリをインストールしている人がいるので、なんとか4.0にも生き残らせたいのだが、回避方法がよくわからん。わからんし、試すことができんので、あんまりやりたくない。こまったものだ(私が)。androidNFCのType整理をしつつ、NFC-Bに思いをはせる長いことNFCの資料を見ていないので、忘れてきてしまった。