● 実験テーマ28● 実験テーマ28
「PIC32MX_モノクロGLCDでの、漢字フォント表示実験」
■ 2013.3.12
・後閑氏HP内テーマで、未着なのが、「漢字表示GLCD
For PIC32ライブラリ」である。
ここで使用している漢字フォントは、12X12ドットで構成される視認性のよいサイズ
のもので、一度表示させたいと思っていた。
・モノクロGLCDは、PIC24Hオシロでも使ったことのある、SUNLINK社の
「SG12864ASLB-GB-R01」である。
・後閑氏HPには、この32bit用のライブラリと、フォントデータは提供されているが、
テストプログラムは公開されていない。
これを自分で考え、テストプログラムを作成してみようと思う。
以前作成した、カラーGLCD用のテストプログラムがあるので、それを元にモディファイ
することにした。
・まず、PIC32MXトレーニング基板を使用して実験を進めるので
ＧＬＣＤ部のみの治具基板と、本体との接続用ケーブル部などのハードを準備しようと
思う。次に、ライブラリの動作をソースと、後閑氏HPの説明から把握。
・とりあえず、主目的である、12X12ドットの漢字フォントを表示させるプログラム
のみ作成してみる。
・水魚堂の回路図CADにて、実験回路図を作成した。
回路図はこちらからどうぞ→ 「PIC32MX_モノクロGLCD実験回路図」
■ 2013.3.13
・モノクロGLCD治具基板の製作を始める。
■ 2013.3.15
・ソフトの検討を始める。
■ 2013.3.16
・モノクロGLCD治具基板の製作完了
■ 2013.3.18
・とりあえず、シフトJIS漢字コード指定による全漢字フォント表示を繰返すだけのメインループ
にしてみた。
→ コンパイル後、動作確認行うが、まず何も表示しない。
ただコントラストVRは効いている。
→ これは、GLCD制御信号（CS1,CS2,DI等）のポート割付の単純ミスであった。
・修正して、一応表示するようになったが、漢字フォントが上に詰まった感じで表示される。
カラム・ラインの指定ミスがあるような気がする。
■ 2013.3.19
・昨日の問題をかたずける。
後閑氏HPに、12X12漢字フォントの格納形式の説明があり、それをよく見ると、KanjiCode関数の
引数に於ける、line：行指定は、単なる行方向の表示位置というわけではなく、漢字フォントの縦方向
12ドットを、上半分：8ドット（ビット）／下半分：4ドットと考え、さらに行間スペースとして下方向4ドット
を、'0'とし、スペースを含めた漢字フォントの縦方向を、16ドット（ビット）としている。
一方、GLCDのデータ制御は、8ビット単位なので、2回読出して一文字の左端16ビット分が表示
されることになる。
よって、引数としての、lineは、8ビット単位で、8行／1画面と考える必要がある。
→ つまり、次のようにソフトを変更すればよいはず。
for (Line=0; Line<4; Line++) {
のループ条件のところを、
for (Line=0; Line<8; Line++) {
と修正。 全体の記述は以下の通りとなる。（案）
//
液晶表示器の初期化
lcd_Init();
//
漢字コード初期値 2バイトコード
Upper = 0x81;
Lower = 0x40;
/// デバッグ用_1： 漢字コード（シフトJIS）による全漢字表示の単純繰返しテスト---------------
while(1) {
lcd_Clear(0);
for (Line= 0; Line<8; Line= Line++) {
for(Colum=0; Colum<10; Colum++){ // 10文字/行
KanjiCode(Line, Colum, Upper, Lower); // 漢字コードによる、1文字表示
// 漢字コードアップ
Lower++;
if (Lower > 0xFC) {
Upper++; Lower = 0x40;
if(Upper > 0x9F) Upper = 0x81;
}
}
}
delay_ms(1000);
}
///--------------------------------------------------------------------------
→ これでもまだ、文字がバラケルような感じになる。ただ、4行表示にはなった。
・ここで、解り易いように、一文字 ’亜’のみ表示させてみる。
’亜’の漢字コードは、889F
Upper = 0x88;
Lower = 0x9F;
Line = 0;
Colum = 0;
として、KanjiCode(Line, Colum,
Upper, Lower); を実行させてみた。
結果は以下の通り。
※ CS2で選択される左半分の画面の、原点位置に表示されるはずが何故か、CS1で選択される
右半分の原点位置に表示されてしまう？？
→ またまた単純ミスであった。
CS1と、CS2の配線が逆になっていた。
→ ハードでテレコ修正した。結果、左側原点に表示した。
→ プログラムを戻す。
やはり、次の行の漢字が前の表示に重なったようになる。
※ 原因が判明
12X12フォントなので、1行に10文字表示した後のラインは、2つ進めないといけない。
(for (Line=0;
Line<8; Line= Line++){→ for (Line=0; Line<8; Line=
Line+2) に修正）
この修正でうまく行く。
■ 2013.3.20
・全てのテストケースを入れ、SW分岐させるように、ソースを変更した。
＜チェック結果＞
① OKケース
case0： 全画面クリアテスト
case2： アスキー文字表示
case3： イメージ表示とスクロール
case4： アスキー文字列表示
case7： 漢字コード指定による漢字表示
② NGケース
case1： 斜め線描画
case5： ボックス描画
case6： 2次曲線描画
case8： 漢字メッセージ表示
・例えば、case1： 斜め線描画は、次の写真のように、斜め線は引けているが、線の周辺に余分なドットが表示
されてしまう。
→ 何故？
斜め線描画／ ボックス描画／ 2次曲線描画の3ケースのみ、lcd_Pixel関数を使っており、この関数の中
でコールしている下請け関数：lcd_Read関数で、GLCDのデータバスを、リード方向に切替えている。
この辺が関係していないか？
■ 2013.3.21
・昨日の現象をもっと解り易くするため、単純に、lcd_Pixel(0,0,1);だけを実行し、CS2側画面上の原点に
１つだけ黒ドットを表示させてみた。
以下が、その結果の写真である。
写真中のコメントにもある通り、本来の黒ドットの上に表示されないはずの黒ドットが表示される。
■ 2013.3.22
・今日は、lcd_Pixel関数の解析をしてみることにした。
以下のような仕組みであることが解った。
＜画素描画の手順＞
① 指定された、Xposより、CS1側をアクセスするか、CS2側をアクセスするか決定
② 指定された、Yposより、アクセスするページアドレスを算出
③ このページアドレスデータを、lcd_Write関数によりコントローラに書込む。
④ 指定された、Xposより、カラムアドレスを、lcd_Write関数によりコントローラに書込む。
⑤ 指定された、ページ・カラムアドレスに対応する表示RAMの、現在のデータを、lcd_Read関数
により読込む。（1回目のリードはコントローラの仕様によりダミーリードになる。）
⑥ もう一度、⑤と同じリードを実施
⑦ 指定されたYposより、アクセスするドット位置（ビット位置）を計算（pos変数に格納）
⑧ ここで再度、カラムアドレスを、lcd_Write関数によりコントローラに書込む。
⑨ 読込んだ、現在の表示RAMのデータと、⑦で算出した実際にアクセスするドット位置をオアした
データを、lcd_Write関数によりコントローラに書込む。
（この操作によって
前のデータを保持したまま、アクセスポイントのドットをONできるようにしている。）
■ 2013.3.23
・昨日の、lcd_Pixel関数解析で、data = lcd_Read(cs);
のリード関数が、怪しいことが判明した。
data = 0と読めるはずが、
data = 0x40と、誤リードしている可能性がある。
→ 一度前の、PIC24H_オシロのハードでやった、GLCD2プロジェクトで
正常動作を確認してみることにした。
■ 2013.3.24
・リード関数によって読取った、表示RAMのデータを、GLCDにHEX表示できるように
別プロジェクトで、デバッグ機能を追加してみることにした。
・とりあえず、確実に動いている前作の、PIC24H_GLCD2プロジェクトに、
デバッグ機能を追加して正常な読取値を確認してみることにする。
■ 2013.3.26
・下に、確実に動いている前作の、PIC24H_GLCD2プロジェクトでの、lcd_Pixel関数内の
各変数読取結果を示した。
→ もくろみ通り、data変数は、ドット表示アクセス前の、表示RAMの内容を
読み出していることが、はっきりした。
■ 2013.3.27
・PIC32MXの現ハードとGLCDに戻して、これにもデバッグ機能を追加し、昨日と同じことを
実施してみた。
→ 結果は以下の写真の通りで、白クリアした場合の表示RAMのデータ：0が読出されず
何故か、直前に設定したカラムアドレスが読出されているようだ。
＜原因調査＞
① ソース上で入れているリードタイミングの、ウエイト値は、十分余裕があるので問題
なさそう。
② 32bitMPUと、16bitMPUの違いとして変数型の問題（特に、16bitMPUの於けるint型は、32bitMPUでは
unsigned short型になるなど異なるので注意が必要）があるが、これも問題なさそうである。
■ 2013.4.1
・リード関数を実行する直前の、GLCDへの書込みデータを、そのままリードしてしまう不具合を調査開始する。
・何となく感ではあるが、PIC24Hのハードではうまく行っていて、PIC32MXのハードではうまく行ってないのは
以前にも、確か、dsPIC30Fと、PIC24Fで問題だったポート読込時に使うマクロの、LATと、PORTの使い分け
の問題ではないかと考えた。
・さっそくPIC32MX活用ハンドブックにある、PIC32MXの、I/Oポートの内部ブロック図と説明を見てみた。
すると、はっきり次のことが明記されていた。
→ 「LATxレジスタを読出すと、LATxレジスタの設定内容を読込むことになり、ピンの状態を読込むことになりません」
（ピンの状態を読出す時は、LATxレジスタでなく、PORTxレジスタを使う必要がある。）
→ これだ！！と思い早速ソフトを、リード時、LATEから、PORTEに修正してみた。
やっとこれでうまく行った。
（元々後閑氏のライブラリをそのまま使用しているので誤りはないと思っていたのだが、
漢字表示がメイン記事であったので、たぶんこの部分は実機でのチェックを、されてないのでは・・・・
と勝手に想像している。）
※ 下にソフト修正後の、case1：斜め線描画実行結果を示す。（この時点でバックライト回路を追加しました。）
■ 2013.4.2
・これで不具合は、case8：漢字メッセージ表示だけとなった。（これは、後閑氏のライブラリにもなかった）
元々カラー液晶のサブルーチンをそのまま使用していることに問題があることは分かっているのだが・・・
症状としては、カラー液晶の時、後閑氏が用意した割と長文のメッセージテーブルを
そのまま読込んでいるが、メッセージが最初から始まらないで途中から始まるが、先に進まない・・・
といったような症状である。
・分かり易いように、極少ないメッセージテーブルに変えてみることにした。
3行に渡っての表示を、試してみた。
→ 何てことはなかった。
カラー液晶の時の漢字メッセージと、今回のモノクロ液晶の時では、1画面に表示する文字数が、異なるので
今回の、10文字x4行の表示形式に、漢字メッセージテーブルを変更する必要があっただけだった。
→ テーブルを変更し読出したら、以下の通りうまく表示できた。
■ 2013.4.3
・一通り、各テストケースの表示が出来たので、以下に各画面のスナップショットをアップしました。
＜最終ソース及び、ヘッダーファイル＞
・こちらから、どうぞ→ MONO_GLCD_TEST.c
glcd_lib32k.c （後閑氏が作成された、PIC32用GLCDライブラリですが、一部修正追加しました。）
glcd_lib32k.h
font.h （フォントデータ： 後閑氏が作成された、アスキー文字データ）
imagedata.h （イメージ・データ： 後閑氏が作成されたオリジナルに、WIN標準のお絵かきソフトで書いたオシロのイメージを追加しました。）
KanjiFont12.h （漢字フォントデータ 12x12ドット： フリーの「M+フォント」を基に、後閑氏が作成したものを使用しました。）
← 実験テーマ1に戻る TOP PAGEに戻る 実験テーマ29へ →
