グラフィックLCD画面のスクロールライブラリ公開

　2013年は年明け早々から、久しぶりのソフト開発に熱中していた。やっとのことでAitendoのモノクログラフィックLCDにキャラクターを出してスクロールするライブラリが出来たので公開することにする。その前に、ちょっと電子工作以外の話題をご紹介。

久しぶりの家族旅行を楽しむ(1/7/2013)
　お正月明けに何年ぶりかで家族揃って泊りがけの旅行に出かけた。行き先は鳥取県の皆生（かいけ）温泉というところで、お目当ては温泉と松葉ガニをたらふく食べることである。

　昔なら東京から山陰と言うと汽車を乗り継いで1日がかりの旅だったが、今は、飛行機でひとっ飛びである。昨年結婚した娘も夫婦で参加し賑やかな家族旅行になった。まだひとり、娘が残っているので、お礼参りと縁結びを願って出雲大社に初詣する。

　宿の蟹料理は、評判どおり何から何まで蟹づくしで、暫く蟹を見たくなくなるほど堪能した。2日目の夕食は蟹を断ったほどである。物価は明らかに東京より3割は安い。松江城の近くで昼食にとった出雲そばの鴨せいろも￥900でたっぷり鴨がのっていた。

　松江は落ち着いた地方都市で、松江城のお堀端にある小泉八雲の旧邸や近くの武家屋敷は俗な観光地化がされていなく（人力車などいない）風情のある佇まいが残され、とても気に入った。温泉を少し離れたところにしてしまったので今度はもう少し近いところに宿をとり、もういちど訪ねてみたいところだ。

AVRでフォントファイルをオブジェクトファイルとして組み込む(1/3/2013)
　それはともかく、電子工作である。AitendoのモノクログラフィックLCD（JCG12864)をSTM8Sで動かしてやろうと言うプロジェクトは、とりあえずAVRで始めている。そら。さんのソースを利用させてもらって、画面に文字が出てくるところまでは確認した。

　前回の記事で、このプロジェクトのロードマップを提示したが、当面の目的であるスクロールを開発する前に、やっておきたいことがある。現在のフォントは8X16なので、128X64の現在の画面ではスクロールさせるには大きすぎて具合が悪い。もう少し小さいフォントにしたい。そうでないとスクロールのありがたみが薄れる。

　というので、ChaNさんの「FONTXの使い方」や「32ビットのお誘い」のページを参考に、小さいフォントを取り込んでみることにした。STM8Sではオブジェクトファイルを埋め込むことはできないが、EEPROMで入れる予定で、フォントファイルそのものも勉強しておきたい。

　ウェブであちこち適当なフォントを探す。すると、Shuji009さんのブログで洒落たフォントをTFTに沢山表示されており、ソースコードも公開されているのを見つけた。ありがたく頂く。おお、結構沢山のフォントが収容されている。

　フォントデータの実装は、ChaNさんのオブジェクトファイルに埋め込む方式が一番スマートだ。詳しい解説も載っている。shuji009さんのフォントライブラリーから、6X12のフォントを選んで、objcopyの方法でFONTXファイルのオブジェクトを作ることとした。

AVRではobjcopyではなくavr-objcopyを使う(1/5/2013)
　ところが、WINAVRには、objcopyがないのである。調べてみると、avr-objcopyというのがあり、これで代用できそうだ。とりあえずWinXPのDOS画面で試してみる。長いパラメーターを打ち込んで実行。ふむ、指示通りオブジェクトファイルが出来たようだ。AVRStudioに持ち込んで、makeしてみる。

　だめだ。「出力ファイルのフォーマットが違う」というエラーではねられる。ChaNさんのコマンド例のelf32-littleではないようだ。なになに、avr-objcopyのヘルプメッセージに、サポートする出力フォーマットの種類が出ている。10個近くあるうち、AVRの名が付いた、elf32-avrというのがくさい。

　ビンゴ！であった。コンパイルとmakeが通った。よーし、出来たぞ。あれ、SRAMが5KBもある。なにー、フォントデータがフラッシュではなくSRAMに入ってしまったようだ。うーむ、ChaNさんのコマンド例はどうもARM用のようで、AVR用ではないようだ。

　ふつうの組み込みマイコンはフラッシュに較べるとSRAMははるかに少ない。SRAMにこういうデータを入れることはまず有り得ない。何かパラメーターがあってそれが抜けているだけなのだろうが、それが何なのかわからない。objcopyの機能は盛りだくさんでそう簡単には見つからない。

　また、あれこれマニュアルや、ウェブサイトで情報を漁る。そのうち、ChaNさんのページの別の手法のアセンブラーステートメントのコメントに、

.section ".rodata"          // ROM(定数領域)に配置(AVRなら.progmem)

と書いてあるのを見つけた（下線は筆者）。これだ！　objcopyのパラメーターのひとつに、

.data=.rodata

というのがある。ここを.progmemに直せば良いのではないか。試してみる。やった、やった。これも大当たりであった。フォントファイルは、SRAMでなくフラッシュに埋め込まれた。いやあ、山勘が2つも当たってすこぶる機嫌が良い。

　これから同じようなことをしようとする人の参考のために、AVRでobjcopyを使うときの正しいコマンド例を以下にお示しすることにする。ここでは、m6x12.fnt　というファイルを、m6x12.oというオブジェクトにして、フラッシュ領域に入れる。

avr-objcopy -I binary -O elf32-avr --rename-section .data=.progmem,alloc,
load,readonly,data,contents m6x12.fnt m6x12.o

　下線が、ChaNさんの例と異なる部分である。入力ファイル名はカレントディレクトリに置かないとフルパスが外部参照名になるので注意されたい。色々考えるより、このコマンド例で動くようにファイルをカレントディレクトリに持ってくるのが簡単だ。

GLCDとフォントのスキャン方向が違う(1/6/2013)
　ソースコードを調整し、Makefileの定義を直して、新しい6X12フォントが出るようにプログラムを修正する。この手間は、フォントデータをオブジェクトファイルにするよりずっと簡単に終わった。早速、わくわくしながらプログラムを動かす。ふーむ、出てきたフォントは、2つに分割され、位置が90°ずれている。

　そうか、そら。さんが言っていたフォントのXY軸を変換したと言うのはこのことだな。6X12のフォントだから、8ドットのフォントグリフ（ビットマップ列のこと）が2つに分かれて横になってしまっている。そら。さんは速度を理由に、フォントグリフそのものを変換されたようだが、こちらは余りフォントデータはいじりたくない。

　フォントグリフのXY変換は、以前LEDマトリックスの電光掲示板でやったことがあるので作業にそれほどの不安はない。しかし、沢山のフォントを試してみたい時に、いちいち変換していくのは大変である。

　それに、STM8Sはオブジェクトファイルを使わず、EEPROMにフォントデータを入れようと考えている。そうすると容量が大きくなるので、日本語フォントまで出せるかもしれない。なおさらフォントファイルはそのままにしておきたい。

　しかし、なぜ、そら。さんがフォントの方向をY軸に変換したのか、その理由はプログラムを調べるにつれて明らかになってきた。このGLCDのハードの構造からプログラム上での変換処理が恐ろしく面倒になるのである。

　このGLCDはドットの表示が縦（Y軸）に8ドットづつで1バイトのシリアルデータが入力単位である。GRAMバッファーは縦8ドット単位に128バイト（正確には129バイトで4ドット使わない）で1ページを構成し、これが8ページあることで全体のドットエリアをカバーする。

　一方、FONTXデータは、横方向（X軸）に8ドット単位のフォントグリフを構成し、端数を切り上げて次の段のフォントとなる。この縦横変換は一筋縄では行かない。フォントの大きさが8ドットの倍数だったり、描きだすところが8の倍数単位なら、それほどでもないが、端数から描きだし、フォント幅が8の倍数以外の端数になると、とてつもなく難しくなる。

GLCDのページアドレスに苦戦（1/10/2013)
　GLCDのページアドレスという構造そのもの自体が、簡単にプログラムが出来る代物ではない。端数からドットが始まる時は、1バイトデータの中のビット単位のシフト演算を繰り返して、隣接するバッファーにデータを埋め込む必要がある。

　どういうことかと言うと、横線のように横にドットが並ぶ時は、1バイトの同一ビット位置にデータをセットし、これを、VRAMアドレス単位に繰り返して始めて直線が引ける。縦線は8の倍数なら、VRAMアドレスを横軸幅単位に飛び飛びにとって描きこめば描けるが、端数から始めたい時は、始点と終点でのビット演算が不可欠になる。

　横スキャンのフォントデータを、縦に8ドットづつスキャンしてレクタングル（四方形）に埋め込むソースコードを書き始めた。久しぶりの本格的なプログラミングである。擬似コーディングというより、一種のパズルに近い。何枚もメモ用紙にGLCDのページとフォントのビット列の図を書いては、ロジックを組み上げていく。

　参考にしているオリジナルのソースコードが難解である。このGLCDのVRAMバッファーに縦横ドット単位のレクタングル（四辺形）を埋め込む関数は、LcdWriteImage()という関数なのだが、これがさっぱり何をやっているのかわからない。

　コメントをこちらでいくつも追加して何とか理解しようとするが、わかったのは、レクタングルのデータのスキャン方向が縦であるということくらいである。縦のデータの配分は、シフト演算で埋め込んでいるようだが、VRAM側のシフトと、レクタングル側のビット単位のシフトが錯綜して、すっきり頭の中に入ってこない。

　こういう構造の中の縦横変換である。8X8などの変換ならまだしも、今度のように6X12という端数の出るフォントの変換はとてつもなく難しい。しかも、ビット順がリトルエンディアンだとすると、2バイトにわたるデータでは見た目が逆になるので大変だ。

　何とかソースをでっちあげてテストするが、さっぱり文字の形にならない。軽い気持ちでフォントスキャンの方向変換を始めたことを後悔する。そら。さんがやったようにフォントデータの方を変換して先に進みたい誘惑にかられる。

　しかし、負けず嫌いの性分だから簡単に引き下がるわけには行かない。UARTに途中経過の数値を吐き出させてはロジックを確認して先に進める。しかし、いつまでたっても画面はゴミのような斑点が出るだけで、一向に文字らしい図形はあらわれない。

やっと6X12フォントの表示に成功。速度はこれくらいなら問題ないか(1/13/2013)
　結局、何とか文字らしいものが出るまでに1週間もかかってしまった(旅行の3日が入っているが）。自分としては珍しく、プログラムの構造を途中で換えた。3段ループを2段ループに変えて、やっと目鼻がついてゴミが文字らしくなってきた。

　反省点はやっぱり擬似コーディングというか、抽象レベルでの念入りな検討が不足していたことにつきる。早くコーディングに入りすぎた何よりの証拠は、プログラムの構造を途中で変えたことである。人に偉そうに言う割には、つい目の前のソースコードに気を取られてプログラムを書いてしまう。

　まだ時々ゴミが出るが、やっとのことで文字が正しく表示された。嬉しくて記念撮影する。横スキャンのフォントデータをビット単位に読み込んで縦方向に展開して表示しているので速度が心配されたが、全く気にならない。

　それでも、これまでの縦にバイト単位に展開するのに較べれば、単純に考えても処理時間は8倍になっているはずである。どれくらい速度が違うのか調べたいおきたいところである。

　ということでロジアナを引っ張り出して測定してみた。オリジナルの16X8フォントを画面一杯に出すプログラムで全体の表示時間を調べたあと、新しく開発した12X6のプログラムの時間を測る。

　おやあ、最初が10.05msで、XY変換した方が9.75msだ。えー、おかしい。あ、そうか、フォントのドット数が違う。128ドットと、72ドットだ。表示するドットが2倍近く多い。しかし条件を揃えて測定するのは、プログラムを書き直す必要があって面倒だ。

　そこで、ロジアナのチャートを見ながら、SPIの実測速度から転送時間を引いて（SPI速度は4Mhzあるが前後の準備で1Mhz程度）、XY変換にかかるロジックの時間だけを推定してみた。理論上は、同じ方向にバイト単位のフォントグリフを流し込む最初の方式にくらべ、ドット単位にデータを移していくので8倍は多くかかる勘定である。

　計算によると、6X12ドットの1文字あたりの処理時間は、87μsで、16X8ドットは44.4μsであった。意外に大きな差ではない。8MhzのCPUクロックなので、40μsの時間差は300ステップ位である。

　まあ、この程度なら、わざわざフォントを変換して入れ直さなくても大丈夫なのではないか。速度（クロック8Mhz）を上げればもう少し早くなる。見た目も殆ど変わりがない。

　スクロールの速度自体も6X12フォントだと、64X128画面で100文字ちょっと。全面書き換え（スクロール時）で16ms程度で納まる。これなら見た目もスムーズなスクロールになるはずだ（テレビの速度がインターレースで20ms)。

スクロールは思ったより簡単に出来た(1/15/2013)
　まだ、文字の下にゴミが時々出たりして完全ではないが、FONTX形式のフォントを直接出力できるようになったので、次のステップのスクロール機能の開発に進んだ。今の画面(128X64)に6X12のフォントで文字を出してスクロールさせるのは、精々が2１字、5行というわずかなスペースだが、ライブラリの形で開発しておけば、今後の汎用的な使い方につながる。

　スクロールの一番大変なところは、画面が一杯になったときに、画面全体を1行分上に描き直す処理をつくることである。データシートによれば、このGLCDのコントローラー(ST7565)には内蔵のVRAMを自由にアクセスする機能があるようだが（データシート26Pにdisplay start line address set commandというコマンドの紹介がある）、実装例がないので、そう簡単には手が出せない。

　となると、アプリケーション側にあるVRAMを全部描き直してもういちど出力させなければならない。文字の位置を決める画面管理はあとにして、まず、この画面を描き直す関数LcdScroll()を新たに開発し始めた。

　例のLcdWriteImage()の解析が相当進んで、ページアドレスのデータ処理に慣れてきたこともある。要するに、ひとつの8ドット（1バイト）のデータをシフトさせてY軸方向のバッファーに移動させて行くテクニックを連続して行うことである。

　思ったより早くコードが出来た。ステップ数もわずかだ。早速main.cにコマンドを新設してテストしてみた。おおお、一発で動いた。いやあ、嬉しい。1ドットづつのスクロールも綺麗に動く（配布するソースには入っていません。テストのため暫定的に作ったコマンドです）。

図形も入れてスクロールテストプログラムの完成(1/18/2013)
　勢いに乗って、直接キャッシュバッファーに書き込む一文字関数の開発に着手する。というのは、文字の出力がどうも不安定で、文字の下の部分（恐らく縦12ドットの下、残り4ドット）にゴミがでるバグがつきとめられないからである。

　現行のやり方は、フォントをレクタングルに描いたあと、更にそのレクタングルを例のLcdWriteImage()を通してキャッシュバッファーに書き込むという2重の手間をかけている。どの部分が悪さをしているのか、どうしてもつきとめることが出来ない。

　こういうときは、現行をあっさり諦めて、新規に作り直すほうが生産性が高い。一文字関数(LcdChr_Ank())に直接LCDバッファーに書き込むコードを追加する。経験値が上がってきているのだろう。こいつもそれほど時間もかからず完成した。

　勇躍、テストに入る。良いぞ。ちゃんと文字が出る。速度も心なしか速いようだ（まさか）。スクロールする。うわっ、画面が目茶目茶になった。何だ、何だ。

　これは、誰かがプログラムの定数部を壊しているからに違いない。慎重にprintfを入れて調査を始める。よーし、フォントアドレスの値が、スクロールをした直後、0になっている。スクロールを上にしたあと残ったエリアを0で埋めているところが臭い。

　やっぱり、ここが犯人だった。1ページ余分に0にしておりVRAMバッファーを越えている。バッファーの直後にあったと見られる外部変数が壊されている。この不具合を直したら、今まで不調だった色々な処理や画面のゴミが一掃された。快調にスクロールが動く。フォントアドレスの内部変数を新設したことで派手に事故が起こり、思わぬトラブル解決に役立った。

　余裕が出来たので、そら。さんが#if 0で止めていた、図形の関数を生かして遊んでみる。点と直線だが問題なく動いた。ちょっと面白いのでGLCDの初期画面（記事の最初）に応用する。ソースコード公開に向けて準備を始める。

　回路図も作る。単にGLCDにSPIをつないだだけである。図の中のプルダウン抵抗はなくても動くと思うが、現行はついているので念のためつけておいた。

　ソースコードは、そら。さんのプログラムを相当程度使わせてもらっている。公開に当たっては本人の事前の承認を得ておかねばならない。ライセンスはこれまでと同様、GPLではなく、もっと制限の緩い、ChaNさんのライセンス条件と同じ、商用、非商用を含めて、使用、複製、改変、配布一切自由、ただし著作権は放棄しない、全くの無保証という条件である。

　間もなく、そら。さんから許諾を頂いた。スクロールライブラリのデモプログラムなので、メインのところはかなりやっつけである。簡単に説明しておこう。まず立ち上がると初期画面があらわれ、同時につないであるPCのコンソール（UARTがないとまだ動かない。38.4kbps 8ドットパリティなし）のキーで、いくつかのコマンドが動く。

　ST7565.ｃとST7565.hのライブラリは汎用性があるように作ったので、FONTXの大抵のフォントファイルで動くだろう。 ST7565.ｈのヘッダーファイルでフォントを指定する。フォントバッファーの値も修正する必要があるかもしれない。Makefileのインクルードするフォントのオブジェクトファイルの修正も忘れないように。

以下に例によってAVRStudioのフォルダーをzipで固めたファイルを置きます。xitoa..Sや、xitoa.hはデバッグ用に入れたxprintfのためで特に必要ではありません。

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

AitendoのモノクログラフィックLCDを動かす

みなさまあけましておめでとうございます
 
　おかげさまで、当研究所のブログは、昨年一年間で20万近いアクセスを頂き、暮には遂に累計アクセスが60万件を突破いたしました。記事も知らないうちに200件近くを数え、結構な分量のブログとなりました。

　しかし、この一年は少々息切れがして、以前のようにFPGAを気張って動かしたり、市販ガイガーカウンターキットの不具合を発見するような、頑張った記事が少なく、本人としては少々物足りない一年でした。

　でも、オーディオや、単なる工作の記事の多い最近の方が、かえってアクセスが増えてきたりして、ブログが読まれる率と言うのは、自分の努力や意欲とは余り相関はなさそうです。

　まあ、所長の年も年ですから、あまり気を張らず、自分のやりたいことをマイペースで続けていくことをモットーに、細く長く電子工作を続けていきたいと思っています。暖かく見守っていただけますようお願い申し上げます。

　というようなわけで、以下は、前記事と日にちが前後しますが、昨年の大晦日までの、STM8Sに続く電子工作らしい工作のご報告です(2013/1/2記）。

Aitendoの中古128X64のモノクログラフィックLCD(12/13/2012)
　このLCD(JCG12864A37-04)は、随分前Aitendoの直営店で、特に使うあてもなく面白がって買ってあったディバイスである。STN液晶モノクログラフィックのLCD（以下GLCD)は、128X64ドットくらいだと普通どんなに安くても￥1000以上するが、こちらは中古なので￥500と格安である。

　このディバイスを、このあいだ動作確認したSTM8Sプロセッサーで動かしてやろうというのが、今度の電子工作のテーマである。

　このGLCDについては、当ブログによくコメントを寄せてくれる、そら。さんがご自分のブログで、電波時計に使われた例を発表されている。このGLCDを動かすデモプログラムも公開されているので動かすことに不安はない。ここでのプラットホームはAVRのMega1284である。

　こちらのアプリケーションも、とりあえずは、そら。さんと同じ電波時計にしておくことにする。こうすると、グラフィックLCD、STM8Sプロセッサー、それにAitendoのデュアルバンド電波時計ユニットという、3つの在庫品が一挙に消化できるからだ。

　電波時計では、グラフィック液晶の特長を生かしにくいとは思うが、あのAitendoの電波時計ユニットは、時計そのものより、JJY電波の受信感度を調べるのに活用されている例がいくつかあり、グラフィックで、受信品質を時系列にグラフにしてやれば面白いのではないかと考えた。

　面白いとは言ってもまだ妄想レベルで、まずはSTM8Sどころか、AVRでこのGLCDの動作確認をすることが先決である。プログラムと同じで、機械は願望と期待だけでは絶対に動いてくれない。とりあえずは動かしてみることが肝腎である。お店のリンクから、ディバイスの資料を集めたり、そら。さんのところからプログラムをダウンロードさせて貰ったりして準備を進めた。

　少し心配なのは、ウェブを探し回ったが、そら。さん以外にこのGLCDを動かしたという人が見当たらないことである。中古だし情報が少ないので手が出しにくいのかも知れない。こういうディバイスは、複数の人の使用記があればあるほど、色々な視点で調べることができて大変参考になるのだが、ないというのなら仕方がない。

LCDのバックライト面の余計な背景は取り除いてある(12/14/2012)
　このLCDには、元のアプリケーションで使われたらしい海の景色の背景がLCDのバックライト面についている。この背景の取り外し方が店のウェブに載っていて、実はこれがこのLCDを買う決め手（こういう少し危ない細かい工作が好き）になったのだが、そら。さんが、取り外し方をお店に要請していたとは、この機会に詳しく調べるまで知らなかった。このガイドのお陰で、余計な海の背景のとりはずしは、とても簡単だった（買ってすぐとりはずしてあった）。

　困ったのは実装である。このLCDの基板は3枚のフラットケーブルが出ているが、コネクターがついているのは2枚(16Pと6P)だけで、残りの1枚はコネクターもついておらず、折りたたまれたままである。どうも、シリアルでドライブするためには不要ということなのだろうが、お店の情報は全くそれに触れていない。基板には2ヶの赤のLEDがついているが、これについての説明もない。

　お店が出している基板の情報はPDFたったの1ページで、ピン割付は略号だけである。VddやGNDはともかく、他のピンアサインは良くわからない。コントローラーのST7565のデータシートは詳しくて良いのだが、基板の略号とは斉合性がとれておらず、ピンアサインについては全く参考にならない。かえって混乱するだけである。

　それに、フラットケーブルについている2ミリピッチのJSTのコネクターは、16ピンもあるので、行き付けの店には常備がない。困ってしまった。わざわざこのソケットを探し回るのは、何かものごとの順番が逆のような気がしてやる気にならない。しかも16ピンのコネクターがあったとしても、結局は2ミリピッチ基板を用意しなければならず、単なるLCDの接続だけでおおごとだ。

　手持ちの2ミリ基板を取り出して、どうしようかと眺めているうち妙案を思いついた。Xbeeの変換基板のときと同じ方法である。2ミリピッチの基板のランドに汎用の2.54ミリのL型ヘッダーピンをハンダ付けする方法が使えそうだ。ただ、22本もあるピンの内、どれがドライブに必要なピンかを見極める必要がある。

　お店のサンプルソースはSPIのようで、そら。さんもシリアル（SPI)で接続されておられるようだ。つなぐ必要のあるケーブルは10本以内で済むはずだが、良くわからない。どうも16ピンのコネクター(J1)だけでは必要な接続ピンが足りず、もうひとつの6ピンコネクターのJ2も使わないと動かないような感じだ。

　そら。さんがデモプログラムのソースコードだけでなく、回路図も公開されているのに気が付いて、あわてて回路図を拡大して見る。おお、この回路図には例のPDF情報と同じ略号でピンアサインが出ている。これは助かった。何々、やっぱりJ2にも2本、必要な線があった（リセットと、コマンド/データ識別）。

ブレッドボードで使えるように汎用基板ピンヘッダーをハンダ付け(12/15/2012)
　必要なピンは8本とわかった。ここまでわかると実装は楽になる。6Pの汎用L型ピンヘッダー2つを2ミリピッチ基板の裏にハンダ付けする工程に移る。

　まずL型ヘッダーピンの一方を、2ミリ間隔にペンチで揃える。そんなに厳密にやる必要はない。次はコネクターのピンである。CR部品のリード線の余りを適当に切って、あらかじめコネクターに差し、それをコネクターごと基板にはめて仮固定し、裏に出てきたリードをランドにハンダ付けしていく。

　さらに、ここがポイントだがコネクターを差したまま、先ほど作ったL型ヘッダーピンをハンダ付けする。出来上がったところでコネクターを抜き、コネクター側の不揃いなリード線をニッパーで切れば立派な2ミリ->2.54ミリ変換コネクターの完成である。究極の資源活用である(究極のケチと言っても良い）。

　コネクターを抜かないのは、L型ヘッダーピンのハンダ付けでコネクター側のピンがずれないようにするためである。CR部品のリード線は軟銅線なので抜き差しは殆ど出来ないと考えるべきだろう。少し太めの電解コンデンサーのリード線が、かたくておすすめである。

　ブレッドボードに差して様子を見る。よーし、しっかり止まっている。テスターで導通を確認する。全く問題ないようだ。念のため、LEDの点灯を確かめる。3.3Vをピン2（LED+)にかける。良かった。バックライトがしっかり点いた。20mAほど流れている。

まずはAVRで動作確認するも動かず(12/17/2012)
　ターゲットはSTM8Sだが、いきなりこれで開発することはとても無理である。そら。さんのソースコードのAVRで動かすことから始める。彼のソースコードには2種類あり、電波時計の方は、ソースの量が多いので、少ない方のデモプログラムの方を詳しく読み込む。

　プラットホームのMega1284は、手持ちがないので、Mega168に移植する。とりあえず動くことを確認するだけだ。電波時計の方が、ChaNさんのFatFSを使っているので（SPIを使う）、デモプログラムの方もLCDを動かすSPIはUSARTのMSPIだ。Mega168は、UARTがひとつしかないので、これを元のSPIに設定し直す。

　UARTの設定もMega168用に変更する。移植は順調に終わった。コンパイルする。山ほどコンパイルエラーが出る。まあ、こういうのには慣れている。Mega1284とMega168の変数が随分違う。定義しただけで使っていないタイマーや、ADCのところを片っ端からコメントにしてエラーを減らしていく（デモプログラムには不要な変数が多い）。

　最後に残ったのが、フラッシュにある文字列の長さを返す関数strlen_P(format)が未定義というエラーである。ふーむ、これは<avr/pgmspace.h>の標準関数で、何か以前ウェブのどこかで、この関数は見た記憶がある。

　Googleに「strlen_P　AVR」で検索してみた。何と、そら。さんとshuji009さんというおなじみの人が、この関数で議論している掲示板を見つけた。そうか、WinAVRのバージョンか何かで、この関数が未定義になることがあるようだ。shuji009さんの解決が一番スマートだ。要するに使わなければ良いのだ。こちらもそっくり真似をさせてもらって、文字列の最終端をチェックするロジックに換える。

　コンパイルは通った。ブレッドボードの一部には、前からMega168用のISP結線は常駐しているので、ハードの実装はあっけなく終わる。5～6本のジャンパーでブレッドボードに差したLCDとの間をつなぐだけである。たいした量ではない。すぐ終わった。動かしてみる。LCDはバックライトがついたが、画面は白いままで全く音沙汰なし。このあたりで本日の根がつきた。明日へ持ち越す。

ロジアナまで動員してやっと画面が出たが、重大な問題に気づく(12/18/2012）
　動かない理由はいくつかあった。まず、SRAM使用が1KBを越えていて、SRAMが1KBしかないMega168では動かすことは無理なことがわかる。このプログラムはLCDの画面バッファーだけでSRAMを1KBも使うのである。

　こういうこともあろうかと328も用意してあった。早速、新しいMega328Pに換装し、フューズビットを書き換えてファームに焼く。と、まだ動かない。どうも片手間では動きそうにない。本格的なトラブルシューティングに入ることにする。

　まずオシロで見る。おお暴走している。UARTらしい。ふーむ、さっき直したところだ。文字列の最終端を見逃しているようだ。ああ、わかった。ここはSRAMのポインターではないのだ。フラッシュにある文字列アドレスを見るようにしなければいけない。

　暴走は止まった。しかし相変わらず画像は出ない。オッシロではもう無理なようだ。ロジアナを登場させる。SPIが動いていない。このあいだの鉄則を思い出す。人さまのソースをデバッグするときは「いじったところだけを集中的に調べよ」というものである。SPI、UARTを重点的にチェックする。

　あ、あ、あ、SPIのピンの入出力方向設定（DDRレジスター)を入力にしたままだ。AVRのこの汎用入出力ピン設定とピン特定の機能の設定との関係はいつも頭を悩ませる。ADCの入力を出力方向にして、入力インピーダンスが下がっているのに気づかず長いこと悩んだこともあった。　

  SPIのデータピンを出力方向にして、ロジアナには、やっとそれらしい波形が出た。しかし、LCDは相変わらず白いままである。うーん、こうなると、残るのはSPIのモードだけだ。SPIはデータ送信をクロックパルスの立ち上がり/立下りのどちらでするか、データを正論理/負論理にするかで、4つのモードがある。一番ポピュラーなモード0に設定していたが、どうもコメントを見ていると3のようだ。

　これを3にし（CPOL=1, CPHA=1)、コンパイルし直した。やった。モノクログラフィックLCDに文字が出た。やれやれお疲れさま。何とかモノクログラフィックが動いた。そら。さん、ありがとう。ディバイスが動いたので、今度はこのソースをSTM8Sに移植する工程に移れる。

　ところが、ソースコードを読んでいるうち重大な問題を発見した。ビットマップフォントのデータがオブジェクトファイルになっているのである。これは困った。STM8Sの開発環境はGNUではない。RaisonanceのCコンパイラーもmakeを使っているので、もしかしたら動くのかもしれないが、GNUで作ったオブジェクトファイルとの互換性は余り期待できない。

　あわててRaisonanceコンパイラーのマニュアルを調べだす。これがなかなか見つからない。やっとのことで探し出し(マニュアルはダウンロードファイル一式の中の/docディレクトリで発見）、詳しく読み込むが、内容は使い方が中心で、こういう構造的な話は出ていない。

　やっていることは非常に簡単で、テーブルの頭を外部参照変数として受け取れるようにするだけなのだが、リンカーのところは、プログラム開発でも一番の奥の院だ。GNUのフォーマットとRaisonanceのが等しい可能性は薄い。

STM8Sでフォントを出すには、EEPROMを外付けするか(12/20/2012)
　色々調べたが、結局、フォントデータを.oファイルで持ち込むことは諦めることとする。バイナリエディターで双方のオブジェクトファイルを検証したが、全くフォーマットが違う。objcopyに相当するオブジェクトツールはRaisonanceにはない。

　しかし、出来ないとなると猛然と何とかしてやろうと、こだわってしまうところがいつもの悪い癖である。AVRで開発すれば何でもないところを、STM8Sでどうやったら実現出来るか頭をひねる。

　ひとつのプログラム実行形式ファイルの中に入れようとするのが難しいのなら、外の記録装置（SDカード）などに入れてやれば良いのではないか。

　ただ、フォントのためだけにSDカードを実装するのは馬鹿げている。しかもSTM8SにはまだFatFSは移植されていない。この移植も少し食指が動くが、これを始めると収拾がつかなくなるので、この案の実現は諦める。

　となると、残るは、EEPROMなどの外付けである。幸い、EEPROMはSPI、IICどちらも手持ちがある。LatticeのFPGAのために買ったEEPROM（M25P40)などは、512KBもある。これだけあれば、日本語のフォントファイルもかなり大きいものが収容できる。

　EEPROMから読み込む関数を開発すれば、現在のソースコードもそれほど変更せずに使えそうだ。ふむふむ、これなら出来そうだぞ。ただ、問題はどうやってEEPROMにフォントデータを書き込むかである。

　がた老AVR研究所は前にも書いたように、なるべくPCでプログラム開発は行わないことを原則としている。だとすると、少々手間がかかるが、一旦、PCでSDカードに .oファイルの形でフォントデータを書き込み、SDカードが読めるマイコンにEEPROMを外付けしてここからデータを移す方法なら何とかなりそうだ。SDカードを読めるマイコンなら既に、STM32や、AVRで実現している。

　余裕があれば、キャッシュを設定して読み込み済みのフォントはそこから読むようにすれば高速化もできる。まあ、そこまで凝ることもないだろう。簡単ではないけれど道筋はついた。

UARTモニターにするのにまた一苦労(12/23/2012)
　そら。さんの、このGLCDのデモプログラムは、電波時計の方のソースコードを流用し表示部分だけに限定したもので、GLCDを初期化して、一気に画面いっぱいに文字を描画するだけのプログラムである。

　せっかく、ここまで来たのだから、STM32のグラフィック気圧計のとき果せなかった、グラフィック画面でのUARTモニターをついでに実現してみようと、少し欲張ってみることにした。STM8Sでは、今のところフォントの実装を急には出来ないが、自由に文字が出力され、画面がスクロールしていくような仕掛けを自前で作っておくことは汎用性が高く、これから他の応用にも効く。

　とりあえずUARTの受信部を導入して、UARTモニタープログラムを作ることにする。いつもの定番のUART開発である。と、これが、うまく動かないのである。割り込み部を作るのだが、ここに処理がまわってこない。オシロでは間違いなくPCからリターンキーなどの信号が来ている。しかし受信割り込みが起きない。

　送信は問題なく、PCのコンソールにはWelcomeメッセージが出ているのだが、PCのキーボードを押しても何の反応もない。やれやれ、またロジアナの登場か、と準備をしかけたときである。コンパイルメッセージで、奇妙な警告を見つけた。

　main.c:298:1: warning: 'SIG_USART_RECV' appears to be a misspelled signal handler

　なにー、「ミススペルではないでしょうか」だとー？　エラーではなく警告だ。もう一回コンパイルすると、こいつはNO ERRORになる。この'SIG_USART_RECV'という割り込みルーチンのエントリーポイントは、昔のMega168のソースファイルから取ってきたものだ。

　もしかしたら、割り込みエントリーが違うのではないか。Mega328のエントリーを調べる。おおー、あたりだ。こいつは'USART_RX_vect'だ。何だ、何だ。エントリーポイントが違うのだ。だから、割り込みが起きても反応しないのだ。

　ここを直したら、全く何事もなく受信が出来た。いやいや、えらい道草を食ってしまった。それにしても、これが警告というのはおかしい。appear to be ～　みたいな遠慮がちのメッセージでなくはっきりエラーとして欲しい。何かやましいことでもあるのだろうか（と八つ当たり）。

GLCDの描画ロジックを研究する(12/29/2012)
　グラフィックな表示装置に、文字フォントを出していくソースコードはいくつかこれまでに見ている。この間のグラフィック気圧計のベースにした、ねむいさんのSTM32などの標準ソースにも、カラー液晶でグラフィックで日本語ファイル名を表示する、しゃれたファイラーがある。

　ねむいさんによれば、このソースは、ChaNさんのFDのソースコードをオリジナルにしているということで、大分前からこのオリジナルを探していた。そら。さんのソースも、これが原典になっているのではないかと思い、そのオリジナルが知りたくて、ここ数日一生懸命探し回っていた。

　その結果、やっと見つけたのだが、それは、なんと、FatFSのサンプルコード集（ffsample.zip)の中のLPC2388用のソースの中にひそんでいた。しかし、そら。さんのソースの原典は、これでもないようだ。いずれにしても、受信が順調に動くようになったので、ちょっと本格的なUARTモニターを、このGLCDで作るため、次のようなロードマップで開発することにした。

(1)スクロール
モニターなので、最低でも、出てきたデータが次々にスクロールしていく機能は欲しい。これが出来れば、PCに依存しないシステムが作れる（キーボードは、4方向スイッチなどで実装）。

(2)複数の大きさのフォント表示
大きさの違う文字を表示しながらスクロールさせるのは、ちょっと難しいが、スクロールできなくても、少なくとも表示だけは出来るようにしておきたい。

(3)あわよくば逆スクロール
一旦消えた文字列を、コマンド（上下キーなど）で画面上に戻す機能。これは文字バッファーを別途に持ち、かなり複雑な構造が要求され実装することはそう簡単ではない。ただ所長は、昔々MS-DOSでパソコン通信ソフトを自作した時、実装したことがあるのでノウハウはある。

　まあ、どれも急にできる機能ではない。少しづつやっていこう。とりあえずは、今動いているUARTモニターに何種類かコマンドを加えて、描画速度などを調べてみた。これが描画が結構早いのだ。一文字づつキャッシュに描いては、updateをかけて連続して出力するが、画面の管理が良く出来ているので、4行を一字づつ書き込むのだが、殆ど一瞬で全部の文字が表示される。

Raspbbery Piが到着してしまった(12/31/2012)
　そうこうするうちに、10月(10/29)に注文していたRaspbbery Pi（以降、RasPi)が遂に到着した(12/25到着)。注文した時は4週で来ると言っていたが、結局、予定の倍の2ヶ月を要したことになる。

　BeagleBoardのとき、「もう、このあたりの工作はしない」と宣言していた筈なのだが、ウェブを見ていると周辺でRasPiが次々に到着し、みなさん何か面白そうなことを始めている。RasPiの詳しいスペックを調べている間に、RasPiの余りの安さに負けて、つい発注してしまったものである。

　BeagleBoardは、安いといっても1万円以上したが、このRas Piは、何と￥3000以下($35)なのである。ケースや、HDMIケーブル、それに送料(￥840)をあわせても￥4500である（$=￥80換算）。もうあきれるしかない安さだ。

　RasPiのCPUはARM11で、クロック700Mhz　コア512MBである。BeagleBoard（ARM cortex-A8 720Mhz 256MB）とほぼ同じだが、ARMのグレードは、RasPiの方が上なので、スペック的に少し上だろう（オーバークロックも出来るようだ）。ペリフェラルもほぼ同じだが、RasPi（モデルB)は、LANが標準なので性能的に有利だし、部品も少なく出来る。

　BealeBoardのときは、宅配便だったが、今度のは郵便箱にいつのまにか納まっていた。この気楽さ。とるものもとりあえず持ち込んで、記念撮影する。ケースが良く出来ている。まだ何も用意していないので、ケースに入れて、ただ眺めて楽しむだけである。

　で、これを何に使うのかである。ウェブカメラが安かった(￥1500)ので買ってある。USBのビデオクラスを使っているのでLinuxでも動くはずだ。これを使って、いよいよ念願のリモートカメラを実現しようと考えている。モーター制御を入れて、パンやズームも試してみたい。