うちにある、一番Android端末っぽい端末。それがSmartQ5。
思えば、私のAndroidはここから始まったんだった。しみじみ。。。
それを分解した。
分解といっても、外枠を外してねじをとるだけなのだが、枠がなかなかとれなくてね。
なんでこの時期にいきなり触りだしたかというと、RC-S620/Sだ。
確か、S3C6410にはUARTが2つ付いているという資料があった。
SamsungのS3C6410XH-66が搭載されている。
銀色のチップは、WLANらしい。WM-G-MR-09。
SunDiskのはiNAND。
SDRAMが2つ。
SDカードソケットの上に載っているのはBlutetoothか。
哀しいことに・・・目を近づけても眼鏡を外しても、チップの文字が読み取れない。
いつか接続できる日が来るのだろうか。
そういうわけで、分割して送信しなくてはならない。
ツールで送信したら、Extendedフレームが使われていた。
私はNormalフレームのみでやりたいので、いくらか減らす必要がある。
見たところ、4byte減らせばよさそうだ。
まず、FeliCaコマンドが255byteまでになる。
そうするとFALPコマンドが251byteまでになる。
送信データが52byte以下なら、1回で転送可能。
それより大きければ、2パケット以上になる。
2つ目以降のパケットは、残りデータ数との兼ね合い。
242byte使えるので、最後に必要な26byteを気にしながら送信する。
まあ、正しくは、OBEX PUTのパケットを作ってしまい、それを242byte単位で送信する、だろう。
そうすれば、残りが何バイトだのあーだこーだのは気にしなくてよくなる。
そのくらいの空きはあるとしていいかねぇ。
さて、FALPで1回に転送できるデータサイズは何バイトだろうか？
ここで言うFALPは、0xbcコマンドだ。
FeliCaコマンドには拡張形式もあるが、使われているのを見たことはない。
仕様としてはあるけど、対応しているチップはあるのかな？
それはさておき、0xbcだ。
ツールで長めのデータを送信して確認した。
FeliCaコマンド0xa0の送信データ長が0xffまでだった。
| RC-S620/S | FeliCa cmd | FALP cmd | データ | RC-S620/S |
「FALP cmd」と「データ」で0xffというところ。
細かいフォーマットは気にしないでおくれ。
とにかく、この辺りが0xffで制限される。
では、実際にどのくらいのデータが入れられるのかを考えておこう。
FALPのプロトコル仕様が出ていないので、データから推測だ。
たぶん、OBEXのPUTからデータ部だろう。
0xffはデータ長の1byteも含んでいるので、シーケンス番号まで引いて246byte。
DEPに比べると、少ないような多いような。
まあ、そんなに比較しても仕方がないか。
もちろん、OBEXというものも含めて考えると、使えるパケットはもっと減る。
1回目はPUTコマンドのヘッダがあるので、減ってしまう。
vNote形式の場合、そのタグの分も考えなくてはならない。
私の場合、2パケット以上で送信するなら、1回目のパケットは82byteだけ自由に使える。
vNoteの終わりにもタグがあるので、2回目移行のパケットは26byte減る。
つまり、1パケットだけで送信するなら、自由に使えるのは56byteということになる。
このときのパケットをRC-S620/Sの層から見直してみた。
ああ・・・Extendedフレームが使われている。
実際にあるのか？とか書いていたが、ここで使われていたのだ。
これを使っても265byteまでしか送れないので、FALPとかになったらもういいんじゃないか？という気もする。
BeagleBoard + RC-S620/Sという構成。
これに、Android 2.3.3が載っている。
RC-S620/SはUARTなのだが、CP2102を挟んでいるのでUSBで接続している。
直接コマンドをやりとりする部分は、C/C++で書いている。
名前は、libnfcutils.so。
これは/system/libにコピーされる。
libnfcutilsをJNIで使えるようにしたものが、javax.nfc.NfcUtils。
これをjarで固めて、javax.nfc.jarとした。
これは/system/frameworkに置くようにしている。
システムとしては、これだけ。
アプリの開発時は、javax.nfc.jarを外部ライブラリとして参照させている。
そうすることで、ようやくLinux環境でなくてもアプリだけ作ることができるようになった。
さて、一つわからないことが。
libnfcutils.soは、mmなどでビルドすると自動的にout/target/products/xxx/system/libにコピーしてくれる。
javax.nfc.jarは、今のところEclipseでjarを作って、SDカードにコピーしている。
自動的にできないものだろうか？
最初から存在するファイルなら、BoardConfig.mkとかに書いておけばいいんだけど。。。
FALPで送信する場合・・・というか、日本国内携帯電話会社のOBEXエンコードはShift-JISだ。
vNoteとか、vMessageとか。
エンコードを指定するタグはあるけど、意味があるのかどうかわからん。
まあ、それは気が向いたらやってみよう。
iconvとか使わんといかんのかと思っていたが、Javaではjava.lang.String.getBytes()でできるらしい。
ほほう、便利なものだな。
引数でCharsetを渡したら、それでエンコードしてくれるらしい。
変換できない文字は、デフォルトの変換用文字に置き換える、ということでいいのかな。
細かく制御したいなら、CharsetEncoderを使えばよいようだ。
さて、Charsetを見ると、Shift-JISは保証されてない。
つまり、実装されていないかもしれない。
うーむ。
まあ、まずは実装のテストだから、Shift-JISが使える前提でいいや。
しかし、getBytes()はどうやって実装されているのだろうか？
大きな変換テーブルがあるんだと思うが、iconvを呼んでいるのかな？
external/icu4cがあるので、これを呼ぶのかなぁ。
すごく適当なシーケンス図を載せておこう。
FeliCaのパケットは、最大でだいたい256byteくらいだ。
なのでファイルのような大きいデータを送る場合、分割する必要がある。
さて、パケットとしての分割は必要になるとして、その分割されたデータを受けとる方も考えなくてはいけない。
どのくらいの受信バッファを用意するか。
もちろん1パケット分は必要だが、もっとないと困る。
かといって、無限に用意できるわけでもない。
そこら辺をうまく解決せんといかん。
FALPではどうやっているかというのは、うっすらとしか記憶にない。
まあ、普通に考えれば、
というところだろう。
受信バッファサイズはいらんかもしれんが、バースト転送じゃないけど連続して送信できるサイズを知っておかないと、送信する方もバッファが必要になるのでな。
ああ、情報が欲しい・・・。
android_native_app_glueというものがある。
これを使うとNativeActivityが楽に実装できるらしい。
前回書いたソースも、使っていることになる。
サンプルの"native-activity"は、glueの機能を全部使ったサンプルらしい。
なので、一通り眺めるとよいようだ。
NativeActivityのJavaDocも参照しろ、といっている。
http://developer.android.com/reference/android/app/NativeActivity.html
最初だけ見てみたが・・・ゲームみたいな使い方をするアプリ向けだ、と明言してますな。
そう言われてしまうと、私はゲームみたいなものを作りたいわけではないよなぁ、と思う。
単に、Javaで書くのは自信がないしJNIを書くのも面倒なのでなるべくC/C++でやりたい、というだけ。
ちょろっとしたアプリしか作らないなら、Javaでもいいかな、という気がしてきた。
それだけだと何なので、いくつか書いておこう。
glueは、NDKにヘッダがあるので、それを見てみるとよい。
説明が書いてあるのだ。
android-ndk-r5b\sources\android\native_app_glue
android_appをラップしたC++フレームワークを作るのもよさそうだけど、ウィジェットの部分はどうしてもJavaを呼び出すことになりそうだ。
そんなのを全部フレームワークにしてしまうのも、大変だ。
使うものだけ定義する、という手もあるが・・・。
まあ、次にやることがあるかもしれんが、今回はこの程度にしておこう。
