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でも動くはずだ。これを使って、いよいよ念願のリモートカメラを実現しようと考えている。モーター制御を入れて、パンやズームも試してみたい。