2011/04/30

[kernel]non-linefetchを探してみるが、よくわからない

kernelをgrepしてみた。

$  grep -r 'non-linefetch' .

バイナリを除くと、
  • arch/arm/mach-ks8695/pci.c
  • arch/arm/mach-integrator/pci_v3.c
  • arch/arm/mm/fault.c
が出てきた。

fault.cには、"non-linefetch"という言葉が3つ出てくる。
このfault.cは、文字列の定義くらいなので、何が理由なのかは分からない。

残りの2ファイルでは、hook_fault_code()を使っているみたいだ。
これの第1引数が、fault.cにある文字列配列の添字と一致しているのだろう。
hook_fault_code(8, ...)とか、hook_fault_code(10, ...)とか。
なんなのかはわからないけど、そういうことだ。

もう1つわからないけど、"non-linefetch"だけでなく"linefetch"という文言もある。
nonだろうとなかろうと、エラー原因になるらしい。
さて、なんなのだろうねぇ。

ARMの本家サイトからの情報を載せておこう。
 6.2.4 Linefetch transfers

ほかにもいくつか。

ARM Fault Status Register Values (FSR register)
どうやら、FSRレジスタの値からエラー文字列に してくれたのが、あの文言のようだ。
MMUがらみってことか。
仮想アドレス空間で実アドレスをたたこうとしているとか、アラインメントがあってないとか?


[PATCH] USB: musb: omap2430: fix kernel panic on reboot
ふむ。そういえばrebootさせようとすると、カーネルパニックが起きていたな。
あれも同じ原因なのか?
 kernel 2.6.38-rc4では修正したよ、ということのようだ。
私が使っているのは、2.6.32だから、可能性はあるな。


[libusb]カーネルか?

libusbが動かん。
Androidアプリからやってるせいかと思ったが、コマンドラインからlsusbなどとしてもだめだ。
だめだー。


で、どうだめかというと、カーネルパニック。
いろいろ考えたが、やはりカーネル側に問題があるよなぁ。
usbfsのようにあまり使っていないものが、libusbによって使われることで発生しているのかしら。

ちなみに、こんなログが出てくる。

# lsusb
cm: Module associated with clock usbhost_48m_fck didn't enable in 100000 tries
Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa064818
Internal error: : 1028 [#1]
last sysfs file: /sys/power/state
Modules linked in:
CPU: 0    Not tainted  (2.6.32.9-gabb2a84-dirty #2)
PC is at ehci_omap_bus_resume+0xb4/0x390
LR is at omap2_cm_wait_idlest+0x5c/0x84
pc : []    lr : []    psr: 20000093
sp : c990fdd0  ip : 00000002  fp : 00000000
r10: 00000000  r9 : c990e000  r8 : cf913000
r7 : 00000004  r6 : 00000000  r5 : cf8a5000  r4 : cf8a50d0
r3 : fa064810  r2 : ffff8566  r1 : c0424071  r0 : 00000000
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 89ba0019  DAC: 00000015

PaSoRiをAndroidで使えるようにしたいが、失敗

いろいろうまくいかない。。。

RC-S620/Sのために部品が到着したのだが、ピンの接続を逆にして使っていたためか、応答がない。
壊れたのかもしれん。。。
残念だが、もう1台注文してしまった。
そのマシンで動くなら、今のが壊れている。
動かないのなら、構成が間違えている。
どっちにせよ、しばらくおあずけだ。

その間に、PaSoRiをBeagleBoardで使えるようにしようとした。
libusb-0.1.12とlibpafeだけあればいいはずだ。
。。。それがうまくいかない。
/dev/bus/usbを見て、接続されているデバイスの数まではわかっているようなのだけど、ディスクリプタが取れないのだ。
しくみがわかってないのが、いかんですな。

libusb-0.1.12を自前で移植(というほどではないが)したものでだめだったので、githubにあったlibusb-androidとlibusb-compat-androidも試してみた。
何が違うのかわからなかったが、libusb-androidはlibusb-1.0系。それをラップしてlibusb-0.1系のI/Fを提供するのがlibusb-compat-android。
おそらく、本家もそうなっているのだろう。
まあ、githubの方でもだめだったんだけどね。

どちらかというと、kernelの設定とかそういう問題なのかな?
それすらわかっていないので、手当たり次第に試して失敗している。
NICも認識していないので、adbが使えず、非常にデバッグ効率が悪い。
何とかせんといかんが、あんまりやる気にならんのよねぇ。。。

2011/04/29

[felica]普通はソフトは何もしない

モバイルFeliCaチップというものがある。
まあ、携帯電話に載っているFeliCaチップのことだ。

FeliCaチップには、アンテナとセキュアエレメントがつながっている。
それと電源とかあれやらこれやら。
そう、カードとは違い、電源がいるのだ。
なのでだいたい、本体は電池を生かすために早く使えなくなる。
FeliCaロックしたまま本体が使えなくなると、もうどうしようもない。
もちろん、ロックしていなくても、電池がある程度なくなってしまうとつかえなくなる。

ついでにいうと、携帯電話にはハードスイッチがない。
なので、電池を入れると常にON状態だ。
「電源OFF」のときは、なるべく電気を使わないように使わないようにしているだけである。
充電中も同じ。
電流や温度を常に計測する機能は動作しているのだ。
海外製だと、あまり気にしないので充電中は電源ONっぽくなるものが多い。
日本製はそこを気にするので、わざわざめんどうな改造を施すのだ。

さてFeliCaだが、かざすときはソフトは動いてない。
FeliCaチップとR/Wが勝手に何かやるだけだ。だから本体が使えなくなってもFeliCaだけ使える。
ソフトが必要になるのは、ユーザに何か見せたり、通信によってFeliCaチップにアクセスする場合くらいだ。
SIMすら必要ないはず。

これが、セキュアエレメントをSIMに持っていくとどうなるんだろう。
やはりFeliCaチップだけでなくSIMにも電源を供給せんといかんだろう。
そうなると消費が少しは大きくなるのかな?
でも、今でもセキュアエレメントに供給しているから、そげんかわらんのかも。

[felica]libpafeで使用しているlibusbは0.1系

少し前に、libusbのビルドだけ対応した、というようなことを書いたと思う。
あれは、libusb-1.0.8だった。

その後、libpafeをビルドしようとしていたのだが、なかなかビルドが通らない。
usb.hにパスを通すためにkernel-headersへinclude pathを追加したり、そこを追加すると他のところがおかしくなったり、もうちゃっちゃくちゃらだった。

ようやくヘッダを解決して、ソースファイルのビルドに取りかかったのだが、やはりエラーが。
これはおかしいぞ?とようやく気づき、APIの使用状況を見てみた。
そしてようやく、libpafeで使っているのはlibusb0.1系で、libusb1.0系とはいろいろ異なっていることが分かったのだった。

libusb0.1をダウンロードしてビルド。
そしてlibpafeをビルド。
warningは出るけど、あっさり完了。

ああ、たくさんの時間を無駄にしたことだよ。。。

android-2.3.4_r1

今朝方、android-2.3.4_r1のタグができていた。
何となく二日酔いで早く目覚めて気付いた。

JBQ氏のメールもあったが、何が変わったのかよくわからん。
NFCのP2Pは、最後は有効になったんだよな。
前のlogを引用しているのなら、引用マークを付けてほしいものだ。


Sat, 16 Apr 2011 03:12:29

Enable P2P 106 passive (again).
Disabling P2P 106 passive caused a large P2P discovery regression.

----
Sun, 17 Apr 2011 14:30:15

Merge "Enable P2P 106 passive (again)." into gingerbread

----
Sun, 17 Apr 2011 14:52:25

am 17018c3f: Merge "Enable P2P 106 passive (again)." into gingerbread

-#define DEFAULT_NFCIP_TARGET_MODE_SUPPORT 0x0EU
+#define DEFAULT_NFCIP_TARGET_MODE_SUPPORT 0x0FU

だし、

324 #define ENABLE_P2P
325
326 #define DEFAULT_NFCIP_INITIATOR_MODE_SUPPORT 0x0FU
327 #define DEFAULT_NFCIP_TARGET_MODE_SUPPORT 0x0FU

なので、P2Pもさることながら、ターゲットモードを有効にしたということなのかな?
うん、ターゲットになることはできるようだ。

さて、ターゲットになることができるのなら、カードエミュレーションもできるのだろうか。
DisableCardEmulationというフラグがあるのだが、たぶんこれがTRUEだとカードエミュレーションできないのだろう。
これにTRUEをセットするのは、SmartMXモジュールなるものがWired Modeの場合らしい。

どうやらSmartMXはNXPのセキュアエレメントらしい。
検索してみると、Nexus SにはSmartMXが搭載されているらしい。
しかし、有効化パッチなるものがあるということは、デフォルトでは無効なのだろう。
ということは、パッチを当てていないのであればカードエミュレーションできるということか?

NXP_HAL_ENABLE_SMXがコメントアウトしてあるので、SmartMXは無効なのだろう。
でも、HOST_EMULATIONもコメントアウトしてあるので、カードエミュレーションはできないみたいだ。
Nexus Sは持ってないけど、惜しいな。


[nfc]OpenNFCというものがある

OpenNFCというものがある。
あまり気にしていなかったのだが、これはNXPではないのだそうだ。

現在のAndroid2.3.3に載っているのは、NXPのライブラリだ。
これだと別のNFCチップに載せ替えるのがめんどうだよなぁ、と思っていたので、もう見ないことにしていた。
ざーっとしか見ていないのだが、external/libnfc-nxpとapp/Nfcの結びつきが強いので、libnfc-nxpを書き換えると、NfcServiceも書き換えないとたぶん動かないと考えたのだ。
OpenNFCは、INSIDE Secure社が開発したものをオープンソースにしたようだ。
噂によると、移植がしやすいらしい。しやすいというか、移植時の変更量が少ない、と。
ほほぅ。

ネットで探してみたけど、あまり情報がない。
理由としては、モバイル向けNFCチップが入手できないからではなかろうか。
それに、アンテナの調整なんかは機材がないとできないので、個人でやるのは厳しい。
スペアナなんて個人持ちしないだろうからなぁ。

モバイルFeliCaチップはまず無理だろうし(型番もわからん)、まだNFC対応してないらしいし。
RC-S956の製品版として、RC-S620/Sとか/Uとかになるが、モバイル向けじゃないしなあ。
NXPも、やはりPN533単体だけだと個人では調整できない。
PN544は、購入申請を直接NXPに出したりするのかな? まあ、それでも同じことだ。
やはり調整済みでないと。

そうこう考えると、企業しかモバイルNFCチップで何か作ろう、とはなりにくい。
企業でやると、情報は企業内でしか持たないだろうから、外に出てこない。
だから、NFC関係のことが開発レベルで出てくるのは、アプリケーションくらいになってしまうのだろう。

国内はNFCチップメーカーが少ないので、さらに市場が少ないように思う。
ルネサスがNFCチップを出していたので、それがどうなっていくかが気になるところですな。

2011/04/27

[hw]mbedを考える

mbedには、SPIがついている。
USB接続で、コーディングはブラウザ経由。
どうせ家でしかコーディングしないだろうから、ちょうどいいかも?

とは思うのだが…うちにはもう、ボードが山のようにある。
Interface誌の付録で、まだ開けていないものもあるくらいだ。
もったいない・・・。

というわけで、mbedはやめておこう。

2011/04/26

[felica]FeliCa Plugを考える

FeliCa Plugなんて、カード代わりにしかならないじゃないか。時代はDEPだ、ぺぺぺっ」と思っていたのだが、どうもそんなことはなさそうだ。

私もいつも「NFC-DEPに対応した端末はないかなー」と思っているくらいだから、そんなに流行ってないのだと思う。
思うに、負担が大きいわりに、今ひとつ仕様がわかりにくいからではなかろうか。
ISO14443でやるのか、ISO18092でやるのか。
Type-Aだけだと、14443で実現している端末ならあるのかしら?
Nexus Sも、14443だったと思う。

ただ、正式には18092でいくらしい。


が、ものがなくては普及しない。
普及しないから、ほしい人もいない。
FALPみたいに、上がOBEXと決まってしまえばいいんだろうけど(決まってはいないか)、LLCPまでしかNFC Forumでは決められていないと思う。
そしたら「その上はどうする?」と迷ってしまいそうだ。
たぶん「LLC」というくらいだから、その上にはIPなんかが載せられるんではないかと思うのだ。

まあ、未だにDEPプロトコルで通信できた程度なので、偉そうなことは言えないのだが。


DEPは敷居が高いし、対応も面倒。
ならば、今までのR/Wでアクセスできる範囲でいいや、と思うのは世の流れ。

そこに出てくるのが、FeliCa Plugだろう。
使えるコマンドは、Read Without EncryptionとWrite Without Encryption。それとPolling。
の、レスポンス。カードだから。

ただ普通のカードと違うのは、転送モードが2つあること。
FTモードは、普通のカードみたいな転送。
FBモードは・・・どちらかというとFALPみたいなアクセスができるようなものだと思う。
面白そうだ。

が、困ったことが一つ。
I/Fが三線シリアルなので、ちょうどいいデバイスがないのだ。
あ、Interface誌のボードがあるから、それなら使えるのかな。
大きめのデバイスよりも、小さめの方が楽しいだろう。

2011/04/25

libusbの移植だけ

RC-S620/Sはしばらく使えないので、PaSoRiを使おうと思った。
PaSoRiを使うには、やはりLinuxでやってるのと同じようにlibusbを使うのがよかろう。
幸い、ネットに移植方法が書かれていたので、まねをした。

多少文字化けしたり欠けたりしているところがあるが、悩めば何とかなった。
config.hはなかったので、githubの人から拝借した。
configureすればできたのかもしれないけど、もういいや。

ビルドまではできたが、動かしていない。
usbfsをマウントするようなことが書かれているけど、いるのか?
いるんだろうな。。。
使い方もよく知らんけど、まあ何とかなるだろう。

今週は、これで遊ぶことにするかね、余裕があれば。。。

[rcs620s]折れた

フラットケーブルを抜いたり挿したりしていたら、RC-S620/Sと通信ができなくなった。
ケーブルは問題なし。
しかし、USBシリアル変換につながっている先とは断線している。
その間にあるのは、半田付けをしたコネクタ。
あー、半田が取れたのかな-、と思ってホットボンドをはいでいくと、ピンが根本から折れていた。
ああ、ああ、あああーあーあー(沢田健二風に)。

偶然、その部品をネット注文したばかりであった。
やっぱり私の腕では、あれを固定させるのは無理だったようだ。
0.5mmピッチでやりづらかったので、ピンを交互に上下させていったのだ。
あれがまずかったな。

2011/04/19

[nfc]カードエミュレーション

NFCの標準仕様には、3つのモードがあるらしい

  • カードエミュレーションモード
  • リーダ/ライタモード
  • 相互接続モード

出所は見つけられなかったが、ここが一番近そうだ。
タグは受動型で、R/Wからデータを読み書きされる方、みたいなことを書かれている。

つまりNFCデバイスとは、NFCチップ、しかもホストCPUから制御できるような代物を指していることになる。
なんとなく、ICカードも含めているのかと思っていたので、ほほー、と思った。


モバイルFeliCaチップの場合、普通はカードエミュレーションモードで動かしている。
これはまあ、モバイルSuicaなどになっているから、感覚的にわかるであろう。

iアプリの「iCタグリーダ」は、リーダ/ライタモード。
これも、スマートポスターなんかが読み取れるので、わかりやすい。

相互接続モード。
これは英語の方がわかりやすい。peer-to-peer mode。P2P。
NFCチップ同士のデータ交換というところか。
FALPはそうなんだけど、NFC Forumの仕様でやりとりしているわけではない。
どちらかといえば、IrDA、やBluetoothでのやりとりに近い。
NFCはLLCPとなっている。
PHY-MAC-LLC、のLLCP。
ネットワークには詳しくないのだが、とにかくそのあたりだ。


さて、Nexus SにはNXPのPN544が載っている。
これはR/Wモードで動作しているようだ。
調べてはいないが、カードエミュレーションが無効にされているという。
ライブラリを見た感じでは、SWPも使えるようではあった。無効にされているかどうかはしらん。
アプリからは、Android APIでアクセスする。

一方、日本のIS-05などはFeliCaが搭載されている。
もちろん、カードエミュレーションモードで動いている。
アプリからは、FNさんが提供しているライブラリ経由のアクセスになる。
なんというか、おなじみのライブラリだ。

モバイルFeliCaチップは、NFCには対応していないらしい。
なので「カードエミュレーション」と呼んでよいのかどうかわからない。
一方、RC-S620/Sに搭載されているFeiCaチップは、NFCに対応しているようなものだと思う。
(かといって、PN544に近いわけでもないと思う。よく知らないが。)
この人がカードエミュレーションできるのは、前回書いた。

カードエミュレーションするとき、まずUIDが必要だ。
どうやるかというと、コマンドのパラメータに、Type-A、Type-B、FeliCaのUIDをすべて指定するのだ。
Type-Aはなんか制限があるけど、FeliCaのはIDmもPMmも指定する。
ポーリングすると、そのIDmやPMmが読める。
コマンドが来たら、適当に作って返すことができる。
そりゃまあ、カードエミュレーションだからな。

じゃあこれを使って電車に乗るデータを偽造してやれ!と思う人がいるかもしれないが、まあ無理だ。
理由は説明しないがね。
少なくとも、犯罪を助長する気はない。


なんでPN544をカードエミュレーションで動かせないようにしているかは推測だが、やはり怖かったからではなかろうか。
能力的には、MIFAREとして振る舞うことができるんだと思うのだ。
そういう機能があるなら、技術さえあれば試してみたくなるではないか。
そして、行き着くところまでいってしまうかもしれない。

そんな心配をするよりも、私としてはP2Pモードだけ使えるようなチップがほしいのだ。
ねー。

2011/04/18

[falp]やはりOBEX PUTくらいは別にしないといかんか

バッファを抑えたいとか何とか言っていたが、めんどくさくなってきた。
なんでFALPの中で送信回数を条件分岐せんといかんのじゃー!

そんなわけで、来週は余裕があればOBEX PUTくらいは別にしようかね。
しかし、もっと別に考えるべきものがあった。
今はvNoteで文字列しか送信していないけど、メール転送や画像転送もあるんだった。
vMessageとか、画像は何だろう? とにかくデータ部が別にできるようにしておかないと。
データ部が別になると、つられてOBEX PUTも別になり、FALP送信が独立してしまう。
あんまり好きじゃないが、そうのほうがやりやすいんだからしかたない。

実装をかなり進めてから変更するってのは、やっぱり設計が甘いんだろうな。
ええ、よくやるんですよ仕事でも。
C++だと、デフォルト引数なんかを利用して「そのままでも今まで通りでコンパイルできますが、拡張部分は引数を追加してください」なんて手が使えるんだけどね。
Cの...はめんどくさいから、やだ。

2011/04/17

[nfc]PaSoRiもターゲットになれる

いまさらだが、「PaSoRiはターゲットになれない」という記事を自分で書いていたのに気付いた。

ごめんなさい。なれます。

今までの作業記録を見ていればわかると思うが、RC-S620/Sと同じだ。
ただ、無線的な要因で、あまりターゲットには向かないとのこと。

testdiskによるデータ復旧

知人PCのWindowsが起動しなくなったらしい。
知人と言っても、きょうだいの知人だが。
起動できないけど日本語でメッセージが出るという。
それならディスクは死んでないからデータくらいは吸い上げられるだろうと請け負ってしまった。
これが間違いだった。

生きているのは、MBRとそれ以外の部分。
Windowsが入っているパーティションも生きてはいるのだが、NTFSのMTFが壊れている(のは後でわかった)。
つまりまあ、dirとかしても何も出てこないのだ。何も出てこないどころか、エラー。
今思えば、chkdskくらいしてみればよかったが、それは昼からやってみよう。

とにかく読めないことが分かったので、バックアップをとって復旧作業をやろうとした。
が、セクタが壊れていてバックアップできない。。。
あまりそこに時間をとられたくないので、そこそこにあきらめて復旧へ。

市販のノートPCで、メーカ独自のバックアップ用パーティションなどがあった。
きっと後ろの方にあるんだろうと思ったら、前の方にあってね・・・。
構成を把握するまでに時間がかかった。
それまでは、パーティションテーブルが壊れていると思ってたのだ。

NTFSでドライブごと復旧できそうなツールが、testdiskだった。
これで見てみると、NTFSブートセクタに問題はなさそうだった。
が、MTFの確認をすると・・・壊れているらしい。
どうもセクタが壊れているのが、ちょうどそのあたりらしい。
まいった。。。

というところで「List」というのがあったので試すと、ファイル名が出てきた。
おお!
ここからファイルを別の場所へコピーできるようだ。
どういうしくみなんだろうねぇ。

では、と寝る前に仕掛けていったのだがよく確認してないのがまずかった。
Linuxで確認し、Win32版でコピーさせたのだが、日本語が化けていたのだ。。。
調べていったけど、文字コード自体がおかしくなってるので、文字コード変換ではなく修正を行わねばならない。
しかしそのルールがよくわからん。。。。
U+30C7がU+FF87になってるんだよなぁ。

あきらめて、Linuxでやり直している最中である。
返却して、Knopixとかでやってもらおうかなぁ。

2011/04/16

[falp]分けた方がいいんだけどねぇ

わかってはいるけれども、やりたくないことは多々ある。

FALPとOBEXは別々に分けた方がいいのだ。
データを送りたくてOBEXを呼ぶ人と、OBEXが転送のためにFALPを呼ぶ人と。

OBEX PUTは、サイズとして65535byte送ることができる。
FALPは、FALPパケット込みで255byte。FALP転送コマンドを除くと247byte。
なので、OBEXの人は247byteずつ分割してFALPを呼んでくれたら済むのだ。

そこまでわかっていてなぜやらないかというと・・・OBEX層を用意したくないから。
だって、作ってるのはNFC/FeliCaのライブラリだから、あんまり不要なものは作りたくないのだ。
かといって、OBEX層をライブラリから外すと、FALP送信のたびにJNI呼び出しするので、遅くなる。
遅くなるのがあらかじめわかっているので、嫌なのだ。

それに、OBEXとFALPをわけると、OBEX用のパケットを作るところと、FALP用のパケットを作るところが出てくる。
そうすると、重複したデータを持つバッファができてしまう。
FALPは255byteくらいだからいいやん、という気もするが、なんかね…。
今でさえ、NFCとRC-S620/Sで別のバッファを持つのが嫌なのに。

だから、作るならOBEX/FALP込みのライブラリ。
バッファはなるべく使い回し。

2011/04/11

const値はある程度展開される

こんなコードを書いていた。

const char val[] = { 1, 2, 3, param, 4, 5 };

何かというと、配列の初期化子に変数が入っているのだ。
私のイメージとしては、初期化子はROM領域にあり、memcpy()でRAMに展開される、というものだ。
間に変数が入ることでどうなるのだろうか?

gcc -Sでコンパイルすると、全部展開されていた。
つまり、1byteずつmobvで代入されているのだ。
あらまあ。

movbが何バイトの命令かはわからないけど、1byteではあるまい。
2byteだったとしても、元のサイズの倍は必要になるのだ。
そりゃ確かに、アンロールすると高速にはなるだろうけど・・・。

かといって、変数をなくすと展開しないかというと、そうでもない。
初期化子のサイズ次第みたいだ。
-Osとかしても変わらない。

ふーん。
なんか落ち着かないが、仕方あるまい。
ARM版のgccでも同じなのかな?

[hw]SmartQ5の枠を開けた

うちにある、一番Android端末っぽい端末。それがSmartQ5。

思えば、私のAndroidはここから始まったんだった。しみじみ。。。
それを分解した。
分解といっても、外枠を外してねじをとるだけなのだが、枠がなかなかとれなくてね。

なんでこの時期にいきなり触りだしたかというと、RC-S620/Sだ。
確か、S3C6410にはUARTが2つ付いているという資料があった。

SamsungのS3C6410XH-66が搭載されている。
銀色のチップは、WLANらしい。WM-G-MR-09。
SunDiskのはiNAND。
SDRAMが2つ。
SDカードソケットの上に載っているのはBlutetoothか。

哀しいことに・・・目を近づけても眼鏡を外しても、チップの文字が読み取れない。
いつか接続できる日が来るのだろうか。

2011/04/10

[falp]OBEX PUTを分割

そういうわけで、分割して送信しなくてはならない。

ツールで送信したら、Extendedフレームが使われていた。
私はNormalフレームのみでやりたいので、いくらか減らす必要がある。
見たところ、4byte減らせばよさそうだ。

まず、FeliCaコマンドが255byteまでになる。
そうするとFALPコマンドが251byteまでになる。
送信データが52byte以下なら、1回で転送可能。
それより大きければ、2パケット以上になる。

2つ目以降のパケットは、残りデータ数との兼ね合い。
242byte使えるので、最後に必要な26byteを気にしながら送信する。

まあ、正しくは、OBEX PUTのパケットを作ってしまい、それを242byte単位で送信する、だろう。
そうすれば、残りが何バイトだのあーだこーだのは気にしなくてよくなる。
そのくらいの空きはあるとしていいかねぇ。

[falp]1回の転送サイズは何バイトか?

さて、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とかになったらもういいんじゃないか?という気もする。

[bb]現在の構成

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とかに書いておけばいいんだけど。。。

JNIライブラリの使いまわしはどうやる?

朝からカラスがうるさい・・・。
不吉な朝だ。

とりあえずというレベルであるが、Androidアプリから文字列をFALP送信できた。
どこらへんがとりあえずなのかというと、
  • 数バイトくらいしか送信できない(複数パケットに対応してない)
  • ソースコードに埋め込んだ文字列しか送信できない
というあたりだ。
複数パケット対応はめんどうなので、まずはアプリの改修を行おう。


必要なのは、テキストボックスとボタン。
たったこれだけなのだが、アプリ慣れしていないのでめんどくさい。。。

そしてもう1つめんどうだと思っているのが、JNI。
今のところ、RC-S620/Sとやりとりする部分はJNIで作っている。
BeagleBoardでやっているので、プラットフォームのビルドと一緒にアプリもビルドさせている。
なので、できあがったアプリは/system/appにあるのだ。
そして共有ライブラリは/system/libにコピーされている。

ということは、共有ライブラリに関しては誰でもアクセスできることになる。
なのに、JNIライブラリ?と呼ぶのかどうか分からんが、共有ライブラリをJavaで呼び出せるようにしたclassはアプリの中にあるのだ。
格好が悪い。
共有ライブラリへのアクセスclassも、共用したい。
さて、どうやったらいいのだろう?

eclipseでI/Fだけのプロジェクトを作り、Is Libraryにチェックして、AndroidManifest.xmlなどを取り除いてからjarを作ってやればよさそうだ。

2011/04/09

[java]getBytes()で文字コード変換できるのか

FALPで送信する場合・・・というか、日本国内携帯電話会社のOBEXエンコードはShift-JISだ。
vNoteとか、vMessageとか。
エンコードを指定するタグはあるけど、意味があるのかどうかわからん。
まあ、それは気が向いたらやってみよう。

iconvとか使わんといかんのかと思っていたが、Javaではjava.lang.String.getBytes()でできるらしい。
ほほう、便利なものだな。


引数でCharsetを渡したら、それでエンコードしてくれるらしい。
変換できない文字は、デフォルトの変換用文字に置き換える、ということでいいのかな。
細かく制御したいなら、CharsetEncoderを使えばよいようだ。

さて、Charsetを見ると、Shift-JISは保証されてない。
つまり、実装されていないかもしれない。
うーむ。

まあ、まずは実装のテストだから、Shift-JISが使える前提でいいや。


しかし、getBytes()はどうやって実装されているのだろうか?
大きな変換テーブルがあるんだと思うが、iconvを呼んでいるのかな?

external/icu4cがあるので、これを呼ぶのかなぁ。

[nfc]RC-S620/S用ライブラリ更新

githubのRC-S620/S用NFCライブラリというか、FeliCaのI/Fだけ更新した。
まだFALPはつないでいない。
ようやく以前のレベルに戻った、というところだ。

URLのPUSHができるだけで、これといった特長はない。
BeagleBoardでしか試していないが、シリアルポートが使えるならなんとかなるんじゃなかろうか。

2011/04/06

[dep/falp]P2Pの方がおもしろい

NFCで何が面白そうかというと、NFCチップ間の通信か、カードとしての振る舞いだと思っている。
カードに書き込んだり、読み込んだりというのは、あんまりやる気が出ない。
NFCチップが、NFCカードとして振る舞うというのは、面白そうではないか。
というのは、なんか毎回書いているような気がする。

さて、NFCでP2P通信するならば、
  • ISO-DEP(ISO14443?)
  • NFC-DEP(ISO18092?)
  • FALP(FeliCa)
くらいだろう。
DEP系、Data Exchange Protocolは仕様を探し出せる。
しかしFALPは今のところ仕様が公開されていない(2011/04/06)。
まあ、DEPだっていきなり公開されていたわけではないだろう。
だからFALPだって、今は公開されていないだけであろう。
DEPやFALPが公開されたとしても、それだけでは手持ちが寂しい。
どちらもチップ間の通信プロトコルだけなので、アプリまでは達していないのだ。
FALPが「iC通信」として実装されているならば、FALPの仕様だけではなくiC通信の仕様が必要となるのだ。
DEPも同じ。
よく知らないけど、海外ではISO-DEPで実装したP2P通信があるのではなかろうか。
何となく例えると、「可聴音域の声を出すと聞き取ることができるようにはなった」というのがRF仕様で、「同じ言語を話しますよ」というのがDEPとかFALP仕様。
話し合う内容をあらかじめ決めておく、という部分がアプリ仕様だろう。
DEPやFALPだけでは、そこはカバーできていない。
FALPではそこにOBEXが使われている。
オブジェクト交換だ。
DEPでは、LLCPとなるのだろう。
LLCPはそのまネットワークプロトコルにつながるので、応用は広い。
広いけど、ネットワーク関係を実装しないといかんので、いろいろと重たい。
限定されたOBEXならば、かなり軽くなるのではなかろうか。
なので、組込みの中でも制限があるならばOBEXのみで、もうちょっと余裕があるならOBEXとLLCPで、というのがいいんではないかなあ。

2011/04/03

[falp]シーケンス図

すごく適当なシーケンス図を載せておこう。

falp_seq.png

FeliCaのパケットは、最大でだいたい256byteくらいだ。
なのでファイルのような大きいデータを送る場合、分割する必要がある。

さて、パケットとしての分割は必要になるとして、その分割されたデータを受けとる方も考えなくてはいけない。
どのくらいの受信バッファを用意するか。
もちろん1パケット分は必要だが、もっとないと困る。
かといって、無限に用意できるわけでもない。
そこら辺をうまく解決せんといかん。

FALPではどうやっているかというのは、うっすらとしか記憶にない。
まあ、普通に考えれば、

  • 開始前に自分の受信バッファサイズを相手に伝える
  • 自分が受信できなくなったら相手に通知する
  • 自分が受信できるようになったら相手に通知する

というところだろう。
受信バッファサイズはいらんかもしれんが、バースト転送じゃないけど連続して送信できるサイズを知っておかないと、送信する方もバッファが必要になるのでな。

ああ、情報が欲しい・・・。

2011/04/02

[ndk]NativeActivityを使ってみる(2)

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を呼び出すことになりそうだ。
そんなのを全部フレームワークにしてしまうのも、大変だ。
使うものだけ定義する、という手もあるが・・・。

まあ、次にやることがあるかもしれんが、今回はこの程度にしておこう。