2011/12/30

[rcs620s]RC-S620/SでNFC-DEPする

もうすぐ実家に帰るので、最後に書き残しておこう。
RC-S620/SとPaSoRiでNFC-DEPしていたので、そのコードを。

・・・と思ったが、あまり本体は変わっていないように思う。
Resetコマンドの使い方を間違えていたので、そこを修正したというところだ。
以前、終わらせ方がわからん、という記事を書いたが、Resetできてなかったのだろう。

githubではなく、assemblaを使ってます。
assemblaはprivateが使えるので、書きかけのコードでも気にせず置けるところがありがたい。
まあ、誰もアクセスしてないだろうから気にしすぎなんだけどね。

https://www.assembla.com/code/rcs620s/git/nodes

2011/12/26

[llcp]LLCPのシーケンスを描こうとしたが難儀する

libnfcとlibnfc-llcpを使ったLLCPでAndroid Beamを動かそう、などと思っていた。
R/Wは、PaSoRiやRC-S620/Sを想定(それしか持っていない)。
libnfc-llcpがどう動くのが正解なのかわからないので、めんどくさくなってきた。
おそらく、オープンソースでPaSoRiをつかったLLCPをしようとするならば、nfcpyがいいだろう。
libnfcを介さず直接libusb(PyUSB?)を操作するし、なんといってもRC-S956をサポートしている。
RC-S330で動いたと言うことだし、NexusSとNPPできたとあるので、まあ大丈夫じゃないんかね。

しかし、私は自前で実装しようかと思う。
限定的であれば、そこまで大変なことにはならないんじゃないかい?
パフォーマンスとかそんなに気にしないし、そもそもAndroid Beamできそうな端末も持ってないので、急いで作ったとしても確認できない。
(それを言うと、完成させたとしても確認できないがね・・・。)



NFC ForumのLLCP 1.1を読んで、とりあえずシーケンスだけでもひっぱってみようとした。
しかしまあ、ネットワークの知識がないせいか、英語の知識がないせいか、何をいってるのかわからん。
せめて図があればよかったのだが、プロトコルの説明以外で図がない。
まいった・・・。
一般的なLLCの勉強をしつつ、一部だけ引っ張ってみた。
実装したわけでもなんでもないので、間違ってるかもしれん(まあ、間違ってるだろう)。
地道に引っ張っていきますかね。
https://sites.google.com/site/hiro99ma/home/experiment/snepunit/llcp

2011/12/18

[felica]Resetコマンドの使い方を間違えていた

DEP後、RC-S620/SやRC-S370をあれこれやっても、DEPを再開できなかった。
Resetコマンドを出しても戻らないので、なんか別のことがあるんだろう、くらいに考えていた。

PN533にはResetコマンドはなく、同じ数字が別のコマンドとして存在する。
ResetコマンドはRC-S956専用コマンドなのだ。
そして忘れていたが、RC-S620/Sの簡易コマンド仕様書にはResetコマンドのことが記載されている。

 

どうせ他のコマンドとあんまり変わらんだろうと考えていたのだが、そんなことはなかった。
いやいや、仕様書は確認しないと、と常々いっているのに、またこれだ。
確認不足でしたわ。

[libnfc]1.5 new apiはまだビルドが通らない

Ubuntu11.10でしか試していないが、libnfc-1.5-new-apiはまだビルドが通らない。
nfc-internal.hの扱いをどうするつもりなのかがよくわからんので、とりあえず解決させてみる、という気にならなかった。
まあ、急ぐ必要はないんだけどね。

 

RC-S956用のドライバをPN53xとは別に作った方がいいんだろうけど、追加するにはconfigureとかから変更していかないといかんだろうから、めんどくさい。
やっていないので「やれない」とはいわないのがずるいところだ。
当面は、1.5.1に対して追加していきましょうかね。

Accessory Modeが動かんというのは、VIDのせいじゃなかろうかね

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に載ってた値なので、よくわからん。

android-4.0.3_r1もUbuntu11.10でビルドできないことだよ

タイトル通りだ。

エラーになって終わるのだが、その理由はwarningをerror扱いにするオプションが指定されているからだ。
しかしそこを解除しても、4.0.1のときは他の原因でエラーがいくつも発生した。
修正箇所は、他の人がブログに書いているので調べてみるとよかろう。

masterでビルドできるんならいいや、と思ったが、さっきsyncしてmakeすると、mesa3dでコンパイルエラーが出た。
まあ、まだ使ってないからいいや。

[nfc]今年のまとめ

来週やるかどうかわからんので、気が向いたときにまとめをやっておこう。

どうやら、このブログに移ってきたのは、今年のことのようだ
2月1日である。
2月2日には、「LLC PDU」などという記事を出しているところから、あれからずっとLLCPのことを考えているようだ。
もう10ヶ月以上経つが、まだLLCPできてない。
できてないというよりも、LLCPを自力で実装しようと考えてないから、まあ・・・いいとするか。

2月は43件の投稿。
多いなー、と思ったが、だいたい毎月そんなもんのようだ。
連休の前月は少なめなのかもしれんが、毎日投稿しているわけでもないと思うと、週末にけっこう出しているようだ。

3月は、最初ちょろちょろDEPして、間にカメラなんてものを挟んでいる。
BeagleBoardに、USBカメラを動かそうとしていたようだ。
うちにあるUSBカメラのI2Cあたりで、待ち時間を入れたとかなんとかした記憶がある。
その影響か、JNIをやったりしている。
NativeActivityが出たので「Javaじゃなくてもアプリができるのかも」と思っていたのかもしれん。
アプリで楽をしたい私は、結局Javaしかないことがわかったところだ。

4月は、FALPなんてやってる。
NFC Forumの分類としては、NFC用途は3種類ある。
その中でも、やはりPeer to Peerの通信が一番面白いし、用途が広いと感じているようだ。
そして、PaSoRi RC-S370をターゲットにするなどして、R/Wコマンドに興味を示している。
ここら辺から、深みにはまっているように思う。

そして最多の5月。
OTGに興味を示している。
AndroidからUSBで(逆だな、USBでAndroid機器を、だ)操作できるAccessory Modeができたからだろう。
機器を操作したい私としては、USB Host機能を持つ3.1以上じゃないとどうでもよくなったみたいだ。
kernelとの関係や、USBプロトコルなどを見ているので、結構濃いことをやってたようだ。

6月は、あれやこれや。
Accessory Modeや、Qt、Windows USBやNFCの規約。
雨が多いせいかしら?

7月は、結構変なことをしている。
「かざしてログオン」をだます、というのは、私としては大きな分岐点だった。
NFCといっても、結局のところ通信の一種でしかない、という当たり前の結論を得たのだ。
そして、RC-S620/Sの簡易仕様が出てきた。

8月は、PaSoRiのアプリを作ってMarketに出したりしている。
9月にかけて、FeliCa Liteの片側認証を実装している。
なんというか、「わかってきた」というところだ。



10月はLLCPの実装を自分ではやらず、任せてしまおうと思っているみたいだ。
libnfcなどの、オープンソースプロジェクトを探している。
私らしくないような、私らしいような。

SONYのSDKも気にしてはいるものの、先にP2Pとして運用されていたFALPがNFC標準になっていない以上、どうすることもできない。
そう、技術は最初に作っていたので、間違いなく研究されていると思う。
DEPよりもFALPは先にできていたはずなのだ(たしか)。

FALPが普及しなかったのをSONYのせいにするのは、ちょっと酷だろう。
私としては、第2のTRON、みたいなことになったんじゃないかと何となく思っている(根拠無し)。
14443に含まれなかったのは、かなり痛い。
しかし、18092でDEPの標準としてNFC-Fも入っているのは、大きい。
携帯電話内部に情報を押し込めるのであれば、デバイスレベルの技術が左右してくる。
今やってる、SEを個別に置くのかSWPでSIMに置くのかとか、そんなの。
しかしネットワークとして外に出ていくとなれば、「どうせ外に出るやん」という考え方になる。
本体内にセキュリティをしっかりかけていても、お金の情報は外にあるので、その経路はさらされてしまうのだ。
内部を操作されてデータを書き換えられるのはまずいけれども、ネットワークでそれができてしまうと危険の比率がまったく異なる。
これは、SEがSIMにあろうと別にあろうと、ネットワーク上の問題だからどうしようもない。
SONY/FNがやってるその辺を、Googleが覚悟してやってるのだろうか、というのは気になる。
正直なところ、あんまり考えきれてないんじゃないかなー、という気がしている。
これもまた、証拠無しの印象だけなので、聞き流しておくれ。

さて、来年のことを考えよう。
PN533とRC-S956の違いがnfcpyでわかってきたので、制御はできそうに思う。
libnfcとlibnfc-llcpが動けば、Android Beamもできそうだ。
ただ・・・うちでは動作確認できない。
確認できないので、やっても面白くない。
面白くないなら、やりたくない。
そこをどうするか決めるのが、最初の目標ですかね。

2011/12/17

[dep]InJumpForDEPを受けとれば、DEPになるのだろう

nfcpyの情報を元に実装してみた。
うん、GetGeneralStatusの特定バイトを読むと、DEPと思われる値が取得できた。
InJumpForDEPを投げていないときには別の値だったし、FALPでも別の値だった。


ということで、InJumpForDEPを受けとれば、TgInitAsTargetでもDEPになると考えて良かろう。
DEP_REQがトリガになるのかな?


大きな問題は解決したが、細かいのは残る。

弱っているのは、InJumpForDEPした側のR/Wを終わらせた後、再度初期化処理を行うとエラーになるのだ。
初期化時にいくつかコマンドを投げているのだが、nfcpyに載っていた初期化にさしかかるとエラーになる。
うーん、何しているコマンドなんだか・・・。
電源ON後に1回しかできないコマンド、とかならいいんだけど、戻り値だけではわからん。

なんか間違えてるかなぁ。。

[dep]nfcpyを読む

またまた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のソースは初めて読んでみたが、案外わかりやすい。
スクリプト系は苦手なので拒絶しがちなのだが、食わず嫌いはいかんな。

2011/12/16

[adk]FeliCa PlugをADKで接続する記事(だと思う)

英語版のブログに、こんな記事があった。

 

How to control the NFC Dynamic Tag with an Android Tablet

http://blog.felicalauncher.com/en/?p=482

 

FeliCa Developers' Blogの英訳だけと思っていたけど、よく見ていくとそういうわけでもない。
この記事は、日本版にはないし。

ADKなんて、けっこう日本でもメジャーな方だと思うけど、何かあるのかしら?
Arduinoとか持ってないから気にしたことがなかったのだけど・・・。

 

うちにも、USBホストになることができるものはいくつもあるので、あとはプロトコルさえ実装してしまえばA500なんかをADK(アクセサリ側)として動かせるんじゃないかな、と思う。
そういえば、A500でADKできないって記事を読んだことがあるのだが、なんだろう?
AccessoryChatは動いたような記憶があるのだが・・・。
遠い記憶なので、あんまりあてにならんな。

[libnfc]Diagnoseは実行されていなかった

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とはフォーマットが異なりそうだ、というくらいにしておこう。

2011/12/13

PN532とPN533ですら少し違う

「felica dep」などで検索しても、ほしい情報が出てこない。
そんな中、PN532のユーザーズマニュアルが出てきた。
RC-S956も、こんな感じで出てきたらいいのに・・・。

しかし考えてみれば、ここ最近のFeliCaに関する情報公開は、どんどん広がっている。
実にすばらしいことだ。
最近では、個人利用限定とは言えPaSoRiを操作できるライブラリを公開したり、Android向けの開発環境を無料で提供したりと、かなりの勢いで公開されていっている。
公開されることにより、使う人が増え、情報が増える。
いい流れができてきたので、どんどん進んでほしい。


で、PN532とPN533だが、パラメータがちょこちょこ違う。
全部見たわけではないが、PN533の方が設定が減ったように見える。

RC-S330とRC-S370は、果たして同じなのだろうか?
同じRC-S956とはいえ、さらに細かいリビジョンがあったりしたらどうしよう。

 

とかいろいろ考えようとしたが、風邪っぽいのでやめた。

2011/12/12

PollとListen、ActiveとPassive

鳥頭っぽくていかんが、またわからなくなってきた。

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では動作しなくなってたりするのかしら。

2011/12/11

RC-S956でDEPはできるはず

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]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の自動検索が邪魔をして、2台接続での確認が難しい。
まずは指定したデバイスを使用するような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とみなすようにした。
そしたら、一応終了した。そらそうだな。

うーん、これからどう進めたものか・・・。

LOCAL_DEX_PREOPT := false

NFCのON/OFFをするAppWidgetが作れないだろうか?と思ったので、試している。
EjectSDも動いたんだから、なんとかならんかなぁ。

適当に作ってadb installすると「」というエラーになった。
何かと思ったが、最近ではapkとodexの2つファイルができるらしい。
うーむ。

いろいろ調べたところ、Android.mkに

LOCAL_DEX_PREOPT := false

という行を追加すると、apkだけになるみたいだ。
実際に、なりました。

mmでビルドするときだけかもしれんけど、覚えておいて損はあるまい。


肝心のON/OFFするやつだが、調べると難しいみたいだ。
パーミッションが普通のアプリからは取れないみたい。
NFC以外も巻き込んでいいなら、AirplaneモードにすればOFFになるようだが、それだとなぁ。

Androidの「NFC OFF」がハードレベルなのかソフトレベルなのかは気になるところ。
PN544の仕様は知らないのだけど、だいたい

  • 電源OFF
  • アイドル状態
  • 動作中
  • 無線送受信中

くらいの状態があると思う。
下に行くに従って、消費電力が大きくなる。
NFC OFFにしたときが「電源OFF」なのか「アイドル状態」なのか。
使わんのやけん電源OFFしたらいいやん、と思うかもしれんが、そうするとも限らん。
libnfc-nxpでもそこまでは書いてないようなので、kernel側にあるのだろうか。

まあ、端末を持ってないから追求しないけどね。

2011/12/10

二重署名できるときとできないときの差がわからん

EjectSDというAndroidアプリをマーケットに置いている。
このアプリは、アップするときに二重署名になっている。
二重署名、というのは、すでに署名済みのjarファイルに、別の署名をしたものだ。

Androidでよくある質問に「apkファイルに署名すると『java.util.zip.ZipException: invalid entry compressed size』が出てくる」というものがある。
この回答として一番多いのは「apkファイルが署名済みだからです」というものだ。
しかしよく考えてみよう。
ここでエラーを出しているのはjava.util.zipで、圧縮サイズがうんぬん、という内容だ。
署名がすでにあるからエラーを出しているというわけではない。
結果として同じことなのかもしれないが、気になるではないか。
というのも、二重署名できるということは、署名済みであってもさらに署名ができるということだからだ。
エラーが出る場合と、出ない場合がある。
今のEjectSDは、そんな状況に追い込まれているのだ。
署名が違うと、マーケットにアップするのが大変。
新規のアプリにしないといかんのだ。

まずはこちらのサイト。
http://d.hatena.ne.jp/skirnir/20090220/1235143925
.NETの話ではあるが、エラーの原因はそういうことなのだ。
jarファイルはzipと同じ構造なので、同じことだろう。

こちらは、おそらくExceptionを出す箇所のソースファイル。
http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Core/Collections-Jar-Zip-Logging-regex/java/util/zip/ZipOutputStream.java.htm
真ん中くらいに「invalid entry compressed size」の文字がある。

ああだこうだ考えたが、結局のところjarファイルのヘッダ情報が正しくない、ということだろう。
なら、作り直せばいいじゃないの、ということで、jar xfしてjar cfした。
そしたら、二重証明できるようになった。
ふーん。

[felica]フィーチャーフォンとのFALP受信はあきらめよう

SDK for NFC Starter Kit(長いので、SNSKと略す)でFALP受信をやろうとしている。
送信元は、DoCoMoのP906i。そう、フィーチャーフォンだ。
持ってないから、仕方ない。

そして、うまくいってない。

 

FALPライブラリのログを見ていたのだが、ようやくログの見方がわかってきた。
TgGetInitiatorCommandに対してStatusエラーを返しているようなのだ。
しかし、PN533のドキュメントを見ても該当する番号がない・・・。
FALP独自のエラーなのか?

 

FALPライブラリの使い方が間違えている可能性も考慮しよう。
受信開始はWindowメッセージで取得することになっている。
Windowハンドラは、この順でメッセージを受け取っている。

  1. WM_GETMINMAXINFO
  2. WM_NCCREATE
  3. WM_NCCALCSIZE
  4. WM_CREATE

うん、ウィンドウの生成はできているようだ。
RegisterWindowMessage()も失敗してないし、set_falp_target_callback_parameters()もOK。
falp_listen()もOK。
こっから先は、Windowメッセージが来ない。

 

ログの内容からしても、まだ認証に至っていないので、フィーチャーフォンとのFALPはやはり想定されていない、と考えた方がいいのかもしれない。
あるいは、P906iのFALP実装がSONYさんの想定にないものになっているか・・・というのも考えたが、CTSに通っているからそれはないだろう。

あきらめた。

2011/12/08

SDK for NFC Starter Kit Ver.1.0

今までβ版としてリリースされてきたSDK for NFC Starter Kit。
とうとう正式リリースされた模様です。

http://www.sony.co.jp/Products/felica/business/products/ICS-D004_002_003.html

おめでとうございます。


β2版とざっと比較したところ、AIR関係とドキュメント、ドライバが変更になってた。
細かいところまでは見てないけど、AIR以外のサンプルソースは同じだった。

 

正式版になったので、FeliCaのブログにサンプルソースなんかが出てくると思う。
楽しみですわ。

2011/12/06

android-4.0.1_r1.2もUbuntu11.10でビルドエラーになる

android-4.0.1_r1.2もUbuntu11.10でビルドエラーになる。
なりました。

以上、ご連絡まで。
よろしくお願いいたします(?)。

2011/12/04

[llcp]訳がわからなくなる

libnfc-llcpだが、うまくいってないことはわかった。
しかし、何がだめなのかがよくわからなくなった。


今のところ、PaSoRiとRC-S620/Sを重ねてやっていたのだが、ふと両者を離してからそれぞれllcp-test-serverとllcp-test-clientを立ち上げると、後者を立ち上げたときに前者がエラーになって終わってしまっていた。
これはどうも、libnfcが空いているNFCデバイスを検索しているために起きているみたいだ。
しかし、さっきまでは特に問題なかったような・・・。

cleanなどしてたら、直った。
ような気がしていたが、そうでもないみたいで、タイミングか何かで発生する。
PC1台でやるのは、難しいんかね。


両方のPCDをばらばらに起動できたことを確認してから、重ねるように手順を変更した。
動作結果は同じで、InJumpForDEPでタイムアウトが返ってくる。

前回、ATR_RESを自動返信にしていると書いたが、あれはPN533のドキュメントを参考にした値だ。
RC-S956がどうなのかは、SetParametersの資料がないため、わからん。

うー、SetParametersとかWriteRegister/ReadRegisterの仕様が出てこないかなぁ。
libnfcでは、これらを普通に使っているのだが、PN533と同じ値でいいのかどうかすら判断ができんのだ。

[llcp]InJumpForDEPとATR_REQとSetParameters

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がもう1枚あればいいのになぁ。
1枚壊したのが、非常に痛い。。。ACKが返ってこないから、致命的だ。
修理したいけど、無理だろう。情報ないし。せめてTPの情報が欲しいところだ。
開けてみたけど、小さい部品ばっかりでわからん。
しかしこんだけ小さいなら、逆電流なんかに弱いかもしれん。
うぅ、ピンの1~6が逆になってただけなのに・・・。

 

InJumpForDEPがタイムアウトしてないこともあった。
しかし、それでもTgInitAsTargetは終わってない。
何だろうねぇ・・・。

[libnfc]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()の中で受信データの先頭を見て、何を返すか判断している。
考え方は、同じみたいだ。

[win]assocとftypeだけでは関連づけが取り戻せない?

以前、こんな記事を書いた。
http://hiro99ma.blogspot.com/2011/11/win.html
さっき、QtCreatorをインストールしたのだが、CやらHやらがQtCreatorにとられてしまった。
Qt、おまえもか・・・とは思ったが、それほどあせらない。
assocとftypeで取り戻せばいいからだ。
が・・・取り戻せない。
assocもftypeも、設定したテキストエディタを指しているのだが、肝心なExplorerがQtCreatorを指したままになっている。
ログオフも再起動もやったのだが、変わらず。
assocとftype以外に、何か要素があるのだろうか?
そもそも、QtCreatorがインストールされてExplorerがQtCreatorを指しているときから、assocは変更されていない。
つまり、最初からassocは無視されているのだ。


こちらに、関連づけがどう動作しているのか説明された文書があった。
http://www.glamenv-septzen.net/view/14
.Hファイルを例に見ていこう。
QtCreatorインストール前は、EmEditorに割り当てられていた。
HKLM\SOFTWARE\Classes.hというキーがあり、そこに(既定)として「emeditor.h」が登録されていた。
emeditor.hというキーもあり、(既定)は「Hファイル」になっている。
openもEmEditor.exeになっている。
うーん・・・。
うん?
.hキーの下に「PersistentHandler」というキーがある。
削除するといけるか・・・だめか。
Explorerのフォルダオプションで見ると拡張子Hは「C++ Header file」なのだが、ヘッダファイルを右クリックして開くプロパティから見ると「Hファイル」になっている。
emeditor.hは「Hファイル」なのでプロパティとは一致しているのだが、フォルダオプションとは違っている。
他のも見てみると、H++なんて拡張子もQtCreatorに関連づけられているのだが、Classes以下にはそんなキーはない。
つまり、キーがなくても関連づけをできる仕組みがあるということだ。


おっと、上のリンク先の続きを見ると、auto_fileというしくみもあるようだ。
これは自動で関連づけするものらしい。 レジストリエディタで検索をすると、HKEY_LOCAL_MACHINEの下ではなく、HKEY_USERS\(ユーザID)\Software\Classesの下にあった。
なるほど、こちらが優先されるのか・・・。
HKEY_CLASSES_ROOTを見ると、確かにそうなっている。
assocやftypeはこっちを操作してくれないってことですかね。
試しに、HKEY_CLASSES_ROOT\.hを削除してみた。
フォルダオプションはEmEditorに戻った。
Hファイルのプロパティはまだqtcreatorになっているが、ダブルクリックするとEmEditorが起動した。
再起動すれば直るんだろう。
auto_fileキーのみを削除してみたが、これだと関連づけがなくなってしまうだけだった。
やはりHKEY_CLASSES_ROOTから拡張子のキーを削除してやらんといかんらしい。
しかし、それはそれで危険だなぁ。
HKEY_USERS\(ユーザID)\Software\Classesの下にある方を削除すれば、少なくともassocなどの設定が削除されることはないんだろうけど、すっきりしない。

というところまで調べてネットで検索すると、同じことをやってる人がいた。
まあ、そうだよねぇ。。。
EmEditorでも関連づけができるのでやってみると、HKEY_USERS\(ユーザID)以下にある方を書き換えていた。
ユーザごとに拡張子の関連づけを変更するんだったら、それしかないというところか。
しかし、それを設定する方法が標準で提供されていないのがつらいところだ。
ならば作るまでよ!
というわけで、あれこれ迷いながら作成。
assocなどは使えないので、レジストリのインポート用ファイルを作ることにした。
UTF-16LEで保存する方法がわからなかったので、こちらからいただきました。ありがとうございます。
VBScriptでまとめてしまえばいいんだろうけど、もういいや。
使いたい方は、batファイルの中身を必ず書き換えてから使ってください。
動かんごとなっても、責任はとらんのであしからず。
デフォルトだと、うちの拡張子割り当てになるし、デフォルトのインストールパスなわけでもないので動かんでしょう。
また、そのままだとreg.regというファイルを作るだけなので、自分でレジストリに登録してください。
めんどうなら、自動でそこまでやってもいいんでないですかね。
https://sites.google.com/site/hiro99ma/home/windows/%E6%8B%A1%E5%BC%B5%E5%AD%90.zip?attredirects=0&d=1



うーん、新規作成にテキストファイルが出てこなくなった・・・。
Tweakなどで追加しても出てこない。
まずいなぁ。
まずいかも。

2011/12/03

[llcp]toolsのserverとclientを動かすが、うまくいかん

うまくいかんシリーズです。

前回、clientはInJumpForDepを実行して、ACKは返ってくるのだが失敗が返ってきた。
それは、相手がいないからだ。
ではserverをtargetにしてやればいいはず。

コンソールを2つ立ち上げ、

$ 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プロトコルをやりとりし始めてからのタイムアウトなのだ。

なんだろうねぇ。

[llcp]llcp_test_client

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のログまで出さなくては。


このテストプログラムはちょっと今ひとつで、

  • UTF-8に一部なってる
  • setUpとtearDownがない(うまく動いてない?)ので、途中で失敗すると搬送波が出っぱなしになる

などがある。
まあ、テストだからねえ。

とはいえ、搬送波を出しっぱなしというのも困るので、修正。
これは、libnfcのpn53x_idle()に手を加えた。
InReleaseなどに失敗してもエラー終了させず、とにかく一連の流れを終わらせるようにしたのだ。
これは自作のドライバでも迷ったところであるが、アイドル状態にどうしても戻したいのであればエラーを無視するしかないと思う。

[nfc]PollとListen

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になるのかどうかを気にしていたのだが、どうでもよくなったので、それもいいや。

[tool]mscgen

シーケンス図を、文字列から生成することができるツール、mscgen。
ルールに従ったテキストファイルを作成し、mscgenを実行すると、pngなりなんなりのファイルにしてくれる。
libnfc-llcp/docにはmscファイルがあったので、mscgenをapt-getでインストールして実行すると、シーケンスを作ってくれた。
他に、ドキュメントは作ってくれなさそうなのよねぇ。
dotファイルがあるのだが、これが何のツールに対応しているのか知らんのが残念だ。
と思って調べると、dotはgraphvizだった。
doxygenの準備はしているけど、まだ整っていないというところか。
ソースを見たけど、コメントがほとんどないのよね・・・。
関数の説明もないので、なんだかわからんな。
そして、staticな関数が1つもない!
うーん、これを仕立てるのは厳しいなぁ。。。。

[無駄話]マクロをdo-whileで囲むか否か

続けて無駄話だ。
今、仕事でマクロをばしばし使っている。
inline関数はないし、関数呼び出しするといろいろとオーバーヘッドがかさむからだ。
直に書いてもいいけど、メンテナンスを考えるとマクロでやるか、という状況だと思っておくれ。

さて、関数マクロの場合、私はdo-whileで囲むことが多い。
#define MACRO_FUNC(x,y) \
do { \
 y = (x) * (x); \
} while(0)
習慣みたいなものだが、静的解析ツールにかけると「while内が固定なので変だ」みたいな警告が出てくる。
うーん、この書き方は市民権を得ていないのか・・・。
do-whileなしでも、括弧だけで十分という気もする。
薄れた記憶からすると、括弧だけでは対処できないパターンがあるのでこの文法が使われていたと思う。
なんだっけ・・・。最適化が絡んでいたような。
Google検索
ああ、if文で途切れるのね。
if(xxx)
 MACRO_FUNC(x,y);
else
 //to do
で、MACRO_FUNCが{}だけだと、
if(xxx)
 {
  y = x * x;
 };
else
 //to do
となり、
if(xxx) {
 y = x * x;
}
;
else
 // to do
となってしまい、elseが浮いてしまうのだ。
でもまあ、コーディング規約で「必ず括弧で囲め」とやってるから、別にいいんだけどね。
コンパイルエラーになるから、動作がおかしい、ということにはならないし。

[無駄話]ハードTABは4か8か

ハードTAB、文字コード0x09。
私はソースを書くとき、インデントをTABキーを使って入れる。
うちのテキストエディタは、TABキーはそのまま0x09が入るようにしている。
その設定は、ソースコードは4文字、それ以外は8文字にしている。

Linuxの場合、2文字インデントが結構多い。
2文字インデントが4つになると、ハードTABになってたりするので、テキストエディタで見るとインデントが崩れてしまう。
まあ、設定を変更すればいいんだけど、どういう設定の人が多いのかは気になる。
私の予想では、こんな感じではなかろうか。
  • ハードTABは4文字で、インデントはハードTABのみ
  • ハードTABは8文字で、インデントはハードTABのみ
  • ハードTABは8文字で、インデントは4文字。2インデントでハードTAB1つ。
  • ハードTABは8文字で、インデントは2文字。4インデントでハードTAB1つ。
  • ハードTABは使わず、インデントはスペースのみ。
つまりまあ、スペース文字を混在させるか否か、というところだ。
「この設定はだめだ」みたいな狭量なことをいうつもりはないのだが、バラバラなのも困るような気がする。
気がするのだが、何十年もこんな状況が続いているのだから、そんなに困ってないのかも。

困るというか気になるのは、自動的にインデントを設定してくれるエディタだ。
親切なのはいいんだけど、なんでこの位置なんだろう?と疑問に思うことがしばしばあるのだ。
長いものに巻かれるってわけでもないが、人に不審な思いはさせたくないので、一般ルールがあるならあわせてもよいと思っている。
ありがちなのは、ifの条件文中で改行したい場合。
私は4文字インデントなので、こういう場合は2文字のインデントにして区別するようにしている。
    if(aaa && bbb && ccc
      && ddd && eee && fff) {
        // todo ......
    }
あとは、引数の途中で改行したい場合。
このときは、ばさっとずらす。
 function(aaa, bbb, ccc,
    ddd, eee, fff);
まあ、何が正しいってのはない世界だけど、自分ルールを持っていないと困るからねぇ。
自分ルールがあると、仕事でコーディング規約を与えられたときに反発してしまうという弊害があるが、そこはご愛敬だ。

2011/12/01

[felica]Suica/PASMOのFeliCaポケット解禁

FeliCaポケット機能が、SuicaやPASMOで使えるようになるらしい。

http://www.sony.co.jp/SonyInfo/News/Press/201111/11-151/

 

もともと搭載していた機能を、12月から使用許可したということらしい。
FeliCaポケットというのは、たとえば1枚のSuicaカードで、買い物のポイントや行政サービスや切符の購入などができるようにすることなのだが、これは「Suicaの情報を他のサービスにも使えるようにする」ではなく「Suicaで使っていない領域を他のサービスにも使えるようにするから勝手にやって」というものだと思われる。

まあ、勝手にやって、といっても誰かが管理するんだけど。

 

FeliCaポケット自体は少し前、いやかなり前からある機能だ。
Suica/PASMOにそれがあることすら知らんかったし、公表されてなかったんじゃないかと思う。
サービスを始めたわりには、宣伝も特にしてなかったし、採用されたものも知られてないと思う。
(私が知らんだけか?)

 

最初にガツンと宣伝しないとダメなのでは・・・と思ったけど、そうでもないかも。
当時にこれを大々的に宣伝したって、何に使うの?、みたいな感じで流されてしまい、印象が悪くなってたかも。
今なら、NFCってのが以前よりも市民権を得てきたので、やってもいいかも、と思う業者があるのかな。
いっそのこと「新サービス FeliCaポケット!」って言い張ってもいいのかも。

 

このサービスはセキュアなことが売りなので、NFC Forumで公開されている情報ではアクセスできないはず。
セキュアってなった途端、FeliCaは日本+αローカルになってしまうのがつらいところだ。