2013/09/27

家からもEdyチャージできる(要クレジットカード)

コメントで教えてもらい、PaSoRiでもEdyチャージができるということだった。
うーむ、まさかクレジットカード経由という名称だとは。
なんでPaSoRi経由って書かないんじゃ-!

それはさておき。
Edyが家からチャージできるのなら、RC-S390でチャージできるのも不思議ではない。

では、サイバネ系はどうかというと、そうではないようだ。
たとえば、nimoca
チャージ方法は、乗り物か、お店でしかできない。
じゃあ、サイバネ系の親玉はどうだろう?

Suicaには、インターネットサービスがあるようだ。
SFの入金を見ると、クレジットカードの登録が必要ながらも、PaSoRiでできるみたいだ。
クレジットカードも、ある程度決まりがあるようだ。
・・・うーん、リボであることに目をつぶれば、ビュースイカのリボカードが一番楽そうだ。
なんたって、年会費が無料だから、忘れてても大丈夫そうだ。

そんなわけで、Suicaってどうなんだろう、を試してみるか迷い始めたところだ。
いや、いままでNFCって通信路としてしか見ていなかったんだけど、そういえばサービス面もあったな、と思い出したのだ。

2013/09/26

世間はクリスマスらしい

http://www.nfcworld.com/2013/09/25/326061/rapidnfc-offers-nfc-christmas-cards/

RapidNFCさんが協力して、NFCタグ入りのクリスマスカードを提供するらしい。
日本では、クリスマスという風習がないため・・・と書こうとしたが、あんまりそうでもなさそうだ。
まあ、賛美歌312番でも歌いながら、世の平和を願うのもよかろう。

 

image

・・・今日はこれで勘弁してくれねぇか・・・。

2013/09/25

RC-S390なるものが出るらしい(サービス事業者向け)

iPhone / iPadで電子マネーの残高・利用履歴を確認できる
非接触ICカードリーダー/ライター PaSoRi®(パソリ) 「RC-S390」を発売

とのこと(詳細はこちらより)。

詳細は見ていただくとして、iOSから使えるのと、そのため(だけじゃないと思うが)USB接続とかじゃなくてBluetoothになっているのが目新しいと思う。
Bluetoothも、BTLEだ。これにより、20日くらい充電せんでも使えるらしい。
ほほー。

さて、このRC-S390。
Sonyが提供するのはサービス事業者だそうだ。
だから、いつものように「スイッチサイエンスさんから出らんかな-」と待っていても、出ないんだと思う。
第1弾は、楽天Edyとのこと(Edyって、楽天になったんだ・・・)。

機能的な特長は、Edyのチャージができることじゃなかろうか。
モバイルEdyみたいなのではなく、チャージする側になる、ということだ。
カードをRC-S390につけたまま支払いできるのだけど、あくまでS390はR/Wに徹し、支払い機能なんかは持たない。
Suicaやnanaco、waonも使えるが、それは残高を見るのみ。
(だけど、チャージもできるんじゃないかって勘違いしてしまう人もいるかも。クロノメーターは2つではいけない、というやつか。)

なかなか思い切った仕様だと思う。
これだったら、PCのPaSoRiからでもEdyチャージできればいいのに。
 ※2013/09/27追記
 ごめん、クレジットカードがあればチャージできます。
 コメント参照して下さい。

 

あとは、買って試してみるかどうかだなぁ。
BTLEって全然知らないので、制御できる気がせんが、そんな弱気がいかんのか。

2013/09/22

[nfcpy]ちょっと不明なところがあったが、書いていくうちにわかった

nfcpyを見ると、rcs380.pyというファイルが増えていた。
まあ、ダウンロードした理由はそこにあるのだが。

pythonに詳しくないのだが、なんか実装で不明なところがあった。
Frameクラスのinitで、引数を見て判断しているところがある。
たぶん、受信したフレームデータの1次解析みたいなことをしてるんだろう。

data[0:3]が、00 00 ffかどうかを見ている。
pythonでは「名前[start:end]」だと、その範囲はstart~end-1らしい。
なので、フレームの先頭3byteが00 00 ffかどうかを判定しているのだろう。
それはいい。
「00 00 ff」で始まっていたら、そのデータによって、ACKかERRかDATAかを分けている。

分けているのだけど、こんな感じになってるようなのだ。

ACK  : 00 00 ff 00 ff 00
ERR  : 00 00 ff ff ff
DATA :       ff ff

最後にelseがないから、これ以外だったらどうするんだよってのはあるとして、ERRとDATAの見方がおかしいと思うのだ。
実装としては、ERRは「00 00 ff ff ff」と一致する場合、DATAはdata[3:5]が「ff ff」と一致する場合・・・

と書いていて、ようやくわかった。
ERRになるのは受信データがちょうど「00 00 ff ff ff」だった場合で、DATAとするのは「00 00 ff ff ff ・・・」とさらに値が続いていた場合ということなんだな。

 

い、いや、RC-S380はコマンド調べるつもりはないからね。

[nfc]nfcpyをとってくる

とりあえず、nfcpyをとってこようと思う。
実行ファイルではなく、ライブラリだから、とってくるだけじゃなくて開発環境も整えないといかん。
が、そっちはあとで考えよう。

まず、codeのサイトに行って、取ってきかたを見ておこう。
bzrというコマンドを使って、ソース一式を取得する。
このbzrがないと、たぶんダウンロードできないと思うので、なんとかしよう。
今回はcygwinで取得することにしたが、opensslがうんたらかんたらと言われたので、ちょうど調べた知識が役に立ちそうだ・・・と思ったが、認証を外すことで対応した。

$ bzr branch lp:nfcpy -Ossl.cert_reqs=none

 

ドキュメント類はこちら
tutorialのページに、インストールからp2pまで一通り書いてある。
WindowsでもLinuxでもやれるっぽいことが書いてあるから、OS Xもいけるんじゃなかろうかね。

opensslのルート証明書がほしかった

cygwinからopensslを使ってみようとした。
openssl自体は、普通にcygwinのsetupツールからインストールできる。
できるのだが、openssl自体はルート証明書を入れてないということだ。

/usr/ssl/certs/README.RootCerts

The OpenSSL project does not (any longer) include root CA certificates.

Please check out the FAQ:
  * How can I set up a bundle of commercial root CA certificates?

リンク先を見ると、ルート証明書は提供してないから、好きにしな、とある。
それだけでは不親切と思ったのか、別のところではこうしている例もあるよ、というリンクがある。
Mozillaの例らしい。

リンク先にはperlのスクリプトがあり、cvsで取ってきて加工するようなのだが・・・。
pserverのところが[EMAIL PROTECTED]になってて、どこだかわからない。

 

で、みんなどうしているかというと、Mozillaのルート証明書をとってきてるみたいだ。
http://curl.haxx.se/ca/cacert.pem

でも、なんかすっきりしない・・・。
haxxって誰だよー、って気もする。
cacert.pemをテキストエディタで開くと、元データのURLがあった。
こっちはmozilla.orgだから、これを使ってみよう。

http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1

このcertdata.txtを取ってくるのがさっきpserverがわからんといってたところだから、certdata.txtを別でダウンロードして、catで吐きだしたものをスクリプトにすればいいんじゃなかろうかね。
あるいは、curlで取ってくるか(curlって、cat urlの略なのか?)。

   1: #!/usr/bin/perl -w
   2: #
   3: # Used to regenerate ca-bundle.crt from the Mozilla certdata.txt.
   4: # Run as ./mkcabundle.pl >; ca-bundle.crt
   5: #
   6: #original
   7: #http://www.mail-archive.com/modssl-users@modssl.org/msg16980.html
   8:  
   9: my $curltxt = 'http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1';
  10: my $certdata = 'certdata.txt';
  11:  
  12: #open(IN, "cat $curltxt |")
  13: open(IN, "curl $curltxt |")
  14:     || die "could not check out certdata.txt";
  15: 
  16: my $incert = 0;
  17:  
  18: print<;<EOH;
  19: # This is a bundle of X.509 certificates of public Certificate
  20: # Authorities.  It was generated from the Mozilla root CA list.
  21: #
  22: # Source: $certdata
  23: #
  24: EOH
  25:  
  26: while (<;IN>) {
  27:     if (/^CKA_VALUE MULTILINE_OCTAL/) {
  28:         $incert = 1;
  29:         open(OUT, "|openssl x509 -text -inform DER -fingerprint")
  30:             || die "could not pipe to openssl x509";
  31:     } elsif (/^END/ && $incert) {
  32:         close(OUT);
  33:         $incert = 0;
  34:         print "\n\n";
  35:     } elsif ($incert) {
  36:         my @bs = split(/\\/);
  37:         foreach my $b (@bs) {
  38:             chomp $b;
  39:             printf(OUT "%c", oct($b)) unless $b eq '';
  40:         }
  41:     } elsif (/^CVS_ID.*Revision: ([^ ]*).*/) {
  42:         print "# Generated from certdata.txt RCS revision $1\n#\n";
  43:     }
  44: }
  45:  

なんとかなりそうだ。

が、これで作ったcrtファイルは900KB近くある。
haxxさんから取ってきたpemは220KBくらい。
むぅ。

 

ここまで読んでこられて気付いたかもしれないが、私はこの辺りはまったくわかっていない。
pemとかcrtとか出てきても、「ぺむ?」くらいにしか思っていない。
ちょっと調べておかないと痛い目に会いそうだ・・・。

http://ja.wikipedia.org/wiki/X.509
まずよく聞く「X.509」だが、これは証明書の形式みたいなものらしい。
断りがなければ、証明書と言えばX.509の形式なのかな?

で、形式といっても「こんな構造で書け」というようなタイプみたいで、形式に沿っていればテキストでもバイナリでもよく、テキストも暗号化したりしてよいみたいだ。
ここら辺で、さっきのpemとかcrtが出てくるみたいだ。

wikipediaには、CER, DER, PEMはあったけど、CRTがない。
さっきのスクリプトでは、「openssl x509 -text -inform DER -fingerprint」となってるから、certdata.txtにはさまってる\xxxってなってるところがバイナリなのだろう。
-outformの指定がないが、デフォルトがわからん。PEMかDERかNET(Netscape)。。。試すとPEMだった。

haxxさんとの違いは、Signatureのことが書いてあるかどうかみたいな感じがする。
-textオプションをなくすとよさそうだ。

・・・とここまで調べて、haxxさんのところに変換スクリプトの紹介があることに気付いた。
まあ、世の中そんなもんだ。
http://curl.haxx.se/docs/caextract.html

2013/09/15

[rpi]initが読めん

Buildrootは便利なのだが、今はkernelとbusyboxが動く程度の環境を作りたい気分なのだ。
しょうがないので、kernelからビルドすることにした。

といっても、Raspberry Pi用のkernelがあるようなので、それを使う。
ビルドの仕方は、こちら

SDカードは、vfatをp1、ext4をp2にし、initramfsなどは使わずにext4のところに環境を置いた。
initは、/sbin/init。
vfatのところにconfig.txtというファイルがあり、ここにkernelとかcmdlineとかが指定できるようだ。

kernelのファイル指定はできることが確認できたが・・・cmdlineがよくわからん。
というのも「init=/sbin/init」と指定しても、initが見つからん、ということでpanicになってしまうからだ。
kernelビルド時のブートオプションにも指定してみたのだが、同じ。
うーむ。

そもそも、kernelにどんなオプションが渡っているかわからない。
Raspberry Piのありがたいところは、起動時にkernelの吐くログもHDMIから出てくれることなのだが、kernelのオプションはスクロールアウトしてるんだかドライバが有効になる前だからか知らんけど、見えない。
GPIOピンにシリアルが出ていたのでPCとつないだのだが、何か出力はされてるんだけど文字になってない。
シリアルの設定がされてないんだか、受信設定が間違ってるんだかよくわからん。ケーブルが適当なので化けてるのかもしれんし。
ともかく、そのルートで調査するのは難しそうだ。

 

というところで止まっている。
Buildrootで動く環境はあるんだから、そこからごっそり削除してbusyboxのみに仕立てるっていうこともできるんだけど、なんかそれだと敗北した気分になってしまうではないか。
仕事でやると、そういう回り道をやる時間がないので、早くできそうな道を選んでしまうのだが、個人でやってるんだからもう少しゆっくりさせてもらおう。

2013/09/08

今までの失敗まとめ (1)

Raspberry Piでいろいろ失敗しているので、メモを残しておこう。
失敗しているのは私なんだけどね。

buildrootのビルドができない!

これは、Androidビルドのために.bashrcに「export CCACHE=1」などという適当なことをやっていたからだ。
Androidはこれでもいいのだが、おそらく普通はccacheコマンドがインストールされていたらCCACHE環境変数に登録する、という使い方をするのだろう。


SDに焼けない!

ビルドが終わると、gamaralはスクリプトファイルを使ってSDカードに焼いてくれる。
が、ext4くらいでエラーが出てしまった。
理由は簡単で、SDを挿したときにLinuxが自動マウントしていたからだった。
umountすることで、ちゃんと焼けた。


eth0がない!

SDを挿して電源を入れると、普通に起動した。
rootアカウントで入ることができる。
さて、ネットは使えるものかどうかと思ったが、eth0は見えない。
うちはDHCP環境なので、udhcpcを直接実行するとeth0が使えるようになった。

/etc/network/interfacesに書けばいけるかと思ったが、そういうわけでもないのか。
rcSみたいな、起動スクリプトに入れ込むのかな?


sshがつながらない!

SD起動すると、ちゃんとHDMIポートにつながったモニタに出力される。
されるのだが、モニタをあっち見たりこっち見たりするのが面倒なので、sshで接続しようとした。
が、パスワードの期限が切れたとかで接続できない。。。

これは、Raspberry Piの時間設定をしていなかったから。
RTCというか、バックアップ電池というか、とにかく起動すると1970年にタイムスリップしてしまう。
手段は問わないので、日時の設定をしないといかんのだ。

とりあえずはdateコマンドで手入力したけど、せっかくなのでntp使って取得したいところだ。
make nconfigでntpを有効にはしたものの、まだ設定の仕方を調べてないので、udhcpcを有効にするところと一緒にやっておこう。

[nfc]最後はSEとLLCPSに落ち着いたりせんだろうか

また飲みながら書くので、適当な話だ。

NFC Forum的な見方で、NFCを見てみるとこうなっている。

http://www.nfc-forum.org/aboutnfc/interop/

  • NFC Card Emulation Mode
  • Peer-toPeer Mode
  • Reader/Writer Mode

今のSuicaみたいなサイバー系や、Edyみたいな金融系は、支払う側からすると、自分がカードをかざして相手に読み取ってもらうReader/Writerモードだ。
あるいはカードがスマホになって、スマホとしてはNFC Card Emulationモードで動作している(相手はReaderモード)というだけだ。

事情に詳しいわけではないのだが、世界的にも同じようなものだと思う。
Card Emulationモードといっても、ソフトで全部まかなっているわけではなく、カードエミュレーションするときにはセキュアエレメントからデータを読み書きする、という状態になってるんだろうと思う。

NFCの静的なタグだと、細かい制御ができないので1カード1会社みたいになるけど、エミュレーションであればソフトでメモリを読む先を変更できるので、マルチアプリケーション(ここのアプリは、取引先みたいなものか)にできるんだろう。

だから、今はセキュアエレメントを持っているところはNFCを押しているし、そうじゃないところはクレジットカードでいいやん、と言ってるんじゃなかろうか。
まあ、そんな単純ではないんだろうけど、要因の一つくらいにはなってるんじゃないかな。

 

なら、ハードでがちがちに決まっているセキュアエレメントをやめよう、ということになるんじゃなかろうか。
セキュリティの担保がハードではできないので、そこが今後の課題になるか。
LLCPSは、そんなところで出てきたと思っている。

いくらNFCの距離が近いものとはいえ、無線である以上、読み取るのは難しくない。
極端な話、13.56MHzの無線を拾い続ければ、あとはビットをずらしながらデータを取りだせばいいだけだ。
つまり、素のデータが危険なのは、NFCだろうとHTTPだろうと一緒だ。

HTTPがSSLかなんかでHTTPSを作ったように、LLCPも暗号化してLLCPSにしようとした、というところだろう。
なので、これからはSEを作ることができないメーカでも、LLCPSによって決済できるようになる時代が来るんじゃないかな、と密かに思っている。
お金の世界はそんなに簡単じゃないんだろうけど、SEがあるだけで決済できるんだったら、HTTPSのようなLLCPSがあることで決済できる世の中であってもおかしくないんじゃなかろうか。

まあ、可能性としてはいいんじゃなかろうか、というところだ。

2013/09/01

NFCの成功ってなんだろう

最近、というか、転職してから精神的にまだ余裕がなく、このサイトも更新が滞っている。
同じ業界なのだけど、自分で手を汚さず動かすよりも、まとめる方の作業になってしまったのだ。
慣れないので、全部に全力を使わないとまだ対応できない。

1年くらいしたら、手の抜きどころがわかって、余裕ができるんじゃないかなー、と思っているのは、気楽すぎだろうか?
とにかくまあ、そんな近況です。
(時間の余裕がない、というよりも、精神的に余裕がなくて「そんなことを調べるくらいだったら」とか思ってしまうだけなんだけどね。)


そんな状況なので、NFCからもずいぶん遠ざかっている。
さっきも記事を書きはしたけど、新規ってよりも、焼き直し程度だ。
過去の資産を使っているだけだ。

そんなわけで、多少は目線が客観的に見られるようなところにいるかもしれない。
で、気持ち的に遠ざかってみてみると、NFCは今年も流行している、という程ではないように思う。
後退している方向ではないが、まだ「及び腰」という感じがしている。
本当に力を入れていいのかどうか?という疑問を持ちながら、無視もできない、という印象だ。


Suicaは成功しているだろうと思う。
Suicaを持ってるわけじゃないし、ふだんは乗り物に乗らないのだけど(歩き通勤)、西鉄バス通勤しているときには、とうとうnimocaを買ったくらい、便利だ。
理由は何だろうか?

  • 乗り物に乗るんだから、乗るだけの金は持っている
  • 利用料金よりも高い切符を買えば問題はないけど、それは腹立たしい
  • きっちりとした額で終わらせたい
  • あと、「金額を調べてる」って姿を人に見られたくない
  • 視力が弱いので、いちいち見てられない

4番目は、めんどくさいのが嫌だとか、田舎者に見られたくないとか理由はありそうだが、要因としては強そうな気がする。
あの、値段を調べるためだけに表を見るのが面倒なのだ。

といいつつ、私は5番目だ。
経路と値段の表が、もう目で追うのがつらい。
往復で万単位を使うこともそうないので、多めに入れておいて使う、というのが手軽だ。

http://www.jreast.co.jp/development/tech/pdf_41/Tech-41-33-36.pdf
上記などを見ると、また違った目線で見られる。
Suicaを他で使わない理由とか(「Suicaって鉄道で使うものだから、日常では使わない」とか)。
電車で便利、という売りがあるが故に、それ以外の用途で使わない要因にもなっているという、面白い現象だ。
それ以外にも「電車用だから、そのときにお金が足りないと困るので使わない」という人もいるんだろう。
オートチャージもできるようだけど、紛失したときのことを考えると、あんまり使いたくない。
じゃあ、Suicaは乗り物専用にしておこう、という考え方なんだろう。

あと、ビッグデータとかも少しあるかもしれない。
最近あった、駅を使用した人の年代とか性別を集計するとか言う、あんな感じのやつ(詳しくなくてすまん)。
嫌な人は嫌なんだろうと思うが、私は「どうでもいいー」っていう人なので、いずれは普通になるんじゃないかと思っている。
たぶん、最初は「データを供給していただける人は割り引きます」みたいな感じで、了承を得るようになるんじゃなかろうか(そのデータも、それはそれで重要なデータだろう)。


それ以外は・・・よくわからん。
というよりも、NFCの成功ってなんだろう?というのが、わからんごとなってきた。

何もかもがNFCになるってことはないだろうし、NFCがまったく消え去ってしまうというのも何となく考えにくい。
一番嫌なのは、ほどほどに普及してるけど広がりそうにない、という状況になることなんじゃないかな。
撤退する要素もなく、撤退もできず、みたいな。
Suicaなどに至っては、撤退という道は既になくなっているように見える(撤退せんでもいいレベルだろうけど)。

あとは、やっぱり、海外でどうなるか、というところか。
NFC-A、特にMIFARE系が多いのは、事実だろう。
でも通信規格上、NFC-Fの424kbpsが一番速いので、P2PなんかはNFC-Fがいいんじゃないかと思う。
NFC-Bはなんかデータアクセスが難しそうなので、セキュリティが強そうな気がする。

そう考えると、棲み分けってのも難しそうだ。
NDEFでデータ統一、という見方もあるけど、用途からすると、セキュリティ対策としてアクセスしづらくしたいというのもあるだろう。

第1段階として、セキュリティなしとしてのアクセス手段は用意した、というところか。
ならば次は、セキュリティのあるアクセス手段が活発になるところか。
一番手を付けやすいのは、LLCP/SNEPのところだろう。
あそこは、各社の利権というか特許というか、そういうのが絡んでなさそうだからだ。
FeliCa StandardやMIFARE Ultralight-Cなんかは、セキュアなアクセスが可能だけど、その方法は公開されていない。
なので、そうじゃないところから規格化されるんじゃなかろうかね、というところだ。


まあ、適当なことしか書かなかったが、そういうのも楽しいものだ。

[nfc]Windows7からSNEPする

やりたいことは、非常に単純だったのだ。
単に、Windows PCからNexus7にURLを送りたいという、ただそれだけ。

いろいろ考えたあげく、PaSoRiのドライバをWinUSBで乗っ取り、libusbxを使って操作してAndroid Beamする、というやり方にした。
標準のドライバじゃないものを使うので、やらない方がよいと思うが、まあできなくはないですよ、というくらいで見てもらえばよいか。

 

PaSoRiはRC-S370/P。
実行環境は、Qt5。
Qtの実行ファイルを動かすのにはどうするのが正当なのかわからなかったので、dllをエラーが出るごとに追加していった。
ソースファイルも全部公開しているので、ライセンス的には大丈夫な気はしているのだが・・・。

https://sites.google.com/site/hiro99ma/home/files/windows/usbtest.zip?attredirects=0&d=1
https://sites.google.com/site/hiro99ma/home/files/windows/usbtest_exe.zip?attredirects=0&d=1

うちはWindows7 64bitなので、ほかで動くかどうかはよくわからんです。


まず、PaSoRiのドライバを標準のものから置き換えないといけない。
WinUSBはWindowsの汎用USBドライバみたいなものなのだが、それを置き換えるのは多少面倒だ。
私は、zadig.exeを使わせていただいている。

コンボボックスからRC-S956のドライバを選ぶのだが、「Options→List All Devices」としないと出てこない。
選んだら、下のドライバ選択から「WinUSB」を選択し、「Replace Driver」のボタンを押す。
そうすると、しばらくしたら成功する(と思う。失敗したことないのでわからん)。

あとは、usbtest.exeを実行し、URLを打ち込んで、Sendボタンを押して、かざせばよいと思う。
あんまりアプリの出来がよくないので、反応が悪かったり、途中で落ちたりするかも。
応答がわるいのは、ポーリングの周期を遅くしているためかもしれんな。


技術的なところは、そんなにない。
もともとlibusbxで動くように作ったNFCライブラリなので、移植はそんなに大変じゃなかった。
といいつつ、時間はかかったんだがね・・・。
Windows8であれば、たぶん標準機能でやれるのだろう(RC-S380必須になるが)。

Chromeとかでタブの同期をすればいいやん、とか言われそうだが、そういうのはあまり使いたくない派なので、こんなまどろっこしいやり方になってしまった。
まあ、libusbxとQtなので、うまくやればMacでもLinuxでもビルドできるんじゃなかろうかね。

WindowsでUSBを簡単に扱うのはなにがよいやら

ときどき、WindowsでUSB機器を扱いたいことがある。
まあ、私の場合はPaSoRiなのだが、バルク転送とかしたいわけだ。

そのとき、どうやるのが一番簡単なのか、まだ決め切れていない。
今のところlibusbを使っているのだが、これを他の人に用意してもらうのは、敷居が高いような気がしている。
敷居が高いと、使ってもらえない、ということになり、それは寂しいと思うのだ。


では、もっと容易そうな環境となると、WinUSBが出てくる。
WinUSB自体は、XPの途中から入ったしくみで、アプリからも制御ができる。
うん、これならよいだろう、とC#から使ってみようとしたが、なかなかいいライブラリがない。

winusbnet - WinUSB .NET wrapper library - Google Project Hosting
WinUsbNet: A managed interface to WinUSB.sys - Home

だいたい、この2つが出てくる。
名前も、大文字小文字が違うだけだ。
だから同じものだろうと思い込んでいたのだが、そうではなかった。

そして困ったことに、どちらもビルドできるサンプルプロジェクトがない。
codeplexの方はサンプルソースはあるが、プロジェクトでは提供されていない。
自分で周りを埋めてしまえばいいんだろうけど・・・手間がかかるのでやりたくない。

デバイスをオープンするところまではできたが、これからまたPaSoRiへのアクセスを移植していくかと思うと、その気力がなくなりそうなことに気付いた。


じゃあ、やはりlibusbに戻るか、と思って探すと、これが出てきた。

LibUsbDotNet C# USB Library | Free software downloads at ...

そもそも、WinUSBを使おうとlibusbを使おうと、標準のPaSoRiドライバを差し替える必要があるので、敷居はどっちにしても高そうだ。
じゃあ、もうlibusbでもいいかもしれん。

NuGetではlibusbのパッケージが見つからないので、自分でインストールすることになる。
(ちなみに、codeplexじゃない版はNuGetにある。他にもFTDIのD2XXインターフェースとかあった。)

じゃあ、libusbにしようか、と思ったが、また考え込んでしまった。
さっきまでは、WinUSBからlibusbへの移植が面倒だとだけ考えていたが、今度はC/C++からC#への変換になるから、むしろそちらの方が面倒だ。
ならば・・・C++/CLIでライブラリにしてしまう、というのがよさそうな気がした。


C++からC++/CLIなら楽だろう、と思ったが、そうではなかった。
CLIになると、^とか、マネージ/アンマネージとか、よく知らない単語が出始めた。

うーん、Windowsでばしばしコーディングするなら覚えるけど、めったに使わないのに勉強するのはめんどくさい・・・。

 

そんなわけで、結局Qtを選択しましたとさ。
めでたしめでたし。