[8byte]NFCID2は、いわゆるIDm。コマンドを投げるときにシステムコードを要求すると、メインのシステムコードも返ってくる。基本的にFeliCaにコマンドを投げる場合は、まず相手のシステムコードをInListPassiveTargetで投げておくのが無難である。追記1InListPassiveTargetというコマンドにまとめられているが、行っている内容は種別によって異なる。種別というのは、TypeAとかBとかだ。いうR/Wに投げたコマンドは、R/Wがエアプロトコルに変換してターゲットに投げる。ここも、例えばPOL_REQなどに変換されているのだ。POL_REQのパラメータが、InListPassiveTargetのパラメータと一致している。X5211を見るのがよかろう。foundとhw_get_module()昨日の続き。カメラアプリが起動しないので、その調査。found!!!omxはどこをたどるとよくわからないので、logcatで最初に出ているこれを見ていこう。cgrepで探してもいいけど、ALSAでHardwareと書いてあるので、hardwareディレクトリにいってalsaという名前を探すと、alsa_soundがあった。中にAudioHardwareALSA.cppがあり、見てみると上記のログがあった。cgrep/jgrepよりも、OESFさんが提供している検索サイトの方が、きっと速い。found!!!"が出る条件。それは、ALSAのモジュールが見つからないこと。・・・Androidでよく用いられる関数にhw_get_module()がある。hw_module_tのポインタのアドレスを渡すと、使えるアドレスを返してくれる関数だ。const**)&module);こんな感じ。hw_module_tはC++の基底クラスみたいなもので、各ハードウェアのI/Fはアドレスを取得した後、それをキャストして自前の構造体として使う。Cでvirtualっぽいしくみを実現するのによく使う手法だ。このhw_get_module()。**module)ALSA_HARDWARE_MODULE_IDは"alsa"。hw_get_module()は、"alsa"がわかればhw_module_tを返すことができるのだ。このプロパティがあるか。ro.hardwarero.product.boardro.board.platformro.archあったら、そっから文字列を引っ張り出して、"/system/lib/hw"か"/vendor/lib/hw"にあるかどうか。今は"/vendor"って使わなくなったように思うが、これは/deviceに移して、/vendorをそういう意味に使おうとしているだけなのかしら?歴史を追ってないのでわからん。それでもなければ、/system/lib/hw/*.default.soがあるかどうか。それであれば、もういいみたい。いうことは、そこら辺になかったのだろう。今回は、"alsa.*.so"がほしかったところ。ないのは、ビルドしてないからか、置き忘れか。いうところから、少しずつやっていかないかんですな。android2011/03/07[camera]OMXMaster::addPlugin()で落ちる思い出しながら、USBカメラを動かそうとしている。最後に動いたのは、froyoのとき。gingerbreadでもそんなに変わらんだろうと思っている。ディレクトリなんかは変わってたけど。ドライバは、USBカメラを認識してくれた。カメラアプリを起動させたのだが、いきなりアプリが落ちる。OMX_ErrorNoMoreなどといわれている。その後、mediaserverが落ちる。いうよりも、mediaserverが落ちるのは上記のせいだろう。わからないが、キーワードは「omx」「libstagefright」「openmax」というところか。openmaxは、Android.mkに出てきてた。libstagefrightは検索したけど、よくわからず。出てきたのは、OpenMAX。これはKHRONOSがまとめてる?やつで、OpenGLとかあんなのと同じ感じがする。ストリーミングのコーデックAPIをまとめているようだ。omxは、これの略だろう。カメラ画像はストリーミング的な扱いになっているのか?フレームバッファにばんばん書き込んでるだけかと思っていたのだけど。少なくとも、CameraHardwareはそんな風になってたな。Camera落ちた後は、こんなログが出ている。android.hardware.Camera.open(id)が呼ばれているので、たどってみよう。Cameraのコンストラクタが呼ばれ、native_setup()が呼ばれて。全部追わなくていいのだけど、ログがこれくらいだとわからんなぁ。Androidは久しぶりなので、リハビリがてら追っていくことにしよう。camera2011/03/06[camera]うちのUSBカメラは初期化に時間が足りないのか?USBカメラをBeagleBoardで使えるようにしていた。バッファローのBWC-35H01/SVというUSBカメラだ。昨年の10月くらいだったらしいので、ほとんど記憶にない。動くだろうと思ってやってみたのだが、だめ。デバイスのopenでこけているみたいだ。デバイスドライバのところ。記憶にないので過去の記録を探ったところ、少し残っていた。デバッグログを出すことで対処していたようだ。それを対処と呼んでいいのかどうかは分からんが。追加したのは、drivers/media/video/sn9c102/sn9c102_core.c。そこのsn9c102_i2c_try_raw_write()。sn9c102_i2c_wait()の直後に、DBG(2)とかでログを追加しただけだ。ログじゃなくても適当なwaitを追加すればいいんじゃなかろうか。・・・呼び出しているのがそもそもwaitの関数だよな・・・。linux[linux]シリアル通信の設定RC-S620/Sでの開発はやらない!と書いたものの、中途半端なのはいかん。Androidで動くかどうかくらいは見ておこうか。なると、やることが多くなる。弱気なので、Linuxで動くことの確認、にしよう。いくつかの修正が必要だったが、動いた。必要な修正のほとんどは、シリアル通信についてだ。今回はこのような設定で動いた。&ter);受信がなかなか動いてくれなかったのだが、CREADしてなかったせいだと思う。思うのだが、削ってみても動くようになった。設定が残っているのか?いつも忘れてしまうのが、カノニカル、非カノニカルの意味。おおざっぱに言うと、リターンを押すまで出力しないのがカノニカルで、文字入力する度に出力するのが非カノニカル、ということになろう。linuxWindowsのオーバーレイアイコン数には上限があるらしいTortoiseSVNとTortoiseGitを使っている。TortoiseGitの方は、あんまり使っていないが便利そうなのでインストールしている。Explorerのオーバーレイアイコンが同じであるため、見分けにくい。Windowsの場合は.gitとか.svnとかがあるのでわかるけど、できれば見た目でわかった方がうれしい。なんとか見分けられるようにできないだろうか・・・。調べていると、どうやらWindowsのオーバーレイアイコンは15個までと決まっているらしい。アプリとして使えるのは11個。それなら、別々になると他が不便になるか。そんなわけで、あきらめることにした。windows仕様がないものを売るなDEPをやろうと、いろいろRC-S620/SのコマンドをPN533の仕様書やISOやらJISやらを見ながらやってきた。なんだ、この無駄な作業は?と思ってしまった。普通は部品を買うと、仕様書が入手できるはずだ。汎用部品ならともかく、RC-S620/Sはけっこうなデバイスだ。仕様書が別売りといっても、一般人の入手ルートはない。RC-S620/Sは一般人が入手できるのだ?というようなことを思いついてしまった。考えなければよかったんだけどねぇ。いま持っている資料だけあれば、たぶんLLCPとかまで実装はできると思う。いって、うちにあるP906iのiC通信(だっけ?)ができるわけではない。これは、FALPの仕様書がないからだ。そんなこんな考えると、FeliCaのカードが読みたいわけでもなかった私としては、買わなければよかったかも、という気がした。買ってしまっただけに、使いこなそうとして、あれこれやってしまう。NFCの仕様にはかなり詳しくなったような気はするが。本来の目的が果たせそうにない。いうわけで、土曜日の夜中なのに私は非常にお怒りである。権力があれば、数社つぶすくらいのお怒りだ(意味不明)。私が怒ったからといって何が変わるわけでもないだろうけど、それでもねぇ。felica2011/03/05[nfc][dep]私は考え違いをしていたように思う私は・・・DEPについて考え違いをしていたのではなかろうか。これは前回も書いたが、InDataExchange()の引数にする必要はないと思う。PN533・・・もそうだが、きっとRC-S620/Sもそうだと思いたい。PN533は、ISO-14443のDEPもサポートしている。それもInDataExchange()で自動的にやってくれていることになる。ISO-DEPとNFC-DEPを使い分けるのは、ホスト側が作るパケットというよりも、コントローラ側が現状を把握して使い分けているということになろう。私も今、DEP_REQ/RESで通信できていると書いているが、実は既にNFC-DEPかISO-DEPで通信しているのではないか?ということである。それがどうなのかを確認するのは難しい。リファレンス機というか対抗機というか、相手がいないからわからないのだ。PN533ではどこを見て使い分けているのかを調べておこう。ドキュメントp.102に、PN533からターゲットに渡すパケットが書かれている。ターゲットに応じてパケットの中身が変わってきている。p.153をみると、ISO-DEPの場合はSEL_REQの戻り値で区別しているように見える。Type-AはISO-DEPもNFC-DEPもどっちもいける。相手からの応答だけで判断できないはずだ。どっちでやるかの意志をどこかで示しているはず。私にわかるのは、ISO-DEPの場合はInListPassiveTargetから始まり、NFC-DEPの場合はInJumpForPSLから始まっているということ。InJumpForPSLは、ほとんどInJumpForDEPと同じはず。PSLだから、通信速度も変更するのかな?それくらいしか、違いがわからない。今はいきなりInDataExchangeをしているから、NFC-DEPになっていると思う。その認識でいいのかなぁ。nfc[nfc][dep]PFBはホストからは不要な気がしてきたPFBの仕様を読みながら、どう実装しようかと考えていたのだが、不要な気がしてきた。コントローラがうまいことやってくれるんじゃなかろうか。MIビットの有無は引数として指定するのよ。PN533のドキュメントで見ていなかったのだが、SecureなDEPのところで、Secureじゃないのとも比較しながらシーケンスが書かれているのだが、ホストからはPFBを指定してないのに、エアプロトコルになってからはPFBが出てきているのだ。InDataExchangeのところにもあった。ホストからPN533へはペイロードだけ渡しているのに、PN533からターゲットになるとDEPヘッダが付加されているのだ。これは、間違いなかろう。PN533は、PFBを制御している。RC-S620/Sはどうなのだ?これはわからない・・・。わからないが、私は何もしてないのに通信できているのだから、RC-S620/Sは何もしていないのでうまくいっているか、ちゃんと制御しているからうまくいっているのかのどちらかだ。なると、後者である可能性が高いな。私は男らしく、ライブラリからPFBの実装を削った。nfc[nfc][dep]中断後にエラーDEP_REQ/RESレベルでの送受信はできている。これはコマンドを投げれば返ってくるので、そんなに難しいことではない。こんな感じでDEPをやっている。今のところシングルスレッドでやっていて、ユーザ操作はほとんどできない。DEPでデータをやりとりしているのを中断させるのに、お互いを引き離す、という方法でやっている。このときの動きがそれぞれ違う。InitiatorにしているPaSoRiは、しばらくしてからタイムアウトしている。タイムアウト処理など組み込んでいないので、PaSoRiがしばらくすると返事をしてくれていることになる。Statusは0x13だ。TargetにしているRC-S620/Sは、すぐに終了する。TgSetDataがStatus=0x31で返ってくる。それはいいのだが、困っているのはその次。終了させようとしてコマンドを投げるのだが、エラーフレームと認識されてしまう。リセットコマンドは大丈夫なのだが、その次に投げているRFConfigurationがそうなる。あー、でも搬送波は出てなさそうだな。P906iが反応してない。エラーフレームはパケットの文法エラーなので、中身が間違っていることになる。普段は大丈夫なコマンドなので、少なくともそこの実装に間違いはない。すると、タイムアウトしてから送ったコマンドが残っているとか・・・とも思ったが、RC-S620/Sはタイムアウト時間を持っていて、それ以上経つと受信したパケットを破棄する。