寒い(今は3月)ので、こたつに入ってnfcpyを読むことにした。
土曜日くらいは店じまいを早くしてもよいだろう。
さて、今のnfcpyは、0.10.2が最新。
あまり使ったことが無いのだが、libnfcよりはSONY系のR/Wをサポートしている感じがある。
今回見たいのは、RC-S380。
S370は販売中止になったと思うので、一般向けはS380だけになったのだと思う。
業務用はまだ息が長いのだろうが、まあよかろう。
おsのRC-S380だが、nfcpyではrcs380.pyという名前になっている。
というよりも、名前がそうだから、たぶんこれだろう。
以前はテキストエディタで見ていたが、少しPythonを勉強してIDEのPyCharmというものがあることを知った。
それで見てみれば、当時よりはもっと簡単に解析できるはずだ!
・・・できない。
ファイルを開いたら、赤線がいっぱい出てきた。
もう、おしまいだ・・・。
まず「import logging」で赤線。
ホバーに「No Module Named logging」と出てくるから、loggingというpythonのモジュールがないのだろう。
でも、標準にloggingはあってもおかしくなさそうだ。
うーむ。。。
あ、こうやるんだ。
・・・だめだ。
「pip install logging」が失敗するらしい。
どうやら、cygwinにインストールしているpythonを最初に設定したようで、そのためにpipでダウンロードまではしても、実際のパスが見つけられないようだった。
新しい酒は新しい革袋に、というわけではないが、場所場所にあったものを使わないとどこかで苦労するということもあるのは知っていて損はないだろう。
では、気を取り直して。
最初の方に、class Chipsetというのが出てきた。
ACKとCMDがある。
ACKはこういう感じだったのは覚えているが、CMDは・・・。
今までの名前と違うし、数値も今までと異なる。
こりゃうまくいかんはずだ、と思うのと同時に、このライブラリを作ったのって、きっと内部の人だろうという感じが伝わってくる。
今までの名前と一致しないけど、名前の付け方から逸脱していない。
ただ、R/Wのチップが変わったとしても、それはR/Wのチップとホスト間が違うだけで、無線の区間については変わるはずがない。
それに、これはR/Wへの制御をまとめるライブラリなので、今まで見慣れているRC-S956系に出す指示と、新しいチップに出す指示の意味は同じはずだ。
そこさえ意識しておけば、むしろ仕様書だけ公開されている場合よりも調査しやすいだろう。
class Chipsetは、R/Wに依存した内容が書かれているようだ。
その次にあるclass Deviceがそれらを隠蔽しているのか?
Chipset.in_set_rfを使っているものを検索すると、Device.sense_ttaがあった。
sense_ttaで検索したが、これから先はなさそうだった。。。
ttaだけでなく、ttb, ttfもあったからTag Typeの略なのだろう。
じゃあ、ttaで検索すれば何か出てくる・・・来ない。
device.pyにclass Deviceがあり、そこにsense_ttaがあったから、これがインターフェースクラスみたいなものなのだろう。
clfの_init_pyで「self.device.sense_tta(target)」としているから、たぶんこれなのだろう。
なお、clfは”ContactLess Frontend”の略だ。
読めばわかりそうな感じはするけど、必要性が今のところないので食指が動かないな。
まあ、そんなことをいえば、そもそもNFC R/Wのことを調べるなんてことをなんでやったのかって聞かれそうなんだが・・・。
それは、勢いだな、うん。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。