STM32F107でTFT液晶基板が動くまで

　Aitendoの生STM32基板は、STM32F107VCT6を載せ、USBの仮想UARTモニターが動くところまで来た。このプロジェクトの最終目標は、この基板にTFT液晶をつけ、グラフィック気圧計を作ることだが、スランプから抜け出せていないので、どうも歩みがのろい。色んなところで道草を食いながらの電子工作である。

仮想UART端末のUSBストリームをロジアナでプローブする(2/7/2012)
  ダブルバッファーを採用してSTM32F107の仮想シリアル端末（VCOM)は、無事、大量のデータをPCに送ることに成功した。しかし実は気がかりなことが残っている。送信の最初に必ず1バイト無駄なデータを送ってしまっているのだ。

　一旦送信ストリームが始まれば送られないし、送っているデータは、0X00という無効（端末に表示されない）データなので表面上は見えない。シリアル端末で操作している限り問題は出てこないが、気分は良くない。1バイトだけとはいえ、ゴミはゴミである。成功したといえるレベルではない。

　何故、こうなったかというと、最初0バイトのデータを送ったところ、新しいUSBライブラリのエンドバッファー書き込み関数SIL_WRITE()が、割り込みルーチンの中では終了割り込みが入るのに、ユーザー側で0バイトを書くと終了割り込みが起きないのである。

　このままだと永遠に送信が開始されない。それで仕方なく、1バイトのNULLデータを送って割り込みを開始するようにした。何とか大量のデータ送出は問題なくなったが、前の記事をアップした後も、これが気になっていろいろと考えていた。

　しかし、ダミーデータを送らなくても送信を開始できるロジックは、考え出してみると、何故、これに気がつかなかったのかと思うくらい簡単なロジックになった。やりかたは簡単で、最初の送信要求１バイトは、バッファーに書かず、直接SIL_WRITE()でエンドバッファーに書き込み、この終了を待って、次の送信要求をバッファーに書いていく。

　こうすれば、最初の1バイトを送ったあとの割り込みが割り込みルーチンに入り、バッファーに入っていたデータが送られていく。最初から有効データなのでゴミは送られない。このあとの送出は、バッファーに書き込まれるだけなので、データの送り込みと、SIL_WRITE()の書き込みは分離される。よし、これで良い筈だ。機嫌よくテストに入る。と、これが反対に頻繁にデータの欠落が起きるようになってしまった。おかしい。正しくデータが入るはずなのに何故だ。

　実は、この仮想端末には極くまれにしか起きないが、まだ不具合が残っている。SIL_WRITE()が少量データを書いたときに限って（リターンキイのみなど）、前のデータを一部重複して出力することがある。USBのハード割り込みがデータ処理時に入ってしまうからかもしれない。

　今度の改良は、この不具合に巻き込まれたのだろうか。ちょうど良い機会なので、トラブルシューティングのために、ロジアナで、実際にUSBにデータを送り出しているところまで徹底的に詳しく調べることにした。　

　ストロベリーリナックスで大枚4万をはたいて買ったロジアナである。200Mhzの分解能を持っている。プロトコルアナライザーにもそこそこ使える。しかし、現在のUSBの主流2.0はサポートしていない（USB1.1はサポートしているが）。

　何故だろうと、ウェブを探して事情が良くわかった。2.0のUSBを見るには、本格的には50万円以上する測定器が必要なのだ。2.0には480Mbpsのハイスピードモードがある。4万足らずのロジアナで見られるわけがない。それでも、中には10万クラスのアナライザーもあるようだが、いずれにしても業務用でアマチュアの手の出せる世界ではない。

　でも今使っているフルスピードクラスは12Mbpsなので、どんな信号か調べるだけならこのクラスのロジアナでも十分把握可能だ。リチウム電池の充電用に作ったUSBのAプラグ、Bプラグ、5Vアダプターコンセントの基板に、ピンソケットを追加して、USBの信号線を途中で取り出せるようにした。

　よーし、USBのデータも見えるようになった。USBがアイドルのときのほうがホストとのやりとりが頻繁で、一旦データ送信モードになるとパケット通信的にデータをひとまとめにして送っているのが良くわかる。

　SIL_WRITE()が少量のデータ送出で極くまれにデータを被って送出する時があるのは、USB本体の割り込みと重なっているからと考えていたが、USBへの送出はかなり時間がたってからであり、それが原因ではなさそうだ。それにしてもおかしい。データが欠落するのは最初だけではない。

　ロジアナでは中身のデータまで調べ切れない。LEDのプローブをあちこちかけて調べる。散々調べて、原因はやっぱりこっちの基本的ミスとわかる。修正のときにバッファーの順番を間違えてしまっていた。ユーザーが書き込んでいる最中のバッファーをエンドポイントバッファーに書き込めば、おかしくなるのは当然である。

　順番を換えて（というより元に戻して）、無事、前のような正確な送出に戻った。ホッと一安心である。これでみなさんに自信を持ってソースコードを使ってもらえる。

　以下にEclipseのプロジェクトとして入ったソースコード一式をzipファイルの形で置きます。前記事同様、libフォルダーが削除されていますので注意してください。前回のコードは破棄してください。

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

秋月の￥1000のステッピングモーターを試す(2/8/2012)
　プロジェクトが進まない時は、気分転換が一番である。秋葉原にもご無沙汰だったので、仕事の帰りに久しぶりに秋月電子に寄った。最近売り出したステッピングモーターを買うためである。

　秋月には、このところマイクロマウスなどに使えそうな適当なステッピングモーターがなかったが、最近、手頃な大きさのものが売り出された。価格も￥1000と安く種類も多い。

　マイクロマウスは、中級者まではステッピングモーターが良く使われるようで（上級者は強力なDCモーター）、前から欲しかったのだが、ウェブに紹介される定番のモーターはどれもひとつ￥5000近くし、ちょっと手が出しにくかった。マウスにするなら少なくとも2台はいるので一回の投資額は1万を超える。どこまで本気でやるか決めかねているときに、この額は大きすぎる。

　一個￥1000なら気楽だ。5Vのユニポーラにする（前の回路がそのまま使える）[ST-42BYG0506H]。テストのためだけなので1台だけである。これまでのFETドライバーに、いそいそとつける。ありゃあ、全く動かない。シャフトをさわると電源を入れるたびにピクピク動いているので配線間違いの可能性が高い。

　接続ケーブルの撚り導線の色は前のステッピングモーターと全く同じ色の組み合わせである（赤、黒、白、青、緑、黄）。これって組み合わせは同じだけれど結線は統一されてないの？　ああ、やっぱり。説明書を確かめると結線がこれまでのモーターとは全く違う。そうだよね。こんなものまで規格が統一されていると考える方が甘い。しかし、それなら色を合わせるなよと、かげで八つ当たりする。

　スペック通り、つなぎなおすと無事、勢い良く廻り始めた。逆転も停止も順調。42ミリ四方のステッピングモーターだ。一相あたり0.5Aだが、手で回転を止めようとすると220グラムのモーターが動くほど強力だ。回転は余り速くない。FETドライバーなので十分電圧は来ているはずだが。

　早くしようとタイミングを少なくしていくと、突然停止した。脱調ではない。うーむ、制御が難しそうだ。電源は2.3AのACアダプターで、動作時は、0.5Vほど下がった4.5Vになる。もっと強力な電源が必要なのだろうか。マイコンと電源を共有しているのがまずいのかもしれない。

　一時間以上、連続で回しても、モーターは、ほんのり暖かくなる程度で全く問題ない。FETの方は気がつかないくらいの温度上昇で、これも大丈夫。ACアダプターも熱は持たない。このトルクならギヤを使わず直結でマウスが動きそうだし、カーテンの開け閉めくらいなら楽勝だ。色々なところで使えそうである。

AitendoのTFT液晶を動かすことに取り組む(2/11/2012)
　やっと、TFT液晶を作りこむ意欲が戻ってきた。STM32基板と、TFT液晶モジュール基板を前に、あれこれレイアウトを検討する。ソースコードは、ねむいさんのコードを有難く頂戴してある。

　STM32などの32ビットプロセッサーに小さなTFT液晶をつけ、画像表示やファイラー（SDカードのファイル操作）にする工作は、このあたりのクラスの電子工作では定番で、ねむいさんを始め多くの先人が、既に成果をたくさんウェブ等で発表されている。

　こちらの工作のグラフィックの目的は、気圧の折れ線グラフを描くだけだが、今後（気圧計以外にも使うこと）を考慮して、TFT液晶とCPUの間は、16ビットインターフェースを選ぶ。AVRと違ってピンが多いので問題ない。これなら動画まで余裕のはずだ。記録装置は、気圧計ならSDカードまでは不要で、フラッシュROMくらいで十分だ。

　しかし、ねむいさんのソースは、SDカードのファイルシステムから、RTC(リアルタイマークロック）、タッチパネルセンサー、JPEG画像送出まで盛りだくさんの機能がついたソースである。英数字や漢字が画面上に出るのは嬉しいが、このソフトをいじらずに動かすためには、SDカードスロットや、RTC、タッチパネルなど沢山のハードを盛り込まねばならない。

　動いているソースコードから機能を外していくことは結構難しい。下手にソースをいじって動かないと頭を抱えるより、ソースをなるべくそのままにして、とりあえず動くことを狙う。カストマイズしていくのは動いた後やる方が、安心して改造できる。

　幸い、RTCはつけてあったので、SDカードをつけるだけで実現できそうだ。タッチパネルインターフェースはMakefileで分離できるようになっていたので未実装にした。フラッシュも200KBを越える。

　TFT液晶モジュールをどう実装するかは頭の痛い問題だった。考えた末、結局、みんながやるようなスタック構造にすることにした。意外とこれが最近の流行だったりする（例の雑誌付録のMARY基板あたりからか）。できあがった形は、LANインターフェースをつけないのにマザー基板（CPU),SDカード基板、TFTモジュールの3段スタックになってしまった。

　はじめにTFTのバックライト部分だけを配線。これは簡単に点灯した。おやあ、画面の右側に傷がついている。うーむ、安いだけのことはある。まあ、致命的な傷ではないので目をつぶろう。

TFT液晶が表示されない(2/15/2012)
　実装を続ける。高速をねらって16ビットバスにしたので配線量が多い。しかもピンヘッダー2つの間を表裏に配線するのは、とても間違いやすい。SDカード部、データバス上部8ビット、下部8ビット、TFT制御ライン、通算4日かかって全部の配線をやりおえた。最近は根が続かない。

　ファームは大分前にNO ERRORになっている。フラッシュは、最初ビルドした時は、240KB以上あって、107でも入るか冷や冷やしたのだが、タッチパネルの部分を外し、ねむいさんの助言に従ってTFTドライバーの初期化コードをILI9325だけに絞ったので、200KB近辺に納まった。

　中華シリアルローダーは快調に200KBを書き込んだ。こいつ時々こける（書き込めないと怒る時がある）が、リトライすると大抵、素直に正常終了する（本当に書いているか時々心配になるが）。

　いよいよ通電である。緊張の一瞬。祈る気持ちでUSBプラグを差す。TFTの画面が白くなる。パイロットのLEDが点灯。しかし、モニター端末からは何の反応もない。画面も白いままである。まあ、初めから動くとは考えていない。とりあえず電源を切って、あちこち触り、どこも熱を持っていないことを確かめる。

　モニター端末が動かないのは、見当がついている。AitendoのSTM32基板は、RS232Cインターフェースを持っており、標準のUART1とUART2を選べるようになっているが、オリジナルのねむいさんのソースは、UART2がリマップされているので、これが使えない。リマップした理由は、SDカードのSPIのSSピンと被るかららしいが、SSピンはSDカードのインターフェースでは使っていないので大丈夫だと判断し、リマップを止めて正規のUART2に戻してある。

　それが良くないようだ。リマップするからには何か理由があるはずだ。ここはやっぱりリマップされたPD5とPD6をUARTに出した方が良い。ピンヘッダーを出してPD5、6を取り出す。コンパイルし直して、ピンにUART線をつなぎ再度テスト。よーし良いぞ、端末に文字が出た。しかし、化け化けの文字だ。

　おう、TFTの画面にも何か出ている。中央部だけだが、これも完全に字が乱れている。ふーむ、何かクロックが違うような症状だ。クリスタルは指定どおり25Mhzになっているが、それがおかしいのだろうか。このあたりは8ビットプロセッサーと違って、非常に複雑なところでとてもソースを追いきれない。

　仕方がないので、ロジアナを持ち出して、シリアルのパルス幅を計測することにした。ソースの指定は230kbpsになっている。出てきたパルスの時間間隔を測る。8ビットが34.705μs。230kbpsは、正確には230400bpsで、この8ビットは34.722μs。ふーむ、0.１%以下の誤差だ。殆ど正しい。クロックは問題ないようだが、それでも字が化ける。おかしい。

　バイナリー端末のAcknowrichを動かしてみた。何い、こいつは230kbpsはサポートしていない。うーむ、そうか、PCにも厳しい速度のようだ。こんなに早くなくても良い筈だ。少しビットレートを落としてみよう。当研究所のシリアルの定番の早さ38400bpsにして再ビルドする。

遂にTFT液晶(YHY024006A)が正常に表示された(2/17/2012)
　良いぞ。端末にソースコード通りのメッセージが戻ってきた。入力も受け付ける。RTCも動いているようだ。ソースコードはなるべくいじらないようにした効果が出たようだ。SDカードからデータを読んでとりあえずはファイラーまでは動いた。

　しかし、TFT画面は中央部に乱れた文字らしいものが出るだけだ。これもクロック関係の不具合に見えるが、ソースがこれだけ動いているのだから、やはり配線間違いが一番疑われる。

　夕食後、気を落ち着けて、TFT基板とマザー基板の間の結線をひとつひとつ確認していく。一番有力な疑いは、16ビットモードでなく、8ビットモードでTFTが動いている疑いである。このTFTは情報によればデフォルトでは16ビットモードとあるが、本当にそうなのか確認する術がない。

　もういちど雑誌記事（トラ技2011年2月号）や、著者のサイトを見ているうち気になるところが見つかった。IM0というピンは雑誌では結線されていないが、データシートを見ると16ビットモードではグランドに落とすことになっている。

　モジュール基板では、既にグランドに落とされているので雑誌のように未結線で良いと解釈していたが、本当にグランドに落ちているのか調べてみることにした。やった。これだ。手元の基板のピンIM0はどこにもつながっていなかった。これに違いない。8ビットモードになってしまっている。これが画面が乱れる理由だ。

　いそいそと、ハンダごてに電気を入れ、IM0とグランドをつなぐ。さあ、どうだ。おーし、画面が出た。ひやあ、小さいけれどファイルリストが出た！これは小さい。端末のキーを押すと、画面が消えてシリアル端末の動作だけになってしまうが、間違いなく日本語のファイル名も見える。

　タッチセンサーを動かさないとTFTのファイラーは動かないと思っていたが、ソースコードを見て、コントロール＋キー（いわゆるCTR+char)でファイラーが操作できることがわかった。うわあ、BMPだけでなく、JPEGの画像までが表示される。すごい。

　テキストファイルは？　これは残念ながら表示されなかった。ソースコードを見て、つい実装したくなるが我慢する。目的は、グラフの描画である。

　とにかく、今まで作りこんできたSTM32基板に2.4インチTFT液晶モジュール(YHY024006A)をつけたグラフィック気圧計の母艦部分がやっとのことで動いた。これから、任意の図形を画面に描くのは、また、ひと苦労だろうけれど、何とか一段クリアした。このあたりでブログに報告しておこう。

　今回の経験で人さまのソースコードを貰って動かすためのノウハウが多く学べた。自分のためにも、同じようなことをやる他の方の参考にもなると思い以下にまとめてみた。

人のソースを動かすときの教訓：

• ソースコードはなるべく触らない
  （UART2を下手にいじって苦労したことを忘れるな）

• 出来るだけ同じ環境に揃える
  （原典と違うところを徹底的に洗う努力があれば解決は早かったはず）
• 悪いのは全部自分。ソースは間違っていない
  （何しろ動いていたのだから。動かないのはみんなあなたのせいである）