あなたの天然記念物
ホーム更新雑談Perl鉄ゲタランドナーコースガイド自転車Linuxリンク経歴連絡先

液晶モジュールSC1602の信号制御 (2012.12.07)

リリース版で制御不可

※SC1602は液晶制御のLSIの型番だったよーな
我々の業界(?)で、おなじみのキャラクタ液晶モジュールをLPCXpressoで制御するためにドライバを作り遊んでいました。 いつもはデバッグ版で動作させているのを気まぐれでリリース版で表示させようとしたら、文字化けというか制御ができない状態になっています。

デバッグ版では確実動作

もう一度デバッグ版で動作させてみると百発百中で表示しています。 リリース版も同一ソースなのにドコが悪いんだろう?

電源周りに異常なし

オシロスコープで電圧を監視しつつ、デバッグ版、リリース版の両方を比較しても変わらない。 液晶モジュールの電源端子に1000μFの電解コンデンサとか付けてみると、症状は変わるけれど制御できていない。

リリース版で動作可能に

信号を変えている所全部に1msのウエイトを挿入すると動作しましたので、そこから1個ずつ削っていき、誤動作する境界を探りました。

何が起きていたのか?

LPCXpresso(LPC1769)にはBITBANDという1ビットずつ変更できる仕掛けがあるので、これを使って信号を制御しています。 液晶モジュールのDB0~7のうち、4ビット通信でDB4~7を使っていました。 EをLに保持してDB4~7を1本ずつ変更する動作になっています。 デバッグ版とリリース版では変更する時間が異なり、特にDB4の変更からDB5の変更までの時間が短いときに制御できていませんでした。 DB4の出力前にDB5の出力データをロードするのでDB4の出力後はシフト命令だけですぐにDB5を出力していました。 残りのDB6とDB7は素直にロードとシフトが入っています。 CPUクロックが120MHzのシフト命令1個は8.3ns程度、ロードとシフトの2個で25nsとなります。 SC1602の信号制御

そんな奴ァいねぇ!!

普通はDB4~7を一度に変更するから、1本ずつのタイミングなんて気にしないよね。 BITBAND、そして数nsで変更していくケースでだけ発生するようです。 こんな症状が発生する人はいませんね、はい。 ただし、コーディングが一度に変更するようにしていてもコンパイラがバラバラに変更するオブジェクトを吐いていたり、 2個のポートを使って4本を用意するケースがあれば、こんな事も起きるかも知れません。 あと何だろうなあ、長い配線で1本ずつの環境が異なって、信号の遅延時間が違っていて時間差ができるとか。

今回の鉄ゲタは…

このページ自体が鉄ゲタですよホントにもう(ぐすん)。 まあ、どうせ話が通じないと思うので、あとはソース見てください(^^;
yrntrlmnmnt20121207.zip (252,124 バイトをVPSから 00:05 で)