2011/11/30

[llcp]cygwinでlibnfc-llcpはビルドできるだろうか (1)

普段、Windows XPを使っている。
週末やビルドの時にはLinuxを立ち上げ直しているのだが、Windowsでもビルドできるとよい。
libnfcはやったので、libnfc-llcpをやってみよう。

いつも1回でうまく行くことはないので、(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でもう少しがんばるか。
まあ、今週だけだと思うけどね。

2011/11/26

[libnfc]pn53x_TgInitAsTarget

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 add
        abtMifareParams[0] = 0x00;
        abtMifareParams[1] = 0x04;
      } else {
        abtMifareParams[0] = 0x08;
        abtMifareParams[1] = 0x00;
      }

mayu-linux

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

2011/11/25

[libnfc]log4cの出力はlog4crcがあればいいというものでもない

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"」。
じゃあ、両方書けばログが出るんじゃないか?

あたーりー。

2011/11/24

ポーリング間隔

Android携帯電話の消費電力計測をしているところがあった。
http://bs-power-save-project.blogspot.com/2011/11/nfconoff.html

電話用のポーリングは2.5秒間隔、NFCのポーリングは0.4秒間隔、ということになるだろうか。
電話用なのかメールみたいなものなのかはわからんがね。

2011/11/23

[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は有効になってるんだけどなあ。

[libnfc]libnfcとRC-S620/S

LLCPの動作確認をするには、R/Wが2つないとだめだ。
うちにあるのは、パソリと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

$ ./configure --with-drivers='pn532_uart,pn53x_usb' --enable-serial-autoprobe --enable-debug
$ make clean all
$ sudo make install
$ utils/nfc-list
utils/.libs/lt-nfc-list uses libnfc 1.5.1 (r1182M)
libnfc.general - 0 device(s) found using PN53x USB driver
libnfc.driver.pn532_uart - Trying to find PN532 device on serial port: /dev/ttyUSB0 at 115200 bauds.
libnfc.bus.uart - Serial port speed requested to be set to 115200 bauds.
libnfc.chip.pn53x - Diagnose
libnfc.chip.pn53x - Timeout values: 1 s, 0 us
libnfc.bus.uart - TX: 55  55  00  00  00 
libnfc.chip.pn53x - SAMConfiguration
libnfc.chip.pn53x - Timeout values: 1 s, 0 us
libnfc.bus.uart - TX: 00  00  ff  03  fd  d4  14  01  17  00 
libnfc.bus.uart - RX: 00  00  ff  00  ff  00 
libnfc.chip.pn53x - PN53x ACKed
libnfc.bus.uart - RX: 00  00  ff  02  fe 
libnfc.bus.uart - RX: d5  15 
libnfc.bus.uart - RX: 16  00 
libnfc.chip.pn53x - Last command status: Success
libnfc.bus.uart - TX: 00  00  ff  09  f7  d4  00  00  6c  69  62  6e  66  63  be  00 
libnfc.bus.uart - RX: 00  00  ff  00  ff  00 
libnfc.chip.pn53x - PN53x ACKed
libnfc.bus.uart - RX: 00  00  ff  08  f8 
libnfc.bus.uart - RX: d5  01 
libnfc.bus.uart - RX: 6c  69  62  6e  66  63 
libnfc.bus.uart - RX: bc  00 
libnfc.chip.pn53x - Last command status: Success
pn53x_check_communication:
Success
(中略)
libnfc.general - 0 device(s) found using PN532_UART driver
No NFC device found.

いやいや、待ってくれ!
成功しとうやん。
なぜなんだ・・・。


ログを追加してわかったのは、最後に

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版のlibnfcはconfigureがなかった

最新版の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/

教訓。
リリース元のサイトも先に確認しましょう。

[nfc]nfc-toolsをビルドしてみよう

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ができるんじゃなかろうか。
問題は「試すことはできん」というところなんだけどね・・・。

2011/11/22

Expresspay test

ネットワークオペレータ(日本で言うキャリア)のソフトバンクと、セゾンカードのクレジットセゾン、アメリカン・エキスプレスは、大日本印刷とGemaltoが提供するNFC技術を用いて、SIMベースのNFCペイメントをAndroid携帯で試すそうだ。

 

でいいのかな?

http://www.nfcworld.com/2011/11/21/311410/japan-gets-nfc-expresspay-test/#utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+nfcw+%28NFC+World%29

 

3ヶ月は、アメリカン・エキスプレスのExpresspayサービスを試すみたい。

 

SIMベースのNFCって、SIMにSEが載っているだけでなく、NFCチップ自体が載ってるの?
チップはまだしも、アンテナは載らないような気がするから、やはりSEだけなのかしら。
だとしたら、NFCチップとアンテナは本体になくてはならないので、専用の端末を作るのだろうか。
あるいは海外から入手して手を入れるだけだろうか。
テストするっていうくらいだから、数は少ないだろうけどそこそこの数も必要だろうから、入手する方向かな。
んで、それをテスターの人に配って使ってもらう、とかだろうか。

2011/11/21

[felica]うまくいってないけど、ソースを載せよう

ホークスおめでとう!
というわけで(?)、うまくいっていないけどFALP受信ソースを載せておく。
https://sites.google.com/site/hiro99ma/home/windows/FalpRecv.cpp?attredirects=0&d=1

Windowsでの作り方がよくわからんので、そこで間違ってるのかも。
FALPライブラリ側も送受信のためにスレッドを立ち上げるので、アプリ側とメッセージをやりとりするための番号が必要になる。
そのために、RegisterWindowMessage(文字列)を使う。
まず、お互いで文字列を決める。
今回で言えば、アプリ側で文字列を決め、set_falp_target_callback_parameters()でライブラリに文字列を渡す。
そしてお互いがRegisterWindowMessage()に同じ文字列で登録すると、やりとりするための番号が決まる。
これが同じ番号になるのか、別の番号がプロセスごとに割り当てられてOSがなんかうまいこと変換するのかは知らないけどね。
同じ数字になるなら、アプリ側が番号を決めて数字だけを渡せばいいと思うんだけど、何かあるのかな?

2011/11/20

NFCフォルダのファイル

packages/apps/Nfc以下にあるソースに、FireflyRenderThread.javaってのがある。
蛍のことらしいが、NFCとは直接関係なさそうだ。
使っているのは、SendUI.java。
FireflyRenderThreadもSendUIも、NFC関係のものをimportしていないので、UIなのだろう。

こんな感じで、NFCフォルダにあるものすべてがNFCのことをやっているわけではない。


フォルダも増えている(いつと比較してなのか忘れたけど)。

ndefpushは、前からあった。
snepができている。
そして、nxpがある。

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の次世代チップも、そういった広がりを見せてほしいなあ。

[nfc]Android Beamって何だろう?

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は比較的素直なようだ。
よかった。

  1. SNEPでの送信を試みる
  2. だめだったらNDEF Pushする。

こういう流れのようだ。
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先を見に行ったりされると「金がかかるじゃないか!」と抗議しそうだ(お金の問題じゃないけどさ)。

ただ、向かい合わせるだけで送信準備ができるというのはよいな。
そのためにはポーリングを消費電力など気にせずやる、という動作が必要だ。

あ、ポーリングするのが送信側なのか受信側なのかを見るの忘れた。
以前と同じ仕様なら、確かホーム画面でロックされていない場合にはポーリングする、だったと思う。
おそらく、それを引き継いでいるんじゃないかな。

[felica]FALP受信でエラーが起きているようだが、よくわからん

まだまだやってるFALP受信。
何のためにやっているかというと、とりあえずは画像をPCに送りたいというだけ。
うちにはあまりいいデジタルカメラがなく、携帯電話のが一番いい。
それをパソコンに持っていこうとすると、microSDカードに入れて、アジャスタを噛ませてSD R/Wに入れて・・・という手順がいるので、めんどくさい。
USBケーブルを挿すって手もあるけど、せっかくFALPが使えるんならやりたいではないか。


こんな手順で受信を開始している。

  1. initialize_library()
  2. open_reader_writer_auto()
  3. transaction_lock()
  4. ウィンドウ作成
  5. Listen用メッセージ登録
  6. set_falp_target_callback_parameters()
  7. falp_listen()
  8. PeekMessage() & GetMessage()によるメッセージループ

エラーは発生していないのだが、P906iから送信しても携帯電話側でエラーだとみなされている。
ソフトの方は、特に動きがない。

 

falp_dump_log_to_file()でログが取れるのでやっているのだが、開始時にエラーが出る。
出るけど、動いているからまあいいだろう。
このログの見方がよくわからないのだ。

なんとなくこのログは、ライブラリのログと言うよりもドライバのログのような気がする。
ログは1行ごとに時間と種類があり、種類はこんな感じになってるんじゃないかと思う。

  • CALL : ドライバI/Fの呼び出し
  • RETURN : ドライバI/Fからの戻り値
  • FCMD : R/Wに送信したデータ
  • FRES : R/Wから受信したデータ
  • STATE : 状態
  • RWAIT : ? 受信待ち?
  • ERROR : エラー

P906iから送信すると、FRESに値が載ってくるので、何かしら受信はしているようだ。
受信すると、STATEが「Propose待ち状態」になり、RWAITする。
その後、2回受信して、ERRORになるのだ。
ERRORのあとは、STATEが終了になっている。

エラーの種類は書いてあるのだが「その他エラー(code=-204)」。
うーん、わからん。


推測するしかないのだが、受信してエラーとしているのだから、受信データに問題があるのだろう。
想定していないパケットが来た、とか。
アプリにまで通知していないところを見ると、FALPの受信シーケンスとして想定していないものが来た、ということだろうか。

でも、P906iだって製品になっている以上、FALPのCTS試験は通っているはず。
変なものを送信しているってのは考えにくい。

 

もう少し試そうとしたのだが、P906iの電池が切れてしまった。
そして、充電中はiC送信できないということを初めて知った・・・。

falp_listen()のままずっといると、WM_TIMECHANGEが発行された。
うーん。
うーーーーん。


こういう結論に至った。

  • 私は間違っていないか、根本的な考え違いをしている。
  • FALP受信のサンプルができるのを待とう。

わからんものは、わからんのだ。
あきらめよう。

 

やっていて思ったのだが、スマートフォンみたいに自分で対抗機を作ることができるものがないと、面白くない。
自由が全くないので、できることが本当に限られてしまうからだ。
そりゃ、想定していないと言われても仕方ないわなぁ。。。

[c/c++]コーディングをときどき考える

さて、さっきはAPIについて偉そうに書いたが、そういう自分はどうなんだといわれるとつらい。
精神的には「動けばいいやん」派だ。

ただ、昔は自分の書いたソースがそのまま製品になっていたからチェックする人がいなかったんだけど、今は、ソースを納品する、という立場になったので、自然と気にするようになった。

一番嫌なのは、自分のコーディングルールをねじ曲げられるところだ。
もちろん、プロジェクト開始時にルールが適用される前にいろいろ文句をつけるのだが、だいたい「会社ルール」という名目で捨てられる(当たり前)。
わかっていても、ルールを押しつけられるというのはストレスがたまるのもわかっているので、なるべく抵抗する。

でも、だめなのもわかっているので、そのコーディングルールが適用されたときは、他のソースを書くときも同じルールで書くようにしている。
自分のソースとかね。
幸い、複数のプロジェクトを掛け持つことはないので、そこは気にしなくてよい。


本来、そろそろ後継者を育てないといけないのだけど、組み込み専門の会社なわけでもなく、自分の下に後輩が付いているわけでもないとなると、育てる人がいないってことになる。
組み込みって、育つのに時間がかかるから、メーカーみたいなところじゃないと育成できないのよね。
ただ、昔みたいに少人数ではとても開発できなくなってきているので、誰でも開発できるような体制を敷かざるを得ない。
そうなると、細かいところに配慮するような日本的な利点は足かせになってしまう。
人数が増えてグループを分けて作業するようになると、細かい作業ってのはグループ間の連携という作業が発生してしまい、工数が増えてしまう上、バグも出やすくなるからだ。
大陸的な開発をすると、そりゃ元々やってるところには負けるわな。

んで、そういうのはネットで複数の人が開発するようなシステムではさらにやりにくい。
できないわけではないけど、時間がかかるし、めんどくさい。
同じ場所にいて意識を共有しながら作るという作業は、けっこう重要なのだと思うよ。


まとまりがなくなってしまったが、いいたいのは「自分の製品が作りたいなー」ということかな。
独立したいとかそんなのではないけど、よその会社の製品に力を注いでいても人が育たないって状況がやだ。

[felica]FALPのAPI

SDK for NFC Starter Kit beta2。
FALPができるのだが、まだ受信できてない。

それはまあいいとして、ライブラリ実装がなんか不自然なのが気になる。
なんというか、静的解析ツールくらいはかけてからリリースした方がいいと思う。
自分では持っていないから何とも言えないが、見ただけで変なところもあるので、ちょっと書いておく。


felica_basic_lite_s.h

 

L.7
マクロ名の先頭がアンダーバー2つっていうのは、システム側で使用するものなので、普通は避ける
一致しなければ別にいいんだけど。
この辺は間違って覚えている人が多いので、ありがちといえばありがちだ。

 

L.41
Visual C++なら通らないからいいけど、そうでなければコンパイルエラーになると思う。
#elif、だ。
よく知らんが、最近は#else ifなんて構文もあるのか?

 

L.42
Cにはboolがないから定義したのだろうが、せめてtypedefしてほしいところ。
boolのサイズはけっこう処理系依存だと思うけど、unsigned charで大丈夫なのか?
下の方でextern "C"してるから、boolは使わない方がいいと思うんだけどね。
戻り値も定義した方が、ソースとしては一貫性があるだろう。

 


felica_mobile2_lite_s.h

 

L.94
このAPIだけ、他と違って変。
違う人が作ったのかな?

 

L.101
XPは32bit版だけだったけど、それ以外は64bit版もあったような。
APIが違うのはドキュメントに書かなくていいのだろうか・・・。


なんとなくFeliCa関係のソースは結構適当なできばえという印象がある。
動くからそれでいいやん、というのもそれはそれでいいんだけど、金を出して買った方からすると「品管は大丈夫なの?」なんて心配をしてしまう。

だって、ソフト仕様書とヘッダファイルなんて、製品で言えば筐体に当たるものやん。
もう少し気を遣った方がよい。

 

ソフトって、OJTだけでは成長しないので、ちゃんとした教育をしないといけない。
動くソフトとちゃんとしたソフトの差は大きく、やはりそれなりの教育がどうしても必要なのだ。

私も長いこと「動けばいいやん」派だったけど、この歳になってようやくわかってきたと思う。
セミナーとかによく参加させられて、「それなら仕事させてくれー」と上司に反発していたのだけど、悔しいが役に立っている。

ただ、教育を受けてしまうとソフトの考え方が固くなってしまうので、それはそれで面白くない。
なので結局、仕事用のソフトと遊び用のソフト、みたいな作り方をするようになってしまう。

とはいえ、こればっかりは難しいのよねぇ。

2011/11/19

[a4]android-4.0.1_r1のビルドエラーが続くが、Ubuntu 10.04以降はmasterの方がいいらしい

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を落としてやり直しましょう。

・・・・

やり直して、何事もなくビルドが終わることが確認できましたとさ。
めでたしめでたし。

LinuxにAndroid SDKを入れる

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の2重定義なのだけど、Android.mkにはないから、build/coreあたりにあるんだろう。
とりあえずだが、build/core/combo/HOST_linux-x86.mkの56行目をコメントアウトした。

<組み込み>:0:0: 備考: ここが以前の宣言がある位置です<組み込み>:0:0: 備考: ここが以前の宣言がある位置です

といわれるから、デフォルトで有効になったのだろうな。

2011/11/18

[felica]HID ?

http://www.sony.net/Products/felica/business/information/111114.html

英語がさらさらっと読めるといいのだが、あいにくそういう能力はない。。。
ここの最初を読んだだけだと、SONY社とHID社がタブレットなどに向けたNFCリーダを作る、みたいな感じだろうか。
iClass SE、なんて言葉も出てきたので、もうちょっと読まんとわからんな。




全然関係ないけど、タイトルに「[無駄]」って書くのはよくないな。
技術に関係のない無駄話を書いているので見分けたかっただけなのだが、「俺はこういうのは無駄だと思うぜ」と主張しているように見えてしまう。
省略の仕方がまずいなぁ。

2011/11/16

[無駄話]PN544のキット

疲れたときは、よそ様のサイトを見て感想を書こう。

http://www.paymentnavi.com/cardnavi/19274.html
ソフィアシステムズ、大日本印刷、バイテックの3社が共同で「NFC組込開発キット」なるものを発売するらしい。
PaSoRiみたいなやつかなーと思ったら、さにあらず。
PN544だ。
つまり、SEなんかに接続できるやつである。
ほほぅ。

面白いのは、ソフィアシステムズさんは開発ボードを、大日本印刷さんはNFCモジュールを、バイテックさんはNFCチップをそれぞれ供給するらしい。
さて、NFCモジュールとNFCチップの違いは何だろうか?
おそらく、PN544をバイテックさんが供給し、大日本印刷さんはそれを使って無線周りを仕立てるのだろう。
私の持ってる知識からすると、高周波の基板ってのは設計がめんどくさい(という話を聞いた)。
それに、PN544だけでNFCができるわけもなく、アンテナとか電源とか、周辺にいろいろといる。
そこらへんを大日本印刷がやるのだろう。
もし、大日本印刷さんがPN544を直接購入できるようであれば、バイテックさんは絡まなかったかもしれない。
だって、モジュールを作る技術はあるんだから、チップがあれば自分でやるはずだ。
そうなっていないところを見ると、購入ルートがなかったということだろうか。

まあ、どうだっていいのだけどね。
単に事情通っぽいことを書いてみたかっただけで、何の根拠もないことを許してくだされ。

さて、これが販売になったとして、一般人が入手できるようになるだろうか?
ソフィアシステムズさんが入っているので、セット販売っぽくなるのではなかろうか。
既に購入済みだったら、NFCボードだけ買えるとか。
PN544のカタログを見ると、ホストとはUART/SPI/I2Cで接続ができるようだ。
だったら、うまくやればBeagleBoardやPCとも接続できそうだ。

が、買えなさそうな気がする。
SDB-200だって、一般人には買えないではないか。
そう考えると、ねぇ。

謎のJBQ氏

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

[felica]FALPテキスト送信サンプル(P906iへ)

SDK for NFC Starter Kit beta2を使ってFALPサンプルを作っていた私だったが、一番の心配事は動作環境がフィーチャーフォン(P906i)向けということだった。
Androidおサイフケータイを想定しているのに、これは大丈夫なのか??

しかし、想定していないだけで「実害はない」ということだったので、ビルドした実行ファイルとソースファイルの大半を置くことにした。

https://sites.google.com/site/hiro99ma/home/windows

ここの「Falp1.zip」がそうだ。
解凍すると、Falp1.exeとFalpSend.cppが出てくる。
Falp1.exeと同じフォルダに「test.txt」というテキストファイルを作り、中にShift-JISで文章を保存しておく。
そしてPaSoRiをつなぎ、携帯電話をFALP受信できる状態にする。
SDK for NFC Starter Kit beta2に付属のドライバをインストールしておけば、Falp1.exeを実行するとメモとして転送される・・・はず。
開発は、Windows XP SP3(32bit)をVisual Studio 2010 Express C++。
SDKサンプルのFalpSend.cppをちょっと変更しただけだ。
ビルドも、includeパスとlibパスを通して、felica.libを使うようにするだけ。
簡単だ。
簡単と言えば、OBEX変換の簡単な実装もついたお得商品だ。
・・・見てがっかりしないように。

が、最初に「ソースファイルの大半」と書いたように、全部のソースファイルを置いていない。
どの部分かというと、APPIDだ。
P906iというか、携帯電話に対する値がどこにも見つからないのだ。
これは、それこそ「知っている人しか知らない」値なのかもしれん・・・。
各社の携帯電話でiC通信はできるので、公開してくれてもいいと思うんだけどなぁ。
SONYさんやFNさんが管理しそうな値ではないとは思う。

2011/11/15

[felica]SDK for NFC Starter Kit β2版の使用許諾契約

Androidじゃない携帯電話にFALP送信できるサンプルができたので、世のため人のため(?)記事に載せてみようかと思った。

が、待つのだ。
使用許諾契約に違反しないか、確認せねば。

前回、Arduinoライブラリを見ながら移植したときは、よくよく読んで問題ないと思う範囲でやっていたつもりだったが、その解釈がよろしくなかった。
まあ、そのときは後付けで使用範囲が広くなったのだが、今回は慎重にやってみよう。

 

こういうのの読み方を説明してあるサイトはないかなぁ。。。


http://blog.felicalauncher.com/?page_id=3373
全文引用はよくないだろうから、上記リンク先を読んでくだされ。

 

第1条が基本で、それ以外の条文は補足だったり、一般的なことだったりのようだ。

ふむふむ、ホームページに書いてある動作環境かつ指定したターゲットで、指定する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ではない。

しゅうりょー

 

ええっと・・・違反した場合は・・・第5条、解約か。。。

さすがに被害は出していないと思うから、請求は勘弁してもらえるだろう。。。
「まさか "おサイフケータイ" にAndroidかそうでないかが含まれるなんて気付かなかったんです!」
と、弁護するしかあるまい。

2011/11/13

[felica]FALPターゲットになれん

SDK for NFC Starter Kitを使って、FALPターゲットになろうとしているが、うまくいかん。
まあ、うまく行かんシリーズみたいなもんだ。

 

とりあえずねぇ、ドキュメントに間違いがあるのが困る。
前も書いたようにFALPのだけじゃないんだけど、どこまで当てにしていいか迷う。
APIの引数がIN/OUTで間違っているくらいなら、まだなんとか予想できる。
でも、状態遷移が間違っていると、なんだかなぁ。

p.14に、FALP関連APIと動作モードの一覧がある。
R/WをオープンするAPIがあるのだが、それを呼ぶと「FALPモードへ移行」と書いてある。
FALPモードへ移行するとFALPターゲットモードにはなれないから呼んだらいかんなー、と思ったら、呼ばないとFALPターゲットになれない。

などなど。

 

まあ、それはやってみればわかるからいいんだけど、うまく行かない理由がまだわからん。
ログが取れるのでやってみたけど、ログを見ても意味がわからん・・・。
falp_listen()はうまくいくけど、Windowメッセージがうまくさばけていないのか、間違っているのか・・・。

 

今日はこの程度までだな。

[felica]FALPのサンプルをシーケンス図に落とす

P906iに向けてvNoteデータを送ろうとしているが、うまくいかん。
よく考えると、OBEXはデータだけじゃだめで、シーケンスをちゃんと動かさなくてはならない。
となると、今のFalpSendサンプルではちゃんと動かないだろう。
改造するために、どういう動きをしているのか把握せねば。


    FalpSend

 

astah* communityで作ったんだけど、でかいなぁ。。。
まあ、いいや。
ライブラリの中がどうなっているかはわからないけど、まあ大きくは間違ってないだろう。


これをOBEX CONNとOBEX DISCで挟んでOBEX PUTすると、ちゃんとvNoteが携帯電話に送ることができた。

 

OBEXデータを作る関数は作ってたんだけどなー、と探しているが、見つからん。
もったいないなぁ。

2011/11/12

[無駄]FALPの使い方を考える

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が対向にならないと通信できないから、意味はないか。。。

[felica]FALPのサンプルを動かす

http://blog.felicalauncher.com/?p=3639

 

SDK for NFC Starter Kit β2にはFALPのサンプルソースがあったので、動かしてみた。

うちの環境

  • Windows XP SP3 32bit
  • Visual Studio 2010 Express C++
  • PaSoRi RC-S370
  • [受け側]DoCoMo P906i

 

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データを送ってないからだな。
なので、あとは送信データだけの問題で済みそうだ。

 

このデータでスマートフォンとはやりとりできるようなので、あっちは結構自由度が高そうだ。
持っていれば試すところだが、持っていないので試せない。
携帯電話はあまり好きではないので、買い替える気もないし、壊れて買い替えるとしても同じような機種にするだろうなぁ。

[win]拡張子の関連づけを取り戻せ

Windowsは、嫌いではない。
Microsoftも、そんなに嫌いではない。
Visual Studioも嫌いになるほどには使ってはいないのだが、1点ものすごく嫌いなことがある。

それは、インストールしただけで拡張子の関連づけを勝手に代えてしまうことだ。
せっかくテキストエディタに割り振っていたものを奪い取られるので、その腹立たしさは並ならぬものである。
そしてサービスパックを当てたら当てたで、また奪い戻される。
さっき奪われた。。。

 

えーい、ならば取り戻すまでよ。

というわけで、こんなバッチファイルを作成した。

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]FeliCa Lite-S

珍しく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さんに許可を得る必要はなく、安く実現できるのが嬉しい(確か、毎年数十万円必要だったような気がする)。
地域通貨みたいなものができると面白かろう。


全然関係ない話だが、説明文に出てくる「シングルジャーニーチケット」が気になった。
どうやら、再利用可能な1回乗車券、というものらしい。
今だと発券機にお金を入れると、紙の券が出てくる。
紙だと、使い終わったら捨てるしかない。
だから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

 

でも「シングル」と言い切っているところをみると、チャージするというようなイメージよりも、その料金区間を1回だけ乗ることができる、という使い方になるような気がする。
FeliCa Liteではできなかったことだな。

2011/11/11

[felica]CXD2235AGG

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になってた名残だろうか。

2011/11/09

[felica]FALPも使えるPC向けライブラリ

昨日、FeliCa Developers' Blogで見逃していた記事があった。

http://blog.felicalauncher.com/?p=3639

なな、なんと!
FALPがPCからでも使えるようになるライブラリが入ったのだ。

わしが生きている間にこれが実現するとは(オーバー)。


ちょっと実装してみる時間が取れないのが悔しいところだ。
まあ、FALP送信だけなら自前ライブラリでもやれるので、まだいいんだけどね。

 

ドキュメントを眺めていて気になったのが、structure_device_information。
どういうときに使うのか知らないけど、device_info_typeの中に「ワイヤレスキーボード」がある。
それ以外は、PaSoRiの機種名っぽいのに。
ワイヤレスキーボードでPaSoRiつきがあるのかな?
タイムアウト時間も、ワイヤレスキーボードが長めになってるみたいだし。

 

まあ、いい。
使ってみればわかることだ。

[c++11]autoってのがあるんだ

発端は、この記事であった。

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チェックに対して答を与えてくれるものかもしれない。
今日は読んでないのだけど、早く読んでしまおう。

2011/11/07

[boost]リンクの順番か・・・

cygwinで、同じソースをビルドしてみた。

$ g++ -o tst -lboost_regex-mt regex.cpp

これならできるだろう・・・できない。
やはりリンクエラーになる。

ふっと思い立って、こうしてみた。

$ g++ -o tst regex.cpp -lboost_regex-mt

あ、通った。

Ubuntuに戻って、同じことをしてみた。
・・・通る。
そういうことか・・・・。

つまり、do_assign()はヘッダにあるけれども、やはりライブラリが必要なのだ。
nmで確認したが、do_assign()は「U(ndefined)」のままだった。
shared libraryでリンクされるから、そのままになっているのだろう。
-staticで静的にリンクさせて確認しようとしたが、あれやこれや無いと言われたので、やめた。

gccの場合、順番にリンクするんだったと思う。
標準ライブラリなんかは、書かなくても自動でリンクするんだけど、あれは一番最後に追加されていたんだったはず。


んで、一方のmayu。
Makefile.inを書き換えれば済むかと思ったけど、うまくいかん。

$ LIBS=-lboost_regex ./configure
$ make
$ sudo make install


Makefileを見ると、リンクの最後に$(LIBS)を見ていたのだ。
逃げた私を許して・・・。

[ubuntu]結局、xubuntuにした

$ sudo apt-get install xubuntu-desktop

 

そんな感じでやった。
うん、確かにgnome2に近い。

あとはboostの件が解決すれば、環境周りは片付くんだけどなぁ。。。

InstallShieldのアップデートを削除

http://kb.flexerasoftware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q111106&sliceId=1&docTypeID=DT_HOWTO_1_1&dialogID=91533023&stateId=0%200%2091525880

ときどき出てきては、異常終了するので正式に消したかったのだ。
でも、Program Files\Common\InstallShield\UpdateServiceにはファイルが残ってるなぁ。
まあ、様子を見てみよう。

2011/11/06

[boost]regexのリンクがうまくいかん

うまくいかんシリーズ。
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しかないんだよなぁ。
まあ、今日はこの辺にしておこう。

[ubuntu]Ubuntu 11.10にして、よくわからんごとなった

昨日までUbuntu 11.04を使っていたが、ふっと思いついて11.10にアップデートした。
まあ、新しもの好きってだけかもしれんが。

 

そしたら・・・いろいろとわからんごとなった。
まず、Unityってのになった。
11.04にもあったけど、gnomeもあったのでそっちを使っていたのだ。
慣れようとがんばったけど、そもそもUbuntuってウィンドウシステムを変更できるんだから、無理する必要はないよな・・・。
そんなわけで、gnomeをインストールした。

したのはいいんだけど、前と違う。
なんか、日付が上部バーの中央に出てくる・・・。
上部バーにパネルが置けない・・・。

 

それはまだいい。
困ったのは、mayuだ。
キーバインド変更のためにmayuを使っていたのだが、ビルドが通らなくなった。
libboost_regexのリンクがうまくいってないように見える。
しかたないのでboostのソースファイルからビルドしたけど、まだだめ。
シンプルなサンプルを作って、boost側なのかmayu側なのかの切り分けをせねば。
とはいえ、11.04のときにはビルドできてたんだけどな・・・。

 

なんやかんやで、アップデートせんのきゃよかったと思った私であった。
こうやってだんだん新しいものに手を出さなくなっていくんだろうな・・・。

2011/11/05

[libnfc]libnfc-llcpをビルドしてみよう

さて、ではlibnfc-llcpをビルドしてみよう。
configureがなかったのでどうしていいかわからんかったが、探すとこうやるみたいだ。

http://www.libnfc.org/community/topic/467/solved-compiling-libnfcllcp-under-linux-does-not-work-correctly/

$ autoreconf -vis
Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 196.
Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
configure.ac:8: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

よくわからんが、libtoolってのがなさそうだ。

$ sudo apt-get install libtool
$ autoreconf -vis
$ ./configure
$ make
$ sudo make install

なんかできた。

examplesを見ると、nexus-get-tag、という実行ファイルができている。
何も考えずに実行。

$ ./nexus-get-tag
引数 -o がない、とかなんとか

$ sudo ./nexus-get-tag -o test.dat
lt-nexus-get-tag: No NFC device found

うーん、sudoでもだめなのか。


ここでNFCデバイスの有無を確認しているのは、nfc_list_devices()という関数。
その呼び出し方は、nfc-pollもnexus-get-tagも同じだ。
んで、さっき動いたnfc-pollも同じことになった。

うーむ。

psで見ると、kworkerがいっぱいある。
これかい?

[libnfc]Ubuntuではすんなり動く

MinGW64環境で動かせたlibnfc(のPN53x USB版)。
Linuxだとどうだろう?
うちのUtunbu11.04(64bit)で試した。
$ ./configure --with-drivers=pn53x_usb,pn532_uart
$ make
$ sudo make install

特に問題なし。
では、パソリをつないで・・・。
$ cd examples
$ ./nfc-poll
/home/xxx/libnfc/libnfc-1.5.1/examples/.libs/lt-nfc-poll uses libnfc 1.5.1 (r1175)
No NFC device found.

あら。
$ sudo ./nfc-poll
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)
FeliCa (212 kbps) target:
        ID (NFCID2): xx  xx  xx  xx  xx  xx  xx  xx 
    Parameter (PAD): yy  yy  yy  yy  yy  yy  yy  yy 
   System Code (SC): zz  zz
 
そういうことですか。
まあ、特に問題なく動くことがわかった。
なので、まずLinuxでパソリを動かすなら、libnfcがいいんじゃないかと思う。

RC-S620/SをUART-USB変換モジュールに接続

いつかやろう、ではだめだ。
というわけで、RC-S620/SをUART-USB変換モジュールに接続した。

RC-S620/S
http://www.switch-science.com/products/detail.php?product_id=353

ピッチ変換
http://www.aitendo.co.jp/product/2202

UART-USB変換モジュール
http://www.aitendo.co.jp/product/2890

 

ピッチ変換基板は在庫無しのようなので、スイッチサイエンス社から買うのがよかろう。
http://www.switch-science.com/products/detail.php?product_id=725

これを買っていたら、半田付けしないでブレッドボードを使った方がすっきりしそうだ。


SANY0001

接続は、特に説明するほどのものではない。
電源は3.3Vの方を使った。テスタでUART-USB変換モジュールのTXD電圧を測ると3.3Vくらいだったからだ。
あとは、RC-S620/Sとクロスで接続するだけ。
すごく簡単。

 

なんだけど、ピッチ変換基板に書いてあるピンの並びをそのまま使うと、RC-S620/Sとは順序が逆になってしまう。
まあ、前壊したのはそのせいなんだけどね・・・。
今回は3回くらいテスタで接続確認をした。

それでも怖かったので、パソコンとつなぎつなぎ確認。
自作のRC-S956ライブラリをCOMポート接続で動かせたので、OKだ。

 

そろそろ、これはケースに入れたくなってきたな。
パソコンで遊ぶ分にはPaSoRiでもいいんだけど、UARTで使えるってのは組込み機器としてはありがたい。


あと、うちにはFeliCa Plugがある。
この子は、SPI接続みたいだ。
なので、パソコンからの接続はあまりやりたくない(やるならFTDIの変換モジュールを買うのか?)。

載せるなら、小さい組込み基板がよかろう。
なぜ「小さい」かというと、FeliCa Plugが小さいからだ。
せっかくだから、小さくまとめたくなるではないか。

そうなると、BeagleBoardは大きすぎる。
(余談だが、BeagleBoardのUARTで未使用のものは1.8Vくらいなので、ちょっとRC-S620/Sはつなげにくい。)
CQ出版社のInterface誌付録の基板がいくつかあるから、それが使えそうだ。

2011/11/03

[nfc]NFCID3とNFCID2の関係を再考

以前、「NFCID3とNFCID2の関係」という記事を書いていた。

http://hiro99ma.blogspot.com/2011/02/nfcnfcid3nfcid2.html

NFC-DEPで使うので読み返したのだが、考察が中途半端だ。

「NFCID2(IDm)の先頭8byteと同じ」というのはよい。
しかし、NFCID3は10byteある。
残りの2byteはどうしたらいいのだ?


まず、上記の英文を引用しよう。
「NFCForum-TS-DigitalProtocol-1.0」だ。

14.6.2.1
If the Initiator is using NFC-F Technology, the Initiator MUST fill Byte 3 to Byte 10 of ATR_REQ with NFCID2 of the Target it wants to address.

これはNFC-FでのATR_REQパケットの説明で、3~12バイト目にはNFCID3が入る構成になっている。

おや、続きがある。

Byte 11 to Byte 12 of ATR_REQ MAY be filled with Any Value.

ああそうですか。
なんでもいいのね。

なお、NFC-DEPで使用するプロトコルは以下の5つである。

  • ATR_REQ/ATR_RES
  • PSL_REQ/PSL_RES
  • DEP_REQ/DEP_RES
  • DSL_REQ/DSL_RES
  • RLS_REQ/RLS_RES

NFC-Fのときはそうだが、NFC-AでもNFC-DEPは使うことができる。
そのときのNFCID3については記載が見つからない。

ってことは、NFC-Fの場合にはNFCID2(IDm)だけあればよく、NFC-Aの場合には別個にNFCID3を持たねばならないということか。
まあ、同じようにNFCID1から作っても悪くはないということなのだろうかね。

[libnfc]今回インストールしたもの

備忘録として、どこからダウンロードしたかを残しておこう。
なお、うちはWindows XP SP3 (32bit)である。

 

libnfc 1.5.1 : http://www.libnfc.org/documentation/introduction

http://code.google.com/p/libnfc/downloads/list

http://code.google.com/p/libnfc/downloads/detail?name=libnfc-1.5.1.tar.gz&can=2&q=

 

cmake 2.8.6 : http://www.cmake.org/

http://www.cmake.org/cmake/resources/software.html

http://www.cmake.org/files/v2.8/cmake-2.8.6-win32-x86.exe

 

LibUSB 1.2.5.0 : http://sourceforge.net/apps/trac/libusb-win32/wiki

http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/

http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.5.0/libusb-win32-bin-1.2.5.0.zip/download

 

TDM-GCC 4.6.1:

http://sourceforge.net/projects/tdm-gcc/files/

http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm-gcc-4.6.1.exe/download


さて、ビルドも通ったことだし、次はNFC-DEPか。
実はサンプルとして、nfc-dep-initiatorとnfc-dep-targetというものがある。
名前からするに、NFC-DEPしてくれそうではないか。

試したいところだが・・・PaSoRiは1台しか持っていない。
RC-S620/Sがあるんだけど、まだ動くように仕立ててない。
なぜ仕立ててないかというと・・・1つ前に買ったRC-S620/Sを壊したのがショックだったからだ。
引き続いて起こした、A500のフレキ切断もそれを補強してしまっている。
また、また壊すのでは・・・。

 

しかし、破壊なきところに創造なしというではないか。
それに、さんざん壊したんだから、もう大丈夫だろう。

 

仕立てたとして、今度はUARTで操作しないといけない。
まあ、USB2つだとどうせ認識できないだろうから、それでいいか。

[libnfc]TDM-GCCでビルドするとうまくいった

libnfc-1.5.1を解凍すると、README-Windows.txtというファイルがある。
これを読みながらやってみた。

最初は素直にMinGWとLibUSB 1.2.5をインストールしたのだがどうもうまくいかん。
しかし本当に「素直に」やるならば、MinGWではなくて、テキストの一番下にリンクがあるTDM-GCCというものを使うやり方になるのだった。

 

cmake-guiで、ビルドしたいpn53x_usbドライバを指定してconfigure。
なんかエラーが出たけど、もう一度configure。
LibUSBのincludeとlibを指定してなかったのでエラー→指定してconfigure。
そうすると、通った。

あとは書いてあるとおりに、mingw32-make。
こちらはwarningは出るけれども、最後まで通った。


examplesディレクトリにexeがあるので、よくわからないままnfc-poll.exeを実行。
・・・libnfc.dllがない、と。
どっかパスが通る場所にlibnfc.dllを置いて実行。
・・・NFCデバイスがない、と。

LibUSBのドライバを正しくインストールしていないためだった。
LibUSBからダウンロードしたファイルを解凍すると、binの中にinf-wizard.exeがある。
それを実行する前にlibusb-win32-bin-README.txtを読むと、dllのファイル名を変更せよとある。
なので、それに従って名前を変え、inf-wizard.exeを起動。
PaSoRiを選択したらinfができ、そのままインストールまで実行できる。
インストールすると、デバイスマネージャの「libusb-win32 devices」の下にPaSoRiが出てくる。

zadigで最初はやってたのだが、それではだめなようだ。
一度インストールしてしまえば、install-filter-win.exeが使えたような気がするが、まあいいや。

 

この状態でPaSoRiの上にMifare Standardカードを置いて、nfc-poll.exeを実行。

nfc-poll uses libnfc 1.5.1
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 zd modulations)
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04
       UID (NFCID1): 1e  63  b2  53
      SAK (SEL_RES): 08

ふむ、動いていそうだ。
FeliCa Liteカードでもやってみたが、ちゃんとIDmなどが取れている。

[libnfc]cygwinでビルドできるか?

libnfcがcygwinでビルドできるかやってみた。

まずはconfigure。
・・・だめだ。
gcc自身がエラーを出しているっぽい。
gcc4.5は早すぎたか・・・。

 

$ set-gcc-default-3.sh
$ ./configure --with-drivers=pn53x_usb --with-libusb-win32 --enable-debug
$ make

uart_posix.c:58:6: #error "Can't determine serial string for your system"

あー、uart.cのなかで、_WIN32が定義されていたらuart_win32.cをincludeするのか。
他にもマクロ定義があるかも・・・と思うと、時間を無駄にしたくない私は指示通りにMinGWを使うことにした。

cygmpfr-4.dllが見つからん場合は、libmpfr4をインストール

cygwinの話だ。
gccでビルドすると、こんなエラーが出た。
/usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared libraries: cygmpfr-4.dll: cannot open shared object file: No such file or directory
見つからんらしい。

ネット検索すると、libmpfr4パッケージをインストールすればいいらしい。
ふーん。
カテゴリーは「Libs」。
説明は「A library for multiple-precision floationg-point arithmatic with exact rounding」。
単にmainしかない関数なんだけど、gcc4のリンカが指定しているってことかな。
それなら自動的にインストールしてほしいものだが(ぶつぶつ)。

ぶつぶつ言っても仕方ないので、インストールしてコンパイル。
うん、よさそうだ。

2011/11/01

[libnfc]まずlibnfcより始めよ

libnfcには、pn53xドライバがある。
ソースを見ると、PaSoRiもいけるみたいだ。

なら、まずlibnfcから始めようかね。

 

しかし、LLCPを使いたいがためにライブラリを使うのもなんだかなー、という気がしている。
仕事でやるわけじゃないんだから、自分でLLCP実装してもいいんじゃないの、とか。

そんな心の声が出てくるまでは、libnfcを動かしてみることにしよう。