(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第４１６回］
●プログラムミスがありました
前回、ＰＩＣの直接アドレッシングの説明をするために書いたプログラムにミスがありました。
今日になってから、アセンブラによって出力された機械語コードのリストをながめていて、プログラムミスに気がつきました。
これがそのソースプログラムでした。
どこが間違っていたかといいますと、真中あたりにある
ｂｃｆ ＳＴＡＴＵＳ，０；ｂａｎｋ ０
が間違いだったのです。
ＰＩＣ１６Ｆ８８のデータメモリが４つのメモリバンクに分かれていることは、すでに説明しました。
そのバンクを選択するのに、ＰＩＣ１８Ｆ４５５０ではＢＳＲレジスタを使うのですが、ＰＩＣ１６Ｆ８８ではＳＴＡＴＵＳレジスタを使います。
こちらがＰＩＣ１６Ｆ８８のＳＴＡＴＵＳレジスタの説明です。
［出典］Ｍｉｃｒｏｃｈｉｐ社ＰＩＣ１６Ｆ８８Ｄａｔａ Ｓｈｅｅｔ
ＰＩＣ１６Ｆ８８ではＳＴＡＴＵＳ ｒｅｇｉｓｔｅｒのｂｉｔ５とｂｉｔ６によってバンクを切り換えています。
ですから本当はｂｉｔ５だけではなくてｂｉｔ６もセット、リセットしなければならないのですが、今回のプログラムではバンク０とバンク１しか使わなかったことと、リセットによってＳＴＡＴＵＳレジスタのビット５とビット６は’０’になることから、今回のプログラムでは、Ｂポートを出力に設定するため、バンク１にあるＴＲＩＳＢに００を書くときに、ＳＴＡＴＵＳのｂｉｔ５を’１’にし、そのあとでポートにデータを出力するため、バンク０にあるＰＯＲＴＢがアクセスできるように、ＳＴＡＴＵＳのｂｉｔ５を’０’にするつもりでした。
ところがそこのところをうっかりして、ｂｉｔ５ではなくてｂｉｔ０をクリアしていたのです。
ということは、ずっとバンク１が選択されていたことになります。
すると当然ＰＯＲＴＢに出力はできなかったはずです。
じつはこの部分のプログラムミスは、前回お見せしたプログラムだけではなくて、はじめにパルス出力プログラムのサンプルとして書いたものがもとになっていて、［第４１０回］の最初のパルス出力プログラムも［第４１１回］のプログラム変更をした２本のプログラムも、全部同じところが間違っていました。
でも、そうすると、当然ＰＯＲＴＢにはアクセスできませんから、パルスを出力することはできなかったはずです。
ＰＩＣ１８Ｆ４５５０のアセンブラは「かしこいアセンブラ」なので、勝手に都合よくパラメータを付加してくれましたが、ＰＩＣ１６Ｆ８８の場合にはそういう芸当はできません。
機械語に変換されたリストを眺めてみても、ＳＴＡＴＵＳのビットを勝手にセット、リセットしたりはしていないようです。
すると、アクセスできないはずのＰＯＲＴＢから、なぜパルスが出力されたのでしょうか？
これはこれで問題です。
たまたま今回はプログラムにミスがあったのですが、そのミスが無視される形で、期待した通りの結果が得られました。
しかし、ＣＰＵは忠実な僕（しもべ）であるべきなので、たとえご主人さまが間違った命令を下したとしても、それにさからうことは許されません。
むむ、それともウチのＰＩＣ１６Ｆ８８は、ひょっとすると、自ら考える知能を獲得してしまったのか？
こ、こういうものは直ちに破壊してしまわなければ、未来からターミネータが攻撃してくるかも…。
んなわけは、ありませんでした。
ターミネータの妄想と戦いながら、必死で考えていましたら、なんともあっけなく謎が解けてしまいました。
いやあ、よかった、よかった。
正月早々、てっきりターミネータと戦わねばならぬのか、と思ってしまったじゃありませんかぁ（おお、こわぁ）。
プログラムのミスのために、本来は選択されるべきバンク０が選択されず、バンク１が選択されていたことは間違いがありません。
当然、
ｘｏｒｗｆ ＰＯＲＴＢ
という命令も、ＰＯＲＴＢをアクセスすることはできません。
ではどこをアクセスしていたのでしょう？
ここでぜひとも思い出していただきたいのが、前回の「直接アドレッシング」の説明です。
ｘｏｒｗｆ ＰＯＲＴＢ
のようにアセンブラで書くと、ＰＯＲＴＢをアクセスして当たり前だと思ってしまうのですが、じつは、
ｘｏｒｗｆ ０６
と書いたのと同じことなのでした。
このように書くと、むむ、本当にこれでＰＯＲＴＢをアクセスするのだろうか？とちょっと自信がゆらいできてしまいます。
前回もお見せしましたが、ＰＩＣ１６Ｆ８８のメモリマップです。
［出典］Ｍｉｃｒｏｃｈｉｐ社ＰＩＣ１６Ｆ８８Ｄａｔａ Ｓｈｅｅｔ
ＰＯＲＴＢはアドレス０６にあります。メモリバンク０です。
その同じ位置のメモリバンク１には何があるでしょうか？
ＴＲＩＳＢです。アドレス８６にあります。
ＴＲＩＳＢはＰＯＲＴＢの向きを設定するためのレジスタです。
ＴＲＩＳＢは、今回のプログラムでも使っています。
前回お見せしたアセンブラによって出力された機械語コードのリストをもう一度見てみましょう。
ＰＯＲＴＢを出力に設定するために、ＴＲＩＳＢに０を書き込んでいます。
その部分は、アドレス０００９にあります。
ｍｏｖｗｆ ＴＲＩＳＢの機械語コードは００８６になっています。
ＰＯＲＴＢに値を出力するための、ｍｏｖｗｆ ＰＯＲＴＢも、機械語コードは００８６です。
この’８６’はＴＲＩＳＢのアドレスの８６ではなくて、もともとｍｏｖｗｆの機械語コードの下位８ビットのｂｉｔ７は１なのです。ｂｉｔ６〜ｂｉｔ０に対象になるメモリアドレスが入ります（前回［第４１５回］参照）。
メモリアドレス部分は７ビットしかありませんから、ＴＲＩＳＢの最上位ビットの’１’は無視されてしまうため、ｍｏｖｗｆ ＰＯＲＴＢもｍｏｖｗｆ ＴＲＩＳＢも全く同じ機械語コードになってしまうのです。
（問題のパルス出力部分は、ｍｏｖｗｆ ＰＯＲＴＢではなくて、ｘｏｒｗｆ ＰＯＲＴＢなのですが、理屈は全く同じです）
この場合ＰＯＲＴＢに出力するか、ＴＲＩＳＢに出力するかを決定しているのが、ＳＴＡＴＵＳのビット５、ビット６なのです。
では、なぜＴＲＩＳＢにしかアクセスできなかったはずなのに、パルスが出力されたのでしょうか？
ＴＲＩＳＢはＰＯＲＴＢの入力、出力の向きを決定します。
ＴＲＩＳＢのビットに’１’を書き込むとＰＯＲＴＢの対応するビットの向きが入力になり、’０’を書き込むとＰＯＲＴＢのそのビットは出力になります。
ＰＯＲＴＢの入力に設定されたビットの出力はハイインピーダンスになります。
抵抗でプルアップしていますから、見かけ上は’１’が出力されたように見えます。
ＰＯＲＴＢの出力に設定されたビットはいつも’０’が出力されるわけではありませんが、ｐｏｗｅｒ−ｏｎしたとき、たまたま出力ラッチがクリアされていると、’０’が出力されます。
つまり、’１’と’０’が交互に出力されていたのではなくて、「入力」と「出力」に向きが交互に切り替わっていて、たまたま出力が’０’であるとパルスが出力されているように見えたのです。
どうりで、今回のＰＩＣ１６Ｆ８８の動きはおかしい、と思っていました。
ときどきｐｏｗｅｒ ｏｎのタイミングによってパルスが出力されないことがあったり、そもそもＤａｔａ Ｓｈｅｅｔには「オープンドレイン」とは書いてないにもかかわらず、どの出力ビットも’１’出力がハイインピーダンスだったのです。
何日かぶりに、やっと、納得。でしたけれど、まあ、ほんとに、正月からなんともみっともないお話になってしまいました（恥）。
２０１０．１．８ｕｐｌｏａｄ
２０１０．１．９一部加筆
前へ
次へ
ホームページトップへ戻る