« 2013年3月 | トップページ | 2013年5月 »

2013年4月の2件の記事

2013年4月26日 (金)

STM8Sでグラフィック液晶に漢字をスクロール表示する

ハングアップするSTM32F107の気圧計を修理する(4/13/2013)
 STM8Sでグラフィック液晶に日本語フォントを表示するプロジェクトは一段落したが、実は前から気になっていることがある。一年ほど前、O-Familyさんの掲示板で知ったのがきっかけで作ったグラフィック気圧計がまともに動かなくなってしまった。

 この気圧計のMPUはSTM32F107で気圧センサーは秋月のMPL115A2、Aitendoの2.4インチのカラーTFT液晶(YHY024006A)に2日間の気圧の変化をグラフィックに表示する。気圧データは、毎秒測定した気圧を1分ごとに平均化し、10分に一回、I2CのEEPROMに蓄積する。

 RTC(リアルタイマークロック)を内蔵しているので、実際の年月日を表示したグラフ枠に直近の2日間の気圧遷移が折れ線グラフで表示される。予報ロジックの組み込みや、ケースに実装する工程が残っているが、とりあえずここ数日の気圧の変化が一目で確認できるので、このままで結構重宝していた。

 当初この基板にはソケットの接触不良があって、長時間稼動させると(2~3日以上)、止まってしまう持病があったのだが、直接ピンとピンの間を別配線してしまうことなどで、トラブルは解消していた。ところが、最近になってまた止まるようになった。しかも動いている期間がどんどん短くなり、このところは数時間が限度である。これでは実用にならない。

 止まる要因で疑われるのは、TFT液晶の描画と、気圧センサーMPL115とフラッシュROMの読み書きに使っているI2Cインターフェースである。最初、液晶の描画ルーチンを疑っていたが、詳細にコードを調べて、このプロセスでは、少なくともMPU側にはループする要素が見当たらないことがわかった。

S_p4255844  とすると、残るはI2Cである。このI2Cのドライバーは、例の弁護士さんの書いた「STM32マイコン徹底入門」でも紹介されたSTマイクロの標準I2Cライブラリーを殆どそのまま使っている。久しぶりにEclipseを立ち上げて、ソースを見る。

 他のウェブや、この本にも書かれているとおり、このライブラリの信頼性は余り高くない。しかし、これに換わる適当なコードはないので、とりあえず仔細にソースコードをチェックする。何だ、何だ、ソースコードには、たくさんwhileでイベントが終わるのを待っているところがある。4箇所もある。しかも無限ループだ。これでは沢山のところでハングアップする可能性がある。

無限ループをやめて、エラーexitをつけたのに止まらなくなった(4/14/2013)
 回数を数えて、一定の回数以降はそのループを抜けるようにソースを書き換えた。ところが、MPL115が正しい値を返さないようになって測定値が乱れる。うーむ、1000回程度ではだめなのか。
クロックを計算してみたら数十μsだ。こりゃいかん。MPL115はまだ測定を終えていない。

 60000回以上(1ms近辺)でループを抜けるようにして、様子を見る。これが不思議なことに、何時間経っても、エラーexitもせず、しかも全く止まらなくなってしまった。2日間でも止まらない。???である。

 要するに少しソースに手を入れただけでタイムアウトもせず(エラーメッセージも出ず)、無限ループにも入らず直ってしまったのである。逆に、UARTの切断/接続でハングする。えー、UARTルーチンにイベントを待つプロセスなどはないぞ。これも謎である。暫く様子を見ることにする。

 それにしても最近の物忘れの程度は度を越えていて、自分でも笑ってしまうほどだ。STM32の開発手順を見事に忘れている。この気圧計の開発を盛んにやっていたのは、わずか1年前である。それが統合環境のEclipseでのソースのコンパイルはともかく、ファーム書き込みの具体的な手順が思い出せない。

 さすがに、どういうツールを使うか(中華製のシリアルローダーMCUISPを愛用している。他のプログラマーの出番なし)くらいは覚えているが、どういう手順でプログラムをロードするのかブートモードが0だったか1だったかも忘れている。見事なものだ。

 エラーが起きないので、これ以上のデバッグは出来ない。デバッグというより、I2Cがエラーで帰ってきたときにどうするかを考えておく方が合理的かもしれない。測定は毎秒やっているのでひとつくらい読めなくても大きな差は出ない。EEPROMの書き込みでも2日間のグラフなので、1回や2回データが欠けても大勢には影響がない。

ハードウェアのスクロールは難しい(4/15/2013)
  気圧計のエラー発生待ちで手が空いたので、いよいよSTM8Sの最後の課題、ハードのDisplay Startコマンドを使った漢字のスムーズスクロールを実装する作業に入った。

 問題は、縦64ラインある画面に12X12ドットの漢字を表示し、これをなるべく乱れなくスクロールしていくことである。これまでの検討では漢字フォントを分割して(画面の最下部と最上部に分けて)描画できればスムーズスクロールが出来るはずである。

S_p3285780  つまり、縦(Y軸)0ラインから、12ドットの漢字を5行表示し、余白になっている画面の60ラインから一字の4 ドット分描画し、画面の0ラインに戻って残りの8ドット分を描画する。さらに4ラインの空白を表示し、ここにハードウエアの描画開始アドレスを移動すれば、全体の漢字の位置は全くずれずに、1行分スクロールされることになる。

 このやりかたは、漢字描画の縦の物理スタートポイントが、決まった位置になく少しづつずれて行き(次の行の開始アドレスは12ではなく8。16回廻って一周)、スクロールのスタートアドレスも、それに合わせてずれるので、コーディングには細心の注意が必要だが、今のところ、この方法以上のやり方は見当たらない。複雑だがこれを実装することにする。

 まず、必要なのはフォントの分割表示のための、グラフィックライブラリの中の日本語フォント関数LcdChr_Kanji())への機能追加だ。これまでは画面の最下部にかかる文字の描画は、エラーリターンしていたのを、折り返して最上部に残りのフォントを描画するようにロジックを追加する。

 この改良は、相当厄介だろうと覚悟していたのだが、思いのほか追加するステップが少なく、簡単に完成した。Y方向(縦)のドットのアドレスを画面の最大幅になったときに0に戻すだけである。こんなにうまくいったのは、最初のプログラムの構造が良かったからだと自画自賛する(動いてから自慢するべきだろう)。

 実際にスクロールを制御するところは、ライブラリではなくmain.cの中である。SRAMが残り少なくなっているので、変数を増やすのは気を遣う。手持ちの変数を使いまわして、描画のスタートポイント、スクロール開始位置のシフトを考える。

 やっぱり一筋縄では動かない。擬似コードを何度もやりなおす。なんとかコーディングを終了した。いよいよテストである。苦労が多いほどこの瞬間はわくわくする。最初は連続ではなく、スペースバーを押すたびに、一字づつ表示するようにする。

 順調に画面の最上部から、漢字が出てくる。スクロールしないときの表示は順調だ。まあ、ここは前と変わっていないので表示されて当たり前なのだが、ついに画面の最後まできて、スクロールするところに来た。

 思い切って先へ進む。おお、画面全体が上に上がった。しかし文字は、表示されない。消し残しのようなラインが出るだけである。さらにキーを押して次の文字を出す。おっ、今度は文字が出た。コードを確かめる。出るべき正しい文字だ。スクロールした最初の文字だけが出ないが、分割したフォントは正しく文字になっている。良かった、この部分はうまく行っているようだ。

 さらに文字を出していく。何とかスクロールが動いているようだが、周辺にはゴミが出るし、行換えした直後の文字が出てこない。一字づつを止めて連続表示をしてみると、文字が乱れたりループしたりして不安定だ。しかし、とりあえずスクロールはしている。とはいえ完成にはまだ程遠い。

すこしづつスクロールが出来てくるが連続はまだ無理(4/16/2013)
 最初の文字が出ないのは、画面の更新をするときの領域の設定ミスとわかった。描画領域の定義は、仮想の描画スタートアドレスではなく、物理的なVRAMの範囲なので、分割して表示する時は結局、全部を描画領域にするしかない。

 これを直して、スクロール直後の文字もめでたく画面に表示された。しかし、スクロールの幅がおかしい。思ったように下の余白が止まっていない。表示が4ドット分上がったり下がったりするので、連続して表示するととてもスムーズなスクロールにはならない。それに画面にゴミが残って、それがスクロールに合わせて動く。

メモに図を描いては、画面の動きを確かめ、UARTにドットアドレスを表示したり、デバッグを進める。スクロールの幅は常に12ドット(文字フォントの幅)で良いはずだ。それなのに何故、4ドットの余白が移動するのだ。そのうち思い違いをしているのを発見した。

 ハードスクロールのスタートアドレスを新しく表示する文字のスタートアドレスに合わせている。ああ、これでは駄目だ。スクロールの開始アドレスは、0ラインから12ラインづつ動かしていけば良いのだ。このままでは空白は最上部に行ってしまう。まさしくプログラムは書いたようにしか動かない。

  面のゴミは原因不明だ。スクロールのあと、表示するまえに1行分全体を消去しているのだが、このあたりは並木算の世界である。0オリジンか1オリジンか、最後の部分は含むのか、含まないのか。画面の途中ならそう難しくはないが、折り返すところがどうしても計算が合わない。

ライン0を表示しないのは元の関数の仕様だった(4/17/2013)
 ゴミが出るのは、折り返しのところだけなのは間違いない。しかし、消去する幅や、起点を調整しても、ゴミがとれない。どうも今開発しているプログラムに誤りはなさそうだ。となると下部関数に何か不具合があるのではないかという疑いが出てきた。

 そら。さんから頂いたこのグラフィック液晶(GLCD)ライブラリのオリジナルは、外国でNOKIAの液晶用に開発されたようだ。グラフィックの部分は、このGLCDではコメントアウトされて使われていなかった。こちらが勝手にコメントをはずして動かしているので、このGLCDで動く保証はない。

 グラフィック関数は階層構造になっていて、新規に開発した特定の行を消去する関数、LcdFill()は、LcdLine()で直線を引き、LcdLine()はLcdPixel()という1ドットを描画する関数を使っている。

 LcdLine()から見ていく。特におかしいところはない。次は、LcdPixel()を調べる。あ、あ、あ、画面の0アドレス(Y軸)は何も処理せず帰っている。何だ、何だ。0ラインにはドットが描けないのか。スクロールは0ラインにもドットが描けなければ正しい字にならないのに。

 不具合でも何でもない。元からこういう仕様だったのだ。やれやれ大山鳴動鼠一匹である。もっと早くここを確認すべきだったのだ。0ラインも描画するようにして今まで汚かった画面は一掃された。漢字フォントだけが綺麗に表示される。一字づつ表示していくだけでは問題なく漢字が表示されて行く。よーし、大分進んだ。

 しかし、連続するとまだ途中でループしたり、画面の位置が変わったりする。まだ何かがおかしい。トラブルシューティングは終わらない。

連続してスクロールが出来ないのも大きな勘違いだった(4/19/2013)
  連続スクロールは、入力されたシフトJISの漢字コードに1バイトづつ足し上げ、漢字コードのときのみ(LcdChr_Kanji()は有効な漢字コードでないときはエラーで帰る)画面上に漢字を出すようになっている。

 待ち時間を入れないで連続表示させると、表示が速すぎて、画面全体が白くなり、字そのものが殆ど読めなくなってスクロールの意味がなくなるので、一字あたりに30ms程度の待ちを入れて表示する。

 ところが、連続しているうちにスクロールの位置が変わったり、ある時点でループに入ってしまう。 一字づつでは問題なく、連続してエラーが出るのは、ハードが疑われる。表示位置を変更するコマンドの前後に待ち時間を入れたり、表示そのものの関数にも待ちを入れたり、時間調整してみるが全く改善されない。

 GLCDのSPIインターフェースが早すぎてデータをとりこぼしているのかもしれない。現在のSPIクロックは、2MHzである。データシートを確かめてみる。何とこのGLCDは20MHzくらいまでサポートしており全く問題ない。

 そのうち一字づつ表示を続けているうち、全く同じところで表示が乱れることがわかった。うはあ、これはハードではない。ソフトだ。非漢字領域をスキップしているところで、どうもエラーが起きているようだ。

 漢字コードでないときのエラー処理がおかしい。念入りに調べる。あっあっあー、わかった。非漢字コードのときは、文字をずらすところをスキップしているのだが、肝腎のスクロール処理がこのループからはずれているではないか。これではたまたま表示が左端で非漢字コードが来た時、無意味なスクロールをしてしまう。

 何というお馬鹿なコードだ。非漢字領域のコードの描画が画面左端から始まるときのみ、おかしくなるので発生がランダムに見え、ハードを疑っていたが、何のことはない、単純なソフトのバグだった。今まで疑っていたGLCDさん大変失礼いたしました。悪いのは全部私です。

この解決で、グラフィック画面は、延々と漢字を表示し続ける。いやあ、良かった。良かった。これで動画が公開できる。この画面では、漢字一字に30msの待ちを入れて表示している(スクロールは待ちなし)。これより少ないと、表示が速すぎて液晶の残像で満足に字が見えなくなる。

これでSTM8SとGLCDの当面のテーマはすべて完了した。この日本語表示を何に使うかが今後の課題である。音声合成チップとあわせてネットワークを経由したメッセージボードのようなことが出来ると面白いかもしれない。

ここに例によって上記のソース一式をSTVDのプロジェクトごとzipファイルにしたものを置きます。STM8のライブラリはこれまでどおり同梱されていません。以前の記事を参考に所定のディレクトリに設定してビルドしてください。容量の関係でフルビルドが必要です。

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

本格的なFETスイッチの実験(4/22/2013)
 このあいだ秋月から買ってきたMOSFET(FKV575)のスイッチの実験の続きである。ブレッドボードにCRとトランジスターの遅延回路を組み込んで、FETでLEDを1秒ほど遅らせて点灯する実験は成功した。しかし実際のスピーカー切り替え用の2つのFETを組み合わせた本格的なスイッチはまだ組んでいない。

S_p4235837  前回にも書いたように、2つのFETで構成されたスイッチの導通抵抗がどうも寄生ダイオードによってミリΩ台になっていないような気がする。ウェブを見ているとACのスイッチには、何と4つのFETでスイッチを構成しているものもあり、その回路図を探していたが見つからなかった。

 迷っていても仕方がない。現物があるのだから実際に試してみるのが手っ取り早いのではないか。まずは最初組んだFETひとつの回路に、オシロと秋月のファンクションジェネレーター(FG)で導通を調べてみることにした。

 FGの出力は、AC(±1V)なので、FETひとつなら、片側が半波整流のような波形になるはずである。ところが、これがおかしなことに、ACが完全に通るのである。所長のFETの知識は、トランジスターのアナロジーで、ドレイン(コレクタ)からソース(エミッタ)に流れる(N型のとき)電流をゲートが制御し、ソースからドレインには電流がそもそも流れないというものである。

 寄生ダイオードは、この逆電位のときに流れるもので(これはトランジスターにはない)、スイッチに使うときは、これが効かないよう、FETを背中合わせにするのだと思っていた。

 ところが、前回の記事に、久しぶりにkugaさんからコメントがあり、自分が勘違いしていることがわかった。FETはゲート電位が上がって導通状態になれば、たとえドレインがソースより電位が低くなっても(NMOSのとき)、寄生ダイオード以外のところでも電流が流れると言うのだ。

S_p4235830  どうも勘違いをしていたらしい。それなら本番用を実験してみよう。ブレッドボード上に背中合わせにFETをつけた回路を組む。たいした手間ではない。FGの出力を、このスイッチを通してオシロにつなぐ。導通は?うむ、全く問題ない。では、ゲートの電圧を0にする。ありゃあ、切れてないぞ。矩形波はサグの出る波形に、正弦波は殆ど減衰せずにそのまま出ている。

負荷抵抗を入れると切れた。うーむアナログは難しい(4/23/2013)

Fet  えー、どうして切れないのだ。良くわからない。ウェブで同じような実験をされているページの回路図を確認した。あ、そうか。負荷抵抗がいるのだ。微小電流ではFETは遮断できないらしい。

今ひとつ理屈はわからないが、本来はスピーカーという数Ωの負荷を切るスイッチである。この状態で調べるべきだろう。しかし、現在のFGは、内部抵抗が高く、とても数Ωの負荷抵抗をドライブすることは出来ない(出力は0になってしまう)。

S_p4235838  とりあえずFGが何とか出力を出す(0.5V)くらいの負荷抵抗、300Ωを入れてスイッチを調べてみた。よし、わずか脈流は残るが、出力は殆ど0になった。スイッチは機能したようだ。しかし、正弦波は切れたが、矩形波は立ち上がり(下がり)に鋭いパルスが残る。

 これは結局、実際の音で確かめるしかないか。使用を予定しているメインアンプの切り替えは少しおおごとなので、手元にあるカマデンデジタルアンプで試してみることにした。スピーカー端子は幸いこのあいだワンタッチの端子板に換えてあるので接続は簡単だ。

S_p4235826  これはFETが持つ内部寄生容量で一瞬導通するからではないかと思うが、これを解説しているところは見つけられない。この症状は0.01μFくらいのコンデンサーを負荷に並列に入れるとパルスはおさまり、何とかスイッチの役目を果したようだ。

 ブレッドボードからジャンパーを出し、念のためオシロもつないで片チャンネルだけスイッチをつける。問題なく入り切りができた。全くの無音になる。音は変化したか。この程度のスピーカーやアンプで、これを判別するのは無理と言うものだろう。

S_p4235824

 ウエブでも、機械リレー方式との音の違いを追及している人がいるが、まあスペックを信用するしかない。矩形波の残留パルスはMhzの世界で、少なくとも可聴周波数域での違いは全くないと言ってよいのではないか。

 ウェブをさまよった挙句、4つのFETを使ってスイッチする理由がわかったような気がする。FETのオン抵抗(Rds)が入力電圧(ゲートソース電圧)によって大きく違うので、レールツーレールにするため、P型とN型を並列にして特性を相殺しているためではないかと思われる。   http://www.analog.com/jp/content/cu_ad4505jp/fca.html
まあ、ここまで心配ならリレーを使えば良いと思うけれど。

 実験はそろそろ良いだろう。これを実装する工程が待っている。いずれにしても、スピーカーのミュートスイッチは、一般のFETのスイッチング特性とは全く別の世界(スイッチング周波数は全く無関係)なので参考になるウェブサイトは意外に少ない。以下は、スピーカーのFETスイッチに関して参考になったサイトのURLである。ご参考まで(勝手リンクご容赦)。

そもそもフォトボル型カプラーを知ってFETスイッチを作ろうとしたきっかけのサイト。
http://easyaudiokit.hobby-web.net/bekkan/MOSFETrelay/MOSFETRELAY.html

スピーカーのミュートをリレーからFETにしたときの考察。切れていたら()内のホームから。
http://members2.jcom.home.ne.jp/2060bl/21review/18ftrly/01vrfctn/vrfctn1.html
http://members.jcom.home.ne.jp/4120blaudio/index.html

マルツのFETスイッチの基礎的な解説。FETの一覧表もある。わかりやすい。
http://www.marutsu.co.jp/user/fet_3.php#mos-fet3

| | コメント (2) | トラックバック (0)

2013年4月14日 (日)

STM8Sとモノクログラフィック液晶を基板に実装する

 今年の正月以来取り組んできたSTM8Sでの日本語フォント表示に、やっとのことで成功し、重い荷を肩から下ろしたときのように、暫く力が抜けて前へ進む気力を失った。記念すべきブログ200本めの記事なのだが、焦点が定まらない。

 当初、このSTM8Sとモノクログラフィック液晶(GLCD)の組み合わせは、電波時計のプラットホームにするつもりだった。しかし、これだけ日本語フォントの表示に苦労したのに、時計は日本語テキストを殆ど使わないというのは、いかにも勿体ない気がする。

 ハードウエアも、まだバラックである。GLCD(JCG12864A37)のインタフェースはブレッドボードで動くように自作のピンソケットをつけたものの、STM8S-Discoveryとの接続は基板のソケットからのジャンパーコードを差しただけで移動することもままならない。

S_p3265778_200top バラックで実験していたのは、電波時計でない他の適当なアプリケーションが見つからなかったためである。しかし、だからといって簡単にばらしてしまうのは、これだけ長い間付き合ったセットに何か薄情のような気もする。使うあてがないにしても、少しはまともな形でSTM8SとGLCDを動く形に残しておくことにした。

秋月の新商品パワーFET(FKV757)を買ってきた(4/1/2013)
 実装するとは決めたが急に方針が決まるわけでもない。手を動かしていないと落ち着かない性分になっている。手は勝手に、このあいだのMOS-FETスイッチ制作の続きに移った。

 念願のサトー電気からフォトボル型カプラー(TLP590B)は手に入れたが、スイッチに使えるようなパワーFETの手持ちがない。部品箱を漁っていたら、2年前のガイガーカウンターづくりのときに秋月で買った高圧用のFET、FQPF3N90(900V 2A)が出てきた。S_p4135804 GM管(SBM-20)やパルストランスなど自作のための高圧パーツはあのとき全部揃えたのだが、あれからガイガーカウンター制作熱はすっかり下がったままである。

 このFETはデータシートを見るとオン抵抗は数オーム近くありスイッチ用には適さない。それでもフォトカプラーを試したくて、ブレッドボードに組んでみた。導通テストは普通のマルチテスターの導通モードで確かめる。ブレッドボードなので組むのに10分もかからない。

 単三を3つ並べた4.5Vを入力側に入れてテストする。おお、無限大を差していた抵抗値が、一気に0Ω近くに下がる。LEDのON/OFFも問題ない。調子に乗って、1.5Vのモーターの入り切りをやってみる。これはさすがに動かなかった。

 やはりオン抵抗の低いFETが欲しい。ウェブ上で色々物色していたら、おあつらえのように秋月電子からサンケン電気のMOS-FET、FKV575が新商品として売り出された。DS間の最大電圧と電流が60V 75Aで導通時のDS間の抵抗が何と8mオーム、しかも値段が¥120と安い。久しぶりに仕事の帰り、秋月に寄った。

 新商品なので、陳列棚には出ていなかった。今日は月曜日。秋月は、月、木はバーコードのついた商品しか売らないということでカウンターのウインドウケースには白いシーツがかかっている。でも、店員に商品名を言えば出してくれることがある。まあ、急ぐものではないが折角ここまで来たのだがらと、だめもとで店員に聞いてみた。

 最初、ないようなことを言っていたが、事情通の別の店員が、奥からリールに入った現物を出してくれ無事手に入れることが出来た。とりあえず4つ買う。帰って夕食もそこそこにわくわくしながらテストに入る。実に安上がりな娯楽だ。

S_p4135810 例のフォトボル型カプラー(TLP590B)をゲートにつないでまずテスターで導通テスト。おお、このあいだのFETは数オームだったが、今度は測定限度の0オーム。1.5ボルトのモーターは快調に廻る。

MOSFETのスイッチ回路と遅延回路(4/5/2013)
 MOSFETスイッチの目的は、オーディオアンプとスピーカーの間に入れて電源投入時のポップノイズを避ける遅延スイッチである。フォトカプラーやFETの部品は揃ったが、回路をどうするかが悩ましい。スピーカーに流れる電流は交流なので、単純なスイッチでは動かない。

 ウェブなどを見ていると、オーディオ製品のこうしたソフトスイッチは、結構おおがかりで、回路がどうなっているかわからないがFETを4つも使って一回路を切ったりしている製品もある。

 こちらは、そんな大げさにするつもりはない。フォトボル型カプラーのおかげでFETをドライブする部分は非常に簡単になったのだが、スピーカーの接続を遅らせる遅延回路と、実際のスピーカー回路に入れるFETの組み合わせになかなか良い回路例が見当たらない。

 FETを対称に並べるスイッチは、片側のFETは寄生ダイオードを利用して導通している。寄生ダイオード(ボディダイオード)の順電圧降下はデータシートによれば、1V以上で、折角、片側がミリオーム台でも、トータルとしては結構な損失になる。

 仮に100Wの最大電力がスピーカー負荷(8Ω)にかかったときの電流は、3.5Aで、このときの損失は順電圧降下が1Vとすると3.5W、ヒートシンクが必要になるレベルになってしまう。

 片側をボディダイオードで導通させない回路を探しているが見つからない。FETを4つ使ったスイッチは恐らく、ボディダイオードを使わない方式だとは思うけれど、どうして実現するのかあれこれメモに書いては見るがうまくいかない。ここも奥が深い。S_p4135805

 遅延回路の方は、最初からCR時定数で組むつもりをしていたが、フォトカプラーの入力電流をCRで遅延させるのは、大容量のコンデンサーが必要で何か資源の無駄のような気がする。トランジスタをかませばもっと簡単になることに気が付いた。電流の少ないベース側にCRを入れコレクター負荷でフォトカプラーをドライブする。

 早速、ブレッドボードに組み込む。定番の2SC1815でベースに4KΩ、220μFの遅延回路を入れて0.8秒程度の遅延時間が得られた。こういう、ちまちました実験も楽しい。

STM8Sとモノクログラフィック液晶を実装する(4/7/2013)
 FETスイッチはさておき、そろそろ本来のプロジェクトに戻ろう。これまでブレッドボードにジャンパーでつながれていたSTM8S-Discovery基板とAitendoのGLCD(JCG12864A37)を基板に固定する工作を始めた。

 まだ何に使うか決まっていない。とりあえずは、STM8S-DiscoveryのST-LINKの部分も切り取らず、秋月の両面C基板の上下に液晶とCPU基板をソケットでつけることにする。STM8S-DiscoveryのCPU周りには、2X6のピンヘッダーが4つ出ており、C基板には、それぞれそれに見合うソケットをつけて固定する。

S_p4135822 GLCDは四隅のビス穴とスペーサーで固定する。インターフェースケーブルにはブレッドボード用のmilピッチのピンをつけてあるので、これを基板にハンダ付けしてしまう。抜き差しは、前々回に紹介したリード線のソケットで出来る(あまりやりたくないが)。忘れずにSPIの逆流防止のSBD(ショットキーダイオード)の1S4もつける。

 UARTは例によって、3ピンソケットでUART線をUSBアダプターにつなぎ、アダプターは共用する。久しぶりのハンダ付けが楽しい。目的がはっきりしているときの作業は捗る。テニスから帰って風呂に入ったあと、少し根を詰めて作業に熱中し、終わった時はさすがに腰が痛くなっていた。

 チェックもそこそこに通電した。よっしゃー、全く誤配線なしでWelcome画面が出た。苦労したあとの成功も嬉しいが、こういう一発で動くというのも爽快なものだ。ただ、これを何に使うかということが決まっていないと言うのがつらいところである。S_p4135820

SPIの不具合再発とその解決(4/9/2013)
  ところが一発で動いた後、思わぬトラブルに巻き込まれた。このあいだのフラッシュメモリの読み出しエラーが再発したのである。ブレッドボードではSBDをGLCDとフラッシュメモリの間にはさんで直ったのだが、今度はSBDが入っていても直結のときと同じようなエラーがでる。

 エラーの状況は、どこかで、SPIのクロックの1ビット程度が抜け(または余分に入る)、それ以降がすべて狂う。フォントデータだと少しずれるだけで済むが、漢字だとフォントデータに辿りつくデータブロックアドレスが目茶目茶になるので全く字にならないゴミが表示される。これでは使い物にならない。

 配線が長くなったからなのだろうか。どこかと干渉しているのだろうか。UEW線で結線した配線の長さが特に大きくなったわけでもない。ブレッドボードよりハンダ付けなので明らかに抵抗値は下がっているはずだ。

 ダイオードをとりかえてみても駄目。配線の位置を変えても駄目。オシロで波形を見る。確かに、GLCDのSPIのクロック線は、フラッシュを読みに行く時にわずかな波形が出ている。このSPIのクロックは、CPUクロックの1/2の8Mhzである。トランジスターや、普通のフォトカプラーでは高速すぎて分離できない。

 ここで、サトー電気で高速フォトカプラーTLP552を買ってあったのを思い出した。おお、先見の明があった。買ってきたのが無駄にならなかったぞ。早速使ってみた。しかし、こいつは10mA以上を入力側に流す必要があり、つないだだけでSPIそのものが動かなくなった。まあ、考えてみたらこんなことに¥200以上する高速フォトカプラーを使うのは明らかに資源の無駄遣いだ。

S_p4105801 それにしても、何故ブレッドボードで動いて、実装するとおかしくなるのだろう。何が悪さをしているのかわからない。こんな些細なことでも上手く行かないと言うのは、不愉快なものである。SPIを複数ディバイスで共用するときのノウハウをウェブで探すが、そういう話はどこにもない。

 そのうち、Vccの違いを吸収するレベルシフターICを使えば、ハード的な干渉を避けられるような気がしてきた。いわゆるバスバッファーICというやつである。こういうICは出力側をHiZ(ハイインピーダンス)にして完全に接続を切ることもできる。

 バスバッファーのICならFPGAのドングルを作ったときの予備のTC74VHC244がピッチ変換基板に取り付けたまま残っている。ブレッドボードにつけて、ジャンパーピンを実装面に無理やりハンダ付けし、空中配線でテストしてみた。

ビンゴ!であった。フラッシュメモリは全くエラーなく読み出せるようになった。今のプログラムのUARTはテスト用に、日本語フォントのフォントブロックテーブルをコンソールに表示するコマンドがあるのだが('q')、これがいくら繰り返しても、全く同じデータを表示する。

Kanjicodeblock ANK文字表示('d')も、今までは、どこかしら字が欠けていたのだが、全く変わらない。いやいや嬉しい。今までの鬱陶しい気分がすかっと抜けて気分は日本晴れだ。達成感で体が軽い。はい、完全に中毒にかかっていますな。

 バスバッファーで問題は解決した。しかし、8チャンネルもある3ステートバスバッファーを使うまでもない話だ。世の中には、1チャンネルだけのバスバッファー(74LVC1G125GW)もあるようだが(Digiで¥15)、これだけ買うわけにもいかない(共立電子の通販でも発見。2ヶ¥60)。

 実際の実装には、昔々、電子工作を始めて最初にChaNさんのシリアルプログラマーを作ったときの予備、74HC126を使うことにする。この石は4回路をチャンネルごとにHiZ(ハイインピーダンス)に出来る。特にHiZにする必要はなさそうだ。enableのままで問題なく動いた。

 1回路しか使っていないけれど、16ピンDIPくらいならあっても邪魔にならない。基板にハンダ付けする。これでやっと実装版が完動した。

ZAZ(ザーズ)にはまる(4/10/2013)
 全く電子工作とは違う話題でちょっと失礼。珍しく感動したことがあって記録を残しておくことにする。この世界に詳しい人には旧聞に属すると思うが、NHK-BSの番組(再放送らしい)でパリのストリートミュージシャンから一気にフランスで大評判の歌手になったZAZという女性歌手(正式名 イザベル・ジュフロワ)を知った。

 所長は音楽と言えばクラシックしか聴かないのだが、これが、このあいだのポルトガルのファドと同じように、何故か心を引き込まれてしまったのである。ジャンルは、シャンソン、ジャズの範囲に入るのだろうか。

 声は美声ではない。むしろハスキーで、メジャーになって本式の伴奏がついたものより、ギターとベースだけのストリート時代の録音の方が訴える力が強い。伝説的なシャンソン歌手、エディットピアフの再来と言われている。日本にも1回来たようだ。

 歌詞(彼女は作詞作曲もする)は、放送の時は字幕がついていて、結構、歌詞でも引き込まれるのだが、不思議なことに全く理解できないフランス語だけのときでも気持ちが伝わってくる。ファドの時と同じだ。PCの前で例の雑誌付録のUSB-AUDIOからYouTubeの音をカマデンのデジタルアンプで再生する。

Zaz  良い時代になったものだ。CDを買ってこなくてもとりあえず自由に音楽が聴ける。ファドと違って気分が落ち込まないのが良い。音楽を聴きながら、このブログの原稿を書いたり、電子工作の資料を検索したりする。至福の時間である。

ハードウエアのスクロールを研究する(4/12/2013)
 大分前に、この液晶のコントローラーST7565のデータシートに画面をハード的にスクロールできるDisplay Start Command(0x40でlowerアドレスが位置アドレス)という命令があることを知り(データシートP26とP42)、いつかそのテストをしたいものだとブログに書いた。

 実は、前回発表したソースコードには既にこのコマンドを動かす機能が入っている。UARTモニターの「s」というコマンドがそれで、sn(nは1桁の数字)とやると、nドット分ずれて画面が表示されるようになっている。

 実装はコントローラーのコマンドたったのひとつで、VRAMのY軸(縦)1ドット単位に任意の場所を画面の最初に持って行くことが出来る。残りの画は巻絵のように上に折り返して表示される。ハードなので表示の切り替えは一瞬である。

 ただ、これを使って、12ドットの漢字をスクロールさせようとコードを入れてみたが、全くうまくいかなかった。液晶がFSTNで残像が大きく、100ms以上の待ちを入れないとちゃんと絵がでないということもあるが、うまくいかなかった理由はそれだけではない。

 このGLCDの縦のサイズは64ドットで、12ドットの漢字を5行表示すると、下に4ドットの余りが出来る。これを単純に12ドット単位にスクロールさせると、この4ドットの余白がずれて動くので、文字が無駄に動いてスクロールしたように見えなくなるのだ。

 理屈はわかったが、これをどうやって解消してスムーズなスクロールに出来るかうまい方法が見つからない。画面下の4ドットの余白を残しながら、画面60ドット分だけをスクロールさせるのは、簡単なロジックでは実現できない。

 ということで、スクロール機能は放ってあったが、実装が一段落したので、これも何とか実現させてみようと取り組んでみた。少し考えれば出来るだろうと思っていたのだが、これが思いのほか手強い。

S_p4135823 どうも、フォントを画面の下段から上段にかけて分離して描画しないと、余白をなくすことは出来なさそうだ。そうなると相当基本的な部分まで手を入れないとスムーズなスクロールは出来ない。しかし、問題が難しいとわかると、余計燃え上がるのが性分である。

 ブログの原稿を書きながら、ロジックに頭をひねる。擬似コーディング以前に考え方を整理しておく必要がある。メモに図を描きながら、何度も発想を換えて一番合理的な方法を研究する。

 その結果、やはり当初のやりかた通り、文字フォントの描画、画面の領域(レクタングル)のクリアなどの関数を、Y軸についてシームレス(最大幅まで来たら折り返して0に戻る)に動くようにすれば、画面のスクロールの部分は単純な演算だけ(フォントを書き出すVRAMアドレスは16回も変わって元へ戻るが)で、表示できることを擬似コーディングで確かめた。

 実装はこれからで、文字フォント描画関数がはたしてシームレスに動くように改装できるか確認できないが、とりあえず何とか動きそうな感じである。ささやかだがこういうときも達成感がある。本当は動いてから報告するべきだが、ちょっと時間がかかりそうなので、このあたりでブログに上げることにする。動いたかどうかは次記事をお楽しみに。

| | コメント (8) | トラックバック (0)

« 2013年3月 | トップページ | 2013年5月 »