2013/02/28

[tizen]また微妙に変わった(サイトが)

なんか、変わった。

https://source.tizen.org/documentation/developer-guide/downloading-and-building

 

なんだろう・・・と思ったら、タイトルが違うんだ!
「Downloading and Building」→「Cloning and Building」となった。
(まあ、URLは同じようだが、そこは気にすることはあるまい。)

別に、細かいところを突きたいわけではなく、現在進行中なんだな、ということを確認したかっただけだ。
仕事でやってるわけじゃないし、本業が忙しいので、これくらいでいいのだ。

2013/02/24

[tizen]今日やったこと

「Tizen(たいぜん)のこと調べるのは、もう大変(たいへん)」、というセリフがすんなり出てくるくらい、私にとってはまだよくわかっていない。

また、ちょうど先週に2.0がリリースされたばかりで、いろいろまだ整理中だったりしているようだ。
たとえば、Tizen associationのja-JPがなくなっていたりとか。
たしか、先週見たときにはまだあったような気がする・・・。

以前から追っていれば、まだわかったのかもしれない(あるいは、かえって訳がわからなくなったか)。
しかし、私はちょうど先週から、というか、3日程度しか見てないので、状況がわかっていない。

そんな目線で、やってみたことを書いておこう。
ソースファイルがダウンロードできなかった件のまとめみたいなものだ。


まず、GBSとMICをインストールするらしい。
Ubuntuか、openSUSEか、Fedoraらしい。
うちは、Xubuntu 12.04がインストールされていたので、それを使った(前回起動したのが159日前だって・・・)。

説明に従っていくだけだった。
/etc/apt/sources.listに追加するのも、ちょうど12.04だったのでそのまま。


で、次のDownloading and buildingをやろうとして、ふと止まる。
Gerrit UI ?
Androidでは、たしかソースのレビューに使っていたような気がするが、私はソースファイルをダウンロードしたいだけなので関係あるのか?

どうも、あるらしい。
GBS(Git Build System)を使ってパッケージ管理みたいなものができるようだが、Androidでのrepoっぽいものではなく、GBSはビルドしたりもできるらしい。
とはいえ、そういうのにアカウントを作ってしまうと、操作を間違ってgit pushとかしてしまわないだろうか・・・。

不安ではあるが、仕方ない。
Environment setupと、slideshareにあったTizen gbs (git build-system)を見ながらやった。
SSHキーはgithubで作ったものがあるので、そのまま使うことにした(セキュリティ的に分けるもの?)。

sshコマンドを使って、
$ ssh review.tizen.org
とやるのだが、確かに「Welcome」とは出たものの、「不幸なことにインタラクティブななんとかかんとか」と出てきた。
解決するために、これこれを実行しなさい、みたいなメッセージが出るのだが、やってもサーバにつながらない。
よくわからんのでそのままにしているが、これがダウンロードできない原因かも・・・と小骨が刺さったような気持ちになっている。


review.tizen.orgのアカウントができたので、Downloading and buildingをやってみた。
Gerrit UIというのは、ブラウザ上にあるもののようだ。

image

ここに、ずらーーーっとプロジェクトがある。
Androidの、ディレクトリごとに切ってあるあれと同じようなものみたい。

で、cloneすればいいらしい。

$ gbs clone review.tizen.org:<プロジェクト名> <プロジェクト名>

と書いてあるのだが、実際のgbs-clone

$ gbs clone review.tize.org:プロジェクト.git

みたいな書き方になる。


それはまあいいとして、GBSには設定ファイルが必要となる。
.gbs.confらしいが、GBSをインストールしてもなかった。
別のサイトで「gbs」とだけ打てばできるとあったのだが、GBSのバージョンが変わったせいか、だめだった(私のは0.13だった)。
見つからなければHOMEの下に作るって書いてあるんだけど・・・。

「gbs build」と打つとなぜかできていたので、それを編集することにした。
こちらのサイト「Git Build System - GBSの環境構築 on Ubuntu 12.04 (1)」ではいろいろ聞いてきてくれたようだが、とりあえず私の時にはなかった。
なので、書いてあることを参考にconfファイルを編集した。

confファイルにreview.tizen.orgのアカウントとパスワードを書いておくと自動的にログインしてくれるようだ。
パスワードが平文だと嫌だなあ、と思いつつも入力しておくと、次に見たときには暗号化か何かわからんけどごにょごにょした文字列になっていた。

他にもいろいろ参考にしたことがあったように思うが、もう忘れてしまった。


「gbs build –A i586」と入力してみたが、エラーになる。
ソースファイルがないとか、なんとか。
まあ、実際にないのだけどね。

じゃあ、あのプロジェクトの中からどれをダウンロードすればいいのだ?というのが前回の話だ。
未だにわかっていないが、見ているといろいろと参考になりそうなところがあった。

  1. インストール直後のGBSでやること
  2. Git Build System - GBSの環境構築 on Ubuntu 12.04 (1)

特に2の方にはrepoのためのパスが書かれている。
今は、releases/latestの次に/2.0/が挟まっているので、そこら辺を書き換えたらうまくいってくれんかなー、と期待している。

まあ、試すのは次回だな。

TIZENのソースファイルをダウンロードしようとして、うまくいかん

Androidだとみんなやってるから、ちょっと違うことをしてみようかと思い、TIZENを見てみようと思った。

SDKは、書いてある通りにやって、インストールできた(Windows XP)。
では、せっかくなのでソースファイルもダウンロードしてみようと思った。

が、うまくいかない・・・。


TIZEN gbsセットアップ」という資料を見て、ツール類はなんとかなったと思う。
(うちは「gbs」とするだけでは設定ファイルができず、「gbs build」としないとできなかった。)

本家にも、ファイルの取ってき方は書いてある。
gbs cloneを使えばいいのだろう(誤記があって、gbsのパラメータにはgitファイルを指定する)。
それもまあ、わかった。

ソースファイルの場所はここ、ということも書かれている。
が、この膨大なプロジェクトの中からどれをダウンロードしたらいいのかがわからん。
Androidだと、repoを使って一括ダウンロードができるのだが・・・。

repoファイルをつくって提供している方もおられるのだが、さっきやったところでは接続ができなかった。
うーむ・・・。

Porting Guide、というページもあったので少し読んだが、こっちではgbsではなくoscというコマンドを使っている。
もう、訳がわからない・・・。


なんとなくわかったような気になったことだけ書いておこう。

  • アプリ側は「developer.tizen.org」、プラットフォーム側は「source.tizen.org」という棲み分けのようだ。
  • IntelがやっているからATOMとかかと思ったが、ARMで動く。
  • Tizen 2.0は2013/2/18にリリースされたらしい。1.0は「Larkspur」(植物:ひえんそう)、2.0は「Magnolia」(植物:木蓮)。ということは、次があるんだったら「N」で始まるのかな。
  • Tizen 2.0 alpha、というのは昨年出ていたらしい。
  • ときどき「IVI」という単語が出てくるが、「in-vehicle infotainment」の略らしい。よくわからんが、車載向けプロジェクトか何かみたい。Tizenの設定がときどき「ivi」のパスを指定していてダウンロードできない、みたいに書いてあるところがあった。

このくらいか・・・。
何もわかってねぇなあ・・・。


kernelだけgbsでcloneし、そこで「gbs build –A i586」と打つと、なにやらいろいろとダウンロードされて、ビルドされたように見える。
「-A armv7l」(あーむぶい7える)は、だめだった。

うーん、やっぱりわからんわ。

[html]Bloggerのエディタで書いてみよう

いつも、MicrosoftのLive Writerで記事を書いている。
自分のサイトのHTMLがどう書かれているかなど気にしたことはなかったのだが、articleタグがないのは気になった。

では、Bloggerの投稿フォームを使って書いたらどうなるんだろう?
Live Writer(しかもXP用)はまだHTML5のことを考えてない時代にリリースされているからarticleタグがないのかもしれない。

さあ、どう見えるかな?



・・・うん、同じですな。
articleタグはなかった。

2013/02/23

[html]URLのページじゃないときにスラッシュを付けるかどうか

そういえば、URLの終わりにスラッシュを入れるべきかどうかも、ときどき気になる。

たとえば、ドメイン名の直後だった場合。
ここだと「http://hiro99ma.blogspot.com」と「http://hiro99ma.blogspot.com/」だ。

この場合、http://のあとだから、ドメイン名しかないことはわかっている。
なので、クライアント(ブラウザ)は文字列をそのまま送っているかもしれないし、うしろにスラッシュを補完して送っているかもしれない。

そうじゃなかったら、ファイルなのかどうか区別がつかないので、クライアントはそのまま送るしかないだろう。
まあ、そう考えると、クライアント側は文字列を加工せずにサーバに送っていると考えた方がよいか。


To slash or not to slash

ハムレットの一部をもじったようなタイトルが恰好いいが、中身もなかなか興味深い。
これは「うちの経験からはこうだった」という、現実的な話である。

 

しかし、私が知りたいのは、どういう定義になっているのか?だ。
サーバの設定とか、ファイルシステムがどうのとかいうのは、結果でしかない。
仕様がこうなっているから、うちのサーバはこうしています、というところの「仕様」が知りたいのだ。

ブラウザって、HTMLであればその通り解釈するし、テキストファイルを突っ込めばその中身が読めるし、画像ファイルを突っ込めば画像が表示される。
私からすると、なんでそこまでやってあげるのだ?という不思議な世界である。
なんというか、世の中のありとあらゆるものを解釈してるんじゃないか、という得体の知れない存在なのだ。

なので「仕様としてやっているところ」と「親切でやっているところ」を見分けたいのだよ。


そういう目線で仕様を探してみたのだが・・・わからんかった。
やはり、Googleがいってるような探し方をするのが「一般的」というだけで、ルールはないってことなのかな。
そして、クライアント側は特に何もしない、と。

まあ、そういうことならそれでいいんだ。

[html]サンプルを理解しよう - HTML部

前回は、HTML5の文書型宣言について見ていった。
次は、HTML部分を見ていこう。

W3Cの仕様書から、「HTML4と同じく『文書型宣言』と『HTML』から構成される」という文書を探そうとしたが、いいのがなかった。
HTMLタグがHTML文書の頭(root)ですよ、ということくらいだ。
じゃあ他の文書もあるかも・・・。

と心配しても仕方が無い。
DOCTYPEにHTMLと書いたんだから、HTMLだけあると考えておこう。


こちらのサンプルは「構造化タグ」を使ったものらしい。
http://html5.imedia-web.net/sample/sections/write_html5.html

構造化タグ、は、bodyタグの中に書くもので、文書の構造的な意味(内容の意味ではなく)を意思表示するものらしい。
ここでは、4つのタグが使われている。

  • header
  • nav
  • article
  • footer

 

説明はなんとなくわかったのだが、「それをどうしたらいいの?」ということを考えて行き詰まってしまった。

構造タグの細分化
こちらのよると、ブラウザや検索エンジンに文書構造を伝える、とあった。
すまん、まだわからんのだ・・・。


HTML5 で新たに導入された構造タグ

検索すると、IBMのページが出てきた。
ありがたいことに、HTML5が出てくるまでの経緯や、DOCTYPEの話も書いてある。

HTMLの文字だけ解析しても、それがどういう構成で書かれているのかわからないので、最小限の構造だけでもタグにして区別できるようにしよう、ということらしい。

それなら、私にもなんとなくわかった。
ブログの1日ごとはsectionにして、記事はarticleにしておく、とかいうことなのだろう。
このページもHTML5っぽいから、きっとそうなってるはず・・・なってなかった。
asideはあるんだけど、sectionやarticleはなかった(Live Writer使ってるからか?)。

 

ともかく、サンプルは何となくわかった気がする。
もちろんHTML5がわかったとか、そんなわけではない。。。

[html]サンプルを理解しよう - 文書型宣言

本を買うまで、こちらのページを見ながら勉強しようとしている。
html5入門

サンプルを見て、動かして、とりあえず動いた。
では、いったいこのサンプルはなんなのかを理解しよう。

そう、HTMLもCSSもよくわかっていないので、そもそもサンプルの意味がわかっていないのだ。


HTML5の特徴を使ったサンプル、ということくらいはわかっている。
特徴の中でも「構造タグ」というものを使ったサンプルであった。

では、「構造タグ」とはなんだろう?
http://html5.imedia-web.net/feature/structure.html

HTML4には「body」というタグがあるが、構造タグというのはその中に書くものらしい。
確かに、サンプルもそうなっている。

では「body」ってなんだろうか?


(日本語訳)http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html

まず、HTML文書というのは、以下の2つから構成される。

  • 文書型宣言
  • HTML要素

 

「文書型宣言」は、HTMLバージョン情報らしい。
この書き方に、3種類あるようだ。

  1. HTML 4.01厳密型DTD : strict.dtd
  2. HTML 4.01移行型DTD : loose.dtd
  3. HTML4.01フレーム設定型DTD : frameset.dtd

うん、よくわからん。
日本語訳をされた方のページを見ると、こうなっていた。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

「Transitional」というのは、移行型らしい。しかし、loose.dtdを指定してないな。。。
「DTD」というのは文書型定義の略らしく、たとえばloose.dtdなどにその内容が書かれている。
ちょっと見た感じでは「タグaは○○します、タグdivは○○します」のような、そういう定義が書かれているようだった。

つまりブラウザの動作としては、まずHTMLファイルの最初を読んで、このHTMLファイルがどういう文書型なのかを探し出し、解析したりレンダリングする機能に指示を与える、ということをやるのだろう。

ただ、毎回そんなことをしていたら表示するまでにとても時間がかかるので、ブラウザ内部にその定義を複数持っていて、「これは移行型だからこの設定でいくぞ」というようなことをやっているのかな。
あるいは、3つ定義があるけど、実はどれか1つをサポートしておけば全部対応できるようになっているとか。
実装する大変さを考えると、どれか1つやっておけばいい、がありがたいな(私が実装するわけじゃないけど)。


サンプルでは、こうなっている。

<!DOCTYPE html>
<html lang="ja">

さっきのに比べると、ずいぶんさっぱりしたものだ。
PUBLIC以降が省略されたように見えるが、文書型宣言はどうなったのだろう?

 

やむなく、原文を探す。。。
http://www.w3.org/TR/2012/WD-html5-diff-20121025/#doctype

「DOCTYPEは、ブラウザが標準モードでレンダリングすることを指定する、という以外のことをしない」と書かれている。
つまり「この文書はHTMLですよ」ということしか言わない、ということだろう。
ふーん。

「標準モード」と書いたが、これはstandards mode、となっている。
標準、というのはおそらく、HTML5標準、という意味なのだろう。

では、HTML4などのDOCTYPEはどうなるかというと、今までの記述は「strict doctypes(厳密なDocType)」ということで、HTML文法で記載することを許可するようだ。
うーん、よくわからんが。。。厳密に指定したものは、厳密なHTML解釈しかしなくてよいですよ、ということなのかな。


厳密なHTML5定義を知ろうとしているわけではないのだが、どこを気にすべきで、どこを気にしなくていいのかわかっていないので、効率が悪いな・・・。

まあ、そういうところも含めて勉強していけばいいか、と気楽に考えることにした。

[html]タグは大文字? 小文字?

インデントは、まあいいとしよう。
それよりも気になるのは、タグを大文字で書くのか小文字で書くのか、だ。

前回参考にさせていただいたサンプルは、1行目に「!DOCTYPE」とびっくりしながら(じゃないと思うが)大文字になっている。
それ以降は小文字だ。

しかし、HTML4.01の技術仕様書には、タグが大文字で書かれていた。

http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.1
(日本語訳をされた方のページ)

うーむ・・・・。


答はここに書かれていた。

(原文)http://www.w3.org/TR/html401/types.html#h-6.9
(日本語訳)http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/types.html#h-6.9

「case-insensitive」というわけで、大文字小文字は区別しない、ということだ。
ほほぅ。

速く処理したい、という観点からすると、区別するようにしておいた方がよいはず。
だって、たとえば「div」にしても、

  • div
  • Div
  • dIv
  • diV
  • DIv
  • DiV
  • dIV
  • DIV

と、2の3乗だけ組み合わせがある。
だから、まず大文字か小文字かのどっちかに変換する処理をしてからタグを識別するように作るだろう。
これが、大文字か小文字かだけに固定すると、変換処理が不要になる。

とはいえ、歴史的な観点もあろうし、そもそもテキストファイルという特性からすると、「タグの種類が異なるからエラー」とはできないのだろう。


じゃあ、URIはどうなんだろう?
昔から気になっていたのだ。

(原文)http://www.w3.org/TR/html401/types.html#h-6.4
(日本語訳)http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/types.html#h-6.4

微妙な表現だ。「general are case-sensitive」。
一般的には大文字小文字を区別する

 

これは多分、ファイルシステムが関係しているんじゃなかろうか。
FATや大文字小文字を区別しない(基本的に大文字管理で、拡張して小文字なども保存している)。
NTFSはよく知らないが、Windowsで使っている分には区別しなさそうだ。

ext2やext3は、区別する。
Androidのプラットフォームをビルドするとき、ファイルシステムが大文字/小文字を区別できるかどうかチェックしていて、Windowsでビルドできないのはそのせいだ(区別しないといかんからだろう)。

ともかく、仕様としては「安全のため、大文字小文字は区別するものと考えておくこと」となっているので、そう思っておこう。

[html]インデントしなくてよい?

ちゃんと取り組んでHTML5を勉強するつもりなので、午後に本を買いに行こう。
それまで、ちょっと下調べをする。


まずは書いてみよう、と思い、サイトを探した。

HTML5入門

そもそも、私にしてみると「HTML5」以前に「HTML」の入門がいるのかもしれんが・・・・。
まあ、あまり深く考えずにサンプルをまねして書いてみた。

> まずは書いてみよう

こちらのページを、そのまま書いて動かした。
ふむふむ、divは知っていたけど、articleとかnavとかいろいろあるんですな。

と、そこまではよかったのだが、サンプルのzipをダウンロードして見てみて、ふと疑問がよぎった。

「HTMLの書き方って、どうやるんだろう?」


私はいつもの習慣で、こういう書き方をした。

<!DOCTYPE html>
<html lang="ja">
    <head>
        <meta charset="UTF-8" />
        <title>喉が痛い</title>
        <link rel="stylesheet" type="text/css" media="screen" href="style.css" />
    </head>
    <body>
        <div id="wrap">
            <header id="head"><h1>エスタック</h1></header>
            
            <nav id="navi"><ul><li><a href="./">HOME</a></li></ul></nav>
            
            <article class="post">
                <h2>記事のタイトル</h2>
                <p>HTML5の構造化タグを使おう</p>
            </article>
            
            <article class="post">
                <h2>記事のタイトル2</h2>
                <p>ふーん</p>
            </article>
            
            <footer id="foot"><a href="./">マーカス</a></footer>
        </div>
    </body>
</html>

サンプルでダウンロードしたファイルを見ると、インデントがないのだ。
HTMLだけでなく、CSSも然り。

気になったので、http://www.yahoo.co.jp/https://www.google.co.jp/も見てみた。
Yahoo! JAPANは、すこーしだけインデントがあるところもあったが、ほとんど平たい。
Googleにいたっては、改行があるんだかないんだかすらわからなかった。。。

3つくらいしか見ずに結論を出すのもよくないのだろうが、一般的にHTMLはインデントしないものなのかね?


私の想像だが、HTMLみたいなテキストは、しょせんブラウザが読むためのテキスト。
人間の読みやすさよりも、ファイルサイズを小さくして、速く読み込み終わるようにしたいのではなかろうか。
そういう意図からすると、インデントは無駄なスペースにしかならないし、改行だってそうだ。

C/C++やJavaのようなコンパイルするソースファイルは、コンパイラが読み込むためのものとはいえ、コンパイルしたオブジェクトが結果として残る。
コンパイラにとってもインデントなんかは不要なのだけど、そこの読み込みに多少時間がかかったからと言って、最終的にできあがるオブジェクトの品質に違いがあるわけではない。
だから、人間がメンテナンスしやすいようインデントなどを付けているのだ。

 

そういえば、Javaなんかはメソッド名や変数名がオブジェクトサイズに影響を与えるから、短く変換するツールなんかがあったよなあ。
HTMLも、最初はインデントなどをつけて読みやすくしておいて、最終的な出力はブラウザが速く読み込めるように変換しているのかもしれない。


さて、たったこれだけのHTMLを手で打ち込んでみたのだが、普段使わないキーを多用するため、腕が疲れた。。。

「<」と「>」と「/」と「”」、とくに「<>」はよく使うので、右手の薬指を動かす筋肉が疲れる。
私はJIS配列のキーボードを使っているのだが、「()」のキーと入れ替えた方がいいんじゃないか、とすら思うくらいだ。

きっと、eclipseとかだと括弧が自動補完されて楽なんだろう。
あるいは、もっとすごい機能がついているのかもしれん。
まだまだ知らないことがたくさんあることだよ。

2013/02/15

[n7]Android 4.2.2で宿題は終わるのか?

以前、こんな記事を書いた。
[nfc]AndroidはType 3 TagのNDEFメッセージが113~127byteだと認識してくれない

コメントで「Android 4.2.1のバグかも」というお言葉をいただいた。
ふむふむ、そういうこともあるのか。
他の端末を試してみたいが、4.2.1は持ってないしな。。。。

 

と思って忘れていたところ、うちのNexus7に4.2.2のバージョンアップが降ってきた。
うひゃっほう(喜んでる叫びのつもり)。

以前試したデータでやってみよう。


結果!

image

読めた!
宿題は終わったんだ!!


まあ・・・別に私が修正したわけでもないし、直してもらうよう働きかけたわけでもないから、以前からわかっていたんだろうね。

こういう細かいところが修正されるのは、うれしいところだ。


気になったので、ソースファイルの変更箇所も調べることにした。
といっても、gitのログを見るだけだが。

https://android.googlesource.com/platform/external/libnfc-nxp/+/35f614f9db6e01ed6d07eda5fba5d647839d50a3%5E!/

おそらく、この変更だろう。
「Type 3 tag読み込みのとき、パディングを捨ててないのでNDEF解析に失敗する」ということらしい。

関数としては、phFriNfc_Felica_HChkApduBuff_Size()に変更が行われただけのようだ。
Type3のヘッダにあるサイズを使うか、読み込んだサイズを使うかの判断が追加された。

FeliCa Liteなどは16byte(1ブロック)単位でアクセスするが、その16byteにまるまる入っているわけではない。だから、それを調整したのか?
しかし・・・それだったら、もっとNDEF解析に失敗しただろう。

まあ、なんかあるんだろうね(深追いせず)。

2013/02/10

NFC-Bの探し方

Fukuoka NFC Hack 7で、IC運転免許証が読めなかったり読めなかったり、ということがわかった。
うちのNexus7だけか?とか、私のIC免許証だけか?とか思っていたが、そうではないことがわかったのだ。

ならば、調べねばならぬのう。


NFC-Bをどうやって探すか、ということになる。
Type-Bの仕様書を読んだ方がいいのだろうが、ISO/IEC-14443を持っていないので、NFC Forumの仕様を読む。

ALLB_REQか、SENSB_REQだろう。
ちなみに、SENSF_REQは、いわゆる「ポーリング」である。

と思ったが、「ALLB_REQ and SENSB_REQ」ということになって、同じコマンドのようだ。
そのパラメータは、AFIとPARAMの2つだけ。
ふっ、解析も楽そうだ。


AFI

Application Family Identifierの略。
NFC Forumでは「0x00」となっている。
念のため、IC運転免許証の仕様書を確認したが、同様に0x00だった(初期化及び衝突防止)。

PARAM

意味を持つのは、この中の3bit分。

Advanded protocol feature supported
Extended SENSB_RES supported
SENSB_REQ / ALLB_REQ


AFIは、どちらの仕様書でも0x00となっているから、PARAMの部分に違いがあるのか。
あるいは、NFC-Bはカード検出無しにアクセスできるのか。。。

今まで聞いてきた感触からすると、NFC-Bはこういった過程を経ずにアクセスできるようになっていたように思う。
ならば、なぜ一握りの人だけがNFC-Bとしてアクセスできるのか?

 

IC運転免許証が読めた人と読めなかった人の違いとして、読めた人は設置してある「IC免許リーダ」のような機械を使った、という動作がある。
警察に「読めんよ」と確認した人も、設置してある機械は使っていなさそうだった。

となると、そのIC免許リーダの仕様で(あるいはバグで)、読み込むときに開いた情報を閉じないままになっているため、他からアクセスできるようになってしまった、ということはないだろうか。
いや、ないとは思うのだが、聞いた感じの話からすると、違いはそれくらいしかなくて。。。

 

Type-Bや、USIMなどのICカード一般の仕様、というものがある。
ICメモリファイルシステムの仕様だったような記憶がある。
そこら辺に引っかかるのかしら?


そんな感じで、NFC-Bについてはまだまだわからないことが多い。
タグを入手するのも難しいので、まあ、理解は先になるだろう。

2013/02/09

複数枚のNFCタグ重ね

Fukuoka NFC Hack 7で、「複数枚のNFCタグを重ねたらどうなる?」という質問があった。
うっ、痛いところを・・・。

NFCの規格の痛いところ、ではなく、私の知識がないという点で痛いところなのだ。


これについては、CQ出版のInterface誌2012年4月号が詳しい。

 

まず、無線、という視点で。
無線は、ほとんど同時に届く。
少なくとも、NFC程度の距離であれば同時と考えていいだろう。

無線を出す方、リーダライタを「イニシエーター(initiator)」と呼んでいる(NFCだけ?)。
無線を受ける方、カードを「ターゲット(target)」と呼ぶ。
NFCの通信は、イニシエーター主導で行われ、イニシエーターの無線送信に対してターゲットが返信をする動作が基本になっている(NBM、Normal Balance Modeと呼んでいる)。

よって、リーダライタが出した無線コマンドを、カードは同時に受信する。
何も考えなければ、そのままカードは返信をする。
同時に受信するので、全カードは同時に返信する。

無線の特徴として、波形は足し算ではなく掛け算になる、ということがある。
データが同じ1になれば波形が大きくなるが、片方でも0があると0になってしまう、ということだろう(済まん、細かいところは知らないのだ)。
大ざっぱに言えば、同じタイミングで複数のカードが返信すると、無線が重なってデータが化け化けになってしまうのだ。
つまり、誰かが勝つのではなく、全員が負ける(読まれない)。

無線のプロトコルを考えるときは、無線が重なった場合の動作も含めて方式を考えておかなくてはならない。
重なったままでもいいようにするか、なるべく重ならないようにするか。
NFCも例外ではなく、無線が衝突したときのことを考えている。
(アンチコリージョン、と呼ばれる。)


特定のカードがわかっている場合、例えばFeliCaであればIDmが既にわかっている場合、IDmを指定して無線を送信して、IDmが一致したカードだけが返信する、というしくみにしておけば返信が重なることはない(IDmは、もともと複数のカードをかざしたときの対策だと思っておいた方がいいだろう)。

しかし、「カードの有無を探す」というような場合には、相手を特定できない。
どういうカードがいるかわからないから「みんな応えて!」というコマンドを出すからだ。

では、どう回避するか?
これはNFC-A, B, Fで異なる。
以下、Interface誌を読みながら書いていく(詳細は、買って確認しましょう)。

 

NFC-A

リーダライタからの要求に対して、カードはUIDを返す。
それを受信したリーダライタは、どうやら同じビットデータを返したときにはわかるらしい。
そのときは衝突したことがわかるだけでなく、衝突したビットがわかるらしい。
そういうときには、リトライをする。するときには「衝突ビット」という情報があり、衝突ビットが「0」となっているカードだけが返信する、というしくみになっているそうだ。

これを繰り返し、全部が衝突しないようになったらおしまい。
このやり方を「ビット・コリジョン方式」と呼ぶそうだ。

NFC-B

読んだが、よくわからん・・・。
「スロット・マーカ方式」という方法だそうだ。

まず、リーダライタが要求したとき、各カードは乱数を発生させ、それをスロットマーカ番号として保持する。
リーダライタもスロットマーカ番号を生成し、それをカードに通知している。
その番号がリーダライタの番号と一致したカードだけが返信する、というしくみになっている。
そうやって返信したものが衝突した場合は、やりなおす。

つまり、じゃんけんして、あいこだった人が一人OKだけど、あいこの人が複数いた場合にはやり直す、ということかな。

NFC-F

NFC-Fはよく使うので、だいたいわかっているつもりだ。

まず、リーダライタから「ポーリング」というコマンドを出す。
このときに、反応してほしいカードの指示をする(システムコード)のだが、それと同時に「この時間の範囲内で適当に返信しろ」という値も指定する。
ポーリングコマンドの説明で「00 FF FF 00 00」というものが多いと思うが、最後の「00」がそれだ。
ここが「00」の場合は、返信時間が0なので、ランダムではなく即時返す。
だから、複数枚のカードがあると返信が衝突する。

この値を増やすと(指定できる値はパターンが決められている)、返信できる時間に余裕ができるので、衝突する確率は減る。
減るが、応答性はその分悪くなる(返信がランダムなので)。

応答性を取るならば値を小さくしたいが、複数枚を区別したいなら大きくすることになるだろう。

しかし、やり方を見てもわかるように、どれも「同時に読み取る」ための方式ではない。
無線は、同じ周波数で複数のデータを返すことはできないのだ。
いわゆる「ブロードバンド」というのは、この周波数帯を複数持つことで、複数のデータを同時に伝えることができるようにしているだけだろう(データバスが、シリアルかパラレルか、みたいなものか)。

同じように、同一周波数の無線を送信しながら受信する、というような芸当はできない。
やったら、自分が送信したデータを自分で受信するだけだ(のはず。いっぺんやらかしたので)。

このように、無線の通信というのは偶発的な要素が非常に多い。
多いので、システム的に回避する手段をかなり考え込んでおかないと、テスト段階では大丈夫でも運用中に失敗する。
有線の方は詳しくないが、無線については既存の安定した方式が既にあるのならば、実装が面倒であってもそれに従うのが最終的には楽だと思っている。

libpafeとlibnfc

Fukuoka NFC Hack 7でRaspberry PiでPaSoRi RC-S370を動かしている例を見た。
そのとき、libpafeとlibnfcを両方やってみたということだった。

そういえば、私も少し触ったことがあったな、と思い出してみた。
思い出すだけで、ソースファイルは見ないから間違ってるかも。


libpafeは、PaSoRiを動かすことに特化している。
また、FeliCa用になっている。
やれることは限定されるけれども、だいたい使う機能は載せられているので、よくできていると思う。

 

libusbは、NFC R/W全般が使えるようにがんばっている。
開発元が日本ではないので、RC-S360へのサポートも含まれてはいるけれども、メンテナンスする人が少ないためか、細かいところまではサポートしていなかったような気がする。

ちなみにlibnfcは、コンパイルオプションか何かでデバイスの検索対象を指定できたような気がする。
USBだけでなく、シリアル接続も対象になっていて、シリアルの場合は接続されている全ポートに対して何かコマンドを投げて応答を見るような作りになっていたと思う。
大ざっぱだなぁ、とは思ったが、接続されているシリアルポートがわからないのだったら他に方法はない。

 

うちのRC-S620/Sでlibusbが動くよう、あれこれ見ていってはいたのだけど、途中でめんどくさくなった。
「もう、自分で作った方が早い!」(できのいかんは別として・・・)というわけで、結果的に自分でライブラリを作ることになったのであった。


今のところの完成形は、こちら。
https://github.com/hirokuma/libhknfcrw_c

「今のところ」のくせに「完成形」も何もあったもんじゃないのだが・・・。
ともかく、今の私の中での最新版である。

当初、C++でつくっていた
どうせNFC R/Wなんか1つしかつながないから、static classだけでいいや、という作りだ。
でも、ライブラリの汎用性を考えていくと、結局Cで作っておいた方が使い勝手がいいか、ということになった。
これが上記のライブラリだ。
なお、C++版を多少いじったのがArduino版だ。
その前に作ったのがAndroid版で、C++版とC#版(SDK for NFC)から持ってきたりしている。

NFC R/Wへの読み書きと、memcpyやタイマ系の部分を分離させ、そこだけ各自のプラットフォーム用に実装すれば使えるようなイメージにしている。
cygwinとFM3基板で動かせるようにはしたので、まあ動くのだろう。

残念ながら、消費電力を抑えるようには作られていない。
そこまでいくと、その上に載せるアプリの仕様などに引っ張られるので、もういいや、と思ったのだ(と思うが、それよりも「めんどう」という気持ちの方が強いがね)。

基本部分は、NfcPcdというソースファイルにあるので、見るべきはそれくらいか。
定数をひたすらバッファに設定してR/Wに送信し、その受信データを見る、というだけだ。

作った当時は、RC-S620/Sのコマンドがわからないので、PN533のドキュメントを見ながら試し、だめだったらパラメータを変更してみる、というような試行錯誤をしていた。
そのため、見た目はわかりやすいが無駄っぽい処理が多い。
あんまりトリッキーなことはしていないと思うので、動かしてみて、必要な処理だけにして、不要なところを改善する、などとするといいのかもね。

2013/02/07

[arduino]うちもSoftwareSerialでデータが化けるなあ

「うちも」というのは、アトリエのどかさんの「Arduino+RC-S620/SでSoftwareSerial通信が上手くいかない」を見たからだ。

ソフトウェアでシリアルをエミュレーションするには、ハードウェアでやってることをソフトでやらんといかん。
今回で言えば、

  • スタートビットの検出
  • そこから8bitを1bit時間ずらしながらサンプリング

くらいだろうか(ストップビットとかは省略)。

SoftwareSerial.cppを見てみると、最初の方に動作クロックごとのテーブルがあった。
ここでタイミングを調整するパラメータを決めているようだ。
Arduino UNOは16MHzで動いているので、最初のテーブルみたいだ。
rxcenterでビットの真ん中まで持ってきて、あとはrxintraずつ時間をずらしながらサンプリングするようだ。

DebugPulseという文字があるから、そこでポート出力させながらUARTの波形と並べてみるといいんだろうけど、めんどくさい。

データが化けるのだけど、だいたいMSBがとれるかとれないか、というような値になっている。
一定していないところを見ると、115200bpsは速度の限界なのかな、と思った。
元になっているNewSoftSerialでも、16MHzだと56kbpsくらいだって書いているので、そんなもんなのかな。

2013/02/05

[nfc]月刊NDEF 2月号(臨時号)

前回が最終号だった月刊NDEF。
しかし、「Type 2 TagのNDEF特集を是非とも見たかった」という読者(私)の声があったので、臨時号として2月号を出すことになりましたとさ。
めでたしめでたし(?)。


「一太郎」というオフィスソフトで作っているのだけど、MS-Wordに慣れてしまったせいか、うまく使えないこともしばしば。
しかし、クリップアートの出来が私の好みに合っていて、それだけでもよかったと思っている。
んで、Wordはなくても何とかいけると思っているのだが、Excelはあったほうがよいと思った。
LibreOfficeを使っていて、スライドはImpressを使うし、図形はDrawを使うけれども、表計算はどうしてもExcelが使いたくなってしまう。
頭が固いのかねぇ。

2013/02/03

[arduino]なんで抵抗器に4本線と5本線があるんじゃー

最初に書いておきますが、抵抗器のことなのでArduinoのせいではありません。。。

私が子供の頃、抵抗器は4本線しかなかったような気がする。
色の覚え方は昔と変わらないかもしれない(最近、ロジアナのプローブが同じ配色であることに気付いて、急に覚えやすくなった)が、本数はちょっと困る。

それに、最近はチップ抵抗が多くて、抵抗の上に数字で「103」などと書いてあったり、さらに小さいやつには書かれてすらいなかったり。

抵抗器はアナーキーな時代になったのだ(おおげさ)。


だいたい、抵抗器にぐるっと色の輪を作るより、数字を印刷した方が楽だったんじゃないだろうか。
いや、それだと印刷してある面だけしか文字が見えないから、取り付けるときに「数字を上にしないと」と飲み会でビール瓶を持つときにラベルを上にしなくちゃ理論が働いてしまい、取り付け効率が悪くなったからだろうか。

 

いかん、脱線しすぎた。

4本の場合と、5本の場合の違いは、こうだ。

  • 4本: AB * 10^C
  • 5本: ABC * 10^D

AとかBとかは、色の順番だ。
4本の場合は、最初の2色で2桁の数字を作り、それに3番目の色を10の乗数にする。
5本の場合は、最初の3色で3桁の数字を作り、それに4番目の色を10の乗数にする。
最後の色は、許容誤差。


そこまでわかっても・・・やはりわかりづらい。
そもそも、色の見た目で区別するということが難しい。
赤と茶色って、けっこう似てないか?

それに、どっちが1桁目かもわかりづらい。
どうやら、偏って端っこになっている方が1桁目らしい。
また、太い線は終わりの桁らしい。
そういわれて見ると、若干太くなっている気がする・・・。

 

でも、結局自信が持てないので、最後はテスターで調べることにしている。
私のいいところは、自分を信用しないということだと思う。

[arduino]なんでLEDにつける抵抗が220Ωなのか

Arduino本(Starter Kitに入ってた本)の最初は、LEDを接続する回路だ。

といっても、ArduinoのGPIOに接続するのではなく、5V出力とGNDにつなぐだけ。
もちろん、抵抗もLEDと直列に接続する。
そうしないと、LEDが焼けてしまうから。

で、その抵抗が220Ωとなっていた。
その値は、どこからやってきたのだろう?


本には、オームの法則で「5[V] = I[A] * 220[Ω]」だから、LEDに流れる最大電流は23mAだよ、と書かれている。

じゃあ、その23mAを上限とすればよい、という値はどこから出てきたのだ?
それ以前に、LEDと抵抗は直列つなぎだから、それぞれに電圧がかかるので、LEDが壊れるか何かでショートしてしまったら上記の式になるかもしれんけど、そうじゃないよなあ。

 

LEDの特性から電流の上限を決めるのだろうが・・・Starter Kitに付属しているLEDの型番はわからなかった。
https://sites.google.com/site/mathrax2010led/led/-arduino-ledno
こちらを読むと、だいたいこんなもん、という数字が出ていた。
色によって違うのね・・・。
通常は、電圧と電流のグラフがあって、そこから「このぐらいなら壊れないかな」という値を決めるようだ。

 

220Ωをつないだ場合の電圧などを、うちのデジタルマルチメータで見てみた。
(すごく安いやつを買ったので、ちょっと使いづらい・・・。)

  • 抵抗:2.85V
  • LED:1.99V
  • 電圧:4.85V
  • 電流:13mA

こんなもんだった。
そもそも、なんアンペアを流したい、という数字は書かれていないので、これが期待した結果なのかどうかがよくわからん。。。

さきほど参考にしたページの次に、気にしていることが書かれていた。
https://sites.google.com/site/mathrax2010led/led/-arduino-ledto-teikou-no-keisan-2
このページでは、LEDに2V-20mAを流したいときの計算が書かれている。
うん、そうよね。LEDにかかる電圧を引いてから計算せんとね。

本を書いた人の意図ははっきりしなかったが、まあ、抵抗値が大きい分には負荷がかからなくてLEDも長持ちするからいいや。