hiro99ma old blog

2013年2月23日

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

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

前回参考にさせていただいたサンプルは、１行目に「!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」にしても、

と、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>記事のタイトル２</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にいたっては、改行があるんだかないんだかすらわからなかった。。。

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

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

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

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

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

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

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

2013年2月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のバージョンアップが降ってきた。
うひゃっほう(喜んでる叫びのつもり)。

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

結果！

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

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

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

気になったので、ソースファイルの変更箇所も調べることにした。
といっても、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年2月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の２つだけ。
ふっ、解析も楽そうだ。

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年2月9日

複数枚の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なんか１つしかつながないから、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年2月7日

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

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

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

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

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

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

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

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

2013年2月5日

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

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

月刊NDEF 2013年2月号(臨時号)

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

2013年2月3日

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

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

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

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

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

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

いかん、脱線しすぎた。

４本の場合と、５本の場合の違いは、こうだ。

４本：　AB * 10^C
５本：　ABC * 10^D

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

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

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

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

[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も長持ちするからいいや。

登録: 投稿 (Atom)