2012/09/30

うちのNexus 7は広州にいるらしい

Nexus 7を注文した、という記事を書いて(そして消した)が、どうやらNexus 7は配達遅延しているとかなんとか。
うちのはどこにいるんだろう？

FedExの配送状況によると、GUANGZHOUにあるようだ。
どうもこれは広州のことらしい。
ほほぅ。
28日から動いてないので、土日が休みなのかしら。

なお、配達予定は10月2日のお昼らしい。
9月26日に注文して、「3～5営業日以内にお届け」となっているから、こんなものなのかな。
(そもそも、Google Playの営業日っていつなんだろう？　FedExの営業日の方かな。)
平日だったらいつでも同じなので、どうでもいいんだけどね。

2012/09/29

SDK for NFC Starter Kit 2.0

SONYさんから、SDK for NFC Starter Kitのバージョン2.0がリリースされた。
1.0との違いは、こんなものだろうか。

Proximity API対応(RC-S380)
PC/SCでType-B以外の開発ができる(RC-S380)

うーん、触手が動かん。
いや、RC-S330で未サポートだったものが使えるようになる、というのもあるのだよ。
あるんだけど、私にとっては今までと変わりが無い。

"SDK for NFC Starter Kit"で検索してみたけど、あまりヒットしない。
まあ、そうだろうと思う。
私みたいに、趣味で何かする人はありがたいかもしれないけど、そういう人はだいたい別のアクセス方法を手に入れているし、知らない人には「なにそれ？」だろうし。
非常に、中途半端だ。
Kitのできがいいとか悪いとかではなく、これをどう使ってほしいのかが見えない。
商用利用であれば、別の製品を購入しないといかんし。
そういう視点を除外したとしても、FeliCa関係の開発製品が、それに少しでも関わった人にどう思われているのか知らないんじゃないか、という気がしてしまった。
遊びで使う分には、どうでもいいんだけどね。

同じ理由で、RC-S380もおそらく購入しないと思う。
別に、RC-S380がよくない、とかいうわけではない。
RC-S370があるから、別にわざわざ購入する理由がないというだけだ。
Proximity APIという、Windows 8で採用されるAPIがあるんだろうけど、なんか、うん、そう、ね。
まだ見ていないものを評価するのはやめておかねば。

2012/09/26

Nexus 7を注文した

Nexus 7が日本で販売されたので、注文した。
注文しようとしても「技術的な問題が・・・」と出ていたので、混雑してるのかな、と思っていた。
出ている画面が「Google Wallet」だったので自分のGoogleアカウント画面を見てみると、サービスにはそういう名前がない・・・。
しかし、「Checkout」ってのはあった。
なんとなくお金の臭いがしたのでクリックすると、「ウォレット」って出てきた。
クレジットカードの登録をするところがあったのでやると、Nexus 7の購入もできた。
わからんがな、そんなの・・・。
そんなわけで、そういう人がいたらお試しくだされ。
ウォレットに登録しておくのって、Googleの人だったら普通なのかしら？

Windows8、という手もあったのだが、電話だったら嫌なのでやめた。
電話は普段かかってこないし、かかってくると訃報が多いから、嫌いだ。
まあ、電話のせいじゃないんだけどね・・・。
坊主にくけりゃ、みたいなもんだ。

ああ、そういえば、なぜNexus 7を急に買ったか書いてなかった。
NFCがついてるから。
本当にそれだけだな・・・。
2万円だったら、まあ悪くはないだろう。
今回の目標は、なるべく分解しないこと。
不良品ぽかったら、さっさと修理に出すこと。
その２点だ。

まあ、しばらく書くネタがなかったから、ちょうどいいかもしれん。
しかしJavaか・・・つらいな・・・。

2012/09/24

EjectSDをAndroid4でビルドし直す

https://play.google.com/store/apps/details?id=com.blogpost.hiro99ma.EjectSD4

自分では見ることもできないし、エミュレータにインストールすることもできなかったんだけど、EjectSDというアプリをAndroid4.0でビルドし直した。

これ、単にSDカードらしきものをアンマウントしたりマウントしたりするというだけのアプリなのだが、下の方のAPIを使っているのでAndroidのバージョンに依存しているのだ。
3.2までは乗り切ったんだけど、4.0でAPIの引数が変わってしまってねぇ。

今までのEjectSDをアップデートすると、もしかしたら3.2までの人にもアップデートされてしまい、今度はそっちが動かなくなるかもしれない。
複数のAPKファイルをアップロードできたような気がするけど、自分で持ってないので危険は冒せない。

そんなわけで、動作確認すらしてないものをAndroid Market(って、もう言わないのだね・・・)に置きました。
4.0になって動かない、と思った人は試していただければ幸いである。

2012/09/22

apkファイルの複数署名

作ったAndroidアプリをAndroid Marketにアップする際、apkファイルに署名しておかなくてはならない。
eclipseでやる場合には、メニューから選んでいけば自動的にやってくれるのだが、手動でやることもできる。

$ jarsigner -keystore xxx.keystore abcde.apk alias_name

このあとでzipalignなどするのだが、まあそれはよかろう。
署名されているかどうかも確認できる。

$ jarsigner -verbose -verify -certs abcde.apk
そうすると、こういう出力がずらずら出てくる。

sm      9812 Thu Nov 18 02:09:34 JST 2010 classes.dex
      X.509, CN=xxxxx, OU=yyyyyy, O=zzzzzz, L=ppp, ST=ffffff, C=jp
      [証明書は 09/09/18 0:28 から 37/02/03 0:28 まで有効です]

デバッグ中のapkは、たぶん各フォルダのbinに入っているやつだと思う。
これを見てみると、こうなった。

sm     24480 Fri Aug 19 00:15:06 JST 2011 classes.dex
      X.509, CN=Android Debug, O=Android, C=US
      [証明書は 11/12/20 23:53 に失効します]

デバッグ用の署名、というやつだろう。
このデバッグ用の署名があるapkファイルに、自分の署名をするとどうなるだろう？
jarsignerで署名することはできた。
見てみると、こうなった。

sm     24480 Fri Aug 19 00:15:06 JST 2011 classes.dex
      X.509, CN=xxxxx, OU=yyyyy, O=zzzzzz, L=ppp, ST=ffffffffff, C=jp
      [証明書は 09/09/18 0:28 から 37/02/03 0:28 まで有効です]
      X.509, CN=Android Debug, O=Android, C=US
      [証明書は 11/12/20 23:53 に失効します]

複数署名されたのだ。
なんとなく、署名は１つだけだろうと思っていたので、驚いたというほどではないが、へー、と思った。

なんでこんなのを調べたかというと、EjectSDアプリのためだ。
EjectSDアプリは、eclipseからビルドできない。
Android.mkをつくって、Androidプラットフォーム上でビルドさせているのだ。
ビルドさせた後、できたapkファイルに自分の署名をしてAndroid Marketにアップしていた。
していたのだが、なぜか急に署名に失敗するようになったのだ。
さっきまでできていたのに！

jarsigner: jar に署名できません: java.util.zip.ZipException: invalid entry compressed size (expected xxx but got yyy bytes)

確か、こんなのだった。
ネットの説明を見てみると、デバッグ用の署名がついているため、と書かれている。
しかし、上記を見るとできるのがわかるので、他にも原因がありそうだ。
Android.mkの場合、LOCAL_CERTIFICATEで署名の種類を選べる。
platform、shared、test、mediaの４つ。
build/target/product/security以下にある。
見てみるとわかるが、ここにはkeystoreではなく、pkcs#8とx509のPEMファイルがある。
Androidプラットフォームでビルドする場合は、jarsignerではなくてSignApk.jarを使っている。
これの引数は、pkcs#8とX509なのだ。

なら、Android.mkで署名させない方法があるはず、と調べるも、見つからず。
ならばここで自前のkeystoreで署名させてやる、とkeystoreからpkcs#8とX509に変換する方法を試したが、何が悪いのかうまくいかず。。。
あれこれあれこれやって、疲れ果ててもう一度普通にやると、署名できた。
なんじゃそりゃー。

そんなわけで、EjectSDは２重署名なのでした。

sm     10136 Wed Apr 16 08:40:50 JST 2008 classes.dex
      X.509, CN=xxxxx, OU=yyyyy, O=zzzzzz, L=ppp, ST=ffffffffff, C=jp
      [証明書は 09/09/18 0:28 から 37/02/03 0:28 まで有効です]
      X.509, EMAILADDRESS=android@android.com, CN=Android, OU=Android, O=Android
, L=Mountain View, ST=California, C=US
      [証明書は 08/04/16 7:40 から 35/09/02 7:40 まで有効です]

困ったことに、自分の署名が同じであっても、Platform側の証明書が変わるとどうしようもない。
早いうちに、自分の署名をPKCS#8とX509に変換できるようにせねば。
いろいろ調べてやったのだけど、SignApkが例外を起こすのよねぇ。。。

2012/09/09

Arduino + FeliCa Plug

「ArduinoとFeliCa Plugでなにかしようかと」という話を昨日聞いたので、ちょっと調べてみた。

NFC-F Developers' Blog

Arduino with NFC Dynamic Tag (2011/05/10)
Arduino library for NFC Dynamic Tag updated (2012/02/24)

FeliCa Developers' Blog

Arduino向けFeliCa Plug 制御ライブラリの提供 [RFワールド No.12連動 -機器構成①-] (2010/10/29)

SWITCH SCIENCE

FeliCa Plugの使い方 (データフォーマットコードについての記載をよく読むこと！)
Usage of Felica Plug

こんなところか。

Arduino版ライブラリがv1.1ってなっているが、2010年5月31日の時点でv1.1のようだ。
Readmeだけじゃわからない変更が入っているのかな？

ちょっとだけ見てみたが、まあコメントがないソースファイルだこと。。

接続はどうなってるんだろう？

Arduino Duemilanove

10(SS)
11(MOSI)
12(MISO)
13(SCK)

FeliCa Developers' Blog

SEL – 10
DATA – 11
SPICLK – 12

へー。こういう接続なんだ。
FeliCa PlugのDATAって、SELによって方向が変わるのだけど、MOSIにしかつなげてない。
どうやってんだ？

ソースを見ると、ソフトウェアでSPIやっているみたいだった。
そうするしかないのか。。
私が別のARM基板を使ったときは、MOSIがHi-Zにできるようになっていたので、MOSIもMISOもDATAに接続し、受信したいときはMOSIをHi-Zにしていたのだ。

SWPは結構速い

SIMと通信するとき、9600bpsくらいだったよなあ、でも覚えてないなあ、と思って少し調べることにした。

wikipedia。
最大1.6Mbpsまでは出せそう、とは・・・。
すんません、甘く見すぎてました。
まあ、そこまで出さないにしても、9600bpsなんてことはないだろう。

SEをSIMに置くと遅い、という記事があったのだが、1Mbpsくらい出せるんだったら、SAM(でいいのかな？)に置くのとそんなに違いが出るのかしら。

でも、ハード結線だったら通信速度とかなきに等しいだろうし、FeliCaは高速にするためにいろいろとやってる。
SWPがいくら速くても、戦略的に高速化をめざして作られているFeliCaにはかなわんのだろう。

NFCは、携帯電話に載らないと広まらないだろう。
携帯電話に載せるとなると決済機能抜きということはありえんと思う(キャリアやメーカーのメリットがないので)。
決済機能がつくなら、セキュアエレメントを何とかせんといかん。

今のモバイルFeliCaチップには、FeliCaのSAMしかつながらないようになっているから、ひとまずSWPでのルートを確保し、最後はSIMにFeliCaのメモリを持っていこう、という図になっている。

http://wirelesswire.jp/special/201101/01/report/201102170455.html

ってことは、SWPを使っても高速にやる算段は付いてるってことか？
あるいは、SWP経由の場合は高速にできないけど、海外端末でもFeliCaがつかえる、という方なのかな。
なんとなく後者のような気がする。

そういう時代になったら、私もスマートフォンとか使うようになってるのかな。
壊れるまで買い替えるつもりはないし、壊れたら修理するつもりだから、しばらくはこのままだな。

SNEPは、できないわけではなかった

昨日は、福岡のNFC勉強会に行ってきた。

そこでようやく、SNEP PUTの動作確認ができた。
うん、できないわけではなかった。
NDEF TEXTを送信したのだが、受信できるものとできないものがあったのだ。

うーん、NDEF TEXTじゃなくて、URIにしておけばわかりやすかったか。
自分でもどういう文字列を送信しているか忘れていたし、受信したらAndroidがどう動くかもよく知らないし。
URIだったら、きっとブラウザとかが起動するようになってるんじゃないかな。

とりあえず「SNEPはできないわけではなかった」ということで、よしとしよう。

さて、R/Wモードもやったし、Card Emulationモードもやったし、送信のみではあるがP2Pモードもやったし、一通りはやったことになる。

一番簡単なのは、やはりR/Wモードだった。
Initiatorになって要求を出せばいいだけだからだ。

Card Emulationモードはそれほど深入りしていないが、ちゃんとやるなら面倒だ。
メモリを持たないカードとして振る舞うなら、それほど難しくはない。
たとえば「FeliCa Liteのように振る舞う」となると、それなりにコマンドに対して応答するような実装をしてやらんといかんだろう。

最後にやったP2Pモードは、DEPだけなら簡単、LLCPは面倒、SNEPはそこそこ、という印象をうけた。
今回はSNEPで送信できるサイズが小さなものしかできないようにしているが、それでも全体としては面倒だった。

そういえば、SNEPはサーバとクライアントがあるが、今回はクライアントのみの実装だった。
これだと、Card Emulationモードでいいやん、という気はする。
FeliCa Plugだと簡単にできるし、こっちの方が電力的には消費が少なくてよい。

そう考えていくと、わざわざP2Pモードでやらなくてもいいやん、という気持ちにはなってくる。
うーむ。

最近、LLCPS、というセキュアなLLCPってのを考えているところがあるみたいだ。
IETFってなんじゃ、とおもったら、wikipediaにあった。
ドラフトドキュメントは、こちら。
"TLS"というワーキンググループが公開してるらしい。TLSは"Transport Layer Security"(RFC-2246)の略とのこと。
図を見ると、「TLS over LLCP」とあるから、LLCPはそのままで、その上にTLSを載せようとしているのかな。

まだドラフトなので読まないが、どのドキュメントのLLCPSシーケンスはわかりやすい。
図になってるからだ。
こういうのを望んでいるんだよ、こういうのを＞LLCPのドキュメント。

2012/09/04

[iso14443]シングルUIDの1byte目には意味があった

ISO/IEC 14443のドキュメントを読み始めた。
といっても、JIS X6322なので、少しは違うところがあるかもしれん。

最初に「特許には自分で注意してね」と書いてあって心配したが、私はカードを読みたいだけだから大丈夫だろう。

あんまりしっかり読むつもりはなく、またTypeBのところだけ読めばよい。

と思ったが、TypeAのところも興味深かった。
特にUID(NFCID1)のシングル(4byte)の説明。
MIFAREのカード仕様書なんか読んでいると、UIDの取得に何回か分けて読み込んでいる。
これが「カスケード」というやつ。カスケードになっている目的は、PICCの衝突を起こしやすくするためらしい(よくわからない…)。

シングルUIDの先頭バイトには、意味があるらしい。
0x08の場合は、残り3byteは動的に発生された乱数、という意味らしい。
そこでようやく、RC-S620/Sの動きに納得がいった。
ターゲットになるときUIDの後ろ3byteを指定できるようになっているのだが、「先頭は自動的に0x08になります」という動作になっているのだ。
当時は何気なく見過ごしていたけれども、そういう意味があったんだねぇ。
(手書きのコメントには「TPEの場合は0x08」と書いていた。)

というところで満足したので、今日はここまで。

2012/09/02

[android]Eject SDをなんとかせんとなぁ

私がNFCを家でやる前くらいにつくったAndroidアプリがある。
当時は円高だったので(今もだけど)、登録料も安いと思って作ったのだ。

いくつかあるけど、その中に「Eject SD」ってのがある。
インストールされてもだいたい消されてしまうアプリの中では、がんばっている。
ってより、これ以外には残ってるのが少ないってだけだがね・・・。

このアプリは、Widgetになってて、SDカードのマウントとアンマウントをするだけのやつ。
AcerのA500を買ったときに、抜き取りができなかったんだかメニューが深いんだったか忘れたが、なんか作ったのだ。
今でも千人くらいはインストールしてもらっていてありがたい。

残念ながらこのアプリ、Android 4.0には対応していないのだ。
あまり調べてないけど、アンマウントするAPIの引数が増えたみたいだ。
この辺の事情は、たまにブログに書いていたような気がする。

放置している理由は、うちに4.0の環境がないから。
エミュレータでやるってのもあるだろうけど、めんどくさい。
それにこのアプリの特徴は、標準以外のSDドライブをアンマウントすることを目的にしているところだと思っている。
ほら、タブレット端末とかだと、Android APIから取得したパスはexternalではあるんだけど、removableじゃない方を指していることが多いではないか。
なので、環境変数を見て候補を選ばせ、どうしようもない場合にはパスを入力できるようにしている、というところだ。

さっき見たら、まだアプリをインストールしている人がいるので、なんとか4.0にも生き残らせたいのだが、回避方法がよくわからん。
わからんし、試すことができんので、あんまりやりたくない。

こまったものだ(私が)。

NFCのType整理をしつつ、NFC-Bに思いをはせる

長いことNFCの資料を見ていないので、忘れてきてしまった。
ちょっと整理しておこう。

NFCのType(Type n Tag)の整理だ。

Type 1 Tag Platform

NFC-A

TOPAZなど

Type 2 Tag Platform

NFC-A

MIFARE Ultralightなど

Type 3 Tag Platform

NFC-F

FeliCa Liteなど

Type 4A Tag Platform

NFC-A

MIFARE DESFireなど

Type 4B Tag Platform

NFC-B

・・・？

そう、NFC-Bだけよくわからないのだ。
Interface誌の特集にも書いてなさそうだし、ネットで検索しても出てこない。

かといってNFC-Bのカードが運用されていないわけではない。
海外にもあるし、日本でも運転免許証や住基カードで使われている。

じゃあNFC-BでアクセスできるカードがType 4Bかというと、そうとは限らない。
MIFARE ClassicはNFC-Aでアクセスできるけど、どのTagにも属さないしね。

そういえば、FeliCa LiteやMIFARE Ultralightだって、買ってきたそのままではまだ「Type n Tag」を名乗ることはできないのかも。
NFC規定のデータが書き込まれるまでは、単に「NFC-nでアクセスできるカード」というだけなのかもしれない。

何が言いたかったかというと、自分で運転免許証にアクセスできないかな、ということだ。
やってる人もいるようだけど、PC/SCじゃなくて、ごりごりとアクセスしたいのだ。
SDK for NFC Starter KitにはType 4Bのサンプルもあるそうだから、試してみましょうかね。

うん、EX_UNSUPPORTED_TAG、みたいな例外が発生した。
やっぱり、違うんですな。

NFP ?

知らない方がよかったのか？

昨日、Windows8でRC-S370は動かん、という記事を書いた。
そしたら「SNEPはPC/SCじゃなくて、NFPだよ」と教えてもらった。

NFP ?
またMicrosoftが新しい用語を作りやがって・・・。
知ってしまったからには、少しは調べておかねば。

NFCは"Near Field Communication"の略だが、NFPは"Near Field Proximity"の略らしい。
Proximityってのが、既に「近接、近傍」みたいなもんだから、「豚のとんかつ」みたいな印象を受けてしまうが、まあいいや。

ドキュメントは、ここ。
私は、2012年2月28日版をダウンロードできた。
ドキュメントの部類としては"Networking"になるようだ。
まあ、無線通信だから、そうなのか。

関係あるか知らんが、こんなページもあった。
近接通信とタップのサポート (JavaScript と HTML を使った Metro スタイルアプリ)

このドキュメントは、以下の章からなっている。

Tap and Do Scenarios and Use Cases
NFP Provider Model
NFP Device Driver Interface Definition and Requirements
System Design & Implementation Guidelines
Peripheral Wireless Device Design and Implementation Guidelines

60ページある・・・。
全部読む気にはならないので、つまみ食い程度に眺めよう。

Microsoftから見たNFCの分析、ともいえるので、ユースケースだけでも読んでおくと面白そうだ。

1. Tap and Do Scenarios and Use Cases

"Tap and Do"ってのが、MicrosoftのNFCアクションに対する名称らしい。
タッチアンドゴー、みたいなもんか。

シナリオ

Peripheral Wireless Device Setup

Tap and Doで周辺機器とのセットアップを済ませよう！かな。

Ad-Hoc Interaction in the Real World

PC間というかユーザ間というか装置間というか、そういったものの関係を作るトリガとしてTap and Doしようぜ！とかかな。。。
URLの交換とか、Wi-Fiとかでの画像交換とか。NFCだけで全部済ませようとはしていないようだ。

ユースケース

Tap and Doゼスチャー

Tap and Setup : 機器とのセットアップ
Tap and Reconnect : 再接続
Tap and Use : アプリとの接続
Tap and Launch : アプリ起動へ誘う
Tap and Acquire : アプリ取得へ誘う
Tap and Share : コンテンツの共有
Tap and Receive : 他のデバイスやポスターからコンテンツを受信

こういう分類をちゃんとやるのは、さすがですな。

ユースケースは、最終的には２つのカテゴリのうちどっちかになる、という。

Personal : システムだけしか関係しない
- 人が関係しない
- ユーザは直接Windowsシステムを操作する(タグ、カード、周辺機器など)
- (うまく訳せぬ)ユーザはユースケースの完全な制御権を持つ。
Interpersonal : 2人のユーザが一緒にやる。最低でも片方はWindowsシステム。
- 相手のユーザが必要
- 相手はWindowsシステムか、モバイル電話。
- お互いがユースケース実行のために協調して動く。デバイスを向かい合わせるとかも含めてね。

それぞれのユースケースについて詳細も書かれているが、めんどうなので省略。
例も書かれているので、NFCを使ったサービスを考えている人にはよさそう。

2. NFC Provider Model

NFC provider modelは、Windowsシステムでさっきのユースケースみたいなものを使うための共通項目(common surface)を提供する。

ここら辺から、NDEFという単語が出てくる。
NFCではNDEFを使う、という前提のようだ。
なおかつ、NFP providerは"Windows"をサポートする必要がある、と。例えば、

Windows.urn:contoso.com:t

のような。
NFC Forumでのサービス名は

urn:nfc:sn:<servicename>
urn:nfc:xsn:<domain>:<servicename>

というルールになっている(LLCP)。
urn(Uniform Resource Name)の標準というものもあるらしいが、私は詳しくない。
AndroidからSNEPできるというところから、これらはWindowsのプロトコルだけに適用されるんだろうけど、なんか、ねぇ。

urn:nfc:xsn:Windows:contoso.com:t

とかでよかったんじゃないの、と思ってしまう。

3. NFC Device Driver Interface Definition and Requirements

ここは、実装詳細だ。
GUIDとか、IOCTLとか。

WindowsのSNEPはPC/SCとは関係ない、ということだったから、ここもPC/SCとは関係ないのだろう。
ってことは、メーカーはNFP用に実装し直さないといけないと言うことか。

NDEF Protocolというのも、ここら辺に書かれている。
LLCPとかSNEPもここだ。
うーん、LLCPの実装までの実装はドライバがやってもいいと思うけど、SNEPはWindowsが自分でやってもよかったのでは。NDEFもドライバでやるからこうなったのかな？
詳細を読みきれていないから認識を間違ってるかもしれんし、そもそも私が実装するわけじゃないからいいんだけどね。

4. System Design & Implementation Guidelines

運用面の話なのかな。
Tap and Doのマークとか、アンテナはここに置け、とか。

5. Peripheral Wireless Device Design and Implementation Guidelines

ペアリングとかWindows8で使うNDEF詳細とか。
Bluetooth OOB(out of band)、なんてものもある。

urnにWindowsってのが出てきたところでテンションが下がってしまったが、だいたいこんなもんだ。

NFC Forumと共通の部分はOSではなくドライバ側でやりそうなので、きっとコンパチビリティテストみたいなものもMicrosoft側でやるんだろう。
やらないと、A社のR/Wではうまく動くけど、B社のでは動かないことがある、みたいな非互換性が出てきてしまうからな。

もうちょっとWindows色を薄くして、「みんなこうやろうぜ」みたいな方がよかったんじゃないかな、と個人的には思う。
Tap and Setupなんて規格化してしまうと今後はいいと思うけど、頭に「Windows」って付くと、ちょっとなぁ(くどい)。

私の英語ドキュメント読み違いであることを期待しよう。
きっと、やましたさんがうまいことやってくれるだろう。

2012/09/01

Windows8はうちのRC-S370に何をしていたのか？

Windows8でRC-S370がちゃんと動かないだろうということはわかった。
では、搬送波を定期的に出しているあれは、いったい何をやっているのだろうか？
事と次第によっては・・・許さん・・・。

ごにょごにょして確認したところ、TypeBのポーリングを行っていた。
そうか、RC-S370はPC/SCでTypeBのみサポートしているから、それでこういう動きをしているのか。
WindowsのNFCアクセスといえば、PC/SCになるのは当然(Microsoftなので)。
よって、デバイスがPC/SCに対応しているものについてだけ、NFCとして動かすようになっているんじゃなかろうか。
ってことは、SNEPもPC/SCの規格に含まれているということか？
RC-S380はPC/SC 2.0仕様をサポートしているが、PC/SC 2.01.11は2012年7月リリースだが、その前の2.01.10は2011年8月リリースだ。
NFC ForumのSNEP仕様がAdoptedになったのは、2011年8月らしい。
これは、RC-S380が対応しているPC/SC 2.0というのはVersion 2.01.10以降ということになるのかな(NFC ForumとPC/SCが仕様をうまいこと整合したと考えた場合)。
でも、PC/SCとNDEFはあまり結びつかないしなぁ。

PC/SCの仕様を全然わかっていないので、データ交換がどうなっているかから調査しないといかんだろう。
正直なところ、PC/SCって「存在するけど忘れられる」んじゃないかなと思っていたので、まったく視野に入れていなかったのだ。
"Windows 8 Near Field Proximity Implementation Specification"なんてドキュメントもあるので、ちゃんと読まんといかんかも(この中には"NDEF"とか"SNEP"って単語が出てきた)。

納得できたので、私はWindows8を許すことにした。

Windows8+RC-S370でSNEP通信は(まだ)できなかった

ブリリアントサービスNFC技術ブログに「Windows8とAndroidでSNEP通信してみた」という記事が載っていた。
衝撃だ・・・
SNEPしたいしたいと思っていたが、Windows8にそんな機能があるとは。
昨晩、さっそく酒を飲みながらVirtualBoxにWindows8 Preview Release(32bit)をインストール。
どうやったか忘れたが(飲み過ぎかよ・・・)、PaSoRi RC-S370のドライバをインストールした。
記事ではRC-S380が使われているが、まだ一般人は手に入らないようだ(10月だって)。

ドライバとしては認識したが・・・FeliCaランチャーは動かず。
でも、携帯電話を近づけると反応しているので、何かしら搬送波を出しているようだ。
しかし、NDEFのカードを近づけるも、Windows8は反応せず・・・。
SNEP通信どころではないってことである。
SONYのPaSoRi比較表では、RC-S370ではWindows8のNFC機能に対応しないとのことだ。
うーむ、残念。

じゃあRC-S380を買うかというと、そこも問題だ。
だって、家にRC-S370と380があったとして、２つもいらんやん、ということになる。
うーんうーん、どうしたもんだか・・・。
いや、そもそもWindows8を買う気があるのか？というところも問題だ。
そろそろXPも潮時らしいので、保険として新しいOSも置いておきたいところ。
Windows8は安いバージョンがあるとか言う話なので、考えてはいるのだ。
考えてはいるけど、本気なのかはまだ疑わしい。

ソフトウェアライセンスを付けようとしたが、よくわからん

たまに、githubなどにソースファイルを置いている。
よくわからないが突然、ソフトウェアライセンスを付けた方がいいんじゃないのか？と思った。

まあ使う人はいないだろうけど、練習としてやっておいても損はあるまい。

といっても、そういうのをやったことがないので「MITライセンスとか修正BSDライセンスが自由そうでいいんじゃないの」くらいしか考えてなかった。
英語の文字列をソースのコメントにひっつけておけばいいや、くらい。

調べていくと、なんかいくつか出てきたので、覚え書きを書いておこう。

最初に見たのが、このタイプ。
これは、http://opensource.org/licenses/BSD-3-Clauseに出ていたものだ。
この「3」というのは、項目が3つあるからのようだ。

/* * Copyright (c) 2012-2012, hiro99ma * All rights reserved. * * Redistribution and use in source and binary forms, with or without modification, * are permitted provided that the following conditions are met: * *  - Redistributions of source code must retain the above copyright notice, *         this list of conditions and the following disclaimer. *  - Redistributions in binary form must reproduce the above copyright notice, *         this list of conditions and the following disclaimer *         in the documentation and/or other materials provided with the distribution. *  - Neither the name of the "hiro99ma" nor the names of its contributors *         may be used to endorse or promote products derived from this software *         without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY * OF SUCH DAMAGE. */

項目が２つのものもあった。

これは、http://opensource.org/licenses/BSD-2-Clauseにあった。

/* * Copyright (c) 2012-2012, hiro99ma * All rights reserved. * * Redistribution and use in source and binary forms, with or without modification, * are permitted provided that the following conditions are met: * *  1. Redistributions of source code must retain the above copyright notice, *         this list of conditions and the following disclaimer. *  2. Redistributions in binary form must reproduce the above copyright notice, *         this list of conditions and the following disclaimer *         in the documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY * OF SUCH DAMAGE. */

訳がわからなくなったので検索すると、こちらのサイトが詳しかった。

3番目は、著作権者の名前を使いたいなら事前に書面で連絡してね、というものらしいが、削除してもいいとか。
私はどっちでもいいんだけど、FreeBSDのサイトには3番目がないので、まねしておこう。

"hiro99ma"をオーナー名として入れたが、いいのかな？
そもそも、hiro99maって、なんだろうねぇ。。。

登録: 投稿 (Atom)