立派に共通変数が被っていた(7/23/2017)このブログは原因がわかってから書いている。原因が解明される前のメモを今読み返しているが、いつものデバッグのときと同じで、なぜこれに気が付かなかったのだろうと感心するほど、思い込みというのは恐ろしい。I2Cの割り込みと、計測ルーチンとは全く独立していると完全に思い込んでいるから、最初は、もしかしたらavr-libcの不具合とか、もっと別なことが原因ではないかと思っていた。そのあいだに以下のような副次的なバグまで発見された。親機から子機(スレーブ)のデータを読み込むのに、いちいちコマンドを送っていたが、そんなことをせずにマスター読み込み宣言で自由にデータが読めることがわかった。SR04のトリガーをかけてからの動作をひとつ省略した。出来る限り競合を避けるため。立ったマスクビットをANDしてバッファーを壊していた。データを送り終えると、元のバッファーデータはALLゼロになる。送ったデータの再送が出来ていなかった。->これも特段の変化なし。データの再利用はしていなかった。完全な迷路にはまっていた。I2Cとエコーロジックは無関係だと思っているから、割り込みのときにレジスターなどが破壊されて値が不正になるのではとも考え、測定部分が関数になっていたので直接にコーディングしなおしたりした。これで一週間悩んでいた。それが見るともなくソースコードを見ているとき、ふと気になるところが見つかった。スレーブのソフトI2Cは先方からの想定したビット列が来ない時は、ハングアップを避けるため1秒程度のタイムアウトを設けて、通信自体をリセットするようになっている。Timeout..."というところがある。Echoというのはどういうことだ。あっあっあー、何ということだ。このタイマーのキャリーを記録する変数をSR04のエコー期間を測定するときにも使っているではないか。プログラムがリエントラントでも、変数を共通にしていては駄目になるのは当たり前だ。I2Cは通信開始時に必ずこの変数を0に戻す。これで、これまでに測っていたエコーのキャリー変数は0に戻り値はでたらめになる。あーあ、何というお馬鹿なプログラム。この修正は極めて簡単である。キャリー変数を、I2Cのタイムアウト用と、エコー測定用のものを分けて定義するだけだ。これで、どれだけエコー期間にI2Cが被っても正常な値を表示するようになったのは当然のことである。やれやれ、長い間かかった。思い込みというのは恐ろしい。「すべてのものを疑え」というデバッグの格言をかみしめる。配線図や、コードの公開は、今ちょっとショックが大きすぎて作業する気力が生まれない。公開は次回以降としたい。半年ぶりのブログ更新に漕ぎつけた(2019.09.19)研究所活動は停滞したままでCCDカメラ顕微鏡導入など(2019.02.08)ドングルのHFコンバーターでJJY標準電波は見えたか(2018.12.12)JJY電波を見るため、RF(高周波)の世界に踏み込む(2018.10.31)ESP8266のJJY電波時計のスケッチ公開(2018.10.02)コメントShuji009さん、コメントありがとうございます。壮大な誤解ありがとうございました(笑)。AVRのCライブラリと言っても、OSがあるわけではないのでそんな大掛かりなものではないとは思いますが。14時00分こんにちは!>avr-libc恥ずかしながら、2009年の8月にAVRを知り、電子工作を始めて8年目になるのですが、「avr-libc」の存在を昨夜まで知らないでいました(大汗;;;;;)。がた老さんが、築きあげてきた、AVRのライブラリかと思っていて、ブログ記事を読んでいました。世の中、知らないことが多すぎます。11時16分きゅうる村さん、コメントありがとうございます。いえいえ、どんな周辺でも反応があるのは嬉しいものです。悪戦苦闘、ご苦労様です。太い耐熱線を使わず、かっこよく済ませたいと思いつつ、つい気楽な耐熱線で済ませてしまいます。書かれているように、ゆっくり、味わいつつ、高温の鏝ですれば、うまくいくのかもしれませんね。いつも、周辺にばかり反応して済みません。08時27分コメントを書く名前:メールアドレス:(ウェブ上には掲載しません)アドレス(URL):この情報を登録するコメントは記事投稿者が公開するまで表示されません。ソフトI2Cはクロックストレッチまで手を出してあえなく沈没。