STM8Sでグラフィック液晶に日本語文字が表示できた

　LPCMプレーヤーでばデバッグの醍醐味を味わって大いに意気が上がったというのに、本来のSTM8Sによるモノクログラフィック液晶(JCG12864A37)への日本語フォント表示の開発の意欲は依然として高まらない。

　進まない理由は前にも書いたように、具体的な目標が決まっていないからである。目的があいまいなので、仕様の選択肢が多くなりすぎ、迷うばかりで先に進まない。何か決めても心配になってまた元へ戻るという堂々巡りになっている。システム開発で良くある失敗プロジェクトのパターンだ。

　こういうときは、少し強引でも、良い加減でもいいから、完成までの作業工程を可能な限り細分し、そのひとつづつを何も考えず、とにかくやってみるという少々乱暴だが効果的な打開策がある。で、今度もこれを応用してみることにした。

手順を分解して沢山の作業項目を作る(3/19/2013)
　ということで、STM8Sの日本語フォント表示計画は、次の5つの手順に分けて、とにかく先に進むこととした。

(1) フォント抽出と、フォント描画の機能の分離
　グラフィック液晶（GLCD)に文字フォントを描く手順は、大きくわけると、フラッシュから、所定の文字のフォントグリフ（フォントのビットマップスキャンデータ）を抽出してくるロジックと、GLCDメモリに、そのデータを移すロジックに分かれる。

　これまでに作った半角のANK文字表示関数と、日本語文字表示関数を分けるか、一緒にするかで悩んでいたが、GLCDの描画部分を共通にして、関数を2つに分けることにした。

(2) 漢字コードの入力
　UARTモニターからは任意の2バイト漢字コードが入力できないといけない。ハードコーディングした漢字コードのテストだけでは不完全である。この開発は、描画とは独立した機能なので、この部分だけでも進める。

(3) フォント構造体の統合とSRAMの構成見直し
　フォントデータを速度の遅いフラッシュに収容しているので、フォント属性だけは、SRAMにあるフォント構造体に収容している。日本語フォントは、FONTXフォーマットを使うとすると、さらに文字データをアドレスするデータブロックがSRAMに必要となり、この量は結構多い(バイナリエディターで調べたところでは蕨フォントで376バイト）。

　このため、ANKとは別の考え方をしないといけない。しかもSRAMは既に限界の2KB近くまで使い込んでいるので、このままではSRAMがオーバーするのは自明である。何とかしなければいけない。

(4) 2バイト日本語フォントデータ抽出関数の開発
　この部分は、ChaNさんのサイトの「FONTXの話」に、幸いソースコード付きで紹介されているので安心である。コードを読んでみると、自分が考えていた手法と殆ど同じで意を強くする。この手順だけで、あのばらばらのブロックに分かれたシフトJISコードがハンドリングできるのか、ちょっと信じられないのだが、彼のコードにぬかりがあるはずはない。

(5) フラッシュメモリの再構成
　フラッシュメモリへの書き込みが、なるべく単純作業で行えるようなメモリの構成とソースコードにしておきたい。そうでないと最初は良くても自分でもメンテナンス不能になる可能性がある。

　しかも今度のフラッシュの初期化の単位がセクター(64KB)ごとなので、今後のことを配慮したメモリ配置をしないといけない。とりあえず、0セクターをワーク用、1セクターをANKフォント、2セクター以降を日本語2バイトコードと割り振って、ソースにハードコーディングしておく。

達成感があるとやる気が出てくるものだ(3/20/2013)
　手順が出来たので、各個撃破のつもりで作業にとりかかった。まず、(1)の手順として、既存のフォント表示関数LcdChr_Ank関数から、フォントデータをLCDメモリに展開するだけの関数LcdPut_Font関数を切り出す。

　やってみると意外に簡単に分離することが出来た。早速、ここだけでテストする。いつもの逐次開発法である。よーし、分離してもこれまでのANK文字は問題なく表示された。これでこれから開発する2バイト漢字コードを表示する関数、LcdChr_Kanji()は、この切り出した関数を呼ぶことでコードの効率化が図れる。

　次に(2)のステップである。16進表示キャラクターから、実際の2バイトバイナリーをデコードするロジックは、AVRなどいくつかのところで実装済みである。このあたりを参考にUARTコマンドのコードを書く。これもそう手間をかけずに完成できた。既存のユーティリティで数値を確認する。

　沢山ある仕事もこうして細かい手順に分けて少しづつ完成させていくと、はずみがつくものだ。ちょっとでも達成感があると次のやる気が出てくる。不思議なものである。しかし、良いことばかりは続かない。(3)の手順で、つまづいた。SRAMのメモリーがなかなか減らないのである。

　フォント構造体の設計は、1バイトのANK系と2バイトの漢字コード系とはヘッダーの部分だけであとは全く別方式でやることにした。そこまでは良かったが、漢字コードのデータブロックに必要な300バイトあまりのSRAMの余剰はどうしても生まれない。

　STM8Sコンパイラーには、変数を、SRAMに置くか(予約語data)、フラッシュに置くか(予約語code)、指定できるようになっている。プログラムの中には、UARTのメッセージのように、固定された定数が多いので、これをcodeでフラッシュに移したつもりなのだが、これが全く効果がない。

　STVD（STマイクロ統合環境）には、出来上がったバイナリーの大きさを表示するsizeコマンドが入っていないので、.mapファイルをエディターで見ている。しかし、これが不思議なことにSRAMのサイズが考えたように減っていかない。変化が連続的でないのである。時々、がくっと減ったり増えたりする。謎である。

　暗礁に乗り上げた。余裕は精々30バイトくらいしかない。このままでは、所望の日本語のフォントデータにたどり着くまでに、何回もフラッシュを読まないといけなくなり速度が落ちてしまう。何とか切り抜ける方法はないがあれこれ考えるが、うまい解決策が思い当たらない。

気を紛らそうとハード工作の道草をする(3/21/2013)
　こういうときは、何か全く別のことで気を紛らわすのが一番だ。そのうち良いアイデアが湧いてくる。ということで前から気になっていたハード工作をすることにした。

　それは、オーディオセットのスピーカーの起動時のポップノイズを避ける遅延装置の作り直しである。LM380革命アンプをテストしていた時、この遅延回路を作って30年以上経っていることに気が付いた。

　この遅延装置の主要な部品は、30年以上前、職場の大型汎用コンピューター(IBM)のハードエンジニアから分けてもらった、大型のリレーとカンパッケージのトランジスターである。それに電源とケースをつけたして自作した。遅延はベースに入ったCR時定数で、電源が入った数秒後トランジスターがリレーをドライブしてスピーカー回路をONする。

　さすがにあの時代の電子計算機の部品である。作ってから全く何の問題なく動いているが、そろそろリレーの寿命が心配になってきた。ウェブなどを見ていると、最近のMOS-FETのオン抵抗は、下手なリレーより低い一桁のミリオーム台なのだそうだ。FETのスイッチングは大電流のところを派手に切るためのものと思っていたが、こういうところにも使われているとは知らなかった。

　ウェブで紹介されている回路を見て驚いた。FETのドライバーのフォトカプラーの2次側に電源線がない。スピーカーの端子を切るだけだからフォトカプラーの絶縁性は余り問題にならないが、2次側に電源が要らないと言うのは回路がとても簡単になる。

　こういうフォトカプラーはフォトボル型といって、1次側のLEDの光だけで、FETのドライブに必要な電圧を出せるのだそうだ。急に欲しくなった。いきつけの千石や、秋月では売っていない。DigiKeyにはさすがにあった(TLP590B、TLP190Bなど）が、これだけ買うわけにも行かない（最近はDigiKeyで欲しいものがない、というよりあらかた買ってしまった）。

　値段は、少々お高い。DigiKeyで￥200ばかりだ。諦めきれずにウェブでさらに探し回ると、例のサトー電気でTLP590Bを売っているのをつきとめた(￥252）。前々から一度は行ってみたいと思っていたサトー電気である。

川崎のサトー電気でフォトカプラーを手に入れる(3/22/2013)
　相当、古くからある電子部品の専門店である。Webの通販ページが手作り感満載の不調法なリスト一点張りのページだが、品揃えは中々侮りがたい。色々な逸話のあるお店である。ただ、お店が町田や川崎など遠方にあるので行く機会がなかった。

　ちょうと良い機会である。フォトカプラーだけというのもちょっと何だが、気晴らしに久しぶりに車を駆って川崎駅前まで出かけてみた。カーナビで目指すところに辿りつき、車をコインパークに入れて探したのだが、これが見つからない。

　場所は、駅近くの府中街道沿いの家内工場街といった感じのところで、看板が全くない。地図を見直して（印刷してきてよかった）、慎重に調べ直しやっと辿りついた。看板が出ていないのは、トラックに壊されて中に入れたままだったということをあとで聞いた。

　3間ほどの間口の店の中には所狭しと電子部品が積み上げられ、ちょっと壮観である。名物のおばさんは10年近くも前に亡くなったそうだ。親父さんはすこぶる元気らしい。川崎の店の息子さんらしい人は意外に愛想が良かった。

　問題のフォトボル型フォトカプラーTLP590Bを4ヶ、ついでに高速(10Mbit/s)フォトカプラーTL522を2ヶ買った。型番を調べてあったので、あっという間に品物が揃う。足が出ているので導電スポンジにつけて欲しいと言ったら、エアシートで包装してくれた。

　買って帰ると何となく安心して、遅延回路を作る意欲が薄れる。面白いものである。第一、まだオン抵抗の低いFETを入手していない。FETの型番はどういうことになっているのだろう、2SK,2SJ以外に多種多様な型番があって、何がなにやらさっぱりわからない。

　暫くは、FETを何にするかで楽しもう。出来合いのSSR（ソリッドステートリレー）を買ってしまうほうが、安くついて簡単なのだろうけど、こういうところにこだわれるのが自作の醍醐味だ。

SRAMのオーバーはやりたくなかったがUNION（共用体）で回避（3/23/2013)
　STM8Sの日本語フォント表示の開発に戻った。(3)が頓挫しているので、残りの(4)と(5)のステップを進めている。(4)はChaNさんのコードを参考に、LcdChr_Kanji()を少しづつ実装していく。SRAMが残り少ないので、なるべくワークを使わないように気を遣う。

　(5)のフラッシュデータの再構成である。これまでのデータはすべて破棄し、0セクターはテスト用に残し、1セクターをANK文字、2セクターを、日本語文字フォントに割り当てる。書き込みコマンドを書き直し、12ドットと10ドットのANKフォント、日本語フォントは12X12の蕨(わらび）フォントを入れ直す。

　あれえ、データ量が少ないなあ。ダンプリストで確認しようとした。あっ、こいつは32ビット対応になっていない。セクター1以降は、64K以上なのでアドレスはすべて32ビット対応にしておかねばならない。まずダンプリストのソースを修正する。

　ダンプリストが1セクター以降でも動き始めた。データがおかしい。ちゃんとデータが入っていないようだ。どうしたのだろう。ああ、なーんだ。ファイル転送をバイナリーモードにしていなかった。お馬鹿な話である。

　ファイルをもう一度、バイナリーモードで転送し直す。これでANKフォントは入ったようだ。テストし直す。これまでと全く変わりなくGLCDの表示が出来た。さらに日本語ファイルを入れる。時間はかかるが正常終了。サイズもピッタリだ。よーし、これで(5)はクリアした。

(4)の日本語フォント表示関数も、そろそろ完成に近づいた。残りは、懸案の(3)のSRAMのやりくりである。GLCDのVRAMに既に１KB以上取られている上、フラッシュ上にコンスタントを移せていないのでちょっとのことでは空きが出来そうにない。

　これまで構想はあったが、実装をためらっていた方策をやはり実行するしかないようだ。UARTバッファーとフラッシュのデータエリアをUNION(共同体）で流用する方法である。フォントデータをファイル転送するために、UARTはダブルバッファーで100バイト以上をとっている。転送してしまえば、UARTにこんな大きなバッファーはいらない。ここにフォントデータブロックのエリアを割り当てる。

　エリアを共用するので、プログラムの構成を良く考えておかないと、予測不能なバグが出る可能性がある。余りやりたくない方法である。しかし、もう背に腹は代えられない。変数名が長くならないように、共用体(union)の名前をなるべく短くして（uとか、tr)プログラムを書き直す。これでやっと全部のプログラムのSRAMを、2KB(2031バイト）内に納めることが出来た。

嬉しい。フラッシュメモリのエラーが直った(3/25/2013)
　ソフトはおおよそ出来上がったが、実はまだ解決しなければならない大きな問題が残っている。SPIフラッシュM25P40のreadエラーがとれないのである。

　単独では全くエラーが出ないのに、グラフィック液晶(SPIインターフェース）とSPIを共用するとデータエラーが頻発していた。当初は、フラッシュにパスコンを入れたり、接触不良を直したりしてエラーが出なくなっていたのだが、今度の漢字フォントのような大容量データを読み出すと再びエラーが起き始めた。

　漢字ブロックデータはアドレスなので1ビットでも間違いが起きれば、フォントのようにドットが欠けるくらいではすまない。エラーの出方がおかしい。単なるノイズでビットが時々乱れるのではなく、発生するときは、ある時点から連続的におかしくなる。止まっているはずのGLCDが時々動いてエラーを出しているような感じである。

　マスターのSPIから見れば、GLCDへは送信（MOSI)だけであり、フラッシュは殆ど受信（MISO)だけである。お互いに干渉しないはずなのにおかしい。GLCDそのものの結線をはずせば、全くエラーがなくなるので、GLCDによっておかしくなっていることは明白である。

　試しにGLCDの電源ラインを切ってみると、かえってエラーが増える。？？？である。しかも、液晶面には、電源を切っているのに、画像が出ている！GLCDのコントローラーは動いているのだ。クリアも有効である。謎は深まるばかりである。

　そこで、さらにCLK線をはずしてみた。おお、これでGLCDそのものをはずした時と同じようにエラーが出なくなった。GLCDの方も完全に止まっている。

　どうも、GLCDのクロックラインがフラッシュのSPIのクロックに悪さをしているようだ。両者の間に300Ωばかりのダンプ抵抗を入れてみる。ふむ、GLCDはこれでも動くが、フラッシュのエラーは改善されない。

　えーい、こんどはダイオードだ。小電力用のダイオードを入れる。だめだ。GLCDが動かなくなる。これは0.7V近く電圧降下するからか。では、SBD(ショットキーバリヤーダイオード）ではどうか。やった、やった。SBD(1S4)を入れてGLCDからの信号を遮断すると、GLCDは正常に動き、しかもフラッシュのエラーはきれいになくなった。何十回フォントデータを読み出してもエラーは起きない。

　いやあ、これで2バイトコードのデコード関数開発に心置きなく専念できる。これまでこのエラーが気がかりで中々先に進めなかったのだ。

遂に日本語フォントの描画に成功(3/27/2013)
　長かったSTM8Sのプロジェクトが大詰めに近づいてきた。当面の目標であるグラフィック液晶への漢字表示である。2バイト日本語フォント表示関数が完成したのでテストに入る。

　漢字コードや、フラッシュのエントリーアドレスなどをUARTに表示するテストステートメントをびっしり入れたお陰で順調にバグがとれ、画面にそれらしい漢字データがあらわれた。あのデータブロックの計算はうまく行っているようだ。この部分は一発で通った。ちゃんと指定どおりの漢字が出る。

　嬉しくて何枚も記念撮影する。まだ、一字づつ16進コードを入れて漢字をひとつ表示するだけだが、表示の度にキーボードの前で何度もガッツポーズを作る。今回は特に感慨深い。とにかく時間がかかっているのだ。

　ブログの記事によれば、STM8Sを触り始めたのが、去年の11月、グラフィック液晶をつないだのが、2ヶ月前の1月、かれこれ5ヶ月近くこれにかかわっている。STM8SがAVRに比べて有利な点を持っているわけではない。情報も少ないし、余りメリットはないのだが、日本語が出るまでと意地になっていた。

　コードを追加して、エンドレスに漢字が表示されるようにする。おやあ、途中で文字が化けてしまう。どうしてだ。ファイル転送は、PCにおけるデータ数と同じ転送バイト数を示しているのでデータエラーは考えられない。ソフトか。うーむ、今までの高揚した気分が一気に落ち込む。

　文字化けし始める漢字コードを探し当てる。8C49「栗」というコードからおかしい。ふーむ、この文字のポインター（ファイルのエントリーからの）と、ひとつ前の8C48「粂」の違いは？あ、あ、あ、わかった。セクター消去を3セクターまでしかやっていない。「栗」からは4セクターに入るんだ。ダンプリストを作っておいて良かった。アドレスの違いが一目でわかった。

　あわてて、フラッシュメモリを7セクターまで消去し、フォントファイルを入れ直す。第二水準の一番最後の文字まで画面に出ることを確認した。これで完全だ。

　遂に、STM8Sの日本語フォント表示プロジェクトは大団円となったようである。次のテーマも良いが、長い間の付き合いでこのSTM8SとGLCDに妙に愛着が出てきた。ブレッドボードのバラックではなくて、ちゃんとした基板に実装してあげようか。

ここに作りかけのソースコードですが、以上の漢字が出力されるプログラムをSTVDプロジェクトの形で固めたものを置きます(フォントは入っています）。以前同様、ライブラリは入っていません。また、容量の関係で、ビルドは最初からやってください。UARTを接続し(38400bps N81)、プロンプトがでたら、kWXYZ でコードWXYZの漢字、kWXYZ- で、連続して漢字が表示されます。中断はスペースキー、終了はリターンキーです。

「JCG12864_330.zip」をダウンロード