というタイトルにすると毎月書いているように見えるが、そんなことはない。
NFCForum-TS-Analog-1.0というドキュメントが非メンバーでも見えるようになりました。
7月だったらしいけど、気付かんかった。。。
アンテナについてなどが書いてあるみたいです。
私にはあまり縁がなさそうなので、ダウンロードしてそのままになりそう。。。
削除というか、なんというか。
RTDのGeneric Controlがなくなりました。
全部で7製品が認証されてます。
8月は1台追加になったのかな。
こんなところですかね。
笛吹けど踊らず、みたいな。
サンプルソースでI2Cが動くことがわかったので、TOPPERS/ASPで動かそうとしている。
よく考えると、TOPPERSで割り込み処理を書くのは初めてだ。
2011年4月号を見つつ、cfgファイルにATT_ISRとCFG_INTを書く。
コンパイルすると、kernel_cfg.cにハンドラが展開されている。
使いたかったのは、SOT1_2の割込になるようなので、No.26になっていた。
MFSだけかもしれんが、割込は「送信割込」と「ステータス割込」が確認できる。
No.26なら、IRQ10MONレジスタになる。
で、やってみると・・・ハンドラが呼ばれない・・・。
IBCR.INTは1になっているので、割り込み要因は発生している。
ロジアナ波形を見ても、ACKのとこまで出力されている。
IRQ10MONは、0x02。つまりステータス割込要求あり。
ここまで揃ってるのに、ハンドラが呼ばれないということは、NVICか。
あら、割込イネーブルレジスタが0のままだわ。
ena_int()しているのに・・・。
とデバッガで追うと、理由がわかった。
ATT_INI()で指定した初期化関数の中でena_int()していたのだけど、コンテキストがタスクじゃないからはじかれていたのだ。
エラーチェックしていればわかったんだけど、省略していたのよ。。。
タスクが始まってからena_int()することで、無事に動くようになりました。
めでたしめでたし。
さて、ようやくここからμITRONっぽいことをやり始めるとしよう。
whileでぐるぐる待つところなんかをそれっぽく仕立てたいものだ。
FM3基板のI2C。
サンプルドライバはFRAMアクセスするようになっているので、動かしてみた。
・・・動く。
割込がちゃんと入ってくるし、ACKも確認できている。
FRAMは、SOT1_0 / SCK1_0を使っている。
じゃあ、SOT1_2 / SCK1_2に差し替えればとりあえず動くのかな？
・・・動かない。
割込が入ってこない。
ソフトは同じで、変更したのはポートだけだ。
では、未接続のSOT6_1 / SCK6_1にしてみたら？
・・・割込が入ってきた。
未接続だからエラーなんだけど、割込は来る。
ではでは、SOT6_1/SCK6_1にLCDを接続すると？
・・・割込が入ってこない。
つまり、接続する相手のせいで割込が入ってこないようになっているのだ。
うーん、その可能性は考えてなかったなぁ。
LCDの型番で検索。
うーん、みんな22kΩくらいのプルアップ抵抗だなぁ。
ストロベリーリナックスさんのページには、20kΩ以上で100kΩでもいい、くらいなことを書いていたように思う。
なので47kΩのを使っていたのだが・・・。
私も20kΩくらいの抵抗を探し出し、つないだ。
出るやん・・・。
プルアップ抵抗って、そんな微妙なものなのか・・・。
では、設定をやり直して。。。
わーい。
素直に嬉しい。
プルアップ抵抗なんてエッジがなまらない程度にしておけばいいんだろうと思ってたけど、神秘の深淵を除いた気持ちである(おおげさ)。
私はI2Cですら動かせないのか・・・と思ったが、まあいつものことだ。
とにかく、まだ動いていない。
今はSOT1_2 / SCK1_2を使っているが、ポートを変えたら動いたりせんだろうか、とSOT6_1 / SCK6_1にしてみたが、状況は変わらず。
EPFR07でリロケートもしてる。
ロジアナ自体が悪さを？と思って外してみたが、そんなわけでもなさそうだ。
皆目見当が付かん。
思いつくことを、つらつら書いていたら、何か浮かぶかもしれない。
EIBCRレジスタがあれば、手動でSDA/SCLをぱたぱたさせられそうなのだが、FM3基板のFM3はTYPE2なのでレジスタがない。
富士通のサンプルでは、「ch0はマイクロコントローラの仕様で使用できない」と書かれている。
I2Cだけみたいだけど、そんなのどこにも書いてないなぁ。
MFSのブロック図がないので、何が関わっているのかがよくわからない。
仕方ないので、FR60のドキュメントを見てみた。
同じ富士通のだから、似てるんじゃなかろうか。
IDARというレジスタが、TDRレジスタに相当するみたいだ。
FR60はダブルバッファになってるらしく、BusBusyのときはシリアル転送用のレジスタに、そうでないときは内部転送レジスタにロードされる、とある(ブロック図では読み取れん)。
シフトレジスタがあるだろうから、そこの図が見たかったのだが・・・ないのか。
なんとなくだけど、クロックさえ生成すればデータが出ていきそうな感じだ。
ってことは、クロック生成できていないか、供給されていないということ？
マルチファンクションシリアルは、APB2バスに載っている。
APB2バスクロックは、PCLK2らしい。
そういえば、TOPPERS/ASPの環境はどういうクロックになってるんだろうか？
target_initialize()を見ると、
のようだ。
PCLK2の出力許可もしているので、クロック供給されていないということはない。
まあ、されてなければRC-S620/Sの制御すらできなかったはずだよな。
ペリフェラルマニュアルの「I/Oポート」も大切そうだ。
表2-2に、GPIOとして使うか周辺機器として使うかと、影響するレジスタが記載されている。
I2Cだから、オープンドレインで入出力。
影響するのは、PFRとPZRらしいから、やはりPZRは設定しておこう。
ADEとかは何もしてないから0だろうと思っているが・・・どうだろう。
心配だから見ておこう。
あー、めんどくさい。。
そして変化無し。。。。。
そうだよなぁ、そんなので動かないなら、スタートコンディションすら生成されないよなぁ。
仕方ないから、オリジナルでFRAMアクセスして波形を取ってみるか。
でも、ポートをつかむような道具を持ってないので、ちょっと一苦労だ。
まあ、波形は取らなくても、動くことが確認できればいいか。
Interface誌のFM3基板を使っているが、I2Cがうまくいかん。
一から書く気力がないので、Interface誌2012年7月号のドライバiic.c/hをそのままTOPPERS/ASPに載せ替え(というほどでもないか)をした。
割込が入らないとか何とかいう以前に、TDRレジスタに値を書き込んでMSS=1にしても、スタートコンディションになるだけでSDA/SCLが動かないのだ。
通信マクロの説明に従ってるのだが・・・
ここまでいくのに、SDA/SCLともにLになりっぱなしなのだ・・・。
今回使っているのは、SOT1_2とSCL1_2。
FM3基板でいえば、CN2の31ピンと32ピン。
ch1は、FIFOなし。
プルアップ抵抗は、47kΩ。
動作クロックは変更していないので、144MHzでAPB1, APB2は72MHz。
APB1が40MHzを超えるならばノイズフィルタを設定した方がいいらしいが、出力だけなら気にしなくてもいいかと思い、設定してない。
DMAも使っていない。
情報はこれくらいか。
TDRに書き込む前は、TDRE=1なので、送信データレジスタへ書き込める条件は整っている。
MSS=1にする際は、同時にINTEとINTも1にしている。読み取ると、INTは0だけど、これは割込条件が整っていないから0なだけだろう(INTへの1書き込みは、意味がないのだな)。
割込が入らないのは、データを送信できていないから。
TDR書き込み直後のMFS関連のレジスタ値
MSS=1書き込み直後
このまま放置しても、レジスタ値に変化なしだ。
うーむ。
FBT=1のままってことは、まだ送信できていないと思っているのだろう。
TRX=1だから、送信ってことはわかってるし。
BB=1なので、送受信しようとはしているようだ。
TDREも0から1になっているので、シフトレジスタへ載ってるんだと思う。
ちなみにオリジナルは、RIEとTIEは0だ。
まあ、まだ割込が発生する以前の問題だから、あとで考えよう。
PZRレジスタでHiZにしてやらんといかんのか？とやってみたが、変わりなし。
なんか全然わからんぞ－。
メモ代わりに、MSS=1後のレジスタを載せておこう。。。
私の知る範囲で、になるが、NFCのP2P、LLCPとかSNEPが使えるのはAndroidしか知らない。
BlackBerryやNokia端末も使えそうだけど、情報が不足している。
AndroidのNFC-P2Pは、Android Beamになる。
最近になってAndroid Beamも拡張され、Wi-FiとかBluetoothとかを併用するタイプになりつつあるように見える。
Bluetoothなんて、日本では「何に使うの？」くらいだったけど、今ではけっこうな市民権を得たのだろうか。
こういうのは、携帯電話をめったに使わない私にはわからないことなんだよなぁ。
まあ、それは置くとしよう。
私が気にしているのは、NFCのP2Pってどういう用途が残っているんだろうか、ということだ。
なんとなく「カードエミュレーションはちょっとイヤだから、P2Pでちょろっと会話して、あとは高速回線ね」という用途にしようとしてるんじゃないかな、という気がする。
というのも、SNEPとかLLCPって、NFCでありがちな通信の途切れを考慮してないように思うからだ。
数秒間向かい合わせるならば、なんらかの通信障害が発生する可能性は高い。
高いので、P2Pでは再送なんかを考慮するんだろうと思ったけれど、LLCPやSNEPを見る限りではそういうのがない。
ということは、通信が途切れたら終わり…というよりも、通信が途切れるほど長い時間は通信しないよ、という意図があるように見える。
カードエミュレーションだと、R/W v.s. カード、という構図が静的に決まるけれども、LLCPであればそうならないので、端末間は基本的にSNEPを使おうか、ということを考えていそうだ。
どういう形でもいいんだけど、NFCは携帯電話と相性はいいのだが、携帯電話だけのものではないと思っている。
なので、どういうサービスがあってもいいんだけど、NFC=携帯電話になるのだったら、関与したくないところだなぁ。
RTDというのは、こちらへ。
その中で、もうすぐなくなるのがGeneric Control RTD。
来週にはなくなる予定なのだけど、なんでそうなったのだろう？
全くの推測なんだけど、名前が悪かったんじゃないだろうか。
「Generic」なんていわれても、どうしていいかわからんじゃないか。
一般的な制御用ルートを用意した方がいいかな、と思って作ったけど、NFC Forumの方針が決まって、そういう曖昧な用途のものはexternalにして各自でやらせて、NFC Forumでは決まった用途のものだけにしよう、という議論があったとか。
まあ、Generic Controlは読まないままだったからいいんだけどね。
