2013/01/27

[openocd]0.7(dev版)を実行させたときのログ

Windows XPの新規インストール中・・・。
ARM-USB-TINY-Hのドライバを入れ直したりしたので、記録を残しておく。

OpenOCDの0.7から、FM3のmb9bfxx8が使えるようになったようだ、という確認だ。
以前より転送速度が遅くなっているような気がする(前は11KiB/sくらいだったような)が、まあ細かいことはよかろう。

Open On-Chip Debugger 0.7.0-dev-00145-gd631b2e-dirty (2013-01-24-00:15)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
adapter speed: 500 kHz
cortex_m3 reset_config sysresetreq
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 1)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 32768 bytes from file asp.srec in 4.343750s (7.367 KiB/s)
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
requesting target halt and executing a soft reset
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000100 msp: 0x1fff1f48
Info : dropped 'gdb' connection

XPを入れ直してから、LiveWriterのCodeSnippetが動かなくなってしまった。
.NETのSDKをインストールすればよさそうではあるが、もういいや。

[nfc]月刊NDEF 1月号(そして最終回)

風邪を引きかけているような気がするので、今日は風呂も入らず外にも行かず、ずっとこたつに座っている。
ちなみに、ここ数年は風邪で仕事を休んだりしてないのは、休日に体調不良になって、なんとか治しているからだ。
そろそろ、そういうのができない体になってきたか・・・。

だからだろうか。
急に「NFCとあんまり関連しないようなタイトルを付けて資料を作りたい」と思った。
思いついたのが「月刊NDEF」だったのは、ベアゴスティーニの影響だろうか(買ったことないけど)・・・。

月刊NDEF(PDF)ダウンロード


「月刊」とつけるからには、なんとなく雑誌っぽい感じにしたくなるではないか。
うちにある月刊誌は、Interface誌しかない。
2013年3月号が手元にあったので、参考にしながら作った。
何気なく見ている目次だが、さまざまな工夫が凝らされていることがわかった。
配置、色、フォント、絵をどこに入れるか・・・。
私はあまり見栄えがいい資料を作っていない(なんとかしようとはしているのだ)けど、こういう冊子になると「目を引きつけさせる」という要素が必要になることがわかった。
技術文書なんて、だいたい技術に関することしか書かれていないので、その技術に興味がある人は見るだろうけれども、そうではない人の足を引き留めるためにどうするか、ということを考えないといかんな。

まあ、そんな細かいことは抜きにしても、あまり作ったことがないような資料だったので面白かった。
読んでわかりやすいかどうかは、今後の課題だろう。


絵でわかる!、って書いたけど、これはInterface誌の「絵とき!」をやってみたかったからだ。
が・・・絵がほとんどなかったな。
まあ、反省すべきところはする、ということですな。

でも、次はもうやらんですよ。

2013/01/26

[nfc][nci]NFCEEはセキュアエレメント?

NCIの調査を始めたが、のっけからつまずいた。

image

これが、NCIに関わるもののおおまかな位置関係だと思う。
(ドキュメントから切り貼りしたかったが、著作権とかありそうなので描いている。)

DHは、ホストマイコンでいいだろう。
よくわからないのが、NFCCとNFCEEの関係だ。
特に、NFCEEっていうのが何だかわからない(まだ全部読んでないからだろうけど)。

Execution Environmentというくらいだから、NFCっぽいことを実行する本体なのだろうと思っていたのだが、NCIスコープの図を見るとNFCCにアンテナがついていた。
それに、NFCEEはなくてもよい、となっていた。
???である。

 

検索すると、どうもセキュリティが関係する内容を実行する場所のようである。
ということは、セキュアエレメントみたいなものなのだろうか。
セキュアエレメントだけということはないかもしれないが、なんというか、そういう感触のものなのだろう。

 

RC-S620/Sを使う場合、RC-S620/S自体はNCI対応していないから、ホスト側がNCIをRC-S620/Sのローカルコマンドに置き換えることになるのかな。
まだ大半のNFCデバイスはNCIで直接やりとりできるようになってないだろうから、こうなんじゃなかろうか。

 image

 

組込みの小さいマイコンだと、容量などの関係からNCIはつらいかもしれんな。
まあNCIだけじゃなくて、共通インターフェース自体がそんなもんだろうけどね。


NFCでよくわからない単語を検索すると出てくるこのサイトhttp://www.ekouhou.net/
国が運用している特許公報のページかと思っていたら、そうじゃないらしい。
特許をダウンロードするときにIPDLDDというツールを使うと貢献できるらしい。
今のところ特許を調べているわけではないのだが、いるときがあるかもしれないので覚えておこう。

[nfc]NCIを調べよう

NCIを早くやらねば、とよくわからない焦燥感に駆られている。
AndroidもNXPからBroadcomのチップに変わったように、今やNCIがないNFCチップは見放されようとしている(と、勝手に思っている)。

まあ、私はNFCチップを売っているわけではないし、そもそもNFCを仕事にしているわけではない。
ないのだが、PaSoRi RC-S370にも搭載されているRC-S956というR/W用NFCチップが搭載されているRC-S620/Sを使って遊んでいるので、他人事ではない気がしている。

 

自分で、RC-S620/Sを使うためのライブラリを作ってはいる。
いるのだが、そのインターフェースの設計はいきあたりばったりで(いや、がんばってはいるんだよ)、もちろん使っている人などいない。
このまま独自路線を貫くという手もあるだろうが、そうやって消えていった例を我々は何度も見てきて「時代に乗り遅れた」と思ってきたではないか。
それを「めんどくさい」というだけの理由で見過ごすというのも、愚かだろう。

 

そんな理由を付けて、最後に残ったNCIドキュメントを読むことにしよう。
過去にも数回眺めてはいるのだが、調査ってところまではやっていないのだ。

Linuxなんかは既に実装があるようなので、それを参考にできたらいいな。

[nfc]Static Handover(Wi-Fi)のまとめ

Arduinoが来てからNFCをもうやらないように見えたかもしれないけど、ときどきやってます。
NFC Forumの仕様に関しては、全部ではないにしても見たいところは見たような気がする。

 

数回に分けて書いていた、Static Handoverについての調査をまとめた。
Static Handoverの例(Wi-Fi)

 

 

siteの方もときどき更新していますよ、ということで。

2013/01/24

[openocd]Interface付録のFM3マイコンに対応したようだ

[nor/fm3] mb9bfxx7 mb9bfxx8 support.

これが3週間前にfixedになったようだ。
Interface誌の付録になっているFM3は、MB9B618T。
今まで、OpenOCDでは、xx6、のサポートまでだったので、FLASHメモリを全部は扱えなかったらしい。

 

まだgitに入っている段階で、0.7.0のリリースはされていないようだ。
ファイルを取ってきて、ビルドすると、とりあえずマイコン指定でxx8を選んでも怒られなかったように思う。
まあ、もともとそんなに大きなプログラムは作ってないんだけどね・・・。

 

とにかく、ビルドで疲れた。
せっかく残業無し日だったのに、いつもより遅いじゃないか。。。
ビルド方法は、こちらを参考に、というよりも、そのままやった。

  • libusb-win32は、書いてある通り1.2.4を使った。最近のはusb.hから名前が変わっているので心配だったのだ(既存との名前衝突を避けるために変更したらしい)。
  • libFTDIは、0.20を使った。
  • ヘッダファイルを置く場所を、勝手に/usr/local/includeとかにしていたのだが、コンパイラをi686-pc-mingw32でやっているので、ここに書いてあるパスに置かないと読んでくれない。
    無理に-Iで指定させたら、あちこちぶつかりだした。
    mingw32じゃないとだめかどうかは、確認してない。動けばよかろうなのだ。

最初、mingw32をcygwinにインストールしていなかったのだが、libFTDIはビルドできたのだ。
そのままOpenOCDをビルドし出すとエラーになったので、インストール。
最後の最後になって、libFTDIのリンクに失敗。cygwinでビルドしていたライブラリだったので、いくつかリンクできないものがあったらしい。

そんなごにょごにょしたことをやりたくなければ、サイトに書いてあるようにビルドするとよろしい。


なんで半年くらいほおっておいたFM3を触ってみたかというと、やはりArduino効果だろう。
Arduinoを動かしてて、「あー、USBホストシールドがあるといいかも」「バニラシールドもあると収まりがいいな」などと散財してしまいそうだったので、その誘惑を断ち切るためにも既存に目を向けることにしたのだ。

Arduinoって5Vだけど、うちには3.3Vのものしかないので、つなげるのが難しいのよね。。。
スイッチサイエンスさんから、簡易レベルコンバータを買ってFeliCa Plugと接続しようとしたところで、「いやいや、3.3Vで動かせる環境は既にあるやん」と思い出したのだ。

基板がきれいだから、見た目もきれいにしたくなってしまうという誘惑に打ち勝たねば。

2013/01/23

ArduinoとAndroid Beam

ArduinoにNFC R/WのRC-S620/Sを載せて「SNEPが動いた-!」と日曜日は喜んでいた。

しかし少し経って冷静になってみると「はて、組込みでSNEPって需要があるんだろうか?」ということに思い至った。

SNEPでNDEFをPUTするなら、その内容はインタラクティブというか、動的な内容になるだろう。
静的な内容だったらカードで十分だからだ。
もし、画像みたいに大きなものを送るのだったらBluetoothとかWi-Fiを使うだろう。
小さいNDEFだったら、カードエミュレーションで相手に読ませた方が楽だ。

SNEPって、相手とデータをやりとりを繰り返すので、それなりに電力を使うのよね、たぶん。
デジタルサイネージの例かなんかで、カメラで広告を見ている人を見分けて、その人に合いそうな広告を出す、というのがあった。
ああいうのに使えそうな気もしたけど、それだったらDynamic TagでNDEFデータを生成させればいいしね。

 

ただ、「カードを読みたい」というときにはR/Wしかない。
つまり、相手に読ませるのではなく、自分で読みたい場合だ。
そういうときにしか使わなくなるのかなあ。

ならば次にやるのは「AndroidからArduinoを近接制御!」だろうか。。。。

2013/01/20

[arduino]サーボモータの制御はPWMなんだ

はい、素人です。
サーボモータ自体知らず、Arduino本の通りに接続して、ソースを書いて実行させました。

サンプルは、ポテンショメーターのつまみをぐりぐり回すと、それにあわせてサーボモータがぐりぐり動くというもの。
ほほぅ、こういうことができるんだ、と素直に楽しめた。

 

ポテンショメーターも初めてだったのだが、これは可変抵抗と電圧出力がセットになったような部品だ。
それはいいのだけど、これの+と-の間に100uFの電解コンデンサをまたぐようになっている。
さて、なんのためだろう?
チャタリング・・・じゃなくてジッタを弱めるためだろうか。
と知った顔で書いてみたが、「ジッタ」って用語で正しいのかわからん。。。

 

同じ容量の電解コンデンサが、サーボモータの+と-のところにも同じようにまたいでいる。
こっちは本にも書いてあって「you can smooth out any voltage changes that may occur」だと。
発生する電圧変化を滑らかに伝える、ということなのかな。
積分回路・・・だっけ?
コンデンサに充電するからすぐに変化がサーボに直結せず、立ち上がりがゆっくりになる、ということか。

あ、同じところに「ポテンショメーターも同じ」みたいなことが書かれている。
「デカップリング キャパシタ」と呼ぶらしい。なんとなく聞いたことがある気がする。
TDKのページによると、高周波成分を通す性質を利用する、という基本機能の応用とのこと。
なので、さっきジッタがどうのって書いたけど、ノイズのような高周波成分をGNDに流すために使っている、ということになるのかな。

容量が100uFということについては、よくわからない。


ソースも少し書くだけで動いたのだが、実はサーボモータはPWMで制御するらしい。
digitalWrite()でPWMのチェックをしているところがあったので「PWMとかそげん使わんよなあ」と思っていたのだが、いきなり使っているではないか。

今のところ、お仕事でもPWMは使ったことがない。
サーボモータやLEDで試しておきたいところだ。

ん、ってことはサーボモータのライブラリをLED制御に使うと簡単なのかな?
と思ったら、それも本に書いてあった。
パルス幅が違うとか、そんなことを書いているようだ。

PWMでのLED制御も本に載っているから、試してみようかね。

[arduino]RC-S620/SからSNEP PUTする

昨日、スタックが足りんと騒いでいたが、cygwinでデバッグしていたコードが残っていた。
printf()しているだけだったのだが、削ると小さくなった。
あまり確認していないが、動いているから動いているんだろう。

 

ある程度、RC-S620/SからSNEP PUTできたので、githubに置いた。

https://github.com/hirokuma/ArduinoHkNfcRw

 

ArduinoのライブラリはC++クラス、みたいなことが書かれていたのでそうしたのだけど、普通のCでもいいんじゃないかな。
今回のだって、結局はstaticメンバ関数しか持たせてないので、インスタンスを作ったりしないのだ。
複数接続しても使えるようにする、とかかな?
まだ慣れていないということで、大目に見てほしい。

 

サンプルは、

  • NFC-Fを500msごとに検出する
  • SNEP PUT(initiator)で「http://www.google.co.jp/」のURIを飛ばす(「http://www」と「google.co.jp/」)

の2つ。
動作確認は、Arduino Uno R3 + RC-S620/S。

image

RC-S620/Sの上に載っているのは、弁当のふた。
FM3基板のセットをケースに収める際に、グルーガンで撃ってそのままにしているのだ。
Arduinoの下にあるブレッドボードに何か挿してあるが、単に片付けてないだけだ。
接続しているのは、RX/TXと、5V/GNDだけ。

 

SNEPのinitiatorにしたのは、動作確認がしにくかったため。
targetでやっていたのだが、搬送波が出ないので、どこまで動いたかわからんかったのだ。
ポートが一杯あるからロジアナでデバッグするという手も使えるのだが、めんどくさくてね(ロジアナを出すのが)。。。

Arduino風にデバッグするとしたら、やはりソフトウェアでUARTを実現して、既存のUARTをシリアルデバッグ出力に使う、ということになるのかな。
まあ、そこら辺はこれから調べればいいや。


上の写真を見ると、Arduinoの左側にごにょごにょとした図柄があるのがわかるだろうか。
これは、スターターキットに付属した木の板で、単に刻印というか、絵が描いてあるだけだ。
何もなくても動作にはまったく関係ないのだが、こういう細かいところはいいな、と思う。
(足がはまっている部分がわかりにくくなる、という利点もあるのだ)

2013/01/19

[arduino]自作NFCライブラリを使うとスタックが足りないっぽい

Arduinoスターターキットに入っていた本を順番に試していくのもいいかと思っていたが、やっぱりNFCに関係したことをやるのが私らしいだろう。
まあ、ハードの勉強も一緒にやるさ。

そんなわけで、以前作っていたArduino用NFCライブラリ for RC-S620/Sを使ってみた。


InListPassiveTargetして、NFC-Fを検出したらLEDを点灯させる、というところは動いた。
スケッチも含めて一発で動いたので、さすがに驚いた。
さすが私!

 

では、とSNEP TargetでPUSHするスケッチを動かした。
これは・・・動かなかった。
そんなもんだ、私。。。


まどろみさんのところを見て、標準のUARTポートじゃないところを使う手段があることを知ったが、どういうやりかたで実現しているのか確認していないし、なによりも初心者ってこともあるので、まずは標準UARTポートを使っている。
Arduino+RC-S620/SでSoftwareSerial通信が上手くいかない

 

エラーになったら、自作Abort関数を呼び、Arduino上のLEDをちかちか無限ループさせるようにしている。
いるのだが、なぜか点灯したままになるのだ。
なして?

setup()のポート設定後くらいにAbortを呼んでも、同じ。
ってことは、どうもロジック的な問題じゃなさそうだ。

よくわからんので、Abort呼び出しの直後に、while(1){}、とそれから先に進まないようにした。
すると・・・LEDがちかちかし始めた。
ロジックは変わってないので、違う原因だ・・・。

スケッチのサイズを見ていて気付いたのだが、avr-gccはよくできていて、while(1){}以降の関数は呼び出されることがないため、リンクレベルで捨てていてサイズが小さくなっている。
なので、setup()直後でAbortとwhile(1)するとサイズが小さいのだが、それをどんどん後ろにずらしていくとスケッチサイズが増えていく。
そして、あるところから先になると、while(1)をしてもLEDが点灯しっぱなしになった。
そこはちょうど、SNEPの処理を始める部分だ。

 

ってことは、スタックが足りなくなってプログラムカウンタがどっかに吹っ飛んでるんだろうな。
SNEPの処理をやると、LLCPや、NFC-DEPまでリンクすることになってしまう。
FM3みたいにメモリが多い環境では動いていたのだが、Arduino Unoでは足りなかったようだ。

Arduino UnoのRAMは・・・2KBか。
2KBでは、汎用に作ったSNEPでは足りないように思う。
FLASHは32KBで余裕があるので、送受信バッファを共用しつつ、処理速度を犠牲にしていけばなんとか・・・。
と思わなくもないが、そこまでしてSNEPしたいか?というと、そうでもないかも。


やるかどうかは別として、MAPファイルで確認くらいはしておきたい。
MAPファイルの出力方法はわからなかったが、Documents and Settingsの下にELFファイルができていることに気付いた。
(Arduino IDEを起動したままTempフォルダの整理をしてばしばし削除した後にビルドすると「フォルダがない」というエラーが出たのでわかった)。
ELFの見方は、BINARY HACKSで調べた。
.BSS(グローバル変数の初期値無し)と.DATA(グローバル変数の初期値有り)を見ればいいのかな。

[/cygdrive/c/Documents and Settings/xxxx/Local Settings/Temp/build4506488131124712308.tmp]$ readelf -S SnepTarget.cpp.elf
There are 16 section headers, starting at offset 0x264c0:
 
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .data             PROGBITS        00800100 003cf0 000bd8 00  WA  0   0  1
  [ 2] .text             PROGBITS        00000000 000094 003c5c 00  AX  0   0  2
  [ 3] .bss              NOBITS          00800cd8 0048c8 00047f 00  WA  0   0  1
  [ 4] .debug_aranges    PROGBITS        00000000 0048c8 000920 00      0   0  1
  [ 5] .debug_pubnames   PROGBITS        00000000 0051e8 001844 00      0   0  1
  [ 6] .debug_info       PROGBITS        00000000 006a2c 00bb4f 00      0   0  1
  [ 7] .debug_abbrev     PROGBITS        00000000 01257b 002c8f 00      0   0  1
  [ 8] .debug_line       PROGBITS        00000000 01520a 006325 00      0   0  1
  [ 9] .debug_frame      PROGBITS        00000000 01b530 000fc0 00      0   0  4
  [10] .debug_str        PROGBITS        00000000 01c4f0 003715 01  MS  0   0  1
  [11] .debug_loc        PROGBITS        00000000 01fc05 005f68 00      0   0  1
  [12] .debug_ranges     PROGBITS        00000000 025b6d 0008b0 00      0   0  1
  [13] .shstrtab         STRTAB          00000000 02641d 0000a2 00      0   0  1
  [14] .symtab           SYMTAB          00000000 026740 0019e0 10     15 220  4
  [15] .strtab           STRTAB          00000000 028120 0016c9 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

 

足すと、4183byte。
あっはっは、スタックどころかRAM自体が全然足りてないやん。。。。

さて、どうしたもんだか。
動いているときの状況でも、1600byte以上使っているので、もともと多いんだ。
そういえば、空っぽの場合はどのくらいなんだろう?
裏で動いているものもあるだろうから、調べておきたい。

[/cygdrive/c/Documents and Settings/xxxx/Local Settings/Temp/build4038602356621893896.tmp]$ readelf -S empty_sketch.cpp.elf
There are 15 section headers, starting at offset 0x1740:
 
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000074 0001d2 00  AX  0   0  2
  [ 2] .bss              NOBITS          00800100 000246 000009 00  WA  0   0  1
  [ 3] .debug_aranges    PROGBITS        00000000 000246 000090 00      0   0  1
  [ 4] .debug_pubnames   PROGBITS        00000000 0002d6 0000cd 00      0   0  1
  [ 5] .debug_info       PROGBITS        00000000 0003a3 0005c5 00      0   0  1
  [ 6] .debug_abbrev     PROGBITS        00000000 000968 000271 00      0   0  1
  [ 7] .debug_line       PROGBITS        00000000 000bd9 000635 00      0   0  1
  [ 8] .debug_frame      PROGBITS        00000000 001210 0000c0 00      0   0  4
  [ 9] .debug_str        PROGBITS        00000000 0012d0 0001ec 01  MS  0   0  1
  [10] .debug_loc        PROGBITS        00000000 0014bc 00016d 00      0   0  1
  [11] .debug_ranges     PROGBITS        00000000 001629 000078 00      0   0  1
  [12] .shstrtab         STRTAB          00000000 0016a1 00009c 00      0   0  1
  [13] .symtab           SYMTAB          00000000 001998 000610 10     14  39  4
  [14] .strtab           STRTAB          00000000 001fa8 000372 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

9byteとは、お主なかなかやるな。

ここにdelay()を加えると、こうなる。

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000074 000290 00  AX  0   0  2
  [ 2] .bss              NOBITS          00800100 000304 000009 00  WA  0   0  1

RAMは変わらんけど、コード量が増えた。
複数のタイマを管理する、という必要がないからRAMは最初に1つ確保しておけばいいということか。
ふーむ。

 

とにかく、2KBのRAMをうまく使うためには、ライブラリにもそれなりの制約を設けないとだめだな。

[arduino]digitalWrite()とdigitalRead()

本を読みながら、スケッチというやつを作ってみた。
今のところ、普通のCプログラムと同じだ。
avr-gcc.exe、というのがあるから、GCCでできることはだいたいできるのかな。

 

setup()とloop()を実装しておくと、勝手に動いてくれる。
割り込みハンドラの定義もできるようだが、まあそれは後の話だな。
AVRは8bitマイコンのようだから、そこは気をつけておかないかん。

 

ポートの方向設定がpinMode()、出力がdigitalWrite()、入力がdigitalRead()。
これらは、#includeしなくても使えた。
検索すると、Arduino.hに定義があり、実装はwriteing_digital.cにあった。
digitalWrite()を見てみよう。

  1. 引数pinから、該当するポート番号を探す(よくわからんが、lpmというアセンブラ命令を使ってる)
  2. PWMのタイマが動いているかどうかも探す
  3. pinがポートの何ビット目になるかも探す
  4. ポート番号が探せなかったら、終わり
  5. PWMタイマが動いていたら、終わり
  6. ポート番号からアドレスを取得
  7. SREGの現在値をバックアップ
  8. 割込禁止
  9. ビットを立てるならOR、落とすならAND~
  10. 7で保存した値をSREGに書き込む

書き込みだけで、けっこう多い。
まあ、他のマイコンでもArduino互換というものがあるから使っておいた方が無難だが、「今回はPWM使わん」というような場合は、もうちょっと端折りたい気がするな。

よくわからんのが、SREG。
これは状態レジスタらしい。Status REGisterか。
割込禁止にしてから、書き込んで、SREGを戻して割込禁止も解除される、ということになりそうだ。
状態レジスタって、なんとなくReadOnlyって気がするのだが、そうでもないということか。
(そういうのは自分で調べよう。)

 

割込禁止と許可を逆に覚えてて、CLIが許可でSTIが禁止かと思ってた(8086の知識)。
AVRでは、CLIは禁止で、SEIが許可らしい。
もちろん8086でも、CLIが禁止で、STIが許可、だ。

もう届いた

17日の21時くらいに注文したArduinoスターターキットが、19日朝に届いた。
18日の時点では横浜にいたようだが、航空便で届いたようだ。
おそるべし、RSコンポーネンツ。

image

いろいろ入っていた。

冊子が入っていたのだが、なかなかおしゃれな感じだ。
表面がエンボスというのか、文字やアイコンが浮き上がっている。

電子部品はいいとして、木の板が入っていた。
これは、ケースみたいなものになる。

image

この写真じゃわからないが、足もついているのだ。
木の板には手で押したら取れるくらいに切られた部品が入っていて、それをくりぬいて、差し込んだりするのだ。
ほほぅ。

 

さて、しばらく遊んでみましょうかね。

[arduino]Arduino Uno rev.3にはI2Cポートがあるようだ

RSコンポーネンツさんから発注メールが来た。
よかった、個人でもやってくれるんだ。
18日の時点で横浜にいるそうなんだけど、福岡に土曜着するのかな?
流通に詳しくないのでよくわからないが、期待して家から出ずにがんばろう。
(納豆とうどんとラーメンがあるので、数日は出なくても大丈夫。)


さて、今のうちにArduinoをもう少し調べておこう。
解説ページもたくさんあるのだけど、今はまだ自分で調べる楽しみを堪能しようではないか。

ほら、仕事だって新しいことをやり始めたときは楽しいけど、慣れてくると飽きが来てしまうやん。
それとは別に、深く知ることで愛着が増す、というのもある。
私が2年以上もNFCをやってるのは、「情報が少なかったときに一生懸命調べたんだ!」という自負というか苦労というか、そういうものがあったからだ。
Arduinoだって、自分でなるべく調べて、困って困って、それを解決する、という楽しみをやっておきたいのだ。

あらまあ、ぜいたくな話だこと。


さて、そんなことを言っておきながらいきなりネットの情報だが、Uno rev3にはI2Cのピンがあるようだ。
スイッチサイエンスさん

AREFは、アナログのリファレンス電圧で、SDA, SCLはI2Cだろう。
IOREFは・・・私の知識にない。
こういうのを1つ1つ調べていって、自分の知識にしていきたいのだ。

 

そういうときは、本家のページを見ることから始めよう。

 

Overview

Arduino UnoはATmega328が搭載されたマイコンボードだ。
デジタルI/Oが14ピン(そのうち6ピンはPWM出力としても使用可能)、アナログ入力が6ピンある。また、クロックは16MHz(セラミック発振子)。USB接続、電源ジャック、ICSP(In Circuit Serial Programming)ヘッダ、リセットボタンを搭載している。

マイコンを動かすのは、コンピュータとUSBで接続するなり、ACアダプタや電池から電源を供給するくらいのシンプルさで済む。

Unoはほかのボードと違って、FTDIのUSBシリアル変換専用チップではなく、Atmega16U2というチップにUSBシリアル変換するプログラミングを行ったチップを搭載している(rev2はAtmega8U2だった)。

rev2ボードではDFUモードにするためのプルダウン抵抗があった。
rev3は次のような特徴がある。

  • SDA, SCLピンの追加。配置は、AREFピンの近くと、RESETピン、IOREFピンの近く。
    (注:シールドのことも書いてあるのだが、まだ知識がないので訳せない)
  • RESET回路の強化
  • R2で使っていたAtmega8U2からAtmega16U2に変更

 

疲れた・・・。

電圧としては、5Vと3.3Vがありそうなのだけど、全体的に5Vメインって感じがする。
最近は3.3Vとか1.8Vが多いので、5Vってのは大きく感じる。

 

5VというとTTL、3.3VというとCMOS、というイメージが私にはある。
どうなんだろう?
ときどき調べないと、「最近ではこういう意味で使われる」ということもあるんでね。。。

2013/01/18

[arduino]Arduino Unoの説明を少し読む

名前はよく聞くArduino。
しかし、よくわかっていない。
ものが来るまで、説明書を読んでみよう。


スターターキットに入っているのは、Arduino Uno rev.3 らしい。
UNOって、1、か。
Arduino1.0にバージョンが上がったから「1」らしい。

  • ATmega328が搭載されたボード
  • Digital I/O : 14ピン(うち6ピンはPWM出力としても使える)
  • Analog Input : 6ピン
  • 16MHz
  • USB接続
  • 電源ジャック
  • ICSPヘッダ
  • リセットボタン
  • USBケーブル、ACアダプタ、電池での電源供給が可能
  • USBシリアル変換チップとして、Atmega8U2をUSBシリアル変換プログラムしたものを載せている
  • Unoは最新のボードだ(と、当時のドキュメントだから書いてあるのだろう)

今の最新が知りたいわけでもないのだが、どのくらい種類があるんだ?


Arduino社が出しているものが"Arduino"なのだろうから、そのホームページを見てみよう。
Arduinoの本体じゃないものもあるが、とにかくハードウェア一覧にあるものを書いておこう。

  1. Arduino USB
    1. Arduino Uno
    2. Arduino Duemilanove
    3. Arduino Diecimila
    4. Arduino NG Rev.C
    5. Arduino NG(Nuova Generazione)
    6. Arduino Extreme v2
    7. Arduino Extreme
    8. Arduino USB v2.0
    9. Arduino USB
  2. Arduino Serial
    1. Arduino Serial v2.0
    2. Arduino Serial
  3. Arduino Single-Sided Serial
    1. Severino (S3V3)
    2. Original
  4. Arduino Mega
    1. Arduino Mega 2560
    2. Arduino Mega
  5. Arduino Fio
  6. LilyPad Arduino
    1. LilyPad Arduino 04
    2. LilyPad Arduino 03
    3. LilyPad Arduino 02
    4. LilyPad Arduino 01
    5. LilyPad Arduino 00
  7. Arduino BT
  8. Arduino Nano
    1. Arduino Nano 3.0
    2. Arduino Nano 2.x
  9. Arduino Mini
    1. Arduino Mini 04
    2. Arduino Mini 03
    3. Arduino Mini 02
  10. Mini USB Adapter
    1. Mini USB Adapter 03
    2. Mini USB Adapter
  11. Arduino Shields
    1. Ethernet Shield
    2. Wireless Shield
    3. Wireless Proto Shield
    4. Arduino Xbee Shield
    5. Arduino Motor Shield R3
    6. Motor Shield
    7. Arduino Proto Shield

 

ここまで書いておいてなんだが、Productsのページには違うものが載っている。。。

  1. Arduino Boards
    1. Arduino Uno
    2. Arduino Leonardo
    3. Arduino Due
    4. Arduino Esplora
    5. Arduino Mega 2560
    6. Arduino Mega ADK
    7. Arduino Ethernet
    8. Arduino Mini
    9. Arduino LilyPad
    10. Arduino LilyPad USB
    11. Arduino Micro
    12. Arduino Nano
    13. Arduino Pro Mini
    14. Arduino Pro
    15. Arduino Fio
  2. Arduino Shields
    1. Arduino Ethernet Shield
    2. Arduino WiFi Shield
    3. Arduino Wireless SD Shield
    4. Arduino Motor Shield
    5. Arduino Wireless Proto Shield
    6. Arduino Proto Shield
  3. Arduino Kits
    1. The Arduino Starter Kit
  4. Accessories
    1. USB/Serial Light Adapter
    2. Mini USB/Serial Adapter

 

疲れた・・・。

Leonardoってのが一番新しそうだ(レオナルド熊、しか出てこんかった)。
Unoの写真と見比べると、

  • USB-Bプラグ(なのか?)が、通常サイズからMicroになった(たぶん)
  • I2Cのピンが増えてる
  • マイコンが直づけになった

Unoのページを見ると、Unoにもいろいろあるんだな・・・。

 

めんどくさくなってきたので、とりあえずUno rev.3のことだけ調べることにしよう。

2013/01/17

Arduinoスターターキットを注文した

年末年始で、気が緩んでいる・・・。
さっき、Arduinoスターターキットを注文してしまった。
ああ・・・。

 

まあ、いいのだ。
ハードウェアの勉強をしよう、とInterface誌の付録ボードを使っていたが、ものすごく簡単なもの以外は接続できるか怖くて試してもいない、というのが実状だ。
怯えて何もしないより、もうちょっと敷居を下げて、動くもので勉強しよう、という魂胆だ。

とりあえず、モーターを動かしてみたい私であった。
田宮のモーターを動かして以来、やったことないのよねぇ。

 

\8,000以上だと送料が無料らしい。
キットが7900円くらいだったので、Nexus7用にUSBケーブルの長いやつも注文した。
ちょっと短くて、デスクトップPCからだと使いづらかったのよね。

 

今日注文した理由は、木曜日の18時から金曜日までに注文すると「土曜日配送」ができるから。
個人注文はだめかと思ったけど、支払い方法に制限を設けるなどで、まったくダメではないらしい。
(でも、基本は企業との取引とのこと)
まだ注文しただけなので、やっぱりダメ、といわれたら、来週考えよう。


さて、注文(だけ)したRSコンポーネンツ。
3月末までにオンライン登録すると、3名にNexus7が当たる!
さらに注文まですると、毎月5名にプレゼントが!!

そして今月のプレゼントは・・・Arduinoスターターキット!

ええっ、そうなの??
もう注文してしまったよ・・・。
2つ当たるのなら、それはそれでうれしいんだけど、「同じものが当たってもうれしくないよね」と抽選外になるんだったら嫌だなぁ。

まあ、5名だからそんな心配はせんでいいかもしれんがね。

2013/01/14

[nfc][試作]Nexus7用の回避策を追加した

Static Handover用のNDEFタグをFeliCa Liteで作ってみたが、Nexus7ではNDEFとして認識してくれない場合があることがわかった。

では、回避しよう。

回避策は2つあった。

  • Android側で、NDEFとして認識しなくても自分でやってしまう
  • Windows側で、NDEFとして認識しないようなサイズにしてしまう

前者の方が対策としては確実なのだが、AndroidにはMifareUltralightのclassはあっても、FeliCaにはないのでちょっとめんどくさそうだった。
全部読み込んで、NdefMessageのコンストラクタに渡してしまうだけでよさそうなんだけどね。

そんなわけで、後者を採用した。
これは、根本的な解決にはならない。
今は「113~127byteだと認識しない」とわかっているけれども、実はもっと別のサイズがあるかもしれない。
他の要因もあるかもしれない。

でも、もういいや。


サイズをどうやってごまかしたかというと、113~127byteになるのだったら、別のNDEFレコードを追加して水増ししたのだ。
TNFがEmptyだと3byteなので、これを5つひっつけただけ。

手抜き・・・ではあるが、当面は回避できるからよかろう。

[android]TECH_DISCOVEREDでNdefMessageが取れるのは、AndroidがNDEFとわかっているときだけのようだ

前回の記事に対する訂正だ。

FeliCa LiteでNDEFデータが113~127byteのときにはNDEF_DISCOVEREDが上がってこない、という話をした。
しかし、NDEF_DISCOVEREDを指定していてもTECH_DISCOVEREDが来ることがある、というのが前回の話。

じゃあ、TECH_DISCOVEREDが返ってきてもNDEFとして処理すればいいやん、と思ってやっていたのだが、113~127byteのNDEFデータだと、

Parcelable[] pac = intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES);

としてもpacはnullになってしまったのだ。

やっぱり、ちゃんとAndroidが「NDEFだ」と思っているときにしか使えないようだ。
すまん、みんな。

まあ、考えてみればそうよね。。。
NDEFと認識しているから、NdefMessageを作って返しているのよね。。。


Nexus7しか今のところ発生する機種がわかっていない、今回の現象。
logcatには、こう出てくる。

D/NfcDispatcher(8422): dispatch tag: TAG: Tech [android.nfc.tech.NfcF, android.nfc.tech.Ndef] message: null

NfcDispatcherが出している。
SmartPosterだと、こういうログになった。

D/NfcDispatcher(8422): dispatch tag: TAG: Tech [android.nfc.tech.NfcF, android.nfc.tech.Ndef] message: NdefMessage [NdefRecord tnf=1 type=5370 payload=91xxx(略)]

この出力のフォーマットは、こうだ。

"dispatch tag: " + tag.toString() + " message: " + message

だから、messageがnullなのだ。

 

messageは、

  • Ndef.get(tag)がnullでないなら、ndef.getCachedNdefMessage()
  • Ndef.get(tag)がnullなら、null

のどっちかだ。
getCachedNdefMessage()は持っている値を返すだけ。
Ndef.get(tag)は、tagがTagTechnology.NDEFを持ってなかったらnullになる。

やっぱり、よくわからんな。


よくわからんので、もうちょっと値で攻めることにした。

まず、ヘッダのNDEFデータ長だけを変えてみよう。
NDEFとして読み込めるデータを、ヘッダに113byteとして登録すると・・・messageはnullになった。
では、NDEFとして読み込めないデータを、ヘッダに128byteとして登録すると・・・同じくnullだ。
つまり、NDEFかどうかはヘッダだけを見ているのではなく、データも確認しているということがわかる。
「チェックサムでは?」と思ったが、データ長が128byteのときは0x00A3、127byteのときは0x00A2と別に変わった値でもない。
(libnfc-nxpでは、uint8_tバッファをuint16_tで加算していってるので、負の数とかは関係ない。)

 

じゃあNDEFデータのせいかというと、そんなこともないと思う。
それなら、NFC-Fだけじゃなくて他のTechnologyでも発生しそうではないか。

 

何が起こっているのか確認したい気持ちと、確認しても回避するしかないやんという気持ちがあって、それに加えて「どこがどう動いているのやら」があって、調査打ち切りの方向に進んでいる。
簡単にやるなら、自分でNexus7のソースをデバッグコードを埋め込んでビルドして焼いてみる、なんだけど。。。
リカバリーで元に戻せるという話は知っているのだが、まだちょっと気が引けているのだ。

2013/01/13

[nfc][試作]Wi-FiのStatic Handover NDEFタグを作るWindowsアプリと、読んで設定するAndroidアプリ

いろいろ制限を付けているが、動いたので記録として残しておこう。
まあ「動いた」といっても、自分で作って自分で設定するんだから、できて当たり前といえば当たり前。

 

Windowsアプリ - github(SDK for NFC Starter Kit用。この中のHandoverWifi_FeliCaLiteがそれ)

Androidアプリ

 

まあ、普通なら全部Androidでやってしまうんだろうけど、まだそこまで至ってない。
それにこれは、暗号化などは全く無し、なのだ。
自分の家用とかではなく、公共の場のようにSSIDやパスワードが貼ってあるけど入力するのがめんどくさい、という用途なのだ。

 

そう思うと、Androidで書き込むソフトはなくてもいいかな、と逃げたくなってくる。
Javaでバイトデータを扱うのがめんどくさいのだよ・・・。

[android]NDEF_DISCOVERED指定してもTECH_DISCOVEREDが来ることがあるのは仕様

Nexus7で、自作NDEFタグを読み込ませようとしている。
私はACTION_NDEF_DISCOVEREDだけしか指定していないのだが、ACTION_TECH_DISCOVEREDのintentが飛んでくるので悩んでいた。

が、それは仕様だった。

i.2 高度な NFC - ソフトウェア技術ドキュメントを勝手に翻訳 (原文)

 

Categoryなどを指定せずにSmartPosterのNFCカードをかざしてみたが、やっぱりTECH_DISCOVEREDになっていた。


さて、原文を見ると「could not be mapped to a MIME or URI」とある。
翻訳されている文章だと「MIMEやURIにマップできなかった場合」と書かれているので、何となく「他にもマップできるものがあるのだろう」と読んでしまったのだが、もしかすると「MIMEURIに」なのかもしれない。
なんでこんなことを言い出したかというと、Static HandoverのNDEFはWell-knownなNDEF Recordタイプではあるものの、MIMEでもURIでもないからだ。

ごにょごにょ考えていたが、ちゃんと書いてあった
うん、順番に読みなさい、ということかな。

 

Static Handoverの場合、ALTERNATIVE_CARRIERを含んだHANDOVER_SELECTと、MIME(RFC2046)になる。
どうも、これらはTECH_DISCOVERED扱いになるようだ。

public static final short TNF_WELL_KNOWN = 0x01;
public static final short
TNF_MIME_MEDIA = 0x02;
public static final byte[] RTD_HANDOVER_SELECT = {0x48, 0x73}; // "Hs"
public static final byte[]
RTD_ALTERNATIVE_CARRIER = {0x61, 0x63}; // "ac"

 

実際にやってみると、そうなった。
だけれども、getParcelableArrayExtra()で取ってきてやると、ちゃんとNdefMessageになった(追記参照)。
ほほぅ。

 

ってことは、NDEFが113~127byteでごにょごにょ悩んでいたが、単にNDEFというintentが飛んでこないというだけで、解析する分にはどっちでもよいということなのか。

勉強になりましたわ。


追記(2013/01/14)

やっぱりだめだ・・・。

「getParcelableArrayExtra()で取ってきてやると、ちゃんとNdefMessageになった」と書いていたが、やっぱりだめっぽい。
nullになっていたのだ。

つまり、TECH_DISCOVEREDだったとしてもgetParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES)がnullにならないようにするには、AndroidがNDEFとわかった上でTECH_DISCOVEREDを返す場合だけ、ということになりそうだ。

ごめーん。

[android]単にNDEF_DISCOVEREDとしただけではNDEFのintentが来ない?

今回は、私の技術不足という問題。
「役者不足」といいますか。

ひとまず、NFC-FでもNDEFとして読み込んでくれるサイズにしたデータを書き込んだカードを作った。
では、それをNDEF_DISCOVEREDでintentを飛ばしてほしい。
ほしいのだけど、自分のアプリが起動しているときだけでいいので、intent-filterはManifest.xmlには書きたくない。

こんな作りにしてみた。

@Override
protected void onResume() {
    super.onResume();
    IntentFilter[] intentFilter = new IntentFilter[] {
        new IntentFilter(NfcAdapter.ACTION_NDEF_DISCOVERED),
    };
    String[][] techList = new String[][] {
        {
            android.nfc.tech.NfcF.class.getName()
        }
    };
    mAdapter.enableForegroundDispatch(this, mPendingIntent, intentFilter, techList);
}

AndroidManifest.xmlにはNFCのintent-filterを置かず、res/xmlも作っていない。

かざすと、logcatにはNDEFと出てくるのだが、onNewIntent()にはTECH_DISCOVEREDとして通知されてしまう。

うーむ。

2013/01/12

[nfc]NFC定義値が更新されていた

NFC Forumのページに「Assigned Numbers Register」というのがある。
さっき見たら更新されていたので、ご紹介を。

http://www.nfc-forum.org/specs/nfc_forum_assigned_numbers_register

 

Webページはしばしば更新されたり消えたりするので、ときどきスナップショットで記録するようにしている。
このページも以前記録していたのだが、久しぶりに見直すと変わっていた、という次第だ。
変更履歴みたいなページがあるといいんだけどねぇ。

  • SAP値「Internet Protocol」がなくなった
  • SAP値「OBEX」がなくなった
  • Well-known NDEF Record Type「Gc」は非推奨、という注釈追加
  • SAP値「Service Discovery Protocol」の説明が、v1.0からv1.1になった(というだけでURIは同じ)

"deprecated"は「非推奨」でいいのかな。

[n7]Nexus7ではFeliCa Liteで113byteのNDEFが読めないようだ

ここ最近やっている、NFC-FのNDEFがうちのNexus7で読めない件についてだ。
さっそく、コメントをいただいた(ありがとうございます)!

Nexus7を含めて4端末を見ていただいたところ、Nexus7だけがこの現象になったとのこと。
ほほぅ。
私の予想では、NXPのNFCチップを搭載した端末はすべてこうなるだろう、というものだった。
しかも、Galaxy NexusはPN65N、Nexus7はPN65なので、同じlibnfc-nxpライブラリを使っているんだろうと思う。

ということは、Android 4.2.1になってバグが混入した、ということになるんだろうか。
枯れている部分だと思っていたので、わざわざバグを入れ込む必要もなさそうだし、Nexus7にしたからって作り込むような気があまりしないのだ。

 

あとは、他の4.2.1端末で現象が発生するかどうか、というところか。
あるいはNexus7がバージョンアップしたら直るとか。

 

当面の私がやりたいのは、単にWi-FiのStatic Handover用NDEFデータを読み込みたいというだけで、頭から自分で読んでいってもなんとかなる程度のものだ。
なのだけれども、やっぱりめんどくさい。

もしNexus7のNDEFパーサが、NDEFメッセージのレコード先頭(MB=1)からレコード末尾(ME=1)までしか解析しないのであれば、NFC-Fのヘッダが持つデータ長は長めにしていても問題ないんじゃないか、という気がする。
「データはもっとあることになっているけど、ME=1だから解析はやめよう」という作りならば、だ。
今度、試してみようかね。

2013/01/01

[n7]リセットしたらインストールエラーが直った

自作のAndroidアプリがあるのだが、なぜかそれだけエラーでインストールできなかった。
不明なエラー「-24」などといわれる。
その数字自体が不明なんじゃ!

と怒っても仕方ないので放置していた。
Ejectするアプリだったので、メディアがないNexus7ではだめなのかも、と適当に考えていた。
今日、注文していたmicroUSB Bのホストケーブルが届いた。
USBメモリを挿してインストールしてみたが・・・だめ。
まあ、そうよね。

ネットで調べてみたところ、-24の原因はよくわからんが、初期化したら直る、というものが思ったよりも多かった。
まあ、そんなにアプリもインストールしてないし、ということで、やってみた。
説明は、こちら

やったら、直った。
えぇぇ、そうなんだぁぁぁ。。。。
でも、こういう破壊的な直し方って、製品としてはだめだと思う。
まあ、そういうのもひっくるめて値段を安くしているってことかもしれんので、否定するわけではない。
私の個人的な好みとは異なるというだけだ。
変にこういうところをがんばって高機能にする時代ではない、ということかもしれんな。

Wi-Fiダイレクトに対応したものは少ない?

Android Beamと同じくらいに採用されたWi-Fiダイレクト機能。
いつも並べて書いてあることが多いので、私はてっきりAndroid Beamと関係した機能と思い込んでいたのだが、まったく別々に使えるようだ。
Windows8でも対応したとか書いてあるので、うちのノートPCでやってみた。
・・・が、Nexus7はうちのノートPCを探すことができなかった。
ん、Windows8になってればいい、というものではない?
http://www.computerworld.jp/topics/612/164810
ハードウェアの変更まではいらないけど、ファームウェアの変更は必要そうだ。
ということは、Wi-Fiダイレクト対応のOSが載ったり、対応したデバイスドライバがあったり、というだけではだめなのだろう。
まあ、メーカーによって作りが違うから、一概には言えんだろうがね。

インテルのMy Wi-F-ダッシュボードという製品があるようだ。
よくわからんが、これをインストールすればいいのか?
うちのノートPCは4965AGNというインテルのWiFiコントローラだかなんだかが載っているのだ。
http://www.intel.co.jp/content/www/jp/ja/wireless-products/my-wifi-technology.html

プリンタは、Wi-Fiダイレクト対応、とかが出てくるのだが、普通のPCで使うような無線LAN子機でWi-Fiダイレクト対応というものがほとんど見つからなかった。
I/OデータのWN-AG300Uというやつは対応していたが、同じページにある他の子機は対応していない。
Baffaloにはマークがなかったが、わざわざ書くまでもないということなのか。。。

などと書いているうちに、My Wi-Fiダッシュボードのインストールが終わった。
「更新」をクリックすると近くのデバイスを見つけてくれるようだが・・・うちのNexus7を見つけられなかった。
Nexus7も、やはり見つけてくれない。
という以前に、My Wi-Fiダッシュボードのアプリ画面が違ってて「ワイヤレスON」という項目がないので、ちゃんと動いていないようだ。
もう疲れたので、今回はあきらめよう。

NFCいろいろ

NFC Worldの記事に、日本語の文字が出ていたので、目立っていた。
任天堂がNFC付きポケモンのおもちゃを出す、というタイトルなのかな。
http://www.nfcworld.com/2013/03/13/323045/nintendo-to-launch-pokemon-toys-with-nfc/
Googleで検索すると、いろいろ出ていた。
NFCタグというと、カードとかシールを想像しがちだが、形にはそんなにこだわらないので、ある程度のアンテナ面積さえ確保できればいいのかな。
きっと、タグデータも自作できるようなものなのだろうけど、おもちゃ自体はそんなに高価なものでもないそうなので、家にタグが余っているような人以外は普通に買った方がうれしいだろうね。

NFCというかFeliCaというか、サイバネ関連だが、交通系ICカードが結構な範囲で相互利用できるようになる。
いつもNFCのことしか書いていないような私だが・・・あまりNFCを生活で使ってはいない。
そもそも乗り物に乗ることが少ないし、買い物も現金でやるほうが多い。
もうちょっと生活に取り入れた方がいいのかねぇ(NFCのことを書く人として、という意味で)。

私の生活であれば、福岡内の移動か、あとは出張で関東に行くときくらいか。
福岡は、JRか、市営地下鉄か、バスだ。3つしかないのでわかりやすい。
JRは、SUGOCA、だ。
市営地下鉄は、はやかけん、だ。
バスというか西鉄は、nimoca、だ。

関東が問題だ。多すぎる。
まず、飛行機を使ったとしよう。
そこから浜松町までは東京モノレールに乗ったとする。
モノレールSuica、というものがあるらしい。
モノルン鉄道むすめはあるが、Suicaと名乗っているためか特定のキャラはいないみたいだ。
東京モノレールは、nimocaと相互利用できるとなっているので、大丈夫だ。
おっと、京急を使うかもしれない。京浜急行電鉄。
こっちは、PASMOのようだ。
PASMOも全国相互利用できるので、大丈夫だろう。
PASMOのロボット、がキャラらしい。
京浜急行は・・・というかPASMOはnimocaと相互利用できるとなっているので、大丈夫だ。
では、まず神奈川に着いたとしよう。
路線は、ここに一覧があった。
・・・多い、多すぎる。JRも、東海と東日本が入り込んでるし。
JR東日本は、Suica。あのペンギンなのだが、意外なことに専用キャラではないらしい。
JR東海は、TOICA。キャラはひよこだが、特に紹介もなにもない。
どちらも相互利用できるとなっているので、大丈夫だ。
ほかの鉄道も、PASMO範囲であればなんとかなりそうだが、細かいところは調べる気力が無い。
東京はどうだろうか。
営団地下鉄・・・ではなく、東京メトロか。会社名は「東京地下鉄株式会社」。ここもPASMOらしい。
都営地下鉄は「東京都交通局」。PASMOらしい。
ゆりかもめは「株式会社ゆりかもめ」。PASMO

疲れた・・・。
他にもたくさんあるのだが、とても調べる気力が続かない。

[無駄話]RTDの謎

かなり無駄な話だ。
現在、NFC Forumで公開されているRTD(Record Type Definition)は4つ。
  • NFC Text RTD Technical Specification
  • NFC URI RTD Technical Specification
  • NFC Smart Poster RTD Technical Specification
  • NFC Signature RTD Technical Specification
Generic Controlは、2012年8月9日でremoved、ってことだから外した。
さらば、Generic Control・・・。

さて、そのドキュメントファイルだが、名前がこうなっている。
  • NFCForum-TS-RTD_Text_1.0.pdf
  • NFCForum-TS-RTD_URI_1.0.pdf
  • NFCForum-SmartPoster_RTD_1.0.pdf
  • NFCForum-TS-Signature_RTD-1.0.pdf
TS、は、Technical Specificationだろう。
SmartPosterにはTSが付いていないが、これは名前が長くなるのを嫌ったからか。
それよりも謎なのが、RTDを先に付けるものと、後に付けるものに分かれていること。
そしてSignatureだけはバージョンとの間がハイフンになっていること。
なんでこんなに統一感がないのだ?

と、どうでもいいことを思った。
疲れてるんだよ・・・。

急にこんなファイル名を見たのは、NFC Worldの記事にRTDって出てきてたからだ。
中身は読んでないんだけど、気が向いたら読みたいところだ。