hiro99ma old blog

2012年7月29日

[無駄話]動作確認できないものを作る

FeliCa Developers' Blogを見ながら移植してみた。
持ってないし、動かしたことがないのでよくわからん。
単にコンパイルが通ったというレベル。
動いたらびっくりだ。
https://sites.google.com/site/hiro99ma/home/files/other/libhknfcrw_Arduino.zip?attredirects=0&d=1

今のところ買う予定はないが、何かの拍子に入手するかもしれないので、まあいいや。

[os]アプリとライブラリを分離

FM3+TOPPERS/ASPに、自作NFCライブラリを持ってこようとしている。

消費電力とか効率とかはまったく考慮せず、PCで動かしたのと同等くらいのものが移植できたんじゃないかな、と思う。
移植といっても、C++だったものをCに置き換える作業がほとんどだったがね。

https://github.com/hirokuma/toppers_snep_target

NFC部分はヘッダファイルとライブラリだけにしてもビルドできるようになった。
まあ、-gで-O0なので、中身は見放題じゃないかね。

gccのリンクって、oファイル単位だったような気がする。
違ったっけ。。。こんなのがあるらしいが、やったことないな。ここにも記載がある。
R/W操作を1ファイルにしているので、けっこう大きくなるかも。
試しに--ffunction-sectionsと--gc-sectionsを付けてみたが、--gc-sectionsがあるとTOPPERS/ASPのcfgってのに怒られた。
なんかあるんじゃろうね。

libhknfcrwはTOPPERS向けに作ったところは特にないとおもう。
移植対象は、hk_misc.hとhk_devaccess.hに分けているので、そこに環境向けの実装を書けばなんとかなるんじゃなかろうか。

今回は、hk_misc.cとhk_devaccess_toppers.cというのにしている。
私が作った中で、唯一μITRONっぽいことをしている箇所だ。
シリアルの送信なんて非同期でやってるので、do-while()でぐるぐる待たせてるくらいだから、あんまりいいしくみではない。
送信側はイベント待ちにして眠らせ、送信完了割込でイベントを発生させるようにすりゃいいのかな？
まだこの辺りの流れがよくわかってない。

[os]InJumpForDEPで失敗しているだけか

FM3+TOPPERS/ASPでSNEPを動かそうとしているが、電源ONだとうまくいくけどリセットだとうまく行かない。

しかし、デバッグしてみると、単にInJumpForDEPでStatusがSUCCESSになってないだけのように見えた。
どっちでもいいや、と思ってInitiatorとして動かしていたのだが、InJumpForDEPはTargetがいないと失敗するんだったっけ。。。

記憶がないので、そういうことにしておこう。

電池で動かすような端末にするならば、Targetにして待ち受けた方が消費電力としては少なくなる。
TgInitTarget実行後は、RF検出するまでパワーダウン状態になるからだ。
パワーダウン状態は最大で100uA。
手元にあるエネループは2000mAhなので、もしRC-S620/SをTargetにしたまま放置したなら、2000÷0.1=20000時間。2年以上保つ計算になる(こんな計算よね?)。
まあ、マイコン側をまったく考慮してないし、通信のことを考えていないからだけど。

FM3の直流特性を見ると、STOPモードが1mA。
けっこう食うなあ。MB9B610Tシリーズはそういう用途ではないってことか。
LPC2388のパワーダウンモードは113uAで、ディープパワーダウンだと20uAまで減るから、手元にある基板で長時間保たせるなら、LPC-2388の方がよさそうだ。

今回はお遊びなので、そんなに考えなくていいや。
ってことで、SNEPをまったく行わないとすると、2000÷1.1=1818時間。2ヶ月くらいか。

今日の開発環境(2012年7月)

ときどき、開発環境の写真を撮るようにしよう。

Interface誌のFM3基板を使っているので、こういう環境になっている。
ブレッドボードの真ん中に乗っているのが、FM3基板。
その右側が、ARM-USB-TINY-HというJTAGデバッガ。
赤黒のよりよりは、リセットボタンにつながっている。
基板の下側から緑と青の線をブレッドボードにつなぎ、そこからRC-S620/Sにつなげている。
これは、UARTのTX/RX。
直接つなげてもいいのだけど、ロジアナで波形を見たかったのでブレッドボードを介している。
ロジアナは、写真左下のやつだ。

ブレッドボードの左下にあるのは、最近買ったI2C液晶画面。
キャラクタ表示が可能らしい。
らしい、というのは、まだ動かしてないから・・・。
やっぱり、ちょっとした表示がほしくて買ったのだけど、まだドライバを作っていないのだ。

このFM3基板、FRAMが載っている。
これもまだ使ってないのだけど、1兆回の読み書きが可能らしい(FRAMは読むときも破壊するそうな)。
これもI2C接続で、I2Cスレーブとして動くし、ドライバがInterface誌に載っていたので、うまいこと持っていけばLCDも表示できるだろうと目論んでいる。
まあ、目論見はいつもすんなりいかないものだがね。

stdbool.hを使ってももういいよね

誰に問いかけてるんだか・・・。

C99になって、boolが定義されたstdbool.hというものが使えるようになった。
trueとかfalseもあるので、C++のbool型がそのまま載せ替えられる。

CodeSourceryのstdbool.hを見ると、_Boolをtypedefではなくdefineでboolにしていた。
目的が「置き換え」だからそうしたのかな。

では、_Bool自体はどうなっているのか。
もしかして、「typedef int _Bool;」なんてやってたらやだなー、と思ったが、CodeSourceryには_Boolの定義がなかったので、中でちゃんとやってるんだろうと思う。

そうなってくれていないと、trueで比較するところがあったら、置き換えないといかん。
なるべくfalseと比較するように実装しているつもりではあるが、忘れてるかもしれないし、借りてきたところはそうなってないかもしれない。

ただ、C99オプションを付けなくてもstdbool.hはincludeできるし、使えている。
ということは、_Bool型もC99オプションなしで使えるのだろう。
「for(int i, ・・・」みたいな書き方は、C99オプションなしだと怒られる。
そういうもん、ってことでいいのかな。

「int型でやりゃいいやん」といわれそうだけど、ライブラリによって戻り値の意味が異なるのはめんどくさいので、標準のものがあれば使いたいのだ。
あるライブラリでは戻り値0が成功だったり、別のライブラリではTRUEが成功だったりすると、レビューするときにライブラリのことを調べてからやらんといかんので、めんどくさい。
基本的に戻り値はboolにして、エラーが知りたければ何か用意する、でもいいかと思っている。

そういいつつ、今の実装も0がSUCCESSに置き換えてしまいそうな気がするが、まあそんなもんだ。

2012年7月28日

[os]大山鳴動してスタック不足

タイトルがすべてを表しているが・・・。

あまりに原因がわからないので、タスクのスタックを512byteから1024byteに増やしてみた。

そしたら・・・動いた。

えー、スタックオーバーフローかよー。
そりゃ、ソースを見ている分にはわからんはずだ。
それより、そんなに使うようなソース書いた、という方がショックだ。

確かにSNEPに関する部分は、プロトコルスタックそのまま実装したので、SNEP→LLCP→DEPと階層が深い。
その分、関数コールも深くなってしまった。

また、いつも仕事で使っているのが16bitマイコンで、その気分が抜けないまま32bitマイコンを使っているというのもあるだろう。

nfcpyを相手にすると、ちゃんとサンプルが動いた。
なので、実装自体はそんなに間違っていないようである。

めでたしめでたし、とするには、ちょっと早いようであるが、少し気が楽になった。

[arm]Imprecise data bus errorとは何者じゃ

TOPPERS/ASP+FM3基板で遊んでいるが、Hard Faultが発生している。
「Hard Faultかぁ」で止まっていたのだが、レジスタの値を見るともう少し調べることができるそうだ。

Fault系のステータスレジスタってものがある。
HFSR(E000_ED2C), MMFSR(MMSR? E000_ED28), BFSR(E000_ED29), UFSR(E000_ED2A)らしい。
MMSR, BFSR, UFSRは、レジスタとしてはCFSRの一部になるのかな？

HardFaultは、HFSR。
見ると、0x4000_0000で、FORCED=1だった。
説明を見ると「他のステータスレジスタをみなされ」だそうだ。なんじゃそりゃ。

仕方なく他のステータスレジスタを見ると、BFSRが0x04だった。
これは、IMPRECISERR=1。

Imprecise data bus errorらしい。

このビットが立ったときには、データバスエラーが起きている。
なおかつ、BFARレジスタにはfaultしたアドレスは残さない、となっている。
残す方のエラーは、PRECISERRのようだ。

IMPRECISERRは非同期で発生するらしく、エラーになった箇所が問題だとは限らないらしい。
プロセッサ側で優先度の高い作業をしていたら、それが終わってからエラーになるんだと。
優先度が高い側ではっきりした?エラーが発生したら、そっちの要因もビットが立つんだとか(このページのIMPRECISERR説明より)。

うーん、それは困った。。。

データバスエラーというのは、データバスに対してアクセスしようとしてエラーになることのような印象を受けた。

アドレス不正
アラインメント不正

どっちかじゃなかろうか。

そう思ったけど、関数は何回か呼ばれていて問題ないし、変なポインタキャストもしてなさそうだし、なんだかわからないなぁ。。。

[nfc]NDEFは短いのだけで許してくれんか

NFC勉強会(not 福岡)があってたので、NDEFのだけ見た。
バイナリの話とあっては、見ざるを得ない(?)。

自分の過去記事を振り返ると、案外NDEFのことを書いているのだが、中身についてはほとんど書いていない。
バイナリ解析好きなのだが、NDEFってアプリ寄りなので、なんとなくやる気が起きないのだ。

先日SNEPを実装したとき、NDEFを送信しないといけないので、さらっと読んで実装した。

https://github.com/hirokuma/libhknfcrw/blob/master/src/HkNfcNdef.cpp

よく考えると、私も相手のnfcpyもNDEFを解析するところまではサンプルに作ってないので実はなんでもよかったような気はする。

NDEFは、SR(Short Record)というビットがあり、SR=1の場合はペイロード部255byteまでという制限になるが、ペイロード長が1byteで済むのでNDEFレコードを小さくできる。
MIFARE UltralightもUltralight Cも、256byteはない。
FeliCa Liteもやはり256byteはない。

なのでもう、NDEFって短いのだけでいいんじゃないかな、と何となく思った。

が、大きなデータを送信する方法もあった。

SNEPみたいにデータ長の制限が特にないものでは、使い勝手が許す限りの巨大なNDEFデータを送信できることだろう。

あるいはカードエミュレーションして、途方もないメモリを持つNFCカードとして振る舞うってのもあるだろう。

巨大なデータになると、NFCはペアリングのみにしてもっと高速な通信網を使うというのが流行(?)のようだが、NFCだけでもまだまだいけるかもしれん。
まあ、使い勝手次第だろうけどね。

2012年7月27日

[os]なぜかハードフォルト

TOPPERS/ASP + FM3基板。
まだまだすんなり動かない。

今日はここでハードフォルトが発生した。
この次の「mov.w」を実行したところで飛ぶようだ。
うーむ。

mov.wって、たぶん16bitデータコピーだろう。
r0レジスタに1という値を入れる、ただそれだけだと思うのだが。。。
この部分は何度も動いているのだが、あるときハードフォルトになるようなのだ。
うーむうーむ。

いつも「ハードフォルトかぁ」で止まってしまうが、実はもっと情報が載っていて、なんかわかるようになってるんじゃなかろうか？

というところで、今日の作業はおしまい。

今日の帰りがけに、なくしたnimocaを探すために同じルートで帰ってみたけれども、24時間後の地球には私のnimocaはなかったようだ。
がっくしだ。もう引退が迫っているのだろうか。。。

2012年7月25日

[無駄話]NFCの勉強って、何をすればいいんだろう (2)

なぜ２回目を・・・。
理由は、前回があまりにNDEFを絶賛しているかのような終わり方になってしまったからだ。
私らしくない。

NDEFなんて知ったことかー！
NFC Forumに俺を縛ることはできないィィ！！

というロックな人(?)は、ISO/IEC 18092とか、ISO/IEC 14443なんかを読むのがよいと思う。
「仕様なんか知りたくねぇ」と思うかもしれないが、考え直してほしい。
これは「聖典」みたいなものだ。
この２つの仕様書の外側というのはあまりないと思うから、世界の端っこかもしれない。
世界の端っこなんて、なんかロックな感じがするではないか。

もっとコアな人がいるかもしれない。
俺がNFCだ、とか。
そういう人はいっそのこと、R/Wを作ってみるといいんじゃないだろうか。
私が知ってるのは、OpenPCDだけだが、作ることができれば、自分のNFC規格を立ち上げることも可能だと思う。
そこまでやれば、もう文句は言わせない、という自信が身につくだろう。

ライトな層の人も大切だ。
例えば、PCとPaSoRiは持ってるけどソフト作っても誰も使ってくれなくてAndroidで作りたいけどNFC端末持ってないから何とかならんかなあ、というような人。
こういう人は、ずいぶん前に途中まで移植したAndroid-x86にPaSoRiをつなぐ部分を完成させてほしいものだ。
JavaとAndroidのしくみがわからず、放り投げているところなのだ。

とまあ、適当なことを書いていったが、自分で得るものがあれば勉強だろう。
あまり難しく考えず、勉強すればいいんじゃないかね。
そういいつつ、参加しない私であった。。。

登録: 投稿 (Atom)