Tiny用のソフトI2Cマスター

世の中には色んなことが(12/17/2007)
　AVRについて語れる数少ない友人（通信関係会社のモデム開発者）と久しぶりに飲んで愉快に帰ってきた。TTL、TK80、Z80の話が通じる友人である。私の作った名刺サイズの温度ロガーを飲み屋に持ち込んで評価してもらう。彼の最初の反応は、「で、データバスはどのピンなの？」である。いやあ半導体の進歩はすさまじい。ワンチップコンピュータなどと言っていたのが、35年前。今やPCですら64ビットバス、ギガを超えるクロック、テラを越すハードディスクの時代である。昔日の思い出に花が咲いた。

　閑話休題。AVRの続きである。先週あたりから、RTCモジュール（例によって秋月で\500で購入）とのI2C通信にはまっている。Megaでやれば良いものをこだわって、USIインタフェースを使ったTinyのソフトウエアマスターI2Cをこのほど完成させた。昨夜、Atmelのアプリケーションノートを元に、関数群をコーディングし、一発でRTCからデータが表示されたときは感激した。I2CはMMCなどの周辺ディバイスとのやりとりには欠かせないので、勉強の意味もある。

ソフトI2Cマスタのソースコードはこちらです。
「I2C_test.lzh」をダウンロード

こいつが結構気難しい。データの読み出し、書き出しは出来るようになったが、どうも内容がおかしい。I2Cのやりとりでチョンボをしているのか、このレジスターがおかしいのか判別がつかない。月日時分秒はBCDなので上位ビットは使われていないが、ここのビットの状態が不定なのである。下位ビットは合っているので大丈夫だと思うが、I2Cも信用は出来ない。（マスクビットをあてて安定した。要するに無駄なビットが立つ。データシートに出ていた。お馬鹿なミス）

それよりショックだったのは、このRTC、電源を切ると今までのデータが全くなくなってしまうことだ、クロックパルスの設定まで何もかもなくなるとは思っていなかった。これでは、「博士の美しい数式」ではないが一瞬と言えども電源を切ることはできない。電源を切ったら最後、全部設定しなおしである。これは参った。ボタン電池をつけた簡便なRTC（Real Time Clock)はないのだろうか。これはやっぱりTiny26の出番かもしれない。

バグが沢山あった(12/20/07)
　忘年会の連続で帰りが遅いが、それにへこたれずPCの前でAVRをいじっている。EEPROMの書き込みは大分前に完成し、玄関などの温度を測っているが、どうも様子がおかしい。2時間ばかりで測定が止まっている。温度が低すぎるから？そんな馬鹿な。零下45度でも動く工業規格だ。はい、これも原因は私でした。861でEEPROMが512バイトになっているのにポインターが256までしか入らない1バイトだったためである。

　しかし、エリアを確保してもうまくいかない。折り返しのデータがおかしくなる。相変わらずコンパイラーからは、「ポインターに変なデータを入れるな」と怒られている。これをなおそうと思ったが結局わけがわからなくなってやめた。キャストの考え方がいまひとつ理解できない。

　それはともかく、結局サイズをわざと小さくしてデータがぐるぐる回るようにしてテストしてみたら、たくさんバグが見つかった。要するにデータエンドなどの臨界点での検証が不十分だったのだ。Cは++などの演算子が便利なのだが、よーく考えて使わないととんでもないことになることがわかった。
　RTCの方は、とりあえず年月日時分秒を表示させるところまで行って一段落している。バッテリーバックアップより、コンデンサー（スーパーキャパシタというのだそうだ）バックアップの方が簡便なのだが、用途がまだ具体的でないので判断が出来ていない。

バグつぶしの爽快感(12/25/07)
年賀状の添え書きもやっと終了し、しつこいバグがこのところ連続で解消されとても爽快な気分を味わっている。512バイトのEEPROMの方は結局テストルーチンを作り直し（これがTiny26用だったので大幅書き直し）、直接512バイトを叩き込んで実際にトラブルが起きることを確認した。アドレスレジスタを見ていたら原因がわかった。512バイト目をアクセスするのは、アドレスでは511番地。つまり512番地はアドレスレジスタの中身は全部0になる。つまり、最初の番地に書き込むことになる。

　最初の番地（0番地）はファイルが存在する特別のコードが入れてあり、これが合致しないとファイルが無いものとして初期化されることになっているので、当然ファイルは初期化され、データは消えてなくなったのである。こう書いてみれば極く当然のように見えるがここまで辿りつくまでが大変だった。

　もうひとつのI2Cのトラブルもしつこかった。RTCのデータをすべて吐き出す処理で、最後に必ず考えられないエラーステイタスが返って来る。データが正しく出ているので最初放置していたが、どうもおかしい。最初、予期せぬエラー条件が出て、これを無視した経緯がある。連続してコマンドを出すとデータが読めなかったり、書けなかったりする時がある。ロジックアナライザでもあれば、一目瞭然なのだが、時間の経過で動く状況を挿入したステートメントで判断するのは難しい。しかも、時々起きるというのが一番厄介なバグである。

　結局、これもテストステートメントをいたるところに挿入し、あらゆる状態をUARTを通じて端末に吐き出させてみて原因がわかった。これを余りやると環境を変えて何をやっているのかわからなくなる危険があるのだが、背に腹は代えられない。原因は２つあった。ひとつは、RTCに対して読み出しを連続してかけるとき、最後の読み出しは、マスタのこちらから終了のサインを送らなければならないのだが、これを怠ったためおかしなデータを送り続け、データの衝突が起きていた。もうひとつは、Atmelの方の不具合で、ストップコンディションのクリアをするのを忘れていた。Atmelのソースコードで、エラーチェックのところがコメントアウトされていたのは、このバグがとれなかったためと思われる。

　いや、トラブルシューティングのあとの爽快感は素晴らしい。4Mのクロックで200Khzの伝送速度までOKだ。しかし、やっぱりロジックアナライザが欲しいな。こういう手探りの捜査は、解決したときの興奮は大きいけれど生産性が悪い。

温度ロガー完成版のソース（他の関数もこれが最新です）
「Thermo_Logger861V2.lzh」をダウンロード