(日々の記録)デジタルオシロを買った。(土)STM8Sでグラフィック液晶に日本語文字が表示できたLPCMプレーヤーでばデバッグの醍醐味を味わって大いに意気が上がったというのに、本来のSTM8Sによるモノクログラフィック液晶(JCG12864A37)への日本語フォント表示の開発の意欲は依然として高まらない。進まない理由は前にも書いたように、具体的な目標が決まっていないからである。目的があいまいなので、仕様の選択肢が多くなりすぎ、迷うばかりで先に進まない。何か決めても心配になってまた元へ戻るという堂々巡りになっている。システム開発で良くある失敗プロジェクトのパターンだ。いうときは、少し強引でも、良い加減でもいいから、完成までの作業工程を可能な限り細分し、そのひとつづつを何も考えず、とにかくやってみるという少々乱暴だが効果的な打開策がある。今度もこれを応用してみることにした。手順を分解して沢山の作業項目を作る(3/19/2013)ということで、STM8Sの日本語フォント表示計画は、次の5つの手順に分けて、とにかく先に進むこととした。フォント抽出と、フォント描画の機能の分離グラフィック液晶(GLCD)に文字フォントを描く手順は、大きくわけると、フラッシュから、所定の文字のフォントグリフ(フォントのビットマップスキャンデータ)を抽出してくるロジックと、GLCDメモリに、そのデータを移すロジックに分かれる。分けるか、一緒にするかで悩んでいたが、GLCDの描画部分を共通にして、関数を2つに分けることにした。漢字コードの入力UARTモニターからは任意の2バイト漢字コードが入力できないといけない。ハードコーディングした漢字コードのテストだけでは不完全である。この開発は、描画とは独立した機能なので、この部分だけでも進める。フォント構造体の統合とSRAMの構成見直しフォントデータを速度の遅いフラッシュに収容しているので、フォント属性だけは、SRAMにあるフォント構造体に収容している。日本語フォントは、FONTXフォーマットを使うとすると、さらに文字データをアドレスするデータブロックがSRAMに必要となり、この量は結構多い(バイナリエディターで調べたところでは蕨フォントで376バイト)。このため、ANKとは別の考え方をしないといけない。SRAMは既に限界の2KB近くまで使い込んでいるので、このままではSRAMがオーバーするのは自明である。何とかしなければいけない。2バイト日本語フォントデータ抽出関数の開発この部分は、ChaNさんのサイトの「FONTXの話」に、幸いソースコード付きで紹介されているので安心である。コードを読んでみると、自分が考えていた手法と殆ど同じで意を強くする。この手順だけで、あのばらばらのブロックに分かれたシフトJISコードがハンドリングできるのか、ちょっと信じられないのだが、彼のコードにぬかりがあるはずはない。フラッシュメモリの再構成フラッシュメモリへの書き込みが、なるべく単純作業で行えるようなメモリの構成とソースコードにしておきたい。ないと最初は良くても自分でもメンテナンス不能になる可能性がある。今度のフラッシュの初期化の単位がセクター(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のサイズが考えたように減っていかない。変化が連続的でないのである。時々、がくっと減ったり増えたりする。