ＰＩＣＢＡＳＩＣコンパイラ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
まるでインタプリタ。でもコンパイラです。超カンタン超シンプルです。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

［第４８回］



●まさかＬＣＤコントローラのバグ？

こういう作業をやっておりますと悪霊の仕業としか思えない現象に出くわして思いっきり悩んでしまうことがあります。
そんなことはないのでありまして気を取り直して原因を追求していきますと大抵は回路のミスだったりプログラムのバグだったりということで一件落着となります。
今回もまずはハードの誤動作を疑いました。

仮に何らかのハードトラブルだとすれば現象はかなり乱れたふうに現れるはずです。
しかし今回は規則性がはっきりしています。
考えられる限りのことを考えてあれこれ試した結果どういう場合に異常な現象が出現するかというところまでは突き止めることができました。
ええ。
１００％の再現性があります。
そうするとどうもこれは回路の問題ではなさそうということになります。

それにしても余りに異常な現象なので次にはＬＣＤ表示器そのものを疑いました。
ひょっとしてＬＣＤ表示器が破損しているのではないか？
それもおかしいのですけれど。
ＬＣＤコントローラが破損していたならばもともとＬＣＤのコントロールなどできませんし、ＣＰＵとの通信もできないはずです。
ところがＣＧＲＡＭにビットパターンを書き込むときだけなんだかよくわからない異常が発生しますがそれ以外のところでは特に異常はありません。
さらに的を絞って追求した結果、突き止めた異常はＣＧＲＡＭの特定アドレスで必ず発生するというものでした。
異常はただ一点そこだけです。

もっと具体的に説明しましょう。
ＣＧＲＡＭのアドレスの先頭００００００〜０００１１１は正常にアクセスできます。
これはキャラクタコード００に対応するキャラクタパターンのアドレスです。
ここには’￥’を書きました。
次の００１０００〜００１１１１も正常にアクセスできます。
これはキャラクタコード０１に対応するキャラクタパターンのアドレスです。
ここには’日’を書きました。
問題はその次です。
その次はキャラクタコード０２に対応するキャラクタパターンのアドレスです。
アドレスは０１００００〜０１０１１１です。
ここには’月’を書いています。
ところが上から４ライン（アドレス０１００００〜０１００１１）までは正しく書き込まれているのですがその次のアドレス０１０１００で「プッツン」してしまっているようです（前回のＬＣＤの写真参照）。
うむむむ。
ひょっとしてＬＣＤコントローラの内部ＣＧＲＡＭが破損していたりして。

そのように考えてＬＣＤ表示器を交換してみたのですが。
なんと。
全く同じ現象になりました。
ということになるとこれはハードウェアの問題ではなくてソフトウェアの問題ではないか、と考えざるをえません。
プログラムのバグを疑うのが常道でありましょう。
当然のことながらそれはそのように考えてＢＡＳＩＣコンパイラもＰＩＣのマシン語サブルーチンも確認してみたのですけれど。
プログラム自体それほど複雑なことはやっていません。
最初にＣＧＲＡＭアドレスをＯＵＴして、それからはビットパターンを連続して送出しているだけです。
連続して？

そこに何かがあるのかもと思ってＣＧＲＡＭのデータコードごとにアドレスをＯＵＴしてみました。
すると。
なんと
火、水、木、金、土
は書き込むことができました。
しかしそのようにしても’月’だけは下半分のパターンは書き込むことはできません。
なんとも奇妙な現象です。

実はそこに至る前に「これはひょっとしてＬＣＤコントローラＩＣのバグなのではないか？」という疑いが頭に浮かびました。
まさかねえ。
あちこち捜してみましたら奇跡的に大昔の２０字×２行のＬＣＤが出てきました。
まさかねえ、と思いながらそいつを接続して２０字×４行ＬＣＤと同じことをしてみましたら。
なんと。

おいおいおい。
それはないでしょうよ。
これは東芝のＴＬＣ−５０１です。
基板の裏には東芝のＬＳＩチップが貼り付けられています。
今回の２０字×４行ＬＣＤはこれもかなり以前ですが秋月から購入したものです。
基板裏のＩＣチップは品番が読めないようになっていますが秋月のサイトで確認するとＳｉｔｒｏｎｉｘ　Ｔｅｃｈｎｏｌｏｇｙ　Ｃｏ．，Ｌｔｄ．の製品らしいようです。
もっともＣＧパターンにカナ文字があることからするとおそらくオリジナルは日本の製品でありましょう。
ひょっとすると東芝のセカンドソースかも。
そんな想像などをしつつ。
これはどうやらＬＣＤコントローラに潜むバグの疑いが濃厚になってきましたよ（元は東芝か？）。
なんとも意外な展開です。
そういうことならば。
さらに追求していきましたところ。
ついにクリアできました！

これこの通り！


ＴＬＣ−５０１もこの通り！


こちらが解決したプログラムです。


カギは５５行の
ＬＣＣ　＄５４
です。
どうやらＣＧＲＡＭアドレスの０１００１１にビットパターンを書き込んだあとでそれがインクリメントされたときになにかよくないことが起きるようです。
ソフトウェア的に考えるとそれもちょっと変で、アドレス０１００１１にデータを書き込んだらそこでアドレスインクリメントしてしまうはずで、それなら０１００１１に書き込んだ時点でアウトになってしまうはずです。
実際には０１００１１にデータを書き込んでもアウトにはなりません。
それに続いて次のデータを送るとそこで何かよくないことが起きてしまうようです。
異常が発生するのはそこだけです。
ほかは上のプログラムのように連続してデータを送っても問題は発生しません。
それならＣＧＲＡＭアドレスの０１０１００にビットパターンを書くと異常が発生するのかというとそういうことでもありません。
先にアドレス０１０１００を指定してそれからビットパターンを書くと正しく書き込まれます。
どうなっているのかよくわかりませんがとにかくアドレス０１００１１にビットパターンを書き込んだ後それに続けて次の（アドレス０１０１００の）ビットパターンを書き込んだときだけ異常が発生します。
そこで。
０１００１１にデータを書いたあとそこで一旦終って、あらためて次のＣＧＲＡＭアドレス０１０１００を設定してからデータを送るようにしたところ異常の発生が回避できました。

断言はできませんがこれはおそらくはＬＣＤコントローラのバグでありましょう。
（まだ信じられませんけれど）
天下の東芝さまがねえ。
もっともサンヨー、シャープに続いて東芝もいまや解体の危機でありますが。
技術産業立国日本、半導体王国日本はどこに行ってしまったんじゃあ。

プログラムの補足説明です。
ＬＣＤ表示器に送る命令コードがビット７＝０、ビット６＝１のときビット５〜０がＣＧＲＡＭアドレスになり、それ以後ＬＣＤ表示器に送るデータはＣＧＲＡＭに書き込まれます。
ＬＣＤ表示器に送る命令コードがビット７＝１のときビット６〜０がＬＣＤ表示バッファアドレスになり、それ以後ＬＣＤ表示器に送るデータはＬＣＤに表示する文字のコードとして表示バッファに書き込まれます。
１２０行の
ＬＣＣ　＄８０
がＣＧＲＡＭアドレスから表示バッファアドレスに切り換えるための命令です。

これにて一件落着です。

ＰＩＣＢＡＳＩＣコンパイラ［第４８回］
２０２３．７．５ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る