もうすぐ実家に帰るので、最後に書き残しておこう。
RC-S620/SとPaSoRiでNFC-DEPしていたので、そのコードを。
・・・と思ったが、あまり本体は変わっていないように思う。
Resetコマンドの使い方を間違えていたので、そこを修正したというところだ。
以前、終わらせ方がわからん、という記事を書いたが、Resetできてなかったのだろう。
githubではなく、assemblaを使ってます。
assemblaはprivateが使えるので、書きかけのコードでも気にせず置けるところがありがたい。
まあ、誰もアクセスしてないだろうから気にしすぎなんだけどね。
DEP後、RC-S620/SやRC-S370をあれこれやっても、DEPを再開できなかった。
Resetコマンドを出しても戻らないので、なんか別のことがあるんだろう、くらいに考えていた。
PN533にはResetコマンドはなく、同じ数字が別のコマンドとして存在する。
ResetコマンドはRC-S956専用コマンドなのだ。
そして忘れていたが、RC-S620/Sの簡易コマンド仕様書にはResetコマンドのことが記載されている。
どうせ他のコマンドとあんまり変わらんだろうと考えていたのだが、そんなことはなかった。
いやいや、仕様書は確認しないと、と常々いっているのに、またこれだ。
確認不足でしたわ。
Ubuntu11.10でしか試していないが、libnfc-1.5-new-apiはまだビルドが通らない。
nfc-internal.hの扱いをどうするつもりなのかがよくわからんので、とりあえず解決させてみる、という気にならなかった。
まあ、急ぐ必要はないんだけどね。
RC-S956用のドライバをPN53xとは別に作った方がいいんだろうけど、追加するにはconfigureとかから変更していかないといかんだろうから、めんどくさい。
やっていないので「やれない」とはいわないのがずるいところだ。
当面は、1.5.1に対して追加していきましょうかね。
A500で、AndroidのUSBアクセサリモードが動かない、という話があったように思う。
うちではAccessoryChatできていたようなので、なぜかわからなかったのだ。
よくよく考えてみると、AccessoryChatを動かすために、PC側のソフトを変更させたような気がする。
何かというと、Vendor IDをチェックするときにAcerの番号もOKにするようにしたのだ。
AccessoryModeの接続確認は、まず最初にUSBのVendor IDとProduct IDをチェックする。
VID==0x1801 && (PID==0x2d00 || PID==0x2d01)であればAccessory Modeになったと判断する。
しかし、VIDの0x1801ってGoogleなのだ。
メーカーとしては、PIDくらいは変更してもいいけれども、VIDを他社の番号にするのが難しいんじゃなかろうか。
なので、ADKのボードみたいなのを持ってるけど動かない場合は、ADK側のファームを変更するといいんじゃなかろうかね。
もってないので適当なことをいえば、
http://developer.android.com/guide/topics/usb/adk.html#getting-started
のThe ADK packageで取得したファイルのAndroidAccessory.hにあるisAccessoryDevice()のidVendorチェック条件を増やせばいいんじゃないかね。
bool isAccessoryDevice(USB_DEVICE_DESCRIPTOR *desc){return (desc->idVendor == 0x18d1 || desc->idVendor == 0x0502) &&(desc->idProduct == 0x2D00 || desc->idProduct == 0x2D01);}
ソース未公開ライブラリがあるんならどうしようもないんだけどね。
AndroidAccessory.cppを眺めた感じでは、アクセサリモードになるためのシーケンスでも使われているようなので、何とかなるんじゃないかね。
USBのベンダIDは、こんなところに一覧がある。
http://www.linux-usb.org/usb.ids
ここから、自分のIDを探して追加するといいかも。
A500のときは、0x0502を追加したようだ。
XOOMだと、0x22B8なのかな？ この数値は、accessorychat.cに載ってた値なので、よくわからん。
タイトル通りだ。
エラーになって終わるのだが、その理由はwarningをerror扱いにするオプションが指定されているからだ。
しかしそこを解除しても、4.0.1のときは他の原因でエラーがいくつも発生した。
修正箇所は、他の人がブログに書いているので調べてみるとよかろう。
masterでビルドできるんならいいや、と思ったが、さっきsyncしてmakeすると、mesa3dでコンパイルエラーが出た。
まあ、まだ使ってないからいいや。
nfcpyの情報を元に実装してみた。
うん、GetGeneralStatusの特定バイトを読むと、DEPと思われる値が取得できた。
InJumpForDEPを投げていないときには別の値だったし、FALPでも別の値だった。
ということで、InJumpForDEPを受けとれば、TgInitAsTargetでもDEPになると考えて良かろう。
DEP_REQがトリガになるのかな？
大きな問題は解決したが、細かいのは残る。
弱っているのは、InJumpForDEPした側のR/Wを終わらせた後、再度初期化処理を行うとエラーになるのだ。
初期化時にいくつかコマンドを投げているのだが、nfcpyに載っていた初期化にさしかかるとエラーになる。
うーん、何しているコマンドなんだか・・・。
電源ON後に１回しかできないコマンド、とかならいいんだけど、戻り値だけではわからん。
なんか間違えてるかなぁ。。
またまたNFC-F Developers' Blogからだが、こんな記事があった。
http://blog.felicalauncher.com/en/?cat=5
Dynamic Tag(FeliCa Plug)の説明もあるが、真ん中に「nfcpy open source project」という項目がある。
以前書いたが、nfcpyのサイトには「RC-S330でLLCPできた」とあった。
リンク先にあるPDFを見ると、p20に構成図がある。
libusbを使い、デバイスドライバはpn53xとかipsimとかになってて、RC-S956は出てきていない。
p.33を見ると「not restricted」とある。
「We can provide」とあるけど、Weって誰なんだろう。
資料元がSONYさんなので、SONYの人？
ってことは、nfcpyはSONYさんが技術提供しているのか？と思ったけど、そういう記述は見つけてない。
うーむ。
このPDFを作っている一人のStephen Tiedemann氏は、nfcpyプロジェクトをlaunchpad.netに登録した人みたいだ。
launchpad.netは「software collaboration platform」というところのようだ。
なんというか、sourceforgeみたいなものかしら。
SONYさんとは直接関係はないけれども、中の人がやってるオープンソースプロジェクトだ、というところでよいのかな。
ならば、ということでTgInitAsTargetをどう処理しているのか見てみた。
libusbを使っているので、データの扱いは素のRC-S956のはずだ。
どうやら、Modeを見ていない。
GetGenralStatusして、その戻り値の一部でDEPかどうかを判断し、PN53x系と同じ処理になるようにModeのDEPフラグをONにしているようだ。
ほほー。
この情報は大きい。
nfcpyのRC-S956ドライバはPN53xドライバを継承して作っているようなので、RC-S956でオーバーライドしている機能がPN53xとの差分と考えて良かろう。
ならば前回気になったDiagnoseを見ておこう。
・・・同じようなコマンドが使えそうだ。
そして最初に考えていたのと同じく、戻り値にテストコマンド番号がひっつかないタイプみたいだ。
PN53xでは、先頭を外して戻り値を返しているようだから、間違ってなかろう。
まあ、深く考えないことだ。
こういう、ソースファイルを使わせてもらうわけではないが、中身を読んで参考にする場合はどういう扱いになるのだろう？
「ありがとう」っていう紹介をしておけばいいのかね。
Phythonのソースは初めて読んでみたが、案外わかりやすい。
スクリプト系は苦手なので拒絶しがちなのだが、食わず嫌いはいかんな。
http://blog.felicalauncher.com/en/?p=482
FeliCa Developers' Blogの英訳だけと思っていたけど、よく見ていくとそういうわけでもない。
この記事は、日本版にはないし。
ADKなんて、けっこう日本でもメジャーな方だと思うけど、何かあるのかしら？
Arduinoとか持ってないから気にしたことがなかったのだけど・・・。
うちにも、USBホストになることができるものはいくつもあるので、あとはプロトコルさえ実装してしまえばA500なんかをADK(アクセサリ側)として動かせるんじゃないかな、と思う。
そういえば、A500でADKできないって記事を読んだことがあるのだが、なんだろう？
AccessoryChatは動いたような記憶があるのだが・・・。
遠い記憶なので、あんまりあてにならんな。
DEPがうまくいかんので、まずは素の状態でInJumpForDEPとTgInitAsTargetを実行させて確認しようと考えた。
libnfcを読んでいって、どこに何があるかを調べていくよりも、RC-S956コマンドを実行させて確認した方がシンプルでわかりやすい。
そんなわけで、久々に自作ライブラリを動かした。
Android版はFeliCa Liteの片側認証などの発行を重視した作りになっているが、Linux版はR/Wコマンドを重視している。
DEP関係のI/Fも実装して動いた記憶はあるのだが、当時は「DEPコマンドでやりとりできる」ということしか考慮していなかったので、DEPモードになっていたような覚えはない。
そのI/Fをいじくって、DEP確認をしよう。
と思ったが、ライブラリの使い方を忘れたので、libnfcに出ているコマンドをいくつか実装しようと思った。
まずは、R/W自動認識で使っているように見えるDiagnoseコマンドだ。
このコマンドは、PN533によるといくつかのサブコマンドが使えて、それによってテストができるようなのだ。
自動認識では、エコーバックする0x00コマンドが使われているようだった。
libnfcでRC-S370を動かしたとき、この戻り値がPN533と違っていたのだ。
PN533では、戻り値はサブコマンドとエコーバックなのだが、RC-S370はエコーバックのみだったのだ。
気になるので、試しておきたい。
しかし・・・実装して送信しても、ACKは返ってくるがアプリケーションエラーが返ってくる。
シンタックスエラーらしいが、コマンド仕様がないので何が悪いかわからん。
いろいろ試したが、戻ってこない。
では、libnfcで返ってきているのは何なのだ・・・。
と、libnfc時代のログを見てみると、いつもの「0x00 0xff・・・」みたいな出力ではなく、なんか「0x55 0x55・・・」のような出力になっている。
なんだこのデータは？
ソースを見ると、PN533のUARTで相手を起こすときのプリアンブルらしい。
当然、RC-S956はそんなの知らないから無応答。
追ってないけど、そこでエラーにはならずに、送信バッファの文字列がうまいこと見えるんだか重なるんだかして、エコーバックしたように見えたのではなかろうか。
ともかく、RC-S956のDiagnoseコマンドはPN533とはフォーマットが異なりそうだ、というくらいにしておこう。
「felica dep」などで検索しても、ほしい情報が出てこない。
そんな中、PN532のユーザーズマニュアルが出てきた。
RC-S956も、こんな感じで出てきたらいいのに・・・。
しかし考えてみれば、ここ最近のFeliCaに関する情報公開は、どんどん広がっている。
実にすばらしいことだ。
最近では、個人利用限定とは言えPaSoRiを操作できるライブラリを公開したり、Android向けの開発環境を無料で提供したりと、かなりの勢いで公開されていっている。
公開されることにより、使う人が増え、情報が増える。
いい流れができてきたので、どんどん進んでほしい。
で、PN532とPN533だが、パラメータがちょこちょこ違う。
全部見たわけではないが、PN533の方が設定が減ったように見える。
RC-S330とRC-S370は、果たして同じなのだろうか？
同じRC-S956とはいえ、さらに細かいリビジョンがあったりしたらどうしよう。
とかいろいろ考えようとしたが、風邪っぽいのでやめた。
鳥頭っぽくていかんが、またわからなくなってきた。
Poll Modeは、ポーリングする方ではなく、ポーリングしてもらう方なので、無線を出す。
Listen Modeは、聞いてもらう方ではなく、聞きに行く方なので、受信する。
というのが、前回までだ。
InJumpForDEPのパラメータに、ActPassがある。
Active ModeかPassive Modeかの選択だ。
あまり気にしていなかったのだが、PN533ドキュメントを読むとプロセスが異なると書いてある。
libnfcのDEPサンプル(initiator側)では、212KbpsのPassive ModeとしてInJumpForDEPを使っている。
まず、POL_REQを送信する。
そのデータは、PassiveInitiatorDataだ。今回はワイルドカードの「00 ff ff 00 00」。
それに対するPOL_RESを受けとったら、NFCID2t(ターゲットのIDm)として覚えておく。
次に、ATR_REQを送信する。
データとして、NFCID3iとGiを付ける。
DIDを使うかどうかは、内部パラメータfDIDUsedで決定される(SetParameters)。
マルチターゲットではないのなら、DIDは0(DEPルール)。
NFCID3iは、さっき取得したNFCID2tに2byte(0x00 0x00)埋めた値を使う。
それに対するATR_RESを受けとったら、ターゲットはTPE(Transport Protocol Equipped)だ。
受け付ける準備ができた、ということだろう。
PN533はNFCID3tを記憶し、Tgを決める。Tgは1。
これがPassive時の動きだそうな。
どこら辺がPassiveなのかわからんので、Active時の動きも見ておこう。
まず、ATR_REQをNFCID3iとGi付きで送信する。
さっきはPOL_RESの値を使ったが、今回はそれがないので自前のNFCID3iを用意する。
DIDの件は同じ。
それに対するATR_RESを受けとったら、ターゲットからのデータを待つ。
これが、Active時の動きだそうな。
違いは、ATR_RES後の動きだろう。
Passiveの場合は、ターゲットが受け付ける準備ができたということで、InJumpForDEPした方が送信する。
Activeの場合は、ターゲットからの送信を待つ。
私のイメージでは、Passiveが相手からの送信を待ち、Activeが自分から送信する、だったのだが、違うようだ。
今回のサンプルはPassiveなので、initiatorが「Hello, World」を送信する。
それを受けとったら、targetが「Hello, Mars」を送信する。
そういう動作になっている。
んで、TgInitAsTargetのModeでDEPとならない件は、これとは絡まなさそうだ。
NFC Forumのドキュメントを読んでいて出てきたのは、ATR_REQのRCバイトはDEPの場合0x00か0x02ということ。
0x00は、いつものポーリング。
0x01は、システムコード付き。
0x02は、通信速度付き、じゃなかったっけ？
まあ、もともと0x00になっていたから、今回は関係ない。
あと、NFCID2の先頭は「0x01 0xFE」であること。
これも決められていたが、サンプルはそうなっている。
PN533のTgInitAsTargetの説明にはDEPのことも書いてあるが、ATR_REQを受けとったらDEPモードって書いてあるんだよなぁ・・・。
うーん、変にSetParametersをされることによって、RC-S956では動作しなくなってたりするのかしら。
https://launchpad.net/nfcpy/+announcements
NFC用のPythonモジュールのページ。
ここを見ると、2010/09/21にRC-S330でLLCPできた、とある。
http://www.sony.co.jp/Products/felica/business/products/ICS-D101_106.html
http://www.sony.co.jp/Products/felica/business/products/ICS-D101_102_103.html
SONYのSDK for FeliCa(RI)のページ。
真ん中くらいに「RC-S956はRC-S330やRC-S370で使われてます」とある。
(2011/12/17：リンク先修正。ICS-D106が削除？)
ということは、RC-S370でもDEPはできる、ということになる。
なるんだが・・・・どうやったものだか。
libnfcでpollingができたのでlibnfc-llcpでLLCPしようとしていたのだが、それは早まりすぎだ。
まずはlibnfcでDEPだけがちゃんとできることを確認せねば。
[ターゲット側]
$ nfc-dep-target
Connected to NFC device: PN532 (/dev/ttyUSB0) - PN533 v1.48 (0x07)
NFC device will now act as: D.E.P. (undefined baud rate) target:
NFCID3: 12 34 56 78 9a bc de ff 00 00
BS: 00
BR: 00
TO: 00
PP: 01
General Bytes: 12 34 56 78
Waiting for initiator request...
[イニシエータ側]
$ nfc-dep-initiator
Connected to NFC device: Sony / RC-S370/P - PN533 v1.48 (0x07)
D.E.P. (212 kbps) target:
NFCID3: 12 34 56 78 9a bc de ff 00 00
BS: 00
BR: 00
TO: 0e
PP: 32
General Bytes: 12 34 56 78
Sending: Hello World!
・・・反応なし。
P906iを近づけるとLEDが光るので、搬送波はちゃんと出ているようだ。
どのレベルでかはわからないが、DEPできていないようだ。
ログをとりながら調べていこうとしたのだが、PCDの自動検索が邪魔をして、２台接続での確認が難しい。
まずは指定したデバイスを使用するようなlibnfcに仕立てる方が先だ。
nfc_connect()の引数がNULLだと検索し、そうでない場合は引数のデータを使って接続するようだ。
引数の型はnfc_device_desc_t。
めんどくさいので、自動検索した結果を利用することにしよう。
acDevice : PN532 (/dev/ttyUSB0)
pcDriver : PN532_UART
acPort : /dev/ttyUSB0
uiSpeed : 115200
uiBusIndex : 32767
acDevice : Sony / RC-S370/P
pcDriver : PN53x USB
acPort :
uiSpeed : 0
uiBusIndex : 3
UARTの方はいいのだが、USBはuiBusIndexが挿すところによって変わってくるな・・・。
USBだけは探すようにした方がよさそうだ。
ログを見ていくと、targetはTgInitAsTargetを、initiatorはInJumpForDEPをしている。
initiatorはtargetを212KbpsのDEPだ、と認識しているようだ。これは意図通り。
targetはinitiatorを212KbpsのFeliCaだ、と認識しているようだ。これは意図通りではない。
TgInitAsTargetのModeが、どのデータを参照しているのかがわかっていない。
212Kbps、というのは実際に無線通信した結果なのだろう。
では、DEPビットとかFeliCa/MIFAREビットはどうやってみているのか。
FeliCa/MIFAREは、SYNCコードなんかでわかりそうだ。
しかし、NFC-DEPはNFC-AかNFC-Fのフレームとしてやってくる。
だから無線だけではDEPかどうかわからんと思うのだ。
プロトコル解析が必要になってくると思う。
ATR_REQをパラメータとして受け取っているのだが、それだけではだめということか。
InJumpForDEPがどうやってDEPかどうか見分けているかというと・・・戻り値が来たかどうか。
DEPのためのコマンドだから、それがエラーにならず応答したらDEPだ、という考え方のようだ。
どうしてもちらつくのが「RC-S956ではパラメータのフォーマットが違うのでは」という思いだ。
試しに、TgInitAsTargetの戻りがATR_REQだった場合は、無理矢理DEPとみなすようにした。
そしたら、一応終了した。そらそうだな。
うーん、これからどう進めたものか・・・。
NFCのON/OFFをするAppWidgetが作れないだろうか？と思ったので、試している。
EjectSDも動いたんだから、なんとかならんかなぁ。
適当に作ってadb installすると「」というエラーになった。
何かと思ったが、最近ではapkとodexの２つファイルができるらしい。
うーむ。
いろいろ調べたところ、Android.mkに
LOCAL_DEX_PREOPT := false
という行を追加すると、apkだけになるみたいだ。
実際に、なりました。
mmでビルドするときだけかもしれんけど、覚えておいて損はあるまい。
肝心のON/OFFするやつだが、調べると難しいみたいだ。
パーミッションが普通のアプリからは取れないみたい。
NFC以外も巻き込んでいいなら、AirplaneモードにすればOFFになるようだが、それだとなぁ。
Androidの「NFC OFF」がハードレベルなのかソフトレベルなのかは気になるところ。
PN544の仕様は知らないのだけど、だいたい
くらいの状態があると思う。
下に行くに従って、消費電力が大きくなる。
NFC OFFにしたときが「電源OFF」なのか「アイドル状態」なのか。
使わんのやけん電源OFFしたらいいやん、と思うかもしれんが、そうするとも限らん。
libnfc-nxpでもそこまでは書いてないようなので、kernel側にあるのだろうか。
まあ、端末を持ってないから追求しないけどね。
SDK for NFC Starter Kit(長いので、SNSKと略す)でFALP受信をやろうとしている。
送信元は、DoCoMoのP906i。そう、フィーチャーフォンだ。
持ってないから、仕方ない。
そして、うまくいってない。
FALPライブラリのログを見ていたのだが、ようやくログの見方がわかってきた。
TgGetInitiatorCommandに対してStatusエラーを返しているようなのだ。
しかし、PN533のドキュメントを見ても該当する番号がない・・・。
FALP独自のエラーなのか？
FALPライブラリの使い方が間違えている可能性も考慮しよう。
受信開始はWindowメッセージで取得することになっている。
Windowハンドラは、この順でメッセージを受け取っている。
うん、ウィンドウの生成はできているようだ。
RegisterWindowMessage()も失敗してないし、set_falp_target_callback_parameters()もOK。
falp_listen()もOK。
こっから先は、Windowメッセージが来ない。
ログの内容からしても、まだ認証に至っていないので、フィーチャーフォンとのFALPはやはり想定されていない、と考えた方がいいのかもしれない。
あるいは、P906iのFALP実装がSONYさんの想定にないものになっているか・・・というのも考えたが、CTSに通っているからそれはないだろう。
あきらめた。
今までβ版としてリリースされてきたSDK for NFC Starter Kit。
とうとう正式リリースされた模様です。
http://www.sony.co.jp/Products/felica/business/products/ICS-D004_002_003.html
おめでとうございます。
β2版とざっと比較したところ、AIR関係とドキュメント、ドライバが変更になってた。
細かいところまでは見てないけど、AIR以外のサンプルソースは同じだった。
正式版になったので、FeliCaのブログにサンプルソースなんかが出てくると思う。
楽しみですわ。
libnfc-llcpだが、うまくいってないことはわかった。
しかし、何がだめなのかがよくわからなくなった。
今のところ、PaSoRiとRC-S620/Sを重ねてやっていたのだが、ふと両者を離してからそれぞれllcp-test-serverとllcp-test-clientを立ち上げると、後者を立ち上げたときに前者がエラーになって終わってしまっていた。
これはどうも、libnfcが空いているNFCデバイスを検索しているために起きているみたいだ。
しかし、さっきまでは特に問題なかったような・・・。
cleanなどしてたら、直った。
ような気がしていたが、そうでもないみたいで、タイミングか何かで発生する。
PC１台でやるのは、難しいんかね。
両方のPCDをばらばらに起動できたことを確認してから、重ねるように手順を変更した。
動作結果は同じで、InJumpForDEPでタイムアウトが返ってくる。
前回、ATR_RESを自動返信にしていると書いたが、あれはPN533のドキュメントを参考にした値だ。
RC-S956がどうなのかは、SetParametersの資料がないため、わからん。
うー、SetParametersとかWriteRegister/ReadRegisterの仕様が出てこないかなぁ。
libnfcでは、これらを普通に使っているのだが、PN533と同じ値でいいのかどうかすら判断ができんのだ。
NADだ。
以前も、NADとDIDについて考えたことがあったのだが、そこまで深くはなかった。
LLCPをやるにあたって、またその問題を考えねばならぬようだ。
llcp-test-serverでTgInitAsTargetして、llcp-test-clientからinitiatorモードでInJumpForDEPすると、serverは「DEPじゃなくてFeliCaから要求がきた」と判断している。
DEPで接続したいので、このInJumpForDEPを無視して、またTgInitAsTargetしている。
これが、いつまでたってもserverがnfc_target_init()から抜けない理由である。
DEPかどうかをどうやって見ているかというと、ATR_REQのパラメータだ。
InJumpForDEPを投げると、R/WはATR_REQを送信する。
その中に、PPiがあり、bit0が1だとNADを使う、ということになっている。
TgInitAsTargetは戻り値のModeでDEPかどうかがわかる。
bit2が1なら、DEPだ。
このDEPビットが、何を見て立てるのかはわからんかった。
PPiを見てるって感じではなく、無線の設定なんかだろうか。
NFC ForumのDIgitalProtocolを読むと、Initiator側のPPiではNADを0にしろ、と書いてある。
ほほぅ。
また、PN533のドキュメントには、NADバイトはInDataExchangeで指定しなさい、とある。
InDataExchangeを使うと、DEP_REQを送信する。
そのDEP_REQにはNADバイトってのが専用にある。InDataExchangeを使うのはそういうわけだ。
ってことは、ATR_REQのPPiに載っているNAD情報は関係がなく、実際にはDEP_REQに出てくるということか？
それなら、現在の動作も納得できるような気がする。
TgInitAsTargetから抜けないのは、InDataExchangeを待っているから、ということだ。
InDataExchangeでNADバイトが指定されていたとき、libnfcのTgInitAsTargetを抜けてlibnfc-llcpに戻ってくるのだ。
さて、そういう動作をしてくれるだろうか？
うーん、InJumpForDEPがタイムアウトしている。
ってのは、昨日と一緒だな。
InJumpForDEPはATR_REQだから、ATR_RESを待っている。
SetParametersでATR_RESの自動返信ビットを立てているから、タイムアウトしなくても良さそうなものなのだが・・・。
それと、無線が不安定だ。
PaSoRiの上にRC-S620/Sをぺたっと置いているのだが、どうもそれだと反応が悪い。
間に紙を挟んだりすると、よさそうな感じがする。
よいというか、タイムアウトするというだけなのだが。
PaSoRiはType-Bに対応させるため、無線の調整をしたという話を聞いたことがある。
元々DEPを想定したものではないから、問題があるのかも。
RC-S620/Sがもう１枚あればいいのになぁ。
１枚壊したのが、非常に痛い。。。ACKが返ってこないから、致命的だ。
修理したいけど、無理だろう。情報ないし。せめてTPの情報が欲しいところだ。
開けてみたけど、小さい部品ばっかりでわからん。
しかしこんだけ小さいなら、逆電流なんかに弱いかもしれん。
うぅ、ピンの1～6が逆になってただけなのに・・・。
InJumpForDEPがタイムアウトしてないこともあった。
しかし、それでもTgInitAsTargetは終わってない。
何だろうねぇ・・・。
llcp-test-serverのログを見ると、TgInitAsTargetを実行後、InitiatorからATR_REQを受け取っているものの、ATR_RESを返していないようだ。
だから、clientはタイムアウトしているのだろう。
私が自分でTgInitAsTargetの動作を実装して、かざしてログインアプリをだましたときには、自前でコマンドに応答するソフトを作っていた。
libnfcではどうやってるのだろう？
では、nfc_target_init()でTgInitAsTargetを実行した後、どうすればいいのかを見ていこう。
libnfcのサンプルであるnfc-emulate-tagを動かして確認しよう。
・・・nfc_target_init()が失敗する。
FeliCaのタグとして動くように変更したのがまずかったか。
見ていったところ、FeliCaの場合にはMifare関連のパラメータを0x00として使っていた。
しかしRC-S956の使用かなんかわからんけど、SENS_RESは0x00 0x04でないと動かん。
適当に書き換えて動くようにし、P906iに入っている「iCタグリーダー」で読んでみる。
・・・対応してないタグということで、アプリがはじいた。
そのせいだと思うが、nfc-emulate-tagには変化なし。
ポーリングの段階ではじいたってことかな。
では、FALPで送りつければ何か送信するだろう。
やってみると、サービスコードの取得を行おうとしているパケットが受信できた。
が、nfc-emulate-tagは「知らんフレームがきた」ということでabort経路になり、終了。
まあ、abort経路がわかればなんとかなるだろう。
どうやら、TgInitAsTargetでターゲット状態になったあとは、ポーリングで受信データを確認しにいくようだ。
nfc_target_init()の引数にバッファを与えていて、そこに格納されるみたい。
コールバックじゃないんだ。。。
nfc-emulate-tagでは、target_io()の中で受信データの先頭を見て、何を返すか判断している。
考え方は、同じみたいだ。
うまくいかんシリーズです。
前回、clientはInJumpForDepを実行して、ACKは返ってくるのだが失敗が返ってきた。
それは、相手がいないからだ。
ではserverをtargetにしてやればいいはず。
コンソールを２つ立ち上げ、
$ tools/llcp-test-server/llcp-test-server --mode=target
$ tools/llcp-test-client/llcp-test-client --mode=initiator -t1
それぞれ実行。
ログは長いので載せないが、serverは生きたままなのだがclientはやはりエラー終了になる。
やはり、InJumpForDEPで失敗になる。
PN533のドキュメントによると、エラー理由は「Timeout」。
コンソールにも、タイムアウトしたことが出力されている。
しかし、InJumpForDEPの引数にタイムアウト時間があるわけではない。
それに、受信しそうなターゲットをかざさない限りタイムアウトもせずに待っている。
だからこのタイムアウトは、RFプロトコルをやりとりし始めてからのタイムアウトなのだ。
なんだろうねぇ。
nfc-tools/libnfc-llcp/toolsの下に、llcp_test_clientというものがある。
READMEを見ると、テスト用っぽい。
何が動くのかわからんが、やってみよう。
$ tools/llcp-test-client/llcp-test-client -T
Available tests:
1 - Link activation, symmetry and desactivation
2 - Connectionless information transfer
3 - Connected information transfer
4 - Connected information transfer (using SN)
$ tools/llcp-test-client/llcp-test-client -t1
[stderr] 20111203 01:24:03.810 ALERT libnfc-llcp.mac.link- mac_link_activate() will behave inconsistently
[stderr] 20111203 01:24:03.810 INFO libnfc-llcp.mac.link- (Sony / RC-S370/P - PN533 v1.48 (0x07)) Attempting to activate LLCP Link as initiator
[stderr] 20111203 01:24:03.834 DEBUG libnfc-llcp.mac.link- (Sony / RC-S370/P - PN533 v1.48 (0x07)) nfc_initiator_init() succeeded
[stderr] 20111203 01:24:04.185 INFO libnfc-llcp.mac.link- (Sony / RC-S370/P - PN533 v1.48 (0x07)) nfc_initiator_select_dep_target() failed
REASON: Timeout
lt-llcp-test-client: Cannot activate link
最初のALERTは、動作モードがinitiatorなのかtargetなのかを指定していないので出ている。その場合、initiatorで初期化してみて、だめだったらtargetで初期化している。<訂正>
ここではinitiatorでの初期化に成功したので「as initiator」となっている。
違った。
initiatorで初期化して失敗したらエラーを返す。
成功したらtargetで初期化して、失敗したらエラーを返す。
成功したら、エラーを返す。
って、エラーにしかならんやん。。。
なんか意図が違っているように思えるので、ソースを変更した。
コマンドの引数で、--mode=initiator、みたいにするのが正しいのだろうな。
次に失敗しているのは、携帯電話を載せたからだ。
initiatorなのでPoll Modeになって無線を出し始めているのだが、それにはInJumpForDEPを使っている。
携帯電話を載せると、その応答コードとして0x01が返ってくるので、エラーにして終了しているのだ。
という部分は、このログを見ただけではわからない。
libnfcのログまで出さなくては。
このテストプログラムはちょっと今ひとつで、
などがある。
まあ、テストだからねえ。
とはいえ、搬送波を出しっぱなしというのも困るので、修正。
これは、libnfcのpn53x_idle()に手を加えた。
InReleaseなどに失敗してもエラー終了させず、とにかく一連の流れを終わらせるようにしたのだ。
これは自作のドライバでも迷ったところであるが、アイドル状態にどうしても戻したいのであればエラーを無視するしかないと思う。
NFC Forumのドキュメントを読むと、「Poll Mode」と「Listen Mode」がよく出てくる。
「Initiator」と「Target」も出てくる。
Poll Modeは、RFを出して他のデバイスをポーリングするデバイスの初期モード。
Listen Modeは、RFを出さずに他のデバイスのRFを受け取るデバイスの初期モード。
と書かれているように読んだ。
気になるのは「初期モード(initial mode)」という言葉だ。
たとえばPICCなんかは自分でRFを出せないので、常にListen Modeになる。
では、DEPみたいにお互いが出し合うようなものはどうなんだろう？
その疑問に、InitiatorとTargetが拍車をかける。
Initiatorは、Poll Modeになったデバイスの役割。
Targetは、Listen Modeになったデバイスの役割。
と書かれているように読んだ。
"reached"ってあるが、これはコマンドとかいろいろ使ってそのモードになった、という意味でとらえたのだ。
で、英文に「Activities」という言葉が出ている。
ACTIVITYドキュメントに書かれているようなので、読まんといかんのか・・・。
Listen Modeが聞く方のRFを「Remote Field」、Poll Modeが出す方のRFを「Operating Field」としている。
Listen ModeとPoll Modeにはそれぞれステートがある。
ドキュメントは、その辺が細かく説明してある。
ということは、そんなに深く知らなくてもよさそうだ。
DEPで、毎回送信する人がInitiatorになるのかどうかを気にしていたのだが、どうでもよくなったので、それもいいや。
習慣みたいなものだが、静的解析ツールにかけると「while内が固定なので変だ」みたいな警告が出てくる。#define MACRO_FUNC(x,y) \do { \y = (x) * (x); \} while(0)
で、MACRO_FUNCが{}だけだと、if(xxx)MACRO_FUNC(x,y);else//to do
となり、if(xxx){y = x * x;};else//to do
となってしまい、elseが浮いてしまうのだ。if(xxx) {y = x * x;};else// to do
あとは、引数の途中で改行したい場合。if(aaa && bbb && ccc&& ddd && eee && fff) {// todo ......}
まあ、何が正しいってのはない世界だけど、自分ルールを持っていないと困るからねぇ。function(aaa, bbb, ccc,ddd, eee, fff);
FeliCaポケット機能が、SuicaやPASMOで使えるようになるらしい。
http://www.sony.co.jp/SonyInfo/News/Press/201111/11-151/
もともと搭載していた機能を、12月から使用許可したということらしい。
FeliCaポケットというのは、たとえば１枚のSuicaカードで、買い物のポイントや行政サービスや切符の購入などができるようにすることなのだが、これは「Suicaの情報を他のサービスにも使えるようにする」ではなく「Suicaで使っていない領域を他のサービスにも使えるようにするから勝手にやって」というものだと思われる。
まあ、勝手にやって、といっても誰かが管理するんだけど。
FeliCaポケット自体は少し前、いやかなり前からある機能だ。
Suica/PASMOにそれがあることすら知らんかったし、公表されてなかったんじゃないかと思う。
サービスを始めたわりには、宣伝も特にしてなかったし、採用されたものも知られてないと思う。
(私が知らんだけか？)
最初にガツンと宣伝しないとダメなのでは・・・と思ったけど、そうでもないかも。
当時にこれを大々的に宣伝したって、何に使うの？、みたいな感じで流されてしまい、印象が悪くなってたかも。
今なら、NFCってのが以前よりも市民権を得てきたので、やってもいいかも、と思う業者があるのかな。
いっそのこと「新サービス FeliCaポケット！」って言い張ってもいいのかも。
このサービスはセキュアなことが売りなので、NFC Forumで公開されている情報ではアクセスできないはず。
セキュアってなった途端、FeliCaは日本＋αローカルになってしまうのがつらいところだ。
普段、Windows XPを使っている。
週末やビルドの時にはLinuxを立ち上げ直しているのだが、Windowsでもビルドできるとよい。
libnfcはやったので、libnfc-llcpをやってみよう。
いつも１回でうまく行くことはないので、(1)とつけた。
cygwinでやる。
だめだったら、Mingw64でやろう。
./configureすると、libtoolがない、といわれた。
cygwin.exeを使ってインストール。
./configureすると、shtoolがない、みたいなことをいわれた。
cygwin.exeには、出てこない。
検索すると、どうも何かやってやればいいものらしい、という気持ちになった。
$ libtoolize --force
libtoolize: putting auxiliary files in `.'.
libtoolize: linking file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: linking file `m4/libtool.m4'
libtoolize: linking file `m4/ltoptions.m4'
libtoolize: linking file `m4/ltsugar.m4'
libtoolize: linking file `m4/ltversion.m4'
libtoolize: linking file `m4/lt~obsolete.m4'
$ aclocal
$ autoheader
$ automake --force-missing --add-missing
configure.ac:8: installing `./config.guess'
configure.ac:8: installing `./config.sub'
configure.ac:14: installing `./install-sh'
configure.ac:14: installing `./missing'
examples/nexus-get-tag/Makefile.am: installing `./depcomp'
Makefile.am: installing `./INSTALL'
$ autoconf
$ ./configure
お、通った。
しかし、makeするとlibnfcがないといわれた。
そうか・・・そういえばlibnfcはMingw64でビルドしたんだった・・・。
ためしにlibnfcをcygwinでビルドさせたが、uart_posixあたりでエラーになった。
タイトルにはcygwinって書いてしまったしなぁ。
Mingw64でlibnfc-llcpのビルドが通るなら、もういいや。
./conftest.exe
あー、これでエラーになるか。
ここは避けられんので、cygwinでもう少しがんばるか。
まあ、今週だけだと思うけどね。
LLCPがうまくいかんのだが、ログを見ていくとTgInitAsTargetのGeneralByteあたりがPN533のドキュメントと違う。
バグにしてはみんな問題なさそうなのだが・・・。
関数はpn53x_TgInitAsTarget()。
見ると、PN531 or RCS360の場合にはLEN Gtを書き込まずにGt[]のみ、それ以外はLEN GtとG[]というようになっていた。
ログからすると、RC-S620/SはRCS360扱いされているようだ。
うむ、実装通りだ。
さて、RC-S620/SのTgInitAsTarget。
コマンドの仕様が手元にない。
うーむ。
では、libnfcがどうやってRCS360と判定しているか見ておこう。
これはVID/PIDで見ているのかと思ったらそういうわけでもなく、GetFirmwareVersionコマンドの戻り値を使っている。
ICが0x33でVerが0x01だと、RCS360で、Verがそれ以外だとPN533になっている。
Revまで見ないといかんのかもしれんが、いかんせん情報がない。
うーむ。
では、とPN533形式にあわせたけどだめ。
他の要素か？と思っていろいろ変更していくと、結果としてはSENS_RESの値が問題だった。
どうも、RC-S620/Sで受け取ることができる値が決まっているようだ。
しかし、だ。
RC-S360もRC-S370もRC-S620/Sも、RC-S956を使っているとSONYのページには書かれている。
そう考えると、LEN Gtのようなプロトコルのレベルで書き方が違うってのは考えにくいなあ。
こればっかりは、General Byteを使うような通信をしてみないとわからない。
けど、ここはPN533とRC-S956で違う仕様なのだと考えた方が自然な気がする。
そんなわけで、今回はpn53x_target_init()のところで、RCS360な0x0004を設定するだけにしておこう。
// Set ATQA (SENS_RES)if(CHIP_DATA(pnd)->type == RCS360) {//ueno addabtMifareParams[0] = 0x00;abtMifareParams[1] = 0x04;} else {abtMifareParams[0] = 0x08;abtMifareParams[1] = 0x00;}
Linux版の窓使いの憂鬱。
infoseekのサイトにあったけど、移動したのか別の人が管理するようになったのか別の場所になっていた。
ありがたく使わせていただく。
FirefoxにWOTを入れていると「信頼性が低い」といわれたので、リンク先に飛ぶかどうかは自己判断で。
http://www42.tok2.com/home/negidakude/
aguse.jpでの調査結果からすると、別に悪くはなさそうだけど、どういう基準なのかなぁ。
http://www.aguse.jp/?m=w&url=http%3A%2F%2Fwww42.tok2.com%2Fhome%2Fnegidakude%2F&x=0&y=0
libnfc-llcpのログがでらんといっていたが、出るようになった。
libnfc/trunkにあったlog4crcファイルを~/.log4crcとしてコピーすると何とかなるんだろうと思っていたが、そういうものではないらしい。
libnfc-llcp/test/log4crcを使うとうまくいった。
そうか、このファイルは出力フォーマットだけでなく、出すログも選択できるのか。
$ tools/llcp-test-server/llcp-test-server --mode=target
[stderr] 20111124 15:28:28.754 TRACE libnfc-llcp.llc.link- service 0x15560f0 bound to SAP 1
[stderr] 20111124 15:28:28.754 TRACE libnfc-llcp.llc.link- service 0x1556480 bound to SAP 16
[stderr] 20111124 15:28:28.754 TRACE libnfc-llcp.llc.link- service 0x1559f90 bound to SAP 17
[stderr] 20111124 15:28:28.754 INFO libnfc-llcp.mac.link- (Sony / RC-S370/P - PN533 v1.48 (0x07)) Attempting to activate LLCP Link as target (blocking)
[stderr] 20111124 15:28:28.780 ERROR libnfc-llcp.mac.link- Cannot establish LLCP Link
lt-llcp-test-server: Cannot activate link
できれば、libnfcのログも一緒に出したいなあ。
log4c4のファイルを見比べると、最後の方にあるcategoryというタグが違った。
libnfcのものは「name="libnfc"」、libnfc-llcpのものは「name="libnfc-llcp"」。
じゃあ、両方書けばログが出るんじゃないか？
あたーりー。
nfc-toolsのlibnfc-llcpを試しているのだが、うまくいかん。
とりあえずログを出したい。
いろいろと参考にしながら、まずはlibnfcのデバッグ出力を。
の前に、log4cのインストール。
$ sudo apt-get install liblog4c-dev
libnfcのデバッグ出力
$ ./configure --with-drivers='pn532_uart,pn53x_usb' --enable-serial-autoprobe --enable-debug
$ make clean all
$ sudo make install
libnfc-llcpの方も同じく
$ ./configure --enable-debug
log4crc(CRC、ではなく、log4cのRC)を準備。
libnfcのtrunkに入っているものを使う。
$ cp log4crc ~/.log4crc
この設定でいけると思ったのだが・・・。
[stdout] ERROR libnfc.driver.pn53x_usb - Application level error detected
こんな感じで、libnfcの方しか出てこん。
config.hを見ても、LOG4Cは有効になってるんだけどなあ。
LLCPの動作確認をするには、R/Wが２つないとだめだ。
うちにあるのは、パソリとRC-S620/S。
ならば、RC-S620/Sをlibnfcから使うことができるならばよかろう。
使うのは、RC-S620/SとUSB-シリアル変換(CP2102)を接続したもので、Linuxでは/dev/ttyUSB0として認識されている。
幸い、libnfcには「pn532_uart」というシリアル向けのドライバが入っている。
RC-S956もPN532も似たようなもんじゃないだろうか？
$ ./configure --with-drivers='pn532_uart,pn53x_usb' --enable-serial-autoprobe
$ make clean all
$ sudo make install
$ utils/nfc-list
utils/.libs/lt-nfc-list uses libnfc 1.5.1 (r1182M)
No NFC device found.
うーむ。
こちらを参考にデバッグ。
http://code.google.com/p/libnfc/issues/detail?id=176
いやいや、待ってくれ！
成功しとうやん。
なぜなんだ・・・。
ログを追加してわかったのは、最後に
pn53x_check_communication: Successといってるけど、これはエラールートを通っているのだ。
Successにだまされてはいけない。
pn53x_check_communication()の中でDiagnoseコマンドを発行しているのだが、期待値が異なるようだ。
先頭の1byteが返ってこないのか何なのかわからんが、そうなっている。
ここでようやく、PN533のドキュメントを読む。
Diagnoseコマンドは、ペイロードの1byte目が診断コード、それ以降がデータ部になっている。
ここでは診断コード0x00で、データ部として「libnfc」を送信している。
その戻り値は、PN533では「診断コード+データ部」ということで、エコーバックみたいな形で戻ってくる。
RC-S956で同じことをすると、診断コードは戻ってこずにデータ部だけが返っている。
まあ、そういう仕様ってことだろうな。
期待値の先頭を削ることで、認識するようになった。
パソリと同じように、nfc-pollでMifare 1Kのカードを見てみる。
examples/.libs/lt-nfc-poll uses libnfc 1.5.1 (r1182M)
fail: pn53x_check_communication: Input/output error
Connected to NFC reader: PN532 (/dev/ttyUSB0) - PN533 v1.48 (0x07)
NFC device will poll during 30000 ms (20 pollings of 300 ms for 5 modulations)
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): 3d c5 73 b0
SAK (SEL_RES): 08
エラーが出てるのは、PCのttyS0か何かだろう。
シリアルを自動認識させようとしてるからよくないな。
固定でもかまわないのだが、どうやって指定するのだろうか？
ソースを見ていった限り、pn532_uartでは指定できなさそうだ。
autoprobeを無効にして、環境変数からとってくるような仕組みにすればいいんだけど、まあいいや。
最新版のlibnfcは、svnからとってくるようだ。
最新版というか、開発版というか。
とってくると、configureがなかった。
make_release.shというスクリプトがあったので、実行。
・・ACR122のビルドができんと怒られた。
これは、別のライブラリを使っているからのようだが、私にはいらんのでmake_release.shのconfigureに--with-driversを指定。
今度はdoxygenがない、と。
ドキュメントは一応作っておきたいのでapt-get install。
そうするとビルドまで済んで完了。
rootでビルドしてないからinstallはされてなさそうなので、make installを実行。
・・・したが、installがなくなっている。
libnfc-1.5.1.tar.gzができたところからすると、このスクリプトはファイル名通り、リリースするためのファイルを作るためのものってことらしい。
そしてよくあるように、答は最後にわかった。
http://code.google.com/p/libnfc/
教訓。
リリース元のサイトも先に確認しましょう。
libnfc用にnfc-toolsというものがある。
この中にlibnfc-llcpという名前があるので、これはきっとLLCPを実現してくれるのだろう。
ビルドしてみた。
環境は、Ubuntu 11.10 (64bit)だ。
$ ./configure
特に何もない。
$ make
libtool: Version mismatch error. This is libtool 2.4 Debian-2.4-2ubuntu1, but the
libtool: definition of this LT_INIT comes from libtool 2.2.6b.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4 Debian-2.4-2ubuntu1
libtool: and run autoconf again.
インストールされているlibtoolは2.4-2ubuntu1だけど、定義が2.2.6bのものだ。
だからaclocal.m4を2.4-2ubuntu1のマクロで作り直してautoconfしなおせ、ということか。
さて・・・aclocal.m4を作り直す、というのは何すりゃいいんだろう？
http://www.fireproject.jp/feature/automake/basic/autotools.html
aclocal.m4は、configure.inを入力としてaclocalコマンドで生成されるようだ。
では、
$ aclocal
$ autoconf
$ ./configure
$ make
なんかできたみたい。
$ sudo make install
とりあえずインストールしておこう。
以下がコピーされたようだ。
libnfc-llcp.la
libnfc-llcp.so.0.0.0
libnfc-llcp.lai
libnfc-llcp.a
さて・・・何ができたのだろうか。
examples/nexus-get-tag/nexus-get-tag
tools/llcp-pdu-explain/llcp-pdu-explain
tools/llcp-test-client/llcp-test-client
tools/llcp-test-server/llcp-test-server
たぶん、こんなところだろう。
それっぽい名前の、nexus-get-tagを実行。
$ ./nexus-get/tag -o xxx
lt-nexus-get-tag: No NFC device found
ソースを見ると、libnfcを使ったデバイス検出に失敗しているようだ。
いまさら、libnfcはWindowsでしか試していなかったことに気づく。
libnfcをビルド。
ドライバは、pn53x_usbのみにしておこう。
$ ./configure --with-drivers='pn53x_usb'
$ make
$ sudo make install
$ cd examples
$ cd ./nfc-poll
libnfc-1.5.1/examples/.libs/lt-nfc-poll uses libnfc 1.5.1 (r1175)
No NFC device found.
すでにだめだったんだ。
そういえば、LinuxでUSBを使うときにはrulesファイルが必要だったと思う。
pn53x.rulesというファイルがあるから、これを使うと良さそうだ。
$ sudo cp pn53x.rules /etc/udev/rules.d/60-pn53x.rules
$ sudo service udev restart
パソリを挿し直して
$ ./nfc-poll
libnfc-1.5.1/examples/.libs/lt-nfc-poll uses libnfc 1.5.1 (r1175)
Connected to NFC reader: Sony / RC-S370/P - PN533 v1.48 (0x07)
NFC device will poll during 30000 ms (20 pollings of 300 ms for 5 modulations)
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): 3d c5 73 b0
SAK (SEL_RES): 08
やれやれ。
ちなみにこのときは、パソリの上にMifare 1Kのカードを置いている。
では、改めて。
$ ./nexus-get-tag -o xxxx
lt-nexus-get-tag: Cannot activate MAC link
相手がいないってことですかね。
では、待ち受けるサーバだったらいいだろう。
$ ./llcp-test-server
待ち状態になった。
P906iを近づけると・・・
REASON: Timeout
lt-llcp-test-server: Cannot activate link
と出て、搬送波が出っぱなしになりながらもアプリ終了。。。
もう一度実行すると、固まってkillせんといかんかった。
パソリを挿しなおさないと、もう復活できなかった。
まあ、何か動いてるってことはわかったので、いいや。
ここらへんで、NexusSとやりとりできてるってこともわかった。
http://www.libnfc.org/community/topic/444/solved-nfcdepinitiator-against-a-nexus-s/
試すことはできんが、うまくやればAndroid Beamができるんじゃなかろうか。
問題は「試すことはできん」というところなんだけどね・・・。
ネットワークオペレータ(日本で言うキャリア)のソフトバンクと、セゾンカードのクレジットセゾン、アメリカン・エキスプレスは、大日本印刷とGemaltoが提供するNFC技術を用いて、SIMベースのNFCペイメントをAndroid携帯で試すそうだ。
でいいのかな？
３ヶ月は、アメリカン・エキスプレスのExpresspayサービスを試すみたい。
SIMベースのNFCって、SIMにSEが載っているだけでなく、NFCチップ自体が載ってるの？
チップはまだしも、アンテナは載らないような気がするから、やはりSEだけなのかしら。
だとしたら、NFCチップとアンテナは本体になくてはならないので、専用の端末を作るのだろうか。
あるいは海外から入手して手を入れるだけだろうか。
テストするっていうくらいだから、数は少ないだろうけどそこそこの数も必要だろうから、入手する方向かな。
んで、それをテスターの人に配って使ってもらう、とかだろうか。
packages/apps/Nfc以下にあるソースに、FireflyRenderThread.javaってのがある。
蛍のことらしいが、NFCとは直接関係なさそうだ。
使っているのは、SendUI.java。
FireflyRenderThreadもSendUIも、NFC関係のものをimportしていないので、UIなのだろう。
こんな感じで、NFCフォルダにあるものすべてがNFCのことをやっているわけではない。
フォルダも増えている(いつと比較してなのか忘れたけど)。
ndefpushは、前からあった。nxp ?
これは、Nativeなんちゃらってファイルをまとめたフォルダみたいだ。
ってことは、NXPのチップから変更するなら、ここのnxpとjni、external/libnfc-nxpなんかを置き換えればいいってことかな。
libnfc-nxpはちょっと巨大だな・・・。
最近見ているlibnfcと関係あるかと思ったが、ファイル名からするとまったく関係ない。
まあ、Linuxでのライブラリルールだと普通の名前だからなぁ。
ファイルヘッダなんかを見ると、libnfc-nxpはNXPがじきじきに作っているみたいだ。
http://www.nfc.cc/technology/nxp-fri
時代としては、ハードを広く採用してもらうためにソフトを無料で出す、ということなのだろうか。
最近「フリー」って本を読んだので、そんなことを考えてしまう。
Linuxのカーネルにもドライバが組み込まれたので、NXPの戦略は当たったのだろう。
SONYの次世代チップも、そういった広がりを見せてほしいなあ。
android-4.0.1_r1ソースもあることだし、Android Beamのことを調べてみよう。
といっても、何から始めてよいものやら。
まず、どういう動きをするものなのかネットで調べよう。
http://itpro.nikkeibp.co.jp/article/COLUMN/20111115/374500/
動画で説明されていた。
送信側でブラウザを、受信側はホーム画面を表示させておく。
そして向かい合わせると、送信側にダイアログが表示されている。
よく見えないのだが、それをタッチすると受信側にもブラウザが表示されていた。
とにかく、送信側のダイアログを表示するトリガを探せばよさそうだ。
packages/apps/Nfc/src/com/android/nfc/SendUi.javaってのがいかにもそれっぽい名前なのだが、どうなのだろう。
とにかく、スクリーンショットを撮っているってのが気になる。
以前はDDMS経由でしかできなかったと思うが、APIが追加されたのかな？
ここのフォルダには、snepとndefpushがある。
それらを見るより前に、NfcService.javaを眺めておこう。
・・・NFC-EEとかNFC-Cとか、よくわからん単語が出てくるな。
NFC-EEは、NFC Execution Environmentのことらしい。
frameworks/base/nfc-extras/java/com/android/nfc_extrasにもそういうファイルがあるな。
しかし、ダイアログっぽいものがよくわからん。
もう少し詳細がわかれば・・・。
YouTubeとかにも動画があった。
どうもダイアログと言うよりも、スクリーンショットを撮って縮小された画像が画面の真ん中に出てきて、背景では星っぽいものが迫っているようなアニメーションになっているようだ。
これはさっきのSendUI.javaでやってそうではないか。
タッチすると、コールバック関数のonSendConfirmed()を呼び出している。
SendUi.Callbackをimplementsしているのは、P2pEventManager。
そこでさらに、コールバック関数のonP2pSendConfirmed()を呼び出している。
だんだん自信がなくなってきたが、これはP2pLinkManagerだろう。
ここでようやく、sendNdefMessage()になった。
が、そこでやっているのは送信タスクの起動。
まだ本体にはたどり着かない。。
あ、SendTaskは比較的素直なようだ。
よかった。
こういう流れのようだ。
SNEPの接続に成功したら、送信に失敗してもNDEF Pushはやらない、という作りになっている。
SNEPはNFC Forumでドキュメント化されているけど、NDEF PushはAndroid独自のものだ(確か)。
だから優先されているのかな。
さて、送信するNDEFはどうなっているか。
これはコールバック関数のcreateMessage()に依存するらしい。
コールバック関数がない場合やメッセージがない場合は、Android Marketへ接続しそうなURLのNDEFを作っているように見える。
あとは、SNEPの話だ。
LLCPとかあの辺がないと動かないので、試したいならそこから作らねば。
ようやくlibnfcの話に戻れるようだ。
Android BeamってPUSHだ(今のところ)。
通信部分にSNEPを使えるようにしたってのはあるかもしれないが、NPPも使えるところからすると、RFに関しては新しいわけではない。
FeliCaにもFALPがあるし、iC通信ができるくらいだからAndroid Beamみたいなことはできるし、実際にやっている。
ただ、使う手間が違う。
有効にしておけば端末を向かい合わせてタッチするだけで使える、という手軽さはなかったものだ。
これは「端末に何かするときにはユーザの許可を求める」という考え方とは異なるものだ。
私も動画を見て「あ、受信側は許可を求められないんだ」と思ったものだ。
でもまあ・・・私はこれを勝手にされたら嫌だろうな。
パケホーダイみたいなものじゃないから、勝手にブラウザを立ち上げてURL先を見に行ったりされると「金がかかるじゃないか！」と抗議しそうだ(お金の問題じゃないけどさ)。
ただ、向かい合わせるだけで送信準備ができるというのはよいな。
そのためにはポーリングを消費電力など気にせずやる、という動作が必要だ。
あ、ポーリングするのが送信側なのか受信側なのかを見るの忘れた。
以前と同じ仕様なら、確かホーム画面でロックされていない場合にはポーリングする、だったと思う。
おそらく、それを引き継いでいるんじゃないかな。
まだまだやってるFALP受信。
何のためにやっているかというと、とりあえずは画像をPCに送りたいというだけ。
うちにはあまりいいデジタルカメラがなく、携帯電話のが一番いい。
それをパソコンに持っていこうとすると、microSDカードに入れて、アジャスタを噛ませてSD R/Wに入れて・・・という手順がいるので、めんどくさい。
USBケーブルを挿すって手もあるけど、せっかくFALPが使えるんならやりたいではないか。
こんな手順で受信を開始している。
エラーは発生していないのだが、P906iから送信しても携帯電話側でエラーだとみなされている。
ソフトの方は、特に動きがない。
falp_dump_log_to_file()でログが取れるのでやっているのだが、開始時にエラーが出る。
出るけど、動いているからまあいいだろう。
このログの見方がよくわからないのだ。
なんとなくこのログは、ライブラリのログと言うよりもドライバのログのような気がする。
ログは１行ごとに時間と種類があり、種類はこんな感じになってるんじゃないかと思う。
P906iから送信すると、FRESに値が載ってくるので、何かしら受信はしているようだ。
受信すると、STATEが「Propose待ち状態」になり、RWAITする。
その後、２回受信して、ERRORになるのだ。
ERRORのあとは、STATEが終了になっている。
エラーの種類は書いてあるのだが「その他エラー(code=-204)」。
うーん、わからん。
推測するしかないのだが、受信してエラーとしているのだから、受信データに問題があるのだろう。
想定していないパケットが来た、とか。
アプリにまで通知していないところを見ると、FALPの受信シーケンスとして想定していないものが来た、ということだろうか。
でも、P906iだって製品になっている以上、FALPのCTS試験は通っているはず。
変なものを送信しているってのは考えにくい。
もう少し試そうとしたのだが、P906iの電池が切れてしまった。
そして、充電中はiC送信できないということを初めて知った・・・。
falp_listen()のままずっといると、WM_TIMECHANGEが発行された。
うーん。
うーーーーん。
こういう結論に至った。
わからんものは、わからんのだ。
あきらめよう。
やっていて思ったのだが、スマートフォンみたいに自分で対抗機を作ることができるものがないと、面白くない。
自由が全くないので、できることが本当に限られてしまうからだ。
そりゃ、想定していないと言われても仕方ないわなぁ。。。
SDK for NFC Starter Kit beta2。
FALPができるのだが、まだ受信できてない。
それはまあいいとして、ライブラリ実装がなんか不自然なのが気になる。
なんというか、静的解析ツールくらいはかけてからリリースした方がいいと思う。
自分では持っていないから何とも言えないが、見ただけで変なところもあるので、ちょっと書いておく。
L.7
マクロ名の先頭がアンダーバー２つっていうのは、システム側で使用するものなので、普通は避ける。
一致しなければ別にいいんだけど。
この辺は間違って覚えている人が多いので、ありがちといえばありがちだ。
L.41
Visual C++なら通らないからいいけど、そうでなければコンパイルエラーになると思う。
#elif、だ。
よく知らんが、最近は#else ifなんて構文もあるのか？
L.42
Cにはboolがないから定義したのだろうが、せめてtypedefしてほしいところ。
boolのサイズはけっこう処理系依存だと思うけど、unsigned charで大丈夫なのか？
下の方でextern "C"してるから、boolは使わない方がいいと思うんだけどね。
戻り値も定義した方が、ソースとしては一貫性があるだろう。
L.94
このAPIだけ、他と違って変。
違う人が作ったのかな？
L.101
XPは32bit版だけだったけど、それ以外は64bit版もあったような。
APIが違うのはドキュメントに書かなくていいのだろうか・・・。
なんとなくFeliCa関係のソースは結構適当なできばえという印象がある。
動くからそれでいいやん、というのもそれはそれでいいんだけど、金を出して買った方からすると「品管は大丈夫なの？」なんて心配をしてしまう。
だって、ソフト仕様書とヘッダファイルなんて、製品で言えば筐体に当たるものやん。
もう少し気を遣った方がよい。
ソフトって、OJTだけでは成長しないので、ちゃんとした教育をしないといけない。
動くソフトとちゃんとしたソフトの差は大きく、やはりそれなりの教育がどうしても必要なのだ。
私も長いこと「動けばいいやん」派だったけど、この歳になってようやくわかってきたと思う。
セミナーとかによく参加させられて、「それなら仕事させてくれー」と上司に反発していたのだけど、悔しいが役に立っている。
ただ、教育を受けてしまうとソフトの考え方が固くなってしまうので、それはそれで面白くない。
なので結局、仕事用のソフトと遊び用のソフト、みたいな作り方をするようになってしまう。
とはいえ、こればっかりは難しいのよねぇ。
android-4.0.1_r1をビルドしているが、エラーが続く。
コンパイラのバージョンかなぁ。
In file included from external/oprofile/libpp/arrange_profiles.cpp:24:0:
external/oprofile/libpp/format_output.h:94:22: エラー: reference ‘counts’ cannot be declared ‘mutable’ [-fpermissive]
-fpermissiveは、非適合エラーを警告に格下げするものなのであるが、ここは「-fpermissiveを指定すると無視できますよ」という意味で出てきているのだろうか。
mutableは、constメンバ関数内でも変更できる変数にするやつなのだが、ここでは参照&にしているものをmutableにしているので、そりゃいかんですよ、といっているのだ。
まあ、そういう気もするが、別に本人がそれでいいんだったらいいんじゃないの、という気もする。
とりあえずmutableを消して逃げる。
external/gtest/src/../include/gtest/internal/gtest-param-util.h:122:11: エラー: ‘ptrdiff_t’ does not name a type
gtestってなんじゃ？
READMEによると、google C++ Testing Frameworkらしい。
ptrdiff_tってなんだろう、と思ったら、ポインタを引き算したときの型らしい。
#include <stddef.h>の追加でよいかな。
しかし、ここまでビルドできないと妙だな。
$ gcc -v
組み込み spec を使用しています。
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
ターゲット: x86_64-linux-gnu
configure 設定: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
スレッドモデル: posix
gcc バージョン 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
linaroだから？
いやいや、androidは自分で持ってるgccでビルドしてるはずだ。関係ない関係ない。
out/host/linux-x86/obj/STATIC_LIBRARIES/libLLVMSupport_intermediates/libLLVMSupport.a(Signals.o): In function `PrintStackTrace':
android-4.0.1_r1/external/llvm/lib/Support/Unix/Signals.inc:219: undefined reference to `dladdr'
(ずらずら)
めんどうだなー、と思ってネットで探すと、同じようなことをやってる人がいた。
https://groups.google.com/forum/#!topic/android-building/AgeruY7XIwQ
ああ、これを見ながらやろう。
と思ったら、JBQ氏が何かおっしゃっている。
https://groups.google.com/forum/?hl=en_US#!topic/android-building/uOxx-vlRrSc
ようがす。
masterを落としてやり直しましょう。
・・・・
やり直して、何事もなくビルドが終わることが確認できましたとさ。
めでたしめでたし。
Ubuntu11.10にしたので、久しぶりにAndroid SDK環境も入れ直すことにした。
なんとなく、Linuxではプラットフォームを、Windowsではアプリを、とやっていたので、Android SDKはあまり使っていなかったのだ。
android-4.0.1_r1のソースも公開されたので、そっちもやった。
SDKをダウンロードして、解凍。
最初にやるのはなんだっけ・・・・としばし悩む。
Readmeを読み、tools/androidを起動することだとわかる。
起動すると、Android SDK Managerが起動するので、適当にインストール。
Platform Toolsは必須じゃないかな。
eclipseを起動して、ADTも新しくした。
さて、とりあえずAVDを作成して、android 4を起動させた。
ほほう。
個人的にうれしいのは、設定アイコンが変わったことだ。
前は、車のタイヤみたいなのだったから、一瞬迷っていたのだ。
今回はつまみがついたようなアイコンなので、わかりやすい。
ソースは、いつものようにrepoで入手。
masterはだめだったのだが、android-4.0.1_r1はうまくいったので、まあいいや。
今makeしたのだけど、エラー発生。
yaffs2など使わないから外してもいいんだけど、どうもそういう問題でもなさそうだ。
-Werrorにしているのを外せば解決しそうだけど、それもなんかいやな感じだ。
_FORTIFY_SOURCEの２重定義なのだけど、Android.mkにはないから、build/coreあたりにあるんだろう。
とりあえずだが、build/core/combo/HOST_linux-x86.mkの56行目をコメントアウトした。
<組み込み>:0:0: 備考: ここが以前の宣言がある位置です<組み込み>:0:0: 備考: ここが以前の宣言がある位置です
といわれるから、デフォルトで有効になったのだろうな。
AndroidのMLで、よく出てくる人がいる。
それがJBQ氏。
的確な短い回答が心地よい。
しかし・・・謎だ。
今回、Android4.0のソースが公開されたという記事があった。
http://www.itmedia.co.jp/enterprise/articles/1111/15/news029.html
そこに「ジャンバプティステ・クエル氏」なる名前が。
ああ、この方が！
安心した方も多いのではなかろうか。
読んでないけど、このメールなのかな。
https://groups.google.com/forum/#!topic/android-building/T4XZJCZnqF8
Androidじゃない携帯電話にFALP送信できるサンプルができたので、世のため人のため(?)記事に載せてみようかと思った。
が、待つのだ。
使用許諾契約に違反しないか、確認せねば。
前回、Arduinoライブラリを見ながら移植したときは、よくよく読んで問題ないと思う範囲でやっていたつもりだったが、その解釈がよろしくなかった。
まあ、そのときは後付けで使用範囲が広くなったのだが、今回は慎重にやってみよう。
こういうのの読み方を説明してあるサイトはないかなぁ。。。
http://blog.felicalauncher.com/?page_id=3373
全文引用はよくないだろうから、上記リンク先を読んでくだされ。
第１条が基本で、それ以外の条文は補足だったり、一般的なことだったりのようだ。
ふむふむ、ホームページに書いてある動作環境かつ指定したターゲットで、指定するOSとR/Wを使え、と。
うちのOSはWindows XP Professional 32bitだから、OSは満たしている。
R/Wも、RC-S370だから、OKだ。
Visual Studioも、Expressではあるが2010だからOKだ。
・・・あれ、β1の動作環境では、2008って書いてある。
でも、もう2005とか2008ってダウンロードできないよなぁ。
あ、使用許諾には「動作環境」とは書いてあるが「開発環境」とは書いていないな。
セーフ。
むむむ？
FALPライブラリは「おサイフケータイとの」と書いてあるが、本文をよく読むと「おサイフケータイAndroidスマートフォン」という言葉も出てくるな。
β1の「カード」にも、「おサイフケータイ対応Android携帯電話」と書いてある。
そして・・・私が作ったのはP906i対応なので、Androidではない。
しゅうりょー
ええっと・・・違反した場合は・・・第５条、解約か。。。
さすがに被害は出していないと思うから、請求は勘弁してもらえるだろう。。。
「まさか "おサイフケータイ" にAndroidかそうでないかが含まれるなんて気付かなかったんです！」
と、弁護するしかあるまい。
SDK for NFC Starter Kitを使って、FALPターゲットになろうとしているが、うまくいかん。
まあ、うまく行かんシリーズみたいなもんだ。
とりあえずねぇ、ドキュメントに間違いがあるのが困る。
前も書いたようにFALPのだけじゃないんだけど、どこまで当てにしていいか迷う。
APIの引数がIN/OUTで間違っているくらいなら、まだなんとか予想できる。
でも、状態遷移が間違っていると、なんだかなぁ。
p.14に、FALP関連APIと動作モードの一覧がある。
R/WをオープンするAPIがあるのだが、それを呼ぶと「FALPモードへ移行」と書いてある。
FALPモードへ移行するとFALPターゲットモードにはなれないから呼んだらいかんなー、と思ったら、呼ばないとFALPターゲットになれない。
などなど。
まあ、それはやってみればわかるからいいんだけど、うまく行かない理由がまだわからん。
ログが取れるのでやってみたけど、ログを見ても意味がわからん・・・。
falp_listen()はうまくいくけど、Windowメッセージがうまくさばけていないのか、間違っているのか・・・。
今日はこの程度までだな。
P906iに向けてvNoteデータを送ろうとしているが、うまくいかん。
よく考えると、OBEXはデータだけじゃだめで、シーケンスをちゃんと動かさなくてはならない。
となると、今のFalpSendサンプルではちゃんと動かないだろう。
改造するために、どういう動きをしているのか把握せねば。
astah* communityで作ったんだけど、でかいなぁ。。。
まあ、いいや。
ライブラリの中がどうなっているかはわからないけど、まあ大きくは間違ってないだろう。
これをOBEX CONNとOBEX DISCで挟んでOBEX PUTすると、ちゃんとvNoteが携帯電話に送ることができた。
OBEXデータを作る関数は作ってたんだけどなー、と探しているが、見つからん。
もったいないなぁ。
SONYさんの SDK for NFC Starter Kit β2を使うと、FALPの送信ができることがわかった。
まあ、FALP受信もできることだろう。
これを使って、何かできるだろうか。
うちで簡単に動かせるのは、Android 3.1が載ったA500。
これでPaSoRiを動かすことはできている。
要領はRC-S620/Sの扱い方と同じなので、これといって難しいことはない。
RC-S620/Sの扱い方とPaSoRiの扱い方は同じなので、FALPもまた同じようにできるはず。
ライブラリの移植は無理なので、プロトコル解析して実装、というような手順にはなるだろうがね。
そしてそれは、見た目だけの実装になるので、たぶんFALP仕様通りではない。
それはなんだかなぁ。
前回の携帯電話との接続実験をしていて思ったのだが、FALPの上にLLCPを実装するといいんじゃなかろうか。
やっていることは重複してしまうので、無駄はかなり多い。
多いのだが、LLCPから上はNFC-DEPでもFALPでも共通にすることができる。
今のフィーチャーフォンはFALPの上にOBEXが載っているが、スマートフォンではOBEXは使わなさそうな感触だった。
でも、FALPはFALPが対向にならないと通信できないから、意味はないか。。。
http://blog.felicalauncher.com/?p=3639
SDK for NFC Starter Kit β2にはFALPのサンプルソースがあったので、動かしてみた。
うちの環境
test.jpgというファイルを送信するサンプルっぽい。
実行結果
initialize_library()...
open_reader_writer_auto()...
transaction_lock()...
polling_and_get_card_information()...
falp_open()...
falp_connect()...
falp_connect() error.
接続エラーっぽい。
携帯電話はLEDが点いたので、PaSoRiから搬送波は出しているようだ。
まあ、ログ通りに、ポーリングはうまく行くけどFALPの接続で失敗している、というところだ。
サンプルの説明が、こうなっている。
〇おサイフケータイ対応Android携帯電話とFALP通信を行う
まあ、確かにうちの携帯電話はAndroidではない。
とはいえ、これはFALPライブラリなので、サンプルをいじれば何とかなるだろう。
unsigned char appid[] = {0x02, 0x00, 0x54, 0x45, 0x53, 0x54, 0x49, 0x44 };
まあ、これだろう。
これを書き換えて、実行。
initialize_library()...
open_reader_writer_auto()...
transaction_lock()...
polling_and_get_card_information()...
falp_open()...
falp_connect()...
falp_wait_event()...
falp wait event: 8
falp_shutdown()...
falp wait event: 4
falp_close()...
transaction_unlock()...
close_reader_writer()...
惜しい。
ログからするとうまくいっているように見えるが、携帯電話側がエラーを出している。
つまり、データを読んで失敗しているのだ。
これはあれだな。
送信側がOBEXデータを送ってないからだな。
なので、あとは送信データだけの問題で済みそうだ。
このデータでスマートフォンとはやりとりできるようなので、あっちは結構自由度が高そうだ。
持っていれば試すところだが、持っていないので試せない。
携帯電話はあまり好きではないので、買い替える気もないし、壊れて買い替えるとしても同じような機種にするだろうなぁ。
Windowsは、嫌いではない。
Microsoftも、そんなに嫌いではない。
Visual Studioも嫌いになるほどには使ってはいないのだが、１点ものすごく嫌いなことがある。
それは、インストールしただけで拡張子の関連づけを勝手に代えてしまうことだ。
せっかくテキストエディタに割り振っていたものを奪い取られるので、その腹立たしさは並ならぬものである。
そしてサービスパックを当てたら当てたで、また奪い戻される。
さっき奪われた。。。
えーい、ならば取り戻すまでよ。
というわけで、こんなバッチファイルを作成した。
set EXEC="C:\Winappli\EmEditor\EMEDITOR.EXE"
set PARAM="%%1"
call :attach c cpp cs def h hpp inc inl java log s asm mak map txt
pause
goto end
:attach
assoc .%1=emeditor.%1
ftype emeditor.%1=%EXEC% %PARAM%
shift /1
if "%1"=="" goto attach_exit
goto :attach %*
:attach_exit
exit /B 0
:end
バッチファイルなんてめったに書かないから、えらく時間がかかってしまった。
EXECに関連づけたい実行ファイルを、PARAMにその引数を書く。
んで、callの行に関連づけたい拡張子をずらずら書くだけだ。
珍しくFeliCaがらみの話が連続してしまった。
http://www.sony.co.jp/Products/felica/business/information/111111.html
噂のFeliCa Lite-Sが公式に出てきた。
書いてある以上のことは知らないのだが、FeliCa Lite-Sの大きな特徴は「ライトアクセス権制御」だろう。
FeliCa Liteでは書き込み制御ができるPADがなかった。
なので、お金に関するような情報は書き込みたくないようになっている。
あれ・・・FeliCa Liteにはリードアクセス権制御があるって書かれているな・・・。
そんな機能あったっけ？
Read w/o Encryptionだから、どっからでも読めたと思うのだが。
そうではなく、MCレジスタへ書き込むとブロック単位でRWかROが決定できる、ということを指しているのかな。
ここにWOが追加されるということだろうか。
ともかく、MACを使った相互認証ができるので、FeliCa StandardみたいにFNさんに許可を得る必要はなく、安く実現できるのが嬉しい(確か、毎年数十万円必要だったような気がする)。
地域通貨みたいなものができると面白かろう。
全然関係ない話だが、説明文に出てくる「シングルジャーニーチケット」が気になった。
どうやら、再利用可能な１回乗車券、というものらしい。
今だと発券機にお金を入れると、紙の券が出てくる。
紙だと、使い終わったら捨てるしかない。
だからRFIDを使って再利用できるようにしようではないか、というもののようだ。
ほー。
韓国でやっているらしい。
http://response.jp/article/2009/07/13/127214.html
T-money、というらしいので調べてみると、位置づけとしてはnimocaやSuicaと同じものっぽい。
http://www.konest.com/data/traffic_info_detail.html?no=1259
でも「シングル」と言い切っているところをみると、チャージするというようなイメージよりも、その料金区間を１回だけ乗ることができる、という使い方になるような気がする。
FeliCa Liteではできなかったことだな。
SONYから、モバイル向けNFCチップが商品化されたという記事があった。
http://www.sony.co.jp/SonyInfo/News/Press/201111/11-145/
図を見るとわかるように、FeliCaセキュリティチップとSIMカードにアクセスできる。
これはNTTドコモの次世代向けだと思われる。
SWPに対応したってのが大きいな。
このチップを搭載したおサイフケータイであれば、Android APIのNFC機能を使うことができないこともないだろう。
でも、現状でもNFC-FだけAPI対応する、というような技は見せていないから、なんかMFC搭載の携帯電話に対する制約が課せられているのかね。
不思議に思ったのは、ARM。
脚注に「"ARM"はARM社の商標です」と書いてあるのだが、記事にARMは出てきていない。
なんだろう？
構成例がスマートフォンなので、ホストコントローラがARMになってた名残だろうか。
昨日、FeliCa Developers' Blogで見逃していた記事があった。
http://blog.felicalauncher.com/?p=3639
なな、なんと！
FALPがPCからでも使えるようになるライブラリが入ったのだ。
わしが生きている間にこれが実現するとは(オーバー)。
ちょっと実装してみる時間が取れないのが悔しいところだ。
まあ、FALP送信だけなら自前ライブラリでもやれるので、まだいいんだけどね。
ドキュメントを眺めていて気になったのが、structure_device_information。
どういうときに使うのか知らないけど、device_info_typeの中に「ワイヤレスキーボード」がある。
それ以外は、PaSoRiの機種名っぽいのに。
ワイヤレスキーボードでPaSoRiつきがあるのかな？
タイムアウト時間も、ワイヤレスキーボードが長めになってるみたいだし。
まあ、いい。
使ってみればわかることだ。
発端は、この記事であった。
http://news.mynavi.jp/news/2011/11/04/014/index.html
C++好きだといいながらも、あんまり最近C++使ってないし、動向も見てなかった。
せっかくなので、この記事を眺めて雰囲気だけでも味わってみよう、などと考えていた。
しかし、最初の項目を見て驚いた。
map<int,string>::iterator i = m.begin(); //C++98↓auto i = begin(m); //C++11
なんと！
autoって、自動変数のautoかと思ったら、定義自体が違うではないか！！
そしてこれは、理にかなっていると思った。
C++には引数が異なる関数の多重定義はあるけれども、戻り値が異なる多重定義はない(よな？)。
だから、引数が決まった時点で、戻り値も決まることになる。
一時的に使いたい変数程度なら、わざわざ型指定とかしなくてもautoでいい、ということになる。
そしてそうした方が、戻り値の型を書くよりも安全だ。
組込みでソースを書いていると、型をきっちり、ということを強いられる。
で、これがけっこうめんどくさい。
ソースが流動的なときなんかは、戻り値の型が変わってしまったりして、関係するところを洗い出さないといけん、とか。
まあ、静的解析ツールにかけたり、コンパイラでwarningレベルを上げたりってのもあるけど、言語レベルでサポートされると気が楽だ。
コードレビューの時なんかは、「autoを使っていないとこだけ確認」とかで済むし。
それよりも、というと変だが、autoの意味合いが変わっているところに驚きを感じた。
これはもう、C/C++ではなく、C++11という言語と考えてもいいんじゃないだろうか。
もっと知らねば・・・。
とりあえずC言語でもほしいのは「namespace」「新auto」「nullptr」かな。
nullptrは、以前から疑問に思っていたNULLチェックに対して答を与えてくれるものかもしれない。
今日は読んでないのだけど、早く読んでしまおう。
$ sudo apt-get install xubuntu-desktop
そんな感じでやった。
うん、確かにgnome2に近い。
あとはboostの件が解決すれば、環境周りは片付くんだけどなぁ。。。
うまくいかんシリーズ。
boostのregexで、リンクがうまくいかんようなのだ。
使っているboostは、1.47.0。
コンパイラは「gcc バージョン 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 」だ。
#include <boost/regex.hpp>int main(){boost::regex r("");return 0;}
$ g++ -o tst -I/usr/local/boost/include -L/usr/local/boost/lib -lboost_regex regex.cpp
/tmp/ccaCv8B6.o: In function `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign(char const*, char const*, unsigned int)':
regex.cpp:(.text._ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j[boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign(char const*, char const*, unsigned int)]+0x2a): undefined reference to `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*, unsigned int)'
collect2: ld はステータス 1 で終了しました
boost_regexがうまくいってないのかと思ってboost_regeとかにしてみると、ちゃんと「ライブラリがない」エラーが出た。
ってことは、libboost_regexがあることはわかってるんだ。
なのに・・・なぜ・・・。
これがリンクできない、といっているのはわかった。
_ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j
では、ビルドしたファイルのあるboost_1_47_0/bin.v2/libs/regex/build/gcc-4.6.1/release/threading-multiを見てみよう。
$ nm *.o | grep _ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j
確かに、ない。
では、何ならあるんだ？
$ nm *.o | grep _ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traits
U _ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9do_assignEPKcS7_j
W _ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE5imbueESt6locale
うーん・・・。
ちなみに今は、こんな環境だ。
Linux kurokiri 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
これを対策できれば、いいんだと思う。
`boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*, unsigned int)'
boost::regexは、こういう定義だ。
typedef basic_regex<char> regex;
なので、このエラーはboost::regexのことであることは間違いがない。
では、basic_regexクラスのdo_assign()を見てみよう。
class basic_regex : public regbase{(略)private:basic_regex& do_assign(const charT* p1,const charT* p2,flag_type f);(略)
宣言はある。
では、実装はどこにあるのだろう。
その下にある、これしかなさそうだ。
template <class charT, class traits>basic_regex<charT, traits>& basic_regex<charT, traits>::do_assign(const charT* p1,const charT* p2,flag_type f){shared_ptr<re_detail::basic_regex_implementation<charT, traits> > temp;if(!m_pimpl.get()){temp = shared_ptr<re_detail::basic_regex_implementation<charT, traits> >(new re_detail::basic_regex_implementation<charT, traits>());}else{temp = shared_ptr<re_detail::basic_regex_implementation<charT, traits> >(new re_detail::basic_regex_implementation<charT, traits>(m_pimpl->m_ptraits));}temp->assign(p1, p2, f);temp.swap(m_pimpl);return *this;}
ヘッダにdo_assign()定義があるということは、ライブラリうんぬんは関係ないことになる。
なんかおかしい・・・。
とりあえず、プリプロセスを展開させよう。
__extension__ extern template basic_regex<char , boost::regex_traits<char > >&basic_regex<char , boost::regex_traits<char > >::do_assign(const char* p1,const char* p2,flag_type f);
定義がないのは、これ。
boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >
::do_assign(char const*, char const*, unsigned int)
もしcpp_regex_traits<T>がbasic_regexをtypedefしたものだったらいいんだけど、別のclassだ。
確かに、定義はないな。
しかし、変だ。
だって、basic_regex<charT, traits>::do_assign()って書いているのだから、traitsがcpp_regex_traitsから置き換わる、なんてのは考えにくい。
nmでbasic_regexのコンストラクタを見ると、
boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::basic_regex(char const*, unsigned int)
と、cpp_regex_traitsのバージョンしかなさそうだ・・・ん？
似たようなのがあったぞ。
boost::shared_ptr<boost::re_detail::basic_regex_implementation<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > >::shared_ptr()
すまん、もう訳がわからん・・・。
あ、でもこのshared_ptrは、do_assign()の実装で使われているものではなかろうか。
shared_ptr<re_detail::basic_regex_implementation<charT, traits> > temp;
do_assign()の定義は
template <class charT, class traits>
basic_regex<charT, traits>& basic_regex<charT, traits>::do_assign()
なので、traitsとしてはbasic_regexと同じものが使われるべきで、regex_traitsが急に出てくるのはおかしいような。
でも、そもそもの話が、
typedef basic_regex<char, regex_traits<char> > regex;
なので、regexの定義としてはおかしくないのか。
でも、nmで見ると、regex_traitsは出てこず、cpp_regex_traitsしかないんだよなぁ。
まあ、今日はこの辺にしておこう。