ざっと見た感じだが、QtからUSBをアクセスする標準クラスはないように見える。
シリアルポートなんかもないようだ。
まあ、グラフィックみたいに基本的に１つしかないことが保証しやすいものはいいけど、USBやシリアルポートのように、あったりなかったり複数あったりするようなものは難しいところだ。
USBならば、libusbを経由させれば何とかできそうに思う。
検索してもだいたいそんな感じだった。
Windowsだけであれば、WinUSBという選択もあろう。
意外と難しいのが、シリアルポート。
Windowsだと「COM3」のようなポートになっているが、Linuxだと「/dev/ttyS2」のようになる。
(Macは使ったことがないので知らない。)
この名前がハードウェアと一意で決定するのであればいいけれども、そうもいかない。
libnfcでは「自動検索」か「ユーザ指定」という形にしているが、そういう解決方法しかなさそうだ。
家に帰って余力が残っているようであれば、LLCPを検索して探している。
普段はNFCなどと関係ない仕事をしているので、仕方ない。
何を探しているかというと、NFCのLLCPについてよい資料がないかどうかだ。
弱気になっているのかもしれないが(そう、年末年始の私は非常に不安定だ)、NFC ForumのLLCPドキュメントを見ながら実装したとしても、まっとうに動かないんじゃないか、と考えてしまったのだ。
理論だけではなく、経験に裏打ちされた情報が必要なのかもしれない、と。
そうなると、また以前の考えに戻ってしまう。
「自分で実装するのが面倒なら、実装されたものを使えばいいじゃない」。
カードの情報を読み書きしたり、NFC-DEPでデータをやりとりするところは面白かったのだけど、LLCPみたいな上位層になってくると興味が非常に薄い。
薄いけど、ここまできたら動くところを見たいし・・・と、やっかいな気分である。
前置きが長くなった。
検索してみていると、Linux NFC Subsystem、という文字が目についた。
PDFになっていたので、ばさばさと目を通す。
libnfc-nxp、OpenNFC、libnfc、それぞれベンダーやハードウェアへの依存が強い。
APIもPOSIXっぽくないし。
新しく、ドライバ追加型にすることでハードウェア非依存にし、POSIXっぽくやろうじゃないか、というように読んだ。
socketとか、netlinkとか、そういうものにあわせるというやり方みたいだ。
残念ながら・・・私はそこまでLinuxで作り込んだことがないので「netlinkって、あったね」くらいなことしか言えない。
でも、そういうプラットフォームができるのなら、私もそれに合わせたいものだ。
今のところ、自分でRC-S620/SやPaSoRiにアクセスするのに、自前のインターフェースを作っている。
libnfcでもCard Emulationならいけそうなのだが、LLCPまでやりたいとなると自信がない。
せめて、自分でNFC-DEPがきちんと動かせるようになってからでないと、移植は無理だ。
ふと、Qtはどうなっているのかが気になった。
Nokiaさんだし、なんらかの形でサポートしているのではなかろうか？
検索して出てきたのは、こちら。
Qtではなく、Qt MobilityのAPIとして存在している。
ということは、デスクトップ向けではなく、携帯電話のような移動端末向けということなのだろう。
(サポートしている端末は限られているようだが。)
ざっと検索してみたが、QtのAPIとしてはなさそうだ。
やるなら、ネイティブAPIを組み込むか、ネイティブAPIをQt Mobility APIに合わせて実装するか。
そんなところだろう。
Androidもいいのだけど、やっぱり必要となるハードウェアは機能が高めになってしまう。
なので、なんでもかんでもAndroid、ということもないだろう。
エアコンや炊飯器にAndroidが使われるかというと、使われんと思う。
レジに入っているOSがAndroidになるかといえば、ならんと思う。
適材適所であろう。
私としては、次の候補がQtなのだ。
自身はOSとしての機能は持たないものの、GUIを持つプラットフォームである。
なら、OSとしては何を選ぼうか？
今のところ、Linuxしか思いつかない。
LinuxはLinuxで結構なパワーが必要だと思うが、Linuxが動かせないならQtも諦めてよさそうに思う。
まあ、私の指標でしかないがね。
もうすぐ実家に帰るので、最後に書き残しておこう。
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に載ってた値なので、よくわからん。