2012/03/31

ARM LPC2388を使おうか

FeliCa Plugは、搭載された機器をNFC-Fカードとして振る舞うときに利用できる。

たとえば、AndroidのADKがあるではないか(持ってないけど)。
Arduinoで実装してあることが多いようだが、そこのSPIとFeliCa Plugをつなげて制御すれば、NFC-F対応ADKのできあがり、となる。

まあSPIを使わなくても、前回みたいにRFDETピンをGPIOに接続して割り込みとかポーリングとかで監視すれば、NFCのR/W動作をするものがかざされたことを検知することはできるだろう。

そういう、NFCセンサ的なこともさせることができるが、せっかくならNFC-Fとしても動作させた方が面白いかと思う。
まあ、順番にやっていくとよいだろうね。


さて、うちにはArduinoはないが、ボードはいくつかある。
BeagleBoardみたいな高機能なものもあるけど、こういうものは電池で動くくらいのものがよさそうだ。

そうなると、あれだ。
Interface誌の付録ボードがたくさんあるので、それがいいだろう。
もったいないことに、定期購読して確実に入手できるようにしたのだが、ボードを使って遊ぶ時間が取れてない。
その基板を生かすいい機会だ。

 

付録ボードは7枚。
SHにRXやV850、FRにARMなんかもある。
今は仕事でNEC系のチップ(NFCじゃないよ)を使っているので、V850はやめとこう。
日立系も使ってるので、SHとRXもやめとくか。
FRは前のプロジェクトで使ってたので、まあいいや。
となると、ARMですかね。
ARMも前の前で使ってたんだけど、まったく覚えてないからちょうどいいや。

 

というわけで、Interface誌2009年の付録であるNXP LPC2388ボードを使うことにしよう。


では、またBSch3Vエディタで図を描いてみよう。

image

こんなイメージでいいのかしら?

簡易的なSPIで、Host側がマスタになればよさそうだ。
割り込みはGPIOで受け付けられるらしい、ということまでしか読み取れていない。

ARM7vは、/IRQと/FIRQの2つしか外部割り込みとして使用できないけど、LPC2388は前段にVICという割り込みコントローラ(8259Aみたいなの?)が入っているので、割り込みハンドラにジャンプしてから割り込み要因を調べて分岐する、というような作りになるっぽい。

全部のGPIOが割り込みに使えるのかわからんし、制約事項も読んでないから、まずはSPIではなくGPIOと割り込みからやっていこうかね。


2週間くらいブログ更新を休もうと思ったけど、休日くらいは書いてストレスを発散させておこう、というところだ。

回路図エディタを使ってみる

回路図を前回描いたが、非常にめんどくさい。
パーツがあるわけでもないので、ちまちまと描いたのだ。

そういえば本屋に行ったとき、SPICEとかいうものがあったことを思い出す。
回路シミュレータらしいが、描くだけだったらそこまでわからなくても使えるんじゃないだろうか?


いくつかあったが、LTSpiceというものを使ってみた。
・・・ヨクワカリマセンデシタ。

FeliCa Plugの部品まで作ったのだけど、やはり図を描くだけという目的にしてはめんどくさすぎる。
Visioみたいなのがいいんだけど、持ってないしなあ。

 

そんなわけで、純粋な「回路図エディタ」を探すと、いくつかあった。
トップに出てきた、「水魚堂の回路図エディタ」を使った。
まだ使い慣れていないが、あまり深く考えずにお絵かきの要領でやってみた。

 

image

 

おお、大したことを描いたわけじゃないのに、それっぽい。

Mifare、ではなく、MIFARE

FeliCaは、ちゃんと「FeliCa」とFとCを大文字にして記載している。
たしか、カタカナもOKだったと思う。

それに対して、MIFAREについてはそれほど気にしていなかった。
以前は全部「MIFARE」と書くようにしていたのだけど、mifare.net、というページ名だったのであまり気にしないのかと思って、英語っぽく先頭だけ大文字にして「Mifare」と最近は書いていた。

 

今朝、ふとlibnfcのバージョンを確認すると、1.6のRC1が出ていた。
変更履歴を見ると、先頭に

- utils/nfc-mfclassic: use MIFARE instead of Mifare typo

と書かれていた。

おおう...
mifare.netも、ページ内を読むと「MIFARE.net」と書いてあった。

登録商標にはちゃんと気を配らないといかん、と思った次第である。

FeliCa Plugで搬送波を検知させる

黒パソリって、黒いやん。
シックといえばシックなのだが、NFCって目に見えないので、なんか寂しい。

私はもっと激しいアクションを求めているのだ!
時に笑い、時に泣くような、そんなNFCがあってもいいんじゃなかろうか。

そんなわけで、13.56MHzの搬送波を検出するしくみがないかな、と考えていた。


最初は、NFCシールのアンテナ部分で得られる電流でなんとかならんか、と考えていた。
やり方がよくわからないので、NFCシールのチップっぽい両端にテスターのプローブを当てて電圧とか電流を測ろうとしたが、だめだった。

弱いのかもしれんし、うちの無印デジタルテスターが今ひとつなのかもしれん。
(だって、ショートチェックのためにプローブをショートさせてもブザーが鳴らないんだよ?)
安物買いはやっぱりいかんな、ということで、そういう手段は諦めた。


第2弾は、やはり半導体を使う案になってしまう。
困ったときのFeliCa Plugだ。
前回の記事も、この前段階のためにやっていたのだ。

まあ、適当な回路を見てもらおうか。

P1000001

ばばーん。
回路図にすると、こんな感じ。

circuit

未だにプルアップ抵抗の値をどうすべきかよくわからんのだけど、オームの法則と仕様書からちゃんと計算できるものらしいが、やっぱりわからん。
※SW, SELはプルダウン、SPICLKはプルアップ、とのこと(ユーザーズマニュアルより)

13.56MHzの搬送波を検出するまでは、/RFDETはHのまま。
Hだと、VDDと電位差がないので、LEDの両端はほぼ同じ電圧。だから、何もならない。
搬送波を検出すると/RFDETがLになり、VDDと電位差が生じる。
高いところから低いところへ流れるようになり、LEDが点灯する。

プルアップ抵抗が必要な理由がよくわかってないけど、/RFDETはOUTPUTだから入力が許容量以上にならないようにしよう、というところだろうか。

 

あー、勉強したいねー。

2012/03/29

[NDEF] UとSp

2週間ほど、ブログをお休みします。
理由は・・・忙しいから。
今まで書きたいことは書いたと思うので、閉鎖してもいいんだけどね。


手元に2枚のNFCカードがある。
両方ともNDEFで、URLが入っているのだが、バイナリを見るとデータ量が異なる。
そう、1つは「U(URI)」で、もう1つは「Sp(Smart Poster)」だったのだ。

さて、何が異なるのだろう?


NDEFレコードのタイプは、どちらもWell-Knownだ。

URIレコードの場合は簡単で、中にURLなどが入っているだけである。
あたまにつける「http://www.」とか「mailto:」などが略称番号として存在するなどというルールはあるけれども、基本的にはURLなどが入っているだけだ。

 

Smart Posterレコードの場合は、ちょっと複雑になる。
Smart Posterレコードのデータ部に、複数のレコードを含んだ構造になっているのだ。
中に入るのは、

  • タイトルレコード
  • URIレコード
  • アクションレコード
  • アイコンレコード
  • サイズレコード
  • タイプレコード

となっている。
この中で必須なのはURIだけで、あとはオプショナルだ。

 

気になるのは、アクションレコード。
今のところ3つしか値の種類がない。

  • 0・・・Do the action
  • 1・・・Save for later
  • 2・・・Open for editing

「Do the action」は、「ブラウザで開く」とか「メールを送る」とか「電話をかける」などの動作を求めるだが、「こうしなさい」という指示はしていない。
なので、受けとった側がそのURIにふさわしい動作をするのだろう。

「Save for later」は、「ブックマークに保存」とか「メールボックスに保存」とか「電話帳に保存」のような、保存動作。
これもまた、明確な指示はしない。

「Open for editing」は、URIを編集対象とするようだ。
これはあまりピンと来ていない。
URLだったら、ブラウザのURL欄に文字列だけコピーして、フォーカスして文字編集可能な状態にするだけ、ということだろうか。


 

というようなことを、いつもこんな時間から書き始めてしまって寝る時間が短くなるので、閉鎖お休みしよう、と自らに宣言しているわけだ。

2012/03/26

FeliCa Plugを開ける

引き出しを片付けていたら、FeliCa Plugが出てきた。
そうだ・・・1年くらい前に買ってから、忙しいのにかまけて開けていなかったんだ。

 

FeliCa Plugというのは、組込機器側に搭載することで、FeliCaカードのように振る舞うことができるようになる部品のことである。
IDmはある程度決められているので、カードになりすます、というような使い方はできないようになっている。
そういう目的ではなく、通信経路としてNFCを使おう、というものだ。

 

買ったのは、いつものようにスイッチサイエンス社
使い方も「Felica Plugの使い方」ページに書かれている(データフォーマットコードの説明があるので、スイッチサイエンス社から購入した場合は必ず読むべし)。
ただ、このページは写真がないので、英語版のページの方もあわせて読むとよいだろう。


私はRC-S802という小さい方を買った。
それと一緒に、変換基板も購入している。

さて、この変換基板との接続方法である。
写真を撮るのが面倒なので言葉で書くと、

  • RC-S802はチップが載った方を上にして、右側に置いた
  • 変換基板は、「FFC-8」と書いている方を上、「SWITCH SCIENCE」が下になるようにして左側に置いた
  • フラットケーブルは、文字が書かれていない方(白い方)を上にして、RC-S802と変換基板に挿した

としている。

FeliCa Plugの製品仕様書FeliCa Developers' Blogの記事を見ると、FeliCa Plugの1ピンはコネクタの左側、上記の置き方にすると上側になるはずだ。

しかし、スイッチサイエンス社の変換基板PDFでは、下側が1ピンっぽく見える。
JP1ってのはジャンパだろうから、ブレッドボードに挿す方だよなぁ・・・。
パターンを見ても、四角い穴が下になっている。
1ピンはGNDだから、そういう意味ではPDFと基板はちゃんと一致している。

とはいえ、RC-S802のコネクタ付近には、うっすらと1ピンマークが見える。
だから、変換基板は一般的なピン配置にしているだけと考えておこう。

なぜここまでびくびくしているかというと、以前RC-S620/Sを逆に接続して壊してしまったことがあるからだ。
あのときは、変換基板に書いてあるピン番号だけを信じて、実際に接続する方を考えていなかったのだ。
考えてみれば馬鹿なことをしたもんだと思うのだが、自信がないときは得てしてそういうものだ。

2012/03/25

PaSoRiでカード状態を知ることはできるか

体の調子が悪くて頭が回ってない。
花粉症、という言葉から逃れられなくなってきたような気がする。
しばらく活動休止しようかしら。

それはそれとして、やりかけのandroid-x86だ。
定期的にポーリングしてカードがかざされたことを検知するしくみは、できた。
さて、カードが取り除かれたことをどうやって検知したらいいだろうか?

私としては、無線コマンドをばんばん出すのは、あまりやりたくない。
仕方ないならやるが、PaSoRiが知っているのなら、それを問い合わせるとよいと思った。

 

PN533にはGetGeneralStatusというものがあるので、まねしてやってみた。
・・・うーん、よくわからない。
カードがあってポーリングしたときと、カードがないときにポーリングしたときの違いがなかった。
やり方が悪いのか、考え方が違うのか。。

 

この部分が解決できれば、アイオイさんのSmartTagSampleがちゃんと動くんじゃないかと期待している。
いっそのこと、android-x86じゃなくてエミュレータに組み込めるといいのだろうが、ビルド方法がよくわからんな。

2012/03/24

血圧計がやってきた

 

私ももう若くない。
いつ何があったとしてもおかしくないし、こういう生活をしているので他の人よりも体が傷んでいるような気はする。

かといって、それを甘んじて受け入れることもないだろう。
少なくとも、予兆くらいはわかっておいたほうがいいだろうし、周りも心の準備ができるというものだ。

では、予兆はどうやって知ればよいか?
毎日病院に行くわけにも行かないし、専属のドクターを雇うのも無理だ。
ならば、家で出来る範囲のことをやるべきであろう。

 

そんなわけで前置きが長くなったが血圧計を購入した。
単に買いたかっただけなのだが、なんか理由がないと自分を納得させられないから困ったものだ。


image

オムロンさんの、HEM-7250-ITだ。
AmazonのJoshinさんで、8500円くらいだったか。
近所のヨドバシで買うつもりだったのだが、まあそれはいいとしよう。

思ったより、小さい。
が、実家にあるのもこんなサイズだったか。
カフ(マンシェット)がけっこうしっかりしている。
2人まで計測記録でき、その切替はハードスイッチで行う。
ハードスイッチにするとコストが上がるのでソフトでやってしまいそうになるところを、ユーザの利便性を考えてハードスイッチにしたのだろう。

 

外部とのI/Fは、

  • 矢印ボタン(左右1つずつ)
  • 記録呼び出しボタン
  • 測定・電源OFFボタン
  • 時計設定ボタン
  • ユーザ切替スイッチ
  • USB miniB
  • カフ取り付け口
  • FeliCa Plug

だ。

そう、この子はFeliCa Plugを搭載していて、NFCでの通信ができるのだ。
いつの間にかここのブログはNFCのことを中心に書くようになったので、今回もNFCに関係することを書いておこう。


オムロンさんの「ウェルネスリンク」というサービスが関係してくる。
ウェルネスリンクにユーザ登録しておくと、血圧などの計測結果をウェルネスリンク上に登録・管理することができるようになる。

計測結果を通信するルートとして、

  • パソコンとUSB接続し、インストールしたソフト経由でサーバに登録
  • NFCで携帯電話と通信し、インストールしたソフト経由でサーバに登録

の2種類がある。

計測結果をネット上のサーバに置くことができると、いろいろとメリットがある。

  • 計測結果が血圧計だけにあるわけじゃないので、ネットにつながれば見ることができる
  • 血圧計本体に記録を持たせることになると「どのくらいの量を保持するべきか?」というメモリ容量を決定しなくてはならない。
    内蔵FLASHなどに持つとしても、上限はある。かといって外部SDカードなどにすると扱いがそれはそれで面倒になるし、価格も上がる。
    ネット上に置くことを前提にすることで、本体のメモリ容量をそれほど多くする必要がなくなる。
  • データを保持したら、そのデータの見せ方も考える必要がある。
    1年分は保持する、などとした場合、○月○日のデータにアクセスする方法を考えたり、データを消す方法を考えないといかん。
    数値だけでなく、グラフで見たいと考えるようになると、液晶もグラフが表示出来るようなタイプにしなくてはならない。
    ネットに置くのであれば、データの加工はネット側に任せて、本体は少量のデータを表示させる程度の機能で済ませられる。
  • こういったもろもろのことが、開発工数を減らし、原価を下げることにつながる。

などなど。
ネットにつなげられないソフトばかり作っている身としては、うらやましいところである。

 

しかし、なぜUSBとNFCの2経路があるのか。
パソコンがあるなら、USBだけでいいやん。
そう思ったのだが、実際に血圧を測ってみるとそうでもないことがわかった。

  • パソコンに電源を入れんといかん
  • USBケーブルが邪魔
  • 計測結果をサーバに置きたいだけなのに、パソコンもUSBもいるなんて・・・

そんな気分になってしまった。
まあ、うちなんかは家にいる間はほぼパソコンがついているからいいんだけど、Windowsばかり使っているわけでもないし、体調が悪いときだったらパソコンを使いたくもないだろう。

 

私はi-modeの使える携帯電話なのだが、それでも使うことができた。
iアプリDXをインストールしてユーザ登録しておき、アプリを起動したら血圧計にかざすだけ。
実に簡単だ。
血圧計は90回分まで記録するので、そう頻繁にサーバへアップする必要もないが、アップするとデータが見られるので、それはそれで面白いところだ。


さて、次にやるのはもちろん、PaSoRiでのアクセスだ。
それ以外なかろう?

NFCヘルスケアライブラリーを使うといいのだろうが、まあ勉強のためだ。
どうやって始めたもんだかなぁ。

NFCヘルスケアライブラリー

(※コメント欄も一緒にごらんください)

明日の土曜日を前に、SonyさんのNFCヘルスケアライブラリーが更新されたようだ。
http://www.sony.co.jp/Products/felica/business/products/NFC_healthcare.html

 

以前もダウンロードしようと試みたのだが、なんとなく企業向けっぽい感じがしたのでやってない。
それに、Androidのライブラリということを考えると、私は持っていないのであまり興味が引かれない。

 

動作環境を読むと、「NFC対応」と「おサイフケータイ対応」がそれぞれ書かれている。
NFC対応ってことは、最近つくろうとしているandroid-x86でも動くのかもしれない。
ちょっと心引かれてしまった。


で、なんで「明日の土曜日を前に」かというと、明日、うちにオムロンさんの血圧計が届くからだ。
もちろん(?)、NFCヘルスケアライブラリー(オムロンヘルスケア)に対応したHEM-7250-ITだ。

 

今週末は、おそらくバイナリ解析で終わるであろう。

2012/03/21

SmartTagサンプルが少し動いた

アイオイさんのSmartTagサンプルが少し動いた。

 

なんでか知らんけど、横向き。

smarttag1

かざすと、こんなのが出てきた。

SANY0003

 

しかし、なんかリトライを繰り返して、ずっと画面を更新し続けてしまった。
タイムアウト時間が足りないのか、ログをたくさん吐いているから間に合わなくなったのか、あるいは実装ミスか。。。

2012/03/20

[felica]extendedフレームはちゃんと対応しよう

nfc-felicaライブラリィも動いたので、ちょっと私すごいんじゃないの、なんて思っていた。
しかし、その傲慢をSmartTagのアプリは見逃してくれなかった。

タイトルからわかるかもしれんが、extendedフレームについてだ。

NFC-F・・・いや、FeliCa限定になるだろうか。
送受信するフレームとして、NormalとExtendedがある。
Extendedの方が9byte多く送受信できるのだ。

はっ、たかが9byte!

と思ってNormalフレームのみのライブラリを作っていたのだが、アイオイさんのSmartTagアプリはExtendedも使っているようだった。
対応していないうちのライブラリは、エラーにするなり例外にするなりで、うまく動いていない。
しまった・・・。

 

負け惜しみではないが、なんでNormalとExtendedができたんだろうか。
どっちか片方にしてくれればよかったのに。
と、規格に文句を言っても仕方がないので、対応中。

[android]パッケージ名とフォルダ名は別物なのだよ

まあ、ひどく当たり前の話なのだが、よかろう。

 

いま作っている、PaSoRiをandroid-x86で動かすパッケージは、フォルダ名でいうと

packages/apps/Nfc

以下に入っている。
このフォルダ名は、android標準環境のものだ。

私は、このNfcをがちゃがちゃと変更しただけ。
しかし、フォルダ名がNfcのままだと管理しにくいので、NfcServiceForPasori、と長々しい名前に変更することにした。

androidでビルドするとき、どのパッケージをビルドするのかは、設定による。
build/以下に標準的な設定があって、それをdevice/以下に自分の端末向けフォルダを作り、そこに設定を書いていく。
”lunch”などで選択するのは、その部分だ。
詳しくは、http://source.android.com/index.htmlに書いてあるかもしれないが、最新になってから見てないのでわからん。

android-x86の場合、私はこんな設定になっている。

============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=4.0.3
TARGET_PRODUCT=generic_x86
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=x86
TARGET_ARCH_VARIANT=x86
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=IML74K
============================================

たぶん、repoでとってきたそのままだと思う。
ここの「TARGET_PRODUCT」が、だいたいdevice/以下にあるフォルダを探すときの目安になる。
今回は、device/common/generic_x86という場所にあった。

この中に、packages.mkというファイルがある。
(*.mkというファイルは、makeファイルの一環で、mやmmするときにさらってくれるようだ。)
ここの環境変数PRODUCT_PACKAGESが、ビルドするパッケージになる。
今まではここに「Nfc」と追記していたのだが、フォルダ名を変えたので「NfcServiceForPasori」に変更した。

そしたら、ビルドされなかった。。。

理由は簡単で、PRODUCT_PACKAGESは「パッケージ名」であって「フォルダ名」ではないのだ。
パッケージ名は、各Android.mkのLOCAL_PACKAGE_NAMEなどに入っているようだ。
これを変更していなかったので「NfcServiceForPasoriというパッケージはない」とみなされたのだ。

はい、そんだけです。。

[llcp]シーケンスを引っ張る

ずっとやっていた作業だが、私の理解でLLCPのシーケンス図を描いた。
ページ数は少ないけど、苦労したのだよ。
疲れた・・・。

https://docs.google.com/open?id=0B33sikPWkTjQVmUwaWEzYmZTNU8wdTdmZW4zMEk1QQ

 

疲れたのだけど、これが正しいのかどうか判断できない。
実際に動かしてみないとわからん。

動かすまで待とうかと思ったけれども、いつになるかわからないので「誰か間違いを指摘してくれるかも」という期待で公開に踏み切った(おおげさ)。

 

でも、指摘は大歓迎ですので、よろしくお願いします。

[win]WindowsのVirtualBoxでもandroid-x86が動いた

Windows XP SP3(32bit)にインストールしたVirtualBoxで自分ビルドのandroid-x86-nfcを動かそうとしたが、PaSoRiの検索に失敗して動いていなかった。

前回、libusb関係を削除してみたが、結局だめだった(Windowsはちゃんと起動した)。
今使っているのは、ORACLEのVirtualBoxだ 4.1.10 r76836だ。
ダウンロード先はORACLEじゃなくて別のところだったけど(ネットが重たかったので)、まあ違いはないだろう。

最新版では直っているかも、と探したが、そういうものもないみたい。
VirtualBoxのダウンロードページを見ると「Extension Pack」なるものがあった。
USB 2.0デバイスをサポートした、というようなことが書かれている。
PaSoRiって、別にそんなわけでもないと思うけど、とりあえずインストール。

USBデバイスの設定で、EHCIコントローラを有効にできるようになったので、チェック。
念のためUSBデバイスフィルタに登録していたPaSoRiを削除して、もう一度追加。

そして起動すると・・・おお、PaSoRiがポーリングし始めた!
(私の携帯電話は、もっぱらポーリング検出器と化している。)

そんなわけで、動かすことはできました。
よかったよかった。


android-x86でPaSoRiをNFCチップに見立てた環境を作ろう、というシリーズ。

 

けっこう、書いているな。
ここに書いているときは、それに満足してしまって、開発資料を残していないことがしばしば。

今回も、また然り。
少しでも記憶が残っているうちに、何か残しておこう。

[win]メモ:libusb関係の削除

VirtualBoxでUSBがつながらない件を検索すると、libusbをインストールしているとうまく行かん、というのが見つかった。

とりあえず消してみよう。

 

 

  1. zipで解凍していたlibusb-win32を削除(フィルタの削除を先にした方がよい)
  2. windows以下をlibusbで検索して、削除
  3. usbdeviewで削除
  4. pnpfindでリストを出し、DDKのdpinstで1つ1つ削除。終わったらinfも削除

 

と、勢いだけでやってみた。
これからリブートするが、しばらく更新がなかったら必要なものまで削除してしまったと思ってくだされ。

2012/03/18

NfcF.transceive()も何とか動いたが、課題も残る

先週、今週と2週続けて行っていた、android-x86にNFC-Fだけ動かすようにするプラットフォームだが、まあまあできたと思う。

なにをもって「動いた」とするかだが、ここはKazzzさんnfc-felicaを判定基準とした。
まだNDEFは使えないので、カードを読み書きするアプリでなくてはわからないのだ。

ISOファイルを置いたけど、まだVirtualBox上のLive CDとしてしか動かしたことがないです。
http://ndrive.naver.jp/shareUrl/Vf5OtSfnapWWY97TUHeXTQw71xLbY4x9aSqLhlQMEvVnb7sLTh8AcHLP2Fu43x18DQ==
(追記)
Windows XP(32bit)にVirtualBoxをインストールして試したけど、起動はするがPaSoRiを認識できず。
CD-Rに焼いて、通常のLive CDとして起動させたけど、android-x86を見つけられずに起動せず。
私の環境では、Linux 64bit上で動かしたVirtualBoxでしか動作確認できなかった。
 

FeliCa Liteをかざしたとき。
書き込みはやってない。

image

 

nimocaをかざして、利用履歴を見た例。

image

 

昨日はまだ読み取れていなかったので、たいしたものだと思いたい。

何がだめだったかというと、CommunicateThruEXの戻り値を返すやり方がよくなかったのだ。
私のライブラリはNFC-F向けにできていて、返すデータはデータ長を除いたパケットの先頭からにしていたのだ。
よく考えると、パケットの頭にデータ長がつくのはNFC-Fだけなので、自分のライブラリも考えておいたほうがよいな。
違うシステムを使うと、いろいろと見えなかったところが出てくるな。

[felica]なんとなく、FeliCa Liteの紹介スライドをつくる

なんでか忘れたが、先週FeliCa Liteの紹介っぽいスライドを作っていた。
紹介といっても「こんな商品ありますよ」というわけではなく、こういう特徴ですよ、というくらいのものだ。
画像もなくて今ひとつなので貼ったまま放置していたが、まあいいや。
http://www.slideshare.net/hiro99ma/about-felica-lite-11923160

たぶん、英語版も作ろうと思っていたのだろうけど、余力がなくてだめそうだ。
ちょっとここ最近やさぐれていて、精神的に余裕がないのよねぇ。

[felica]FeliCa Liteのデータを読む

Linuxの復旧をしている間は暇なので、FeliCa Liteのデータを読む話でも書くとしよう。


FeliCa LiteとアクセスするRFパケットは、FeliCa Liteのユーザーズマニュアルに構成が載っている。

image

もし私がFeliCa Liteのチップを直接制御してRFパケットを送信したり、R/Wのチップを直接制御してRFパケットを送信するなら、このパケットを作ってチップに渡さないといけないだろう。

しかし、仕事でそういうチップを制御するのならばともかく、ライブラリやドライバを介してアクセスするのであれば、ここまでパケットを作る必要はない。
だいたいこんなもんだろう。

image

パソリを使うときは、パソリに対してのパケットフォーマットがある。
また、「パソリからFeliCa Liteカードに対してこれを送信してくれ」というTHRU系コマンドを使ってやらないといけない。

SDK for NFC Starter Kitなんかは、そこまでラップしてくれる。
なので、作るのはLENから始まるデータだけでよい。


それを踏まえて、読み込むコマンドを見ていこう。
名前は「Read Without Encryption」である。
NFC Forumの名称でいえば「Check」になる。

細かい説明は省こう。
1ブロックだけ読み込むなら、こんな感じだ。

image

カードのIDmは、ポーリングで取ってきた値そのまま。
サービスは、最初の01がサービス数、次の2byteがリトルエンディアンでRead Onlyブロックを意味する(Read/Writeブロックも読める)。
ブロックは、最初の01がブロック数、次の2byteが2バイトブロックリストだ(説明が面倒なので、詳細はユーザーズマニュアル参照)。

 

受信は、こういうデータになる。
LENは手計算なのでちょっと心配だが、とにかくこのデータ全体だ。

image

失敗すると、Statusのところまででデータが終わる(ブロック数まで入ってたかどうかは、覚えてない)。
とにかく、必ず返ってくるわけではないことに注意して実装しなくてはならん。


と書いてきたが、まだLinuxの復旧が終わらない。
64bit版のところに間違えて32bit版を上書きしたのが非常に痛い。。。

2012/03/17

android-x86で人様のアプリを動かす

なんとか、NfcF.transceive()まで動かすことができた。
なかなか動かなかったのは、いつものつもりで「ポーリング→コマンド発行」としているつもりだったのだが、ポーリングを定期的に行っているので、すぐにRF OFFにしていたのだ。
そうすると、捕捉が途切れて次のコマンドに失敗する、ということだ。


さて、ここまで動くと人様のアプリを動かしてみたいというのが人情だ。
NFC-Fを使っていて、なおかつtransceive()まで使っていて、そして自分でビルドできるソースが公開されているか・・・。

あった。
nfc-felicaだ。
Androidは詳しくないのだが、とにかくカード情報を細かく読んでくれそうだ。
さて、動くかどうか・・・。

image

おお・・・と思ったが、利用履歴が動かなかったし、書き込みの方も動かなかった。
logcatを見ると、いっぱい例外を出している・・・。

うーん、まだ本物には耐えられないか。
まあ、目標なく作っていたので、ちょうどよかった。

Android Beamの送信側は、たぶんターゲットになる

まあ、たぶん、だが。
Androidは、通常ポーリングをばんばんしている。
カードを探しに行ってるのだ。
だから、相手がRFを出してきても困る。
Beamを送信する人は、まずターゲットになって相手からポーリングしてもらうという受け身の立場になるはずだ。
まあ、だからどうしたって話だがね。

android 4.0.3ではNFC-FがNDEFフォーマット可能とは判断されないようだ

オリジナルのソースファイルでは、ということになるが、android 4.0.3ではNFC-FがNDEFフォーマット可能と判断されないようだ。

試してないけど、ソース上はそうなっているみたい、というところ。


NativeNfcTagというTagEndpointを継承したクラスを作っていくのが習わしのようなのだが、そこにisNdefFormattable()という関数がある。
実装を見ると、

  • Mifare Classicは、OK
  • Mifare Ultralightは、OK
  • NFC-Vは条件付きでOK
  • ISO-DEPは条件付きでOK
  • それ以外はNG

となっていた。

NFC-Fはだめかー。

 

まあ、NFC-FでNDEF対応できそうなカードと言えば、FeliCa Lite。
FeliCa LiteがNDEF対応になっていなかった場合、

  • 1次発行が完了していたら、NG
  • 1次発行していないなら、可能ではあるがMCブロックの書き換えが必要

となるので、システム側でやるにはちょっと難しいところだ。
IDmとシステムコードじゃなくて、中身のデータを読んで判定するような仕組みの方がよかったのかなあ。

まあ、なんかいろいろとあったのだろう。

android-x86でIDmをとるだけのイメージファイルを作る

先週やっていた、android-x86でパソリを使ったNFCを動かすサンプル。
まだIDm (つまり、NFC-Fのみ) 取得しかできないが、NAVERドライブというところにISOイメージファイルを置いた
パスワードは、ここのブログ名と同じもの。

300MBくらいあるので、よろしければ、というところだ。


  • うちでは、まだUbuntu 11.10 (64bit)のVirtualBoxでしか動かしていない。
    VirtualBoxの場合は、USBデバイスとしてパソリを許可しておいてやらんといかん。
  • あ、そうそう、まだLive CDとしてしか動かしたことがない。
    HDDにインストールはしていないのだ。
  • 長時間放置してAndroidがLockスクリーンになると復帰させる方法がわからない。
  • 起動時に、DHCPに接続しにいくようにしているので、注意しておくれ。
  • あと、NFCは強制ONしかない。


今のところ、本当にIDmとシステムコードしか取得できない。
ここまではまだ簡単だったけど、transceive()なんかは敷居が高そうなので手が出ていない。

もうちょっとがんばるかねー。

2012/03/11

[android]やはりAndroid4にはIMountServiceがなさそうだ

EjectSDがAndroid4で動かなかったような気がした。
android-x86を動かしたので、そこでやってみた。

I/dalvikvm( 1570): Could not find method android.os.storage.IMountService.unmountVolume, referenced from method com.blogpost.hiro99ma.EjectSD.EjectSD.clickAction

W/dalvikvm( 1570): VFY: unable to resolve interface method 36: Landroid/os/storage/IMountService;.unmountVolume (Ljava/lang/String;Z)V

少なくとも、unmountVolume()はなくなったみたいだ。
でも・・・ファイルはあるし、APIもありそうなのだよなあ。

public void unmountVolume(String mountPoint, boolean force, boolean removeEncryption)  throws RemoteException;

赤文字の引数が増えただけ?

まあ、同じソースファイルをAndroidバージョンごとに変更するような、そんな器用なまねは私にはできんのだ。
動かないと報告してくれた方には申し訳ないが、許しておくれ。

[java]system.arraycopy()に一人でだまされる

memcpy()がしたかった。

しかし、Javaでやり方がわからんかったので、for文でぐるぐる回していた。
まあ、効率が悪いですな。

今日、ようやくsystem.arraycopy()なるものを知り、使ってみた。
・・・値が0になる。
なんでだ??

 

引数がね、最初にsrc、次にdstの順だったのですよ、奥さん。。。
昔は私も、memcpy()の最初が何でdstなのか疑問に思った時期があったかもしれない。
しかし、インテル系の命令なんかに慣れていったせいか、どうにも思わなくなった。
すれてしまったんですかね(ドキュメントを読んでないだけ)。

ちなみに、C#もsrcを先に書く文法だったと思う。

android-x86でパソリにNFC-Fをかざしてインテントを受け取る

続きだ。

ポーリングまではNfcService内で収まっているので、そんなに難しくなかった。
ここからインテントを飛ばすようにするのが、大変だった。

DeviceHostをimplementsしたNativeNfcManagerクラスを作ったのだが、それだけでは足りない。
タグのために、DeviceHost.TagEndpointをimplementsしたNativeNfcTagクラスを作らねばならなかった。
NativeNfcManagerがデバイスの操作、NativeNfcTagがカードの扱いをしているようだ。

困ったことに、このあたりはソースにコメントがないので、どのデータがどうあるべきなのかがわからんかった。
本物の方は、NfcServiceのJava、libnfc-jniのJNI、libnfc-nxpのC/C++と、あれこれ入り組んでいるし、コールバックでやりとりしていてソースを追っても理解するのが難しそうだった。

なので、今回はNFC-Fに限定し、IDmとシステムコードだけをインテントで返すことに専念した。
PMmは・・・私のライブラリでは捨てているので、なしだ。
IDmは、getUid()で値を返せば、NfcServiceがうまくやってくれる。
PMmとシステムコードは、getTechExtras()でExtrasに入れていた。
前半の0~7バイト目にPMmを、8, 9バイト目にシステムコードを入れているようだ。

 

このあたりのデータの詰め方を把握しないと、移植はできんと思う。


ここまでやって、パソリにNFC-Fのカードをかざすと、TAG_DISCOVEREDに対応したアプリでDmとPMm、システムコードを表示させることができた。
ポーリング周期は1秒。
NFC-Fしか対応しないようにしている。Type 3 Tag前提じゃないので、FeliCa LiteやFeliCa Standardなどでも反応する。
反応はするけど、タグを読んだりする部分はやってない。

図にするほどでもないが、こんな構成だ。

image

 

疲れたー。
VirtualBox用のISOはあるけど、300MBくらいあるので公開できず。。。

かなりがんばれば、android-x86でNFCアプリ開発ができるところまでできなくもなさそうな気がする。
(すごい弱気・・・)

しくみをよくわかってないので、何もかもが手探りってのがよくないですな。
あと、Javaもよくわかってない。

NFCカードを見つけてACTION_TAG_DISCOVEREDを投げるまで

さて、android-x86にポーリングするしくみを作ろう。
自分のメモ代わりに書いているので、断片的になってしまうが許しておくれ。


ポーリング周期は、こちらを見る限りでは400ms周期。
http://bs-power-save-project.blogspot.com/2011/11/nfconoff.html

ソースを400とかでgrepしたが、出てこず・・・。
discoverに関する設定を見ると、Durationという変数があった。
コメントを読む限りでは、PN544が48ms単位で自動的に回してくれるような気がする。
深く追うのはやめて、適当にAndroid側で周期的なポーリングを行うことにしよう。

Androidは詳しくないのだが、AsyncTaskとかHandlerとか、そんなのを使うみたいだ。
UIは絡まないので、Handlerでいいんじゃないかな?
判断基準がまだわかってない。


そもそも、ポーリングだけすればいいと言うものではない。
ポーリングして、カードがなければすぐに寝ないと。
そしてカードがあったら、通知しないと。

どうやって通知するんだろう?

Interface誌2012/4月号を読むと、

ということでいいのかな?
NDEFが一番条件が厳しく、その次がTECH、なんでもありがTAGというところか。
if(NDEF) - else if(TECH) - elseというイメージでいよう。


最終的なインテントを投げるのは、NfcDispatcher.javaみたいだ。
dispatchTagInternal()が投げている。
たどっていくと、NfcServiceHandlerが元になるようだ。

mNfcDispatcher.dispatchTag()がNfcDispatcherの入り口。
NfcServiceHandlerがメッセージを受け取り、

  • MSG_MOCK_NDEF:NdefMessageを作ってdispatchTag()を呼ぶ
  • MSG_NDEF_TAG:NDEFがあるならそれを、なければnullでdispatchTag()を呼ぶ

とするみたい。
そして、MSG_MOCK_NDEFだのMSG_NDEF_TAGだのは、DeviceHostListenerをimplementsしているNfcServiceがonRemoteEndpointDiscovered()みたいな関数で持っている。
自分で用意するNativeNfcManagerのコンストラクタでNfcServiceはもらうことができるので、検出したらonRemoteEndpointDiscovered()とかを呼んでやればいい。

 

だと思う。


このあたりをごそごそといじると・・・

定期的にポーリングするようになった。
カードをかざすと、NfcServiceが落ちるようなので、とりあえず何か動いていそうなことはわかった。

いいんだか悪いんだか・・・。

android-x86+VirtualBoxでadb

軽い話を。

普通にandroid開発すると、adbでログを見る。
android-x86でもそうしたい。


基本的には、android-x86のページに書いてあるとおりだ。
http://www.android-x86.org/documents/debug-howto

うちでは、Ubuntu 11.04 64bitを使っている。
VirtualBoxは4.1.2_Ubuntuというやつみたいだ(Ubuntuソフトウェアセンターでインストールした)。

まず「Host-Only」について。
何も考えずにVMの設定画面を開いてネットワークの設定を「ホストオンリー」にすると、赤字で「ないよ」みたいに言われた。
検索して、まずVMではなくVirtualBoxの環境設定が必要なことを知る。

「ファイル→環境設定」から「ネットワーク」を選択。
エラーが出るときは、ここのリストが空になってると思う。
右端の+がついたアイコンをクリックすると、追加された。
特に変更などはいらんみたいだ。

このあとで、VMのネットワーク設定を「ホストオンリー」にすると、アダプタが選択される。


次に、adbを動かす。

android-x86を起動すると、localhostとなんかとeth0があるようだった。
しかし、どれも有効になっていないので、手動でやらんといかん。
ホストオンリーをデフォルトで追加したときは、DHCPになっているようなので、ここもDHCPでアドレスをとってくる。

まず、VMが起動した画面で「ALT+F1」と押す。
すると、VMの画面にコンソールが重なったような画面になる。まあ、コンソールなのだ。
私は、こうやった。

$ netcfg eth0 dhcp

特にエラーも出なかった。
もう一度「netcfg」だけ打つと、IPアドレスが取れていた。
元に戻るときは「ALT+F7」。

最後は、ホストとなるパソコン側。
adbが動くパスならいいんだろうけど、android-x86の説明に従って「out/host/linux-x86/bin」に移動することにした。

$ cd out/host/linux-x86/bin
$ ./adb kill-server
$ ./adb connect xxx.xxx.xxx.xxx:5555

これでいけた。
5555は、adbがデフォルトで使うポート番号だったと思う。xxx.xxx.xxx.xxxは、VM側がDHCPで取得したIPアドレス。

./adb devicesなどして確認してもよし、shellしてもよし、logcatしてもよし、だ。

android-x86を動かす

私は、RSSでブログチェックをしている。
メールも、twitterやSNSなどもほとんど活用してない。
基本的に、ブログやホームページをチェックする程度だ。

今週、ITproさんに興味ある記事があった。

Android 4.0をx86パソコンで動かしてみよう
http://itpro.nikkeibp.co.jp/article/COLUMN/20120227/383202/

やってみよう。

広島の方ではAndroidのハッカソンが行われているようなので、対抗して一人ハッカソンだ。
・・・嘘です。単なる偶然です。


私はVirtualBoxで動かしたかったので、書いてあることはほとんど読まず、android-x86のページを見た。
いや、書いてあるとおりにやったら動かなかったので、普通にやったというところか。
ITproのページではgrub周りを変更してあるし、ベースとなるPCがうちと違うためだ。

インストールせず、isoファイルをそのままCD-ROMみたいにして動かすと、動いた。


もちろん、これだけをやりたいわけではない。
ちょっと昔の話をしよう。

私がSonyのRC-S620/Sを購入した後だったか前だったか、Android 2.3が発表された。
初のNFC API対応だった。
ソースをダウンロードして、NfcServiceを見て、このくらいなら移植できるんじゃないか、と思った。

そしてやってるうちに、2.3.3だか2.3.4だかが出てきて、一気に複雑になって挫折したのだ。
まあ、おかげでJNIやらなんやらを試すことができたのだが、なんとなくもったいない気持ちだった。
その後、BeagleBoardに自前ライブラリなどは載せたものの、Androidの標準APIとはつなげられなかったので、何とかしたいと思っていたような気がする。

というわけで、今回の一人土日ハッカソンは、「android-x86で少しくらいパソリを動かす」だ。
全部動かそう、とか、APIとつなげよう、なんて大それたことを2日でやっちゃいかん。


まず、android-x86のソースを見て困ったのが、NfcService周りのソースがないこと。
コンパイルされないようにしているわけではなく、そもそも入ってないのだ。
これは、android-4.0.3_r1から持ってきた。

 

持ってきたからと言って、そのまま使えるわけではない。
次の作業は、NfcServiceからlibnfc-nxpを分離する作業だ。
libnfc-nxpという名前からするとlibnfcの分派のように聞こえるが、全く別物だ。
こちらは、NXPがじきじきにメンテナンスしているものだ。
たぶん、これ

NfcServiceは、packages/app/Nfc以下にある。
そしてAPIは、frameworks/base/core以下にある。
見たところ、API側はいじられてないようなので、方針としてAPIには手をなるべく入れないことにした。
Javaはわからないので、あまり触りたくない、というのが本心だ。


2.3.4くらいのときと違って、packages/app/Nfc以下も整理されていた。
nxpを制御する部分がかなり分離されているのだ。
これは、好都合だった。

やってからわかったことだけ書くと、DeviceHost.javaがネイティブとのインターフェースになり、それをうまいこと実装すれば移植しやすいようである。
それがわかるまでは、NfcServiceから先に手をつけ、DEPやLLCPをごそごそ削り、システム側と整合が取れなくなってコンパイルエラーやら動かないやらでてんやわんやだった。

やるなら、まずnxpパッケージを削除して自前のパッケージを追加し、そこにDeviceHostのimplementsクラスを作るとよさそうだ。
名前をNativeNfcManagerクラスにしておくと、NfcServiceとつなげやすい。

あとは、NativeNfcManager側のLLCPを無効にしたりしつつ、NfcServiceで使わないものを整理していくと、そこそこ形が整う。
注意としては・・・ビルドだろうか。
android-x86だが、どうも1回だけしかmでビルドしないと、依存関係がうまく解決できていないのか、VirtualBoxで実行しても異常動作を起こすことが多かった。
ソースを変更せず、もう一度mするとうまくいったので、順序の問題っぽい。
これがわかるまで、動きが毎回違うのかと思って苦労した。


ここまでは、NfcServiceだけの話。
私はパソリを動かしたいので、USBもなんとかせんといかん。

libusbを移植して自前の環境を持ってこようかと思ったが、Android 3.2のときにUSB Host機能を使ってパソリを動かしたことを思い出した。
そのライブラリをNfcServiceで動かせば、あっさり動くだろう。

 

・・・動かなかった。
タイミングの関係だか書き方が悪いのだかわからんが、動かなかった。

アプリでUSB Host機能を動かすとわかるが、普通はユーザに「このUSB機器をつないでもいい?」という認証を求めてくる。
(求める要求はアプリで果敢といかんが、画面はシステムが出してくれる。)
この認証画面が出てくるのが、NfcServiceの起動と重なり、認証させる画面と同時くらいにサービスを動かそうとするためか「サービス起動に失敗した」ダイアログが表示され続け、認証画面にたどりつけなかったのだ。
まあ、書き方が悪かったんだろうね・・・。


しかし、通常使うのであれば、わざわざダイアログが出てきて認証させることがいやだ。
パソリだけを優遇してやろう。

と、今では書いているが、そうするまでかなり迷った。
ダイアログを出させて認証させてから動かす方がよいかどうか、だ。
最終的には「いいんじゃないの」としたけどね。

この「特別扱い」の実行が最後までわからなかった。
frameworks/base/services/java/com/android/server/usb/UsbSettingsManager.javaを見ると、認証しているのはcheckPermission()だ。
これは、USB Host用とUSB Accessory用とそれぞれある。
私としては、認証済みリストにパソリを最初から含めたような作りにしたかった。

認証済みのものは、/data/system/usb_device_manager.xmlにファイルとしておかれているようだった。
ソースで見る限り、だが。
ならば、このファイルを作って置いておけばいいだろう。
・・・と思ってからが長かった。
だめなのだ。私にはわからんかった。

Androidを移植したことがあるとわかるが、最初のルートファイルシステムをどう作るかは機種によってまちまちだ。
私はSmartQ5とBeagleBoardしかないのだが、それですら違いがあるのだ。
android-x86では、どうも/dataに相当する部分はマウントしないみたいである。
最初、/data/system/usb_device_manager.xmlというファイルを置いていたのだが、読んでくれなくてadb shellで確認した。

ならば、とinit.rcの起動処理くらいにcpで/etc/に置いたファイルをコピーするようにしたが、それもだめ。
/etc/init.shのタイミングだとコピーはできたが、UsbSettingsManagerのコンストラクタには間に合っていないのか、だめ。

いろいろ考えて実践したあげく、こうした。

    public boolean hasPermission(UsbDevice device) {
        synchronized (mLock) {
        	//PaSoRi OK(hiro99ma)
            if((device.getVendorId() == 0x054c) && (device.getProductId() == 0x02e1)) {
                Slog.d(TAG, "I am PaSoRi.");
                return true;
            }

ああ、笑うがいいさ。
格好が悪いが、べた書きでしか対応できなかった。


こうすると、android-x86が起動するとNfcServiceが起動し、パソリも自動的に認証して、NfcServiceのenableでポーリング開始を書いていたら、ポーリングしてくれた。
長かった・・・。

明日は、ポーリングをやりっぱなしではなく定期的に行うようにして、検知したらインテントを投げるように変更したいものだ。
ほら、やっぱりAPIとつなげるってところまでは無理そうやん。

2012/03/07

NDEFの資料を読もう (2)

NDEFのやりたいことは、前回でなんとなくわかったと思う。
XMLのようなツリー構造になっているわけではなく、シーケンシャルにNDEFレコードが複数集まったもの、それがNDEFメッセージのようだ。

 

NDEFレコードのことを細かく見ていっても面白くないので、気になるところだけ見る。


2.4.2 Payload Type

 

1番目のレコードが持つPayload Typeは、そのレコードのPayload Typeというだけでなく、NDEFメッセージ全体のPayload Typeでもある(SHOULD)。

この節は、説明が長い・・・。
まあ、必要になったら読めばよかろう。
とにかく、well-knownなもの以外も設定できるのだよ、と。


ここまでの知識で、手元にあるNDEFのデータを読んでみた。
touchanoteのタグ(Mifare UltralightC)と、SonyのNDEF writerで作った人からもらったタグ(FeliCa Lite)。

どっちも、URLを含んでいるのだが、表現方法が異なる。

 

touchanoteの場合、Type2の定義に従ったカードのヘッダ部分に続いてNDEFメッセージが始まっている。
いきなり、well-knownの「U」、すなわちURIになっている。

 

NDEF writerもらったタグの場合、Type3の定義に従ったカードのヘッダ部分に続いてNDEFメッセージが始まっている。
これは、well-knownの「Sp」、すなわちスマートポスターになっている。
SpのレコードにはMBとMEのビットが立っていて、このレコード1つしかないことになっている。
しかし、そのペイロード部分に複数のレコードを含むというメタ構造というのかしら、そういう構造になっている。

スマートポスターはNFC Forumのドキュメントとして別途存在するように、けっこう重要なwell-known typeらしい。


とまあ、こんな感じであった。

実物が得やすいし、NFC Forumのドキュメントにはサンプルもあるので、実装はそこまで難しくないように思う。

 

気をつけるのは、NDEFメッセージが始まるまでは各Tagによって異なるということかな。
Type2とType3では、それぞれ定義が別だった。
「NFC Forum Device Requirements」によると、NDEFメッセージのパーサは積まないといかんようなので、早めに簡単なものを実装したいものである。

NDEFの資料を読もう (1)

NDEFというと、アプリが使うもんだっていうイメージがあったので、まったく把握していない。
NFC Forumのドキュメントを読んで、少しくらい把握しておこう。


2.2 Intended Usage

 

意図する使い方、というところか。

関連するドキュメントを「NDEFメッセージ」にまとめ、それをNFC Forum Device間でやりとりする、というイメージなのだろう。

強調しているのは、MIMEも使えるけど、MIMEとは限らないよ、ということ。
NDEFメッセージを解析するために、NDEFレコードタイプとペイロードのチェックをしなくていいよ、ということらしい。

エラーについての決まりもないようだ。
ここら辺が規定されると、実装がめんどくさいからありがたい。


2.3 NDEF Encapsulation Constructs

 

NDEFの構成、というところか。
"encapsulation" を和訳して入れ込むと、なんかわかりづらくなりそうなのでやめた。

NDEFは、まず「NDEF message」が一番上に来る。
1つのNDEF messageに、複数のNDEF recordが含まれる。

NDEF recordには、「メッセージ始め」という意味のMBビットと、「メッセージ終わり」という意味のMEビットがある。
最短のNDEF messageは、1つのNDEF recordを含み、そのrecordのMBビットとMEビットが両方立っている。
"chunked payload"にするためには、2つ以上のNDEF recordが必要らしい。

 

ときどき聞く "chunk"という言葉。
1つじゃないよ、2つ以上だよ、というくらいの意味のようだ。
それでいいのかどうかは知らんが、まあ困りはすまい。

 

NDEF messageは、MBとMEが最初と最後にそれぞれ1つじゃないといかん。
これを「オーバーラップしてはいかん」と書いている。
ネストさせてはいかん、ということらしい。
データをネストさせたいなら、NDEF messageをペイロードに持つNDEF recordを持つことになる、と。

NDEF recordは、自分が先頭から何番目のレコードなのかは知らない。
なので、順番性はNDEFを伝達する人が保証すること。
DEPとかで分割して送る場合を想定しているのかな?


今日はここまで。
英語は相変わらず苦手だが、ずっと眺めていれば抵抗感は少しぐらい減るんじゃないかね。

世の中は、NFC & Smart WORLD 2012なるものが開かれているが、私はいつものようにコタツに座っている(コタツの上じゃないよ)。
出張でもない限り、関東に用がないからなぁ。

2012/03/06

[nfc]木を見て森を見ず、のようなNDEF

私は、NDEFをあんまり重視していなかったように思う。

単なるデータフォーマットの一つ、くらいの認識だ。
こんだけ世の中にいろいろフォーマットがあるのに、また増やしやがって、というような。

 

しかし、いろいろと考えていくと、NDEFというのはNFC Forum規格の中心に位置するのではないか、と考えるようになった。
何というか、NFC内での共通言語という位置づけなのだろうか。

Digital Protocolは、やっぱりプロプライエタリな部分の寄せ集めという感はぬぐえない。
しかし、無線部分を規格化しましょう、ということなのだから、そこはどうでもいいのかもしれない。
どちらかというと、NDEFというデータにアクセスするまでの物理的な通信手段(PHY)をDigital Protocolにまとめ、メモリ構造をTagに集約し、さあ後はNDEFの世界が広がっているぞ、というイメージかしら。

 

今まで、LLCPのドキュメントばかり見ていたけど、先にNDEFのことを見ておいた方がよいのではないかと急に思った次第である。

Digital ProtocolやLLCPなどの木ばかりしか見ず、NDEFなどの森を見ていない、という状況は避けたいものだ。

2012/03/04

SDK for NFC Starter Kitのソースファイルを整理

今まで作ってきたSDK for NFC Starter Kitのアプリがあるが、ソースファイルを適当にしすぎていた。
まだ覚えているうちに整理しておこう、と今日一日やっていた。
https://github.com/hirokuma/NfcStarterKitWrap

NFC Starter Kitのラップを作っていたものをクラスライブラリにして、アプリからはDLLを参照するようにするだけでいいようにした。
ついでに、CHMファイルのAPI仕様書も作った。
まあ、仕様書というにはわかりづらいところではあるが・・・。
サンプルソースもあるので、困ったらそっちを見た方が早い。

機能の追加も何もないが、ソースファイルの整理はやっておかんといかんですな。

[win]Windows Help2はもうやらんのか

NFC勉強会が終わった後にもかかわらず、いきなりWindowsの話だ。

いや、聞いておくれ。
今までSDK for NFC Starter Kitで作ってきたライブラリがあるのだけど、それを整備していたのだ。
コメントを付けていったくらいだけど。

Visual Studioでコメントをつけると、XML形式でのドキュメントを作ることができる。
それをSandcastleとかに喰わせると、API仕様書みたいなものができあがる。
一度作っておけば、忘れたときに便利だろう。


そう思って、最新版のSandcastleとかをインストールしようとした。

インストールしても・・・特にメニューに何か追加されるわけでも無し。
Sandcastle Help File BuilderというGUIのツールは別途なのだ。
インストールガイドはこちら

ガイドを読むと「Sandcastle Stylesから持ってくるとバグとか直ってるのがあるよ」というように読めたので、そっちを持ってきた方がいいのかな?

 

どうも、SHFBをダウンロードすると、Sandcastleに必要なもの一式が入っているみたいだ。
わざわざSandcastleを単体でインストールしなくてもよいみたいな気がする。


インストールしているときに気付いたのだが、Visual Studio 2010以降ではWindows Help2形式のものは作らん、といっていた。

確か、chmファイルから、なんかよくわからん形式に変わったという記憶はある。
たぶん、それがHelp2形式なのだろう。
それが作られなくなるってのは、なんだ?

検索すると、こちらのページがわかりやすかった。
http://owlsperspective.blogspot.com/2011/01/visual-studio-help3-system.html

「不評だから」が理由らしい。。。
んで、Help3形式にする、と。。。

なんかもう、chmファイルでいいや、という気になってしまった。

NFC勉強会@福岡に行きました

お誘いがあったので、昨日NFC勉強会@福岡に行った。

道は、1回だけ曲がり間違えた・・・。
しかし、ちゃんと着くことができたので、問題なかろう。
あれですな、自分に自信がないと、自分の記憶すら疑ってしまうと言うやつだ。

出不精で勉強会などほとんど行かないため、今回の場所も初めて。
GuildCafe Costaというところである。
店内のレイアウトはこんな感じで、右側のスペースを使わせていただいた。
左側には、普通のお客さんもいらした。
スペースの境目がスクリーンになっていて、そこにプレゼンテーションを表示できる。


内容の詳細は・・・他の方がきっと書くと思うので省略。
時間の都合でHands-onの時間は取れず、プレゼンテーション+会話となった。

まあHands-onするにしても、NFCって通信部分だけなので難しいところだ。
どうしても、勉強会みたいに「やったことを話す」か、ハッカソンみたいに「何か作る」が中心で、「じゃあ1時間あるから何か作ろうか」ってのはやりづらそうだ。

 

勉強会のいいところは、自分が興味を持っていないところの話を聞けるところだ。
一人でやってると、自分の興味分野しか見ないので、他のことを見なくなるのだ。
テレビや新聞みたいに、他のことも見てしまう状況を作らんといかん。


今回、初めて発表なるものをしてみた。
資料はこちら。
http://www.slideshare.net/hiro99ma/nfc-11850428

うーん、地味だ・・・。
話したいことはだいたい話せたのでいいけど、えらく下層の話だったので「なんじゃこりゃー」の人がいたかも。
まあ、そういうのもよかろう・・・と自分を納得させておく。

ネットに置いた方の資料は、多少修正している。
発表時にソフトを切り替えたくないのでPDFのスクリーンショットを貼っていたところを外したり、誤解があったらいかんと思ったところに注釈を入れたりしただけだ。

話していいのかどうか迷っていた後半部分も、結局はそのままにした。
解析方法なんて、考えてみれば書いたことくらいしか方法がないし、解析した結果も「できました」とかしか書いてない。
「まあいいんじゃないの」というところだ。


勉強会とは関係ない話で、ほほぅ、と思ったのは、ツイッターの話だ。

私の場合、平日は仕事から帰ってから1回だけ見るような感じなので、フォローする人は少ないし、フォローする人もツイートが多くない人を選んでいる(そしてだいたい全部読む)。
興味がある人は、そのときにときどき見に行く、という使い方である。
見るのも、ブラウザで見るだけである(ツール類は使ってない)。

しかしフォローする人が多いと、ツイートのあれって流れるように出るらしい。
ずっと見ていても1時間にいくつかしか出てこない自分の状況しか知らないので、へー、と思ったのだ。
同じものでも、人によって使い方が異なるので、いろいろ想定せんといかんなあ、と思った次第だ。

2012/03/03

Raspberry Pi

Qtのブログで存在を知ったのだが、今週発売があったらしい。

http://japanese.engadget.com/2012/03/01/35-linux-pc-raspberry-pi-hdmi-sd-usb-la/

本家のサイトはこちら。

http://www.raspberrypi.org/

 

私はあんまり重たいことをしないし、小さくてちょこちょこ動くようなことしかしないので、BeagleBoardくらいでもちょっと高機能すぎる。
このくらいがちょうどいいかなってところだ。

あ、SPIとI2Cがないのか?
そうでもないらしい。GPIOと兼用ピンということか。ARMだし。
http://www.bitwizard.nl/wiki/index.php/Raspberry_pi_expansion_system_page
途中の情報らしいが、ここにも書いてあった。

 

まあ、買うかどうかはわからんけどね。

2012/03/01

[nfc]どこまで話してよいものやら

今週末、福岡でNFCの勉強会がある。
お誘いを受け、発表の機会まで得ることができた。

さて、どこまで話してよいものやら・・・。

 

今月のInterface誌はNFC特集だが、第3章の「NFC開発に存在する三つの壁」に頷いた人は多いだろう。
ひどく、苦労した。
今でも苦労しているが、当時は投げ捨てそうな程だった。
残念ながら当時の苦労状況は、ここのブログに移ってくる前に閉鎖されたので残っていない。

 

そこからの経緯は、簡単に以前書いたので割愛しよう。
問題は「今まで調べた結果をどこまで話していいのだ?」というところだ。


私としては、チップを買う→データシートがついてくる→それを読めばすべてわかる、なのだが、NFCに関してはそれがまったく通用しなかった。

あれこれ実験した結果、このドキュメントが一番近そうだ、というところまでが長かった。
この情報は、単なる体験談だから、別に話しても悪くないと思う。

しかし、データ解析をしたところは・・・まずいと思う。
PaSoRiを買ったときに付いてきた取説は、かなり目を通したのだ。
でも「リバースエンジニアリングしないでくれ」というような項目がない。
(昔のハードは、買うと回路図つきだったりしたものだった。)

リバースエンジニアリングは権利としてある、という話もあるようだが、知財側面は無視できない。
やらんで済むならやりたくはない。
しかし、わからんものをほっておけるほどおとなしくもないので、ちょっとやった。
この成果が、FALP送信は一応できた、というやつになる。

まあ、ここは詳細に話すつもりはないので、話してもそんなに問題ないような気はする。


どちらかというと気にしているのは、もう1つ話そうとしていること。

わかる人にはわかるだろうが、IDmについてだ。
実際に利用したことはないが、ネットで見ていると「この製品のセキュリティ、大丈夫なのか・・・?」というものがしばしばある。
具体例を見せないとわからんのではないか、という気がしているのだ。

ネットを検索すると、同じようなことを思う人はいる。
その人も「これは危ないから公開しない」といっているが、その気持ちは良くわかる。
IDmをセキュリティ情報として使うなんて、パソコンの前にログインパスワードを付箋で貼っているのと同じくらい危険なのだ。

 

詳細は説明しないけど、NFCが来るということは、そういう情報も入手しやすくなると言うことだと思う。
私だって「あら、ほんとにできた」という感じだったしね。


そんな「どこまで話せるんだ」という苦悩を抱えつつ、NFC開発者は日々不安や孤独と闘っている。
そこに深い井戸でもあれば「王様の耳はロバの耳~」くらいのことは叫びたくなる。

その井戸が、NFC勉強会になる、というだけのことである。

 

と、強気なようだが、原稿を見直してもう少し無難にすべきか迷いはある。
Guild Cafeに行く道ですら迷おうとしているのに、原稿の進む道でも迷わんといかんのか。。。

 

NFC開発者の苦悩は続く。