温度計測でのお粗末
いやはや、LCD表示で頭を抱えていたのもつかのま、温度測定IC(LM35D)とADC用に新しく構成したシステムでもお馬鹿な間違いをやって、夜更かしすることになった。何のことはない。AVRstudioに慣れないせいで折角作ったバイナリでなく前のバイナリをせっせとTiny26に食わせて動かない、動かないと悩んでいたのだ。タイムスタンプを見ればロードしているバイナリはずっと前のファイルだとわかるはずだが、頭に血が上っているとそこまでの注意力は望めない。
LCD表示も難物だった。これは2日くらいかかった。参考にしたソースがヘッダーファイルを別につけているから#defineのところさえ換えれば、別の構成でも通用すると頭から信じたのが悪かった。4ビットハンドリングは面倒なものだが、中身のソースは何のことはない完全に環境依存で、これは中身を全部理解してからでないとこのソースは使えない。ただ、独立性を高めようとすると無駄なコーディングが多くなり、Tiny26ではメモリがそろそろ一杯になってきたので自分もハードコーディングしてしまった。
LCD表示のソースコードは以下にあります。
「LCD_1st.lzh」をダウンロード
スリープはあっけなく実現した。電流計(テスターにピンコードを追加:これはクール)でループ(6mA)から半分以下の2mAになるのを見て満悦であった。結局LEDが一番電力を喰うことが分かった。LCDのバックライトも余計(10mA以上)だ。さきほどのトラブル解消のあと、今システムは演算する前の温度の数字が表示されている。結構正しい。これで、温度ロガーの第一の大きな山を越えたことになる。メモリは1152バイト でまだ半分残っている。このあとはTODとシリアル送出である。
次の日、寝る前にロジックを思いつき、早速昼前から試してうまく動くことを確認した。温度表示の小数点以下がいつも同じ数字なのが気に入らなかった。考えてみれば、どれだけ繰り返し測りなおしてみてもマイクロセカンドの範囲では測った温度がかわるタイミングは万に一つで、これは1秒の間に何回か分けて測る必要がある。今の構造を殆ど変えずにWAITのところで温度を何十回かに一回測ることでこれを実現した。これで、小数点以下が小刻みに変化する。 やったやった。得意になってつい鼻歌が出る。
(11/8/2007)
暗礁に乗り上げる
思うようにデータがPCから受け取れず悩んでいる。送信は今朝、ポートをプルダウンすることであっさり解決した。AVRプロジェクトも最終段階に入り、今はTiny26にないUART機能をソフトで実現しようと、ここ数日メモを10枚近く書き散らし奮闘している。
Mega168があるのだから、こだわることはないのだが、Tinyのような小さい石で温度ロガーを作ることに意義がある。しかも、このシリアルの世界は昔からの私の十八番である。ちょっとのことで諦める訳には行かないのだ。コードサイズも何とか2Kバイトに入りそうだし、もう一息なのだが、受信だけがうまくいかない。
割り込みとリングバッファーを使った少し欲張りな仕様で、4本同時に出る割り込みをなだめすかし、何とかハングアップせずにデータをとりこむところまではうまくいった。リングバッファーアドレスのASM関数への受け渡しや、割り込みの制御など、我ながらうまくやったと思うのだが、肝心のデータがでたらめなのでは話にならない。しかもリングバッファーのカウンターがリセットされるときのデータが特におかしい。わずか1命令サイクルが増えるだけでデータが変わるとは思えない。SRAMをいじるやつは他にはいないし、やっぱり受信タイミングなのかなあ。(11/15/07)
やっとのことで脱出
いや、今度のやつはきつかった。SoftUARTは、紆余曲折の上、何とか19.2kbpsの半二重送受信が実現した。AVRから送信が出来るようになったので、あらゆるところのデータをPCに送らせて解析したが、どうしても説明のつかない現象に根を上げ、アセンブラーをやめてCで作り直したら(20分でできた)、一発で通ってしまった。
奇妙な現象は2つあった。これがリングバッファーの動きをおかしくしていたのだ。まず、レジスタ変数でアセンブラに渡したリングバッファのアドレスがどうも、おかしい。ピンチェンジ割り込みのルーチンの方が1バイトずれている。これはバッファーのデータを16進表示にして最初のデータが00なので始めて確認できた。LEDを要所に挿入して、不規則な割り込みで処理が乱されていないことは確かめてある。
このアドレスずれは、対症療法で、割り込み側のアドレスを減らしておくことで対処できたが、問題は、受け取り側(Tail)のカウンターが途中でずれることである。奇妙なことに、送り込み側(Head)のカウンターが0に戻ったサイクルでカウントアップしなくなるのである。昨日の夜は、バッファサイズを何種類か変えて同じようになることを見て絶望的な気持ちになった。
こんな器用なことがMPUに出来るわけがない。ここにはOSはおろか、モニタープログラムも動いておらず、今ロードしたプログラム以外に動いているものは何もないのである。みんなお前がやっていることなのだ。予想もしない容疑をかけられた被疑者のようなものである。割り込みが悪さをしているわけではない。高々10ステップばかりのリングバッファの処理である。レジスターの指定を色々かえてみたが、結局、この頑固なバグは解明できないでいた。世の中が暗くなる気持ちだ。
残されたひとつの手段は「このルーチンを使わないで別に作る」ことである。こんな小さなルーチンにバグが潜んでいるとは思えず、原因は他にあると考えられ、期待は大きくなかったが、物は試しとCでその部分を書き直してみた(20分もかからなかった)。
何と、直ったのである。ここ1週間悩ましてきた不具合は綺麗に解消され、快適にデータが受け取れるではないか。いったい何が原因だったのだろうか。今でもわからない。
(11/21/07 午前1時)
| 固定リンク
「AVR」カテゴリの記事
- ソフトI2Cはクロックストレッチまで手を出してあえなく沈没(2017.09.02)
- オシロのテストどころかソフト開発で大はまり(2017.07.26)
- 超音波方式の人感センサーI2C化と新しいオシロ(2017.06.29)
- motionの動体検知はRaspi3の電源が安定しない(2017.04.16)
- 赤外線学習リモコンはデータ再現で挫折したまま進まず(2016.07.21)
コメント