デバッガーではわからなかった。本来なら割り込みルーチンにへばりつくべきだが、実際には、メインルーチンの一定の場所(割り込みが起きたところ)に止まったままだった。これもデバッガーの指定で換えられるのかもしれないので、使えないと結論するのは早いかもしれない。AVRのUART受信割り込みは、割り込みルーチンに来た時に自動的に割り込みフラグはクリアされるので他のマイコンもそうだとばかり思っていた。STM8Sのデータシートには、「受信割り込みフラグは明示的にクリアするか、受信データレジスターをアクセスするとクリアされる」とちゃんと書いてあった。はい、はい、悪いのは私でした。原因がわかれば、対処は簡単だ。これで割り込みをフラグだけにしたUARTプログラムは、無事、正常に動作した。これは今後のプロジェクトでモニタープログラムとして活躍してくれるコアプログラムである。こちらにソースコードの中身の参考のため、このUARTモニタープログラムのmain.cを置きます。これだけではライブラリをincludeしていないのでコンパイルエラーになります。リンクしたサイトを参考にライブラリを所定のディレクトリに配置してビルドしてください。Programmer)を試してみる。これは、単なるSTLinkを介した独立のプログラムローダーだ。STVDにもプログラミング環境があるのだが、立ち上がりが遅い上、やたらとハングする。STVPの方が少し早そうだ。焦電型人感センサーの修理に成功。基本的な間違いだった(12/7/2012)階段の照明制御に使っている人感センサーの誤動作がまた目立ってきた。人も居ないのに頻繁に作動し、役に立たない。修理しようと電源を切って工作机に置いていたら、家族から「あら、もう壊れたの」と言われてしまった。へー、頼りにしていたんだ(階段の照明は別にあるのだが、便利なようだ)。今までに何も言われなかったが、こういう反応は予想外である。復旧へのプレッシャーは強くなったように思う。STM8Sが予想外に早く進展したので、ちょっとお休みし、こちらの方の修理に入る。症状は、オペアンプの無入力の時の電圧がマイコンの入力ピンの閾値に近いので、オペアンプのドリフトで感知してしまうというものである。以前も同様な状態になり、入力ピンにプルアップ抵抗をつけて電圧を閾値以上に引き上げた経緯がある。ケースをはずして抵抗値を確かめると22KΩだった。これを半分の10KΩにしてみる。心配したとおり、今度はセンサーが反応した(->0V)ときでも2V以下に下がらず、失敗である。そのうち見るともなしに配線図を見ていて、2段目のオペアンプの入力の一方が、同じ抵抗2本でVccの半分の電圧であることに気づいた。センサーがドリフトしているのではない。このオペアンプは交流増幅なのだ。2.5Vの中位電圧にしてセンサーの出力を上下に振っているだけなのだ。完全に勘違いをしていた。この部分は、秋月の回路のアナログコンパレーターの部分をマイコンにしたところで、HighのVccが無入力、Lowの0Vがセンサー感知というTTL出力だとばかり頭から信じ込んでいた。2.5Vになるのはドリフトではなくもともとの仕様だったのである。理屈がわかれば解決法は早い。この中位電圧をマイコンの閾値に近い2.5Vより、もう少し高い3V近辺にしておけばオペアンプのドリフトくらいで反応することはない。人が近づいた時の反応は、0VからVccまで派手に振れるので中位電圧は高い方が安定する。制御部からプルアップ抵抗を外し、焦電センサーのオペアンプの分圧抵抗を、4.7k×4.7kの組み合わせから、2.7k×3.9kに換えた。オペアンプの定常出力は、3.1Vになった。これにより焦電センサーは完全に安定した。このあいだの電源のふらつきによるディップも、こうしておけば何の問題もなかったのだ。ついでに、センサー基板の固定部分の一部を改善する。何回か前のブログ記事で、基板をアクリルケースに固定する簡便な方法をみなさんにお聞きしたところ、何人かの方がコメントでアイデアを提供してくださった。さんから頂いたアイデアを実行する。やることは非常に簡単で、切片つまりストッパーをアクリル板に固定してしまう方法である。とりはずしは、ケースの剛性で行う。ケースは2つに分かれており、組みあがっているときはたわみが少ないので、この方法はとれないが、アクリルは剛性に富んでいるので、パーツに分解した時は楽にミゾに基板は入り込む。実にコロンブスの卵的解決である。切片に接着剤をつけ、完全に乾くのを待つ(慌てて付けてとれなくなると悲劇)。