気圧計のバグつぶしと、ステッピングモーターの静音化

EEPROMストリームの一周がうまく行かない(5/18/2012)
　気圧センサーMPL115を使ったSTM32F107のグラフィック気圧計は、順調に気圧の推移を表示して稼動し始めた。嬉しくなってこの制作のきっかけとなったO-Familyさんの掲示板にも報告する。みんなが祝福してくれた。

　人は狩猟生活をしていた原始時代から、一人では生きていけない動物である。本来は孤独な電子工作だが、こういう機会を通じて沢山の同好の人と自宅に居ながらにして交流できる。こんな楽しいことはない。ネット社会の有難みをしみじみ実感する。

　稼動が2日以上になって気が付いた。気圧の表示は直近2日間だけなのに、外付けのI2CのEEPROM(24FC256)の容量は256キロビット(32KB)で1週間以上蓄積される。2日分（8KB少々必要）しか表示しないにしては大きすぎる。

  EEPROMのバッファーそのものは、データが一杯になれば、古いものから消していくしかけ（リングバッファー）になっているが、このままではグラフ表示が無用なデータの読み込みで遅くなってしまう。EEPROMの量を制限して、2日で廻るようにした。

　と、これが2日間のあとバッファーが折り返されるとレコードが目茶目茶な形になってグラフが表示できなくなった。折り返しのテストは、開発の初期にサイズを256バイトに縮めて何度もテストし、問題なく動くことを確認している。それなのに何故だ。

　UARTを付けてEEPROMから読んだデータを調べて、その原因はすぐわかった。 データがバッファーの最後まで書かれてオーバーラップした際、スタートポジションを1バイト余分に進めている。そうか、今までこのバッファーの使い方は、バイトストリームなので1バイト飛ばしても余り大きな問題にはならなかったのだ。データが最初に折り返すときに書き潰されるデータがひとつ増えるだけで、そのあとは問題なく折り返されていく。

　しかし、今度のアプリケーションは、32バイトのレコード単位にデータを蓄積している。このような形で、折り返しのストリームバッファーを使っている時には、この1バイトのずれは致命的である。1レコード分をすべて無効にしてアライメントを合わせてしまえば良いが、これでは解決したことにはならない。　

　しかも、今度のストリームはハードウエアがページ単位に読み書きするEEPROMで、アライメントに厳格だ。まあ、EEPROMのページサイズを考慮しないでもアクセスできる構造になっているので、レコードサイズを合わせる必要はないのだが、何となく気持ちが悪い。

簡単に修正出来ると思ったが意外に難しい(5/20/2012)
　始めは、バグのつもりで気楽に修正に取り掛かった。要するに、データがバッファーの最後まで書かれて、バッファーのトップに折り返すとき、スタートポジションを先に1つずらしてしまうのが、データが乱れる直接の原因である。

　データはまだ書かれていないので、このときにスタートポジションを移動する必要はない。次のデータが書かれるときに始めてスタートポジションを動かせば良いはずだ。これでこの問題は解決とばかり、コードを直してテストしてみた。

　しかし動かない。考えてみたら、データを読むときのEOF（End Of File ファイルの最後）の条件は、読み込むポジションがデータの最後に来た時である。データが書かれる前までスタートポジションを変えないということは、スタートとエンドが同一ポジションにあるということである。　既に読み出す前にEOF条件を満足しており、これでは先に進まない。意外や意外、難しい話になってきた。

　調べるにつれて、これは深刻な問題であることがわかった。スタートとエンドが同じポジションにあるとEOFの条件判定が極めて難しくなる。今まで、折り返しストリームバッファーがうまく動いていたのは、スタートポジションとエンドポジションが１つずれていたためなのだ。無駄なデータが必要だったのである。

　頭を抱える。メモ用紙にバッファーの図を書いて、解決法を探る。整理した結果わかったことは、データのスタートとエンドのポジションが重なると、このバッファーが、データが書かれた状態なのか、全くデータのない初期の状態なのかは、これだけで判別することは出来ないということである。

　それなら、エンドポジションの位置をスタートポジションとずらして、リングバッファーを操作すれば良いのではないか。データが全くない初期のときはデータのエンド位置をバッファーの最後に置くなどすればデータがないときと一周したときの判別が出来るはずだ。

　しかし、これも実際に動かしてみるとデータがあっても0の状態になったり、EOFが判別できなくてループになったりしてうまく動かない。いくらエンドポジションをずらしても、最後に書き込まれたデータ位置は、物理的にスタートポジションと同じなのでEOFの判定をするときは前のスタートとエンドを同一にしているときと変わらないからだ。

　結局、3日近くあれこれ考えた末、スタティックなポインターの位置だけでEOFを判別することは諦めた。やりたくはなかったがフラグを持ち込むことにした。スタートポジションを2回通った時に始めてEOFと判断する（1回のときはフラグを立てるだけ）ようにする。

　フラグ方式なら、beforeEOFとも言えるようなフラグを作っても良い。エンドポジションを最終データの一つ前に設定しておき、ひとつずれる形でEOFを返す。どちらが良いか迷ったが、わかりやすい前者の方式で実装することにする。

　ロジックが固まった（勿論例の擬似コードである）ので、テストに入る。EEPROMの関数を直すだけでは、テスト結果は2日かかることになるので、mainプログラムをいじって早く結果が出る（バッファーを使いきる）ようにし、テストする。

　何度かプログラムを修正して、やっとのことでデータは正しくバッファー上に記録されるようになった。これが最善の策か自信がないので、このブログに擬似コードと図を載せて、読者の方からご批評を待ちたいと思う。もっと良い方法があれば教えて下さい。

上記の修正を加えたEEPROMのライブラリをzipに固めたものを下に置きます。以前公開したコードでは折り返しで1バイトずれます。また、気圧計全体のロジックの参考のため、main.cも入っています。ただしこれだけでは動きませんのでご注意。

「5_28_2012eeprom_lib.zip」をダウンロード

自動巻き機のマイクロステップ制御の勉強を続ける(5/21/2012)
　時計の自動巻き機の工作の話である。ステッピングモーターを静かに回すための方策、マイクロステップ制御の検討を続けている。前回記事にマイクロステップ制御には4つもPWMチャネルが必要だと書いたら、コメントでhiraさんがバイポーラなら2本のPWMで出来ることを教えてくださった。

　ユニポーラモーターでも、バイポーラにして使うことが可能なようだが、モータードライバーには、逆転が必要なため、フルブリッジのドライバーが2つもいる。PWMを2つにしたいのは、Tiny13などの8ピンのAVRがPWMを2つしか持っていないためで、Tiny45も、調べたらPWMを4つ持っているのにPWM出力は不思議なことに3本しか出すことができない。

　とはいえ、8ピンのAVRで実装しなければならない必然性は殆どない。AVRチップ最安値(秋月で￥100)のTiny2313は、余裕で4本のPWMが使える。それに、こちらには、Xbeeラジコンのときに間違えて買ったステッピングモーター用のFETモジュールMP4401が5つもある。早くこいつを消化したい気持ちもある。ここはとりあえず2313で実験を進めることにする。

ただ、2313ではタイマーを全て使い切るので、運転制御のためのタイマーがPWMのタイマーと併用できるか心配である。ウェブを見ていると、バイポーラのマイクロステップ制御のICが数多く売られている。それだけ需要があるということなのだろう。

マイクロステップ制御の仕様を固める（5/23/2012)
　だいぶ煮詰まってきたので、細かい仕様を決めていくことにする。クロックの計算をする。波形は、一番ポピュラーな正弦波にすることにした。これを分割して近似波形の0から255 までのテーブルを作る。PWMサイクルは20kHz（5ms)、分解能は8ビットで十分だろう。回転は恐らく、1分20回転もする必要がない。正弦波は、どの部分を使うのだろう。　

　最初はモーターを動かさずにLEDとオシロで実際に波形が出るかどうかを確かめれば良さそうだ。偉そうなことを言っているが、実は、がた老AVR研究所はまともなPWMは始めての経験である（ゼロクロスのトライアックで真似ごとのPWMはやったが）。

　波形はサインカーブをEXCELで作り、1/2π分を32分割で作る。分割の数は良くわからないで適当に決めた。これをテーブルに入れ、PWMカウンターのオーバーフロー割り込みの度にデータを移していけばPWMが出来るはずである。

　さらに、4相のモータードライブ単位に、PWMを設定していく。モーターの1サイクルは全体を少し大きな（ステップ数の多い）ステートマシンで動かせばよい。まずは1チャンネル分のPWMを作り、LEDとオシロで確認することにする。

　久しぶりのAVRの開発である。この前のステッピングモーターのAVRStudioプロジェクトをコピーして、新しいソースコードを起こす。色んなことを忘れている。何かの手違いか、全く同じソースを持ってきたはずなのにビルド出来ない。エラーで帰ってくる。

　こういう統合開発環境の不具合は厄介だ。先を急いでいるので、深追いせずこのプロジェクトをさっさと諦め、もういちど別のプロジェクトを起こしなおす。よーし、動いた。何が悪かったのか追求しても始まらない。ソフト開発の世界はこういう見切りも結構重要な要素のような気もする。

　PWMといっても難しいところがあるわけではない。やたらにタイマーの定義が複雑なだけだ。でもARMに較べれば、AVRのタイマーの定義など可愛いものだ。8ビット高速PWM、コンペアレジスター2つで、2つのPWM波形がとれる。とりあえずタイマーひとつだけに実装し、LEDが人間の目で蛍のように瞬く時間にプリスケールを定義して、簡単にソースコードが書けた。

LEDで実験に入る(5/24/2012)
　ブレッドボードにLEDを差して、早速実験に入る。LEDが点いた。しかし、変な瞬きである。ギクシャクしているし、完全に消えないところがある。オシロを接続して出力波形を見る。ふむ、何となくPWMっぽい波形だが、あちこちにパルスが出て（これがLEDの消えない理由）、しかも綺麗な波形ではない。

　デバッグに入る。ヒゲが出るわけは判明した。スタックを減らしてプログラムを小さくするため割り込みではフラグを立てるだけで、主な処理はすべてメインルーチンに引き込んでいる。ステートマシンの番号でフェーズを判定し、コンペアマッチレジスターを0にしているが、タイマーはCPUの動きとは無関係に動き続けるので、この差の分だけヒゲになるのだ。

　そういうことなら、これを割り込みルーチンで直接やれば良い。これでヒゲはなくなるはずだ。おやあ、まだ残る。何故だ。そうか、高速PWMではカウンターがオーバーフローすると出力は1にトグルされるが、オーバーフローしてから、このユーザープロセスの割り込みルーチンに来る時間は0ではなく必ず少し遅れる。

　CPUクロックとのプリスケールが8程度では、8ステップ以内にコンペアレジスターを0にしなければならず、割り込みでうかうかレジスターの退避などしていては間に合わない。このグリッチはクロックを上げてプリスケールを増やせばなくなるのだろうが、何となく対症療法的でしゃくである。

　データシートを眺めているうち気がついた。意味が良くわからないが「位相基準」PWMというのは、コンペアマッチする場所とオーバーフローするところが違うようだ。PWM周波数は1/2になってしまうが、これならグリッチは出ないのではないか。

　早速、確かめる。タイマーのレジスター設定で「位相基準」PWMに替えて動かしてみる。ビンゴ！だった。全くグリッチはなくなり、LEDも完全に消えるところが出来てホタルらしく点滅する。よーし良いぞ。ただPWMで調整している光の動きがどうもギクシャクしているような気がする。

　出力ピンに4KΩと、1μF程度のLPFをかませてオシロで見てみた。思ったより綺麗なサインカーブが現れた。おやあ、カーブが最大になったあと、少し欠けて次の下降カーブになっている。ちょうど、LPCMプレーヤーでバッファーアンダーランを見つけたときのようなカーブだ。綺麗なサインカーブが一部欠けているところが見つかったのである。

　ソースコードを調べる。すると、カウンターの増やし方を間違えているところが発見された。これを直して動かしてみる。やった、やった。完全なサインカーブがオシロの上で観測できた。いやあ、オシロを買っておいて良かった。これはロジアナではなかなか発見できなかっただろう。

モーターは完全に静かになった。大成功(5/26/2012)
　マイクロステッピング制御でモーターを動かせる環境が少しづつ整って、完成の期待が段々高まってきた。1つだけのPWMチャネルを4つに拡張する。ブレッドボード上にあり合わせのLEDを差して、それぞれホタルのように次々に点滅する様子を暫く楽しんでから、いよいよモータードライバーを接続する。

　さきほどの簡易LPFをさらに3組増やす。ブレッドボードは林のように部品が乱立するがそれにかまっている場合ではない。配線が済んだ。さあ、どうだ。コンパイルはARMと違ってフラッシュが2KBもないのであっという間に終わる。さあ実行である。緊張の一瞬。「ゆけー」という掛け声とともに電源ON。

　しかし、モーターは、「ンゴゴゴ．．．」と言ったまま、廻る気配はない。ふーむ、配線を間違えたか。試しに一部を反転させてみる。廻り始めた。おおお、全く音がしない。手に持っているとわずかな振動が感じられるが、導電スポンジの上に置くと、余程耳を近づけないとモーター音が聞こえない。

　大成功だ。LPFの部分を少しいじってみる。意外なことに、コンデンサーをはずすとモーター音は更に小さくなった。手で持っていても、この状態だと殆ど振動を感じない。ただし、モーターを机の上に直に置くと、PWM周波数(およそ2Khz)の「ピルルル」という音がはっきり聞こえる。ひところの電車のモーター音のようで面白い。

　コンデンサーをつけるとこの高周波音は小さくなるが、モーターの振動は明らかに増える。抵抗は入れてあるほうが静かになる。エッジがなまるからであろうか。パルス制御で言えば一相制御にあたるのでトルクの低下を懸念したが、手で止めることが出来ないくらい力は十分で、時計を回すくらいなら全く問題がない。

　いやあ嬉しい。あれだけゴーゴーとうるさかったステッピングモーターが、全く無音になったのである。同じモーターとは思えないほどだ。PCの横で動かせば、PCのファンの音で、モーターが廻っている音は完全に消える。ただ、長時間動かすとモーターは2相パルス駆動のときより明らかに発熱する。

　2時間連続で動かしても、少し暖かいなという程度なので、これからのアプリケーションには全く問題がないが、やっぱりモーターには少し負担がかかっているのかもしれない。一方、MP4401は全く変化がない。この程度のPWM制御は全く問題がないようだ。

　これで自動巻き機のソフト開発は峠を越えた。これだけ音が静かになったのだ。大威張りで巻き機だと自慢できる。残るは、マイクロステップ駆動の逆転である。これ結構面倒くさそうである。

グラフィック気圧計の完成と、腕時計自動巻き機の制作

　今年始めから手がけてきたSTM32F107と2.4インチTFT液晶を使ったグラフィック気圧計（天気予報計になる予定）が、やっと想定した気圧の推移を画面に描き始めた。いやいや、完成までえらい時間がかかった。これから最後のソフト開発について報告するのだが、実はこのプロジェクトと並行して全く別の工作を続けていた。この話を先にご紹介することにする。

　その工作とは、以前、動作確認だけやって放置していたステッピングモーターの応用で、機械式自動巻き腕時計の自動巻き機（ややこしい）を作る工作である。

自動巻き腕時計は、使わないときの管理の方が面倒である（5/6/2012)
　所長は、いわゆる時計マニアではない。しかし、そこは機械好きのこと、随分昔になるが有名ブランドの自動巻きの腕時計をボーナスをはたいて手に入れている。以来これを愛用している。

　自動巻き時計は、正確さということではクオーツの足元にも及ばないが、電池切れの心配を全くしないで良いし、機械だけでこれだけの精度（日差数秒）を保つ堅固な精密品を持っているという満足感が心を豊かにしてくれる。

　ところが、最近は腕時計でありながら電波時計で、しかもソーラー電池で電池交換不要という正確で全くメンテナンスフリーの時計が、ずいぶん安くなってきた。GPSを受信して世界中で時差の調整不要な最新式の時計にも食指は動くが、スポーツ用の安物のクォーツ腕時計が壊れたのを機に、物欲を押さえることができなくなり、セイコーの電波ソーラー腕時計を衝動買いしてしまった。

　買ってみて軽くて具合が良いので、仕事にもつけて歩こうとしたが、心配なのは自動巻きの腕時計の方である。機械式の自動巻き腕時計は、毎日、腕に巻いていないと、2日ほどで止まってしまう。長時間時計を止めておくことは、時計にとって良いことではないし、使うときには、竜頭を起こして時刻合わせをしなければならず、これを続ければ防水性も損なう。

　世間にはこういうときのために、はずした腕時計をぐるぐる機械でまわして自動的にネジを巻いてくれる自動巻き機というのが用意されている。時計マニアの中には、ここに3つも4つも腕時計を入れて管理しているのをみかける。一方向だけ廻るのでなく、休みをとりながら回転方向を変える。こった機械になると、手の動きのようにスイングして巻くものもある。

　値段も中華製なら￥3000くらいからあり、そう高いものではない。でもカタログをウェブで見ているうちに思いついた。そうだ、何も買うことはない。当研究所には、モーターがごろごろしているではないか。これを利用しない手はない。

　腕時計をぐるぐるまわすだけの機械である。こんなものは電子工作ではないと叱られそうだ。確かに、ただ回すだけなら面白みがないが、一定期間まわしたあと休みをとりまた動かすという操作は、マイコンにとっておあつらえ向きの仕事である。既製品と違ってどんな回し方にもできる。自作の強みだ。

　当研究所にとっては、マイコンのソフトやモータードライバーの部分はともかく（あとでいくらでも変えられる）、機械部分をどう作るかが一番の課題である。色々考えた末、千石のロボット部品館で、ステッピングモーターのシャフトに部品をつけるジョイント（継ぎ手とでも呼ぶのか）を買ってきた。

　手持ちのステッピングモーターの速さとトルクから、減速する必要はなく直結で十分だという判断である。ただ、このジョイント、先が6ミリネジで、もう一方がシャフトを入れるハウジングがあるだけのものだが￥500もする。モーターの半分の価格である。ロボット用部品はどうも高すぎる。

　シャフトの太さをあらかじめ測って、内径6.0ミリのジョイントを買って帰ったきたのだが微妙に入らない。スペックを見ると、このモーター（ST-42BYG0506H)のシャフト径は、なんと6.2ミリであった。

　どちらかを削らなければ入らない。シャフトを削るのはモーターを傷めそうなので、ジョイントの内側を削ることにする。しかし、めくら穴をやすりで削るのは容易ではない。そのうちルーターの小さい丸砥石で削ることを思いついた。早速やってみる。うむ、手でやっているよりはかどる。少しづつ削って、何とか全部入るようになった。

　時計を入れるケースは、このあいだハンズから買ってある。腕時計をまいた形でクッションをかませて入る大きさのアクリル円筒、要するにコップである。円筒の真ん中に穴を開ける。3ミリの下穴から慎重に開けたつもりだが、やっぱり、ヒビが入ってしまう。まあ￥190の部品だ、試作ということで許してもらおう。

　ブレッドボードに残してあったステッピングモーターのFETドライバーで早速まわしてみる。うむ、回転を遅くすると、モーターはうなりが大きくなるが、予想通り、この程度の負荷は全く問題なく力強く廻る。あとは、この組み立てである。ただ、音がゴーゴーと騒がしい。

アクリル曲げ器の最初の実用品(5/10/2012)
　すんさん掲示板のばんとさんの記事に刺激されて自作したアクリル曲げ器で始めて実用品を作る機会が訪れた。自動巻き機のフレームをアクリル板を曲げて作る。手持ちの厚さ2ミリと3 ミリのアクリル板を検討して、3ミリの方を選ぶ。2ミリの方が工作しやすいが、振動が心配だ。

　形は単純で、50度ほどの角度で板を曲げるだけである。斜め方向にモーターをセットし、円筒を傾けながら回す。ただ、3ミリのアクリル板がうまく綺麗に曲がるかが問題だ。板を曲げる前にモーターの取り付け穴を定規で測ってアクリル板の養生紙の上に描く。

この前買ったドリルスタンドで、直径22ミリのステッピングモーターの出っ張り部を3ミリドリルを連続的にあけて切り出す。アクリル板でも厚さ3ミリ程度になると、ちょっと緊張するが順調に22ミリ径の内側に失敗もなく連続穴が開いた。切り取った後をやすりで整形する。

　4隅の取り付け孔は、ひび割れを心配してセンターポンチを使うのをさぼったため、正確に開けられなかった。丸やすりで調整する。まあ、ここはネジで隠れるので、あまり神経質になる必要はない。とりあえず組み立ててみる。よーし、全部ネジ穴が揃った。

　モーターの取り付け孔の工作はうまくいった。モーターをアクリル板から取り外し、いよいよアクリルを曲げる工程に入る。久しぶりにアクリル曲げ器に電源を入れ、温度を230℃に設定する。順調に7セグLEDの温度が230℃に上がり、±10℃で安定する。外部はこれで150℃近辺になるはずだ。

　慎重にアクリル板の目印に引いた線に曲げ器のパイプを当てる。アクリル板が3ミリと相当厚いので本当はいけないのかもしれないが（曲げたところが一直線にならない）、不安なので両側をあてて加熱した。暫くするとユリゲラーのスプーン曲げのように、アクリル板は、突然、柔らかく曲がり始める。

　アクリル板はあっけなく90度以上簡単に曲がり、予定したフレームが完成した。早速モーターを取り付けなおし、円筒をシャフトにつけて試運転する。モーター音が大きく、振動するのでアクリル板の底部には何かの滑り止めが必要かもしれない。マイコン基板は、台の上にセットすれば良いだろう。

　暫く、ブレッドボードのモータードライバーで時計を回してテストする。このモータードライバーはUARTで正転・逆転や速度の制御が出来るので、PCキーボードで指示しながら曲げ器の運転をシミュレートする。30分も回せば、一日、時計は止まらないことがわかった。ただ、音がうるさい。ステッピングモーターには、色々な制御方法があるが、音が静かになるというマイクロステップ制御を試したくなってきた。

マイクロステップ制御はお手本が少ない(5/12/2012)
　正転、逆転、休止などのモーターの運転制御は、マイコンなので、どんな複雑な動きにも対応できる。運転プログラムをどういう形で作るか、あれこれ考える。EEPROMに基本スケジュールをあらかじめ作ってしまっておき、UARTでその修正をするというのが、一番素直なようだ。

　それより、マイクロステップ制御である。今ブレッドボードにあるマイコンは、ATTiny2313だが、8ピンAVRを使ってみたい気もする。ただ、マイクロステップ制御はPWMなので8ピンAVRがどれくらいPWMチャネルを持っているか調べてみた。

　マイクロステップ制御は、4チャンネルのPWMが必要だ。残念ながら、手持ちの最安価のTiny13は、PWM出力を2つしか取り出せず、Tiny45以上が必要のようである。Tiny85ならDigiKeyで買ってある。

  ウェブを漁るが、ステッピングモーターを静音で動かせるマイクロステップ制御については意外にも資料が少ない。前のPID制御のときと同じだ。理論的な話や基礎的な話は、いくらでもあるが、では実際にどういうクロックで、どんな波形でやるのが良いのか参考になるサンプルが極めて少ない。

　特許のページがいやに目に付く。このへんの工夫やしかけはソフトと違って特許で守れるので、それで具体的な話が少ないのだろうか。大体この秋月で買った￥1000のモーター(ST-42BYG0506H)でPWMのマイクロステップができるかどうかもわからない。

　最初、3角波で良いかと思ったが、正弦波が良さそうだという話もあり、別のサイトでは台形波を勧めている。　ハードは揃ったが、ソフトの準備が思いのほか手間取りそうだ。まあ、このあたりは電子工作でも、一番楽しいところだ。存分に悩んでみよう。

グラフィック気圧計の完成近づく(5/11/2012)
　STM32のソフト開発の方である。このあいだTFT液晶で枠線を引くことが出来て、最後の仕上げ、グラフ描画のソフト開発の段階まで来た。

　日付線や、時刻の表示など補助的なグラフィックは、ダイナミック表示（グラフが時間とともに移動していく）のため、とても面倒だったが、これは擬似コードをかなり周到にやって見通しがついた。あとはこれをC言語ソースに替えれば良いだけになっている。

　擬似コーディングから実際のCコードに落とす作業は、擬似コードのレベルにもよるが、単純作業に近くなるので進捗は早い。オリジナルのプログラムを大幅に変えて本来のグラフ描画に絞った関数を残し、FatFS関係を削除する。こちらのほうが大変である。

　FatFS関係だけ削れば良いと思っていたら、グラフィックのファイラー部分は、FatFSの関数を呼ぶところが各所に散在し、いたるところをコメントアウトしていかねばならない。画面描画の部分も残っているので、全部なくすわけにもいかないのだ。

　それに、あまりフラッシュが小さくならない。どうしてだろう。フォントファイルが大きいためなのか。日本語フォントは今のところ使うつもりがないが全部消してしまうとあとから復活させるのが大変なので残しておきたい。それにこの部分だけの削除はもっと大ごとだ。

　なんとか整形して、テストを始める。うーむ、動かなくなった。グラフは一部出ているので、どこか途中で暴走している。テストステートメントを挟んで、慎重に暴走地点を探す。ふむふむ、EEPROMから気圧データを読み出すところでハングしている。

　EEPROMに蓄積する日付と気圧データは、視認性を高めるためと、今後のデータの編集を考慮して、キャラクターになっている。グラフ描画のときは、このキャラクターデータをバイナリーに戻す作業にChaNさんのxatoiを使わせてもらっている。これがどうもうまく動かず暴走しているようだ。

　この関数は強力だが、アドレス、ポインターを多用しているためちょっとでも間違えると、一瞬にしてハングアップしたりリセットしたりする気難しい関数だ。いつもは威力を発揮するprintfデバッグだが、STM32のUART出力はバッファーを使っているらしく、こういうポインター間違いで一気に暴走するバグには無力である。結果をUARTに出す前にハングアップしてしまう。

　いくら調べても原因を究明できない。そのうちじれてきて早く結果が見たいので、xatoiを使わず、自前のルーチンでキャラクタからバイナリに戻すステップを急遽追加する。20桁近い文字の変換だが、この際きれいごとは言ってはいられない。

気圧計が動いた。やっぱり文字が小さすぎるな(5/14/2012)
　この改修で、やっと、プログラムは正常に気圧を出すところまで進んだ（10分間隔）。画面の下に、赤い気圧点が見える。うーむ、このTFTの赤は暗いのでこれでは見難い。1ピクセルではなく、2X2のレクタングルにしてやる。うはあ、画面が赤線だらけになった。画面関数の引数を間違えたようだ。

　利用させてもらって文句を言うのは気まずいのだが、この描画関数群は、引数の座標の順番が微妙に少しづつ違っているので用心しないといけない。XとYが逆になっている関数もある。今度の関数の引数は、XYの順番にはなっているが、X1,Y1  X2,Y2ではなく、X1,X2　Y1,Y2だった。

　指定どおりに引数を直して、無事、少し濃い赤点がでた。暫く放置してグラフになっていることを確かめる。よーし、これでグラフィック気圧計は正常に動き始めた。いやあ、それにしても時間がかかったな。ほぼ4ヶ月かかった。グラフ全体が時間とともに動くという仕掛けが、ソフト開発では特に手間どった。

　半日ほど動かして、グラフの横軸（気圧）のスケーリングが大きすぎて、殆ど気圧の変化が見えないことがわかった。大幅にスケーリングを見直す。最初は、950hPaから、1150hPaという、MPL115気圧センサーの測定可能範囲にしていたが、これを980から1030という狭い範囲にする。

　これで、やっと気圧の変化がはっきりするようになった。すんさんの気圧計のグラフの範囲も、970と1030になっていた。何だ、始めからこれを参考にすれば良かったのだ。へそ曲がりで人のものを参考にしたがらない性格がこういうときに損をする。

　水色で枠をつけてグラフが引き締まり、気圧計らしくなった。下側に、細かく目盛りをつけたりして悦にいる。ただ、時刻と気圧を表示する文字がやっぱり小さすぎる。それに天気予報の機能はまだ何も考えていない。

　今後の計画は、まだ具体的には決めていない。天気の予報をしなくても、グラフの気圧変化を見ているだけで、この先の天気が雨模様になるのか、回復するのかは大体のことがわかる。あらためて数値解析をして予報を出す必要があるか悩ましいところだ。ま、これも暫く悩んでみることにしよう。

 ソースコードの公開は、このブログの容量制限（１MB)を越えるため、今のところ出来ません。いずれ、別のサイトからでも引けるようにしようと考えております。もし、ロジックだけでも知りたいという方がおられれば、このサイトに部分的に置くことにします。コメントをお寄せください。

グラフィック気圧計ソフト開発の合間に道草

　STM32によるグラフィック気圧計は、いよいよ画面に気圧の遷移を折れ線グラフで表示するメインロジックの開発に移った。今年の1月から始まったこのプロジェクトは、まずAitendoの生基板にSTM32F107を実装することから始まり、2.4インチTFT液晶の組み込み、気圧センサーMPL115A2の実装とデータ取り込み、さらに気圧の時系列データを保存するEEPROM(24FC256)の組み込みとそのドライバーの開発まで進んだ。

　最近は電子工作のモチベーションが、夢中になってやっていた頃に較べると明らかに下がっている。いわゆるスランプである。体の奥底から突き上げるような、「作りたい！」という衝動が生まれない。ただ全く興味を失ったわけでもない。考え出すと、あれもやりたい、これもやりたいと迷うことが多くて実際に手が動く（ハンダ付けや、コーディング）ところまでなかなか行かないだけである。

　亀のような歩みだが、それでも、やっと全体を動かすメインプログラムの開発が始められる段階まできた。さあ、一気呵成にと思った途端、別のやりたい工作が入ったりして相変わらず、がた老AVR研究所は道草の連続である。見通しの悪い話の展開で読みにくいとは思うが、まあ、アマチュアの気ままな開発日誌ということで我慢してお読みいただきたい。

TFT液晶でDOS端末のような文字スクロール画面を作る(4/17/2012)
　これまでテストベンチにしていた、ねむいさんのFatFSファイラーのソースコードを基本にEclipseの新しいプロジェクトを起こし、いよいよ気圧計本体のソフト開発に着手する。 残っていたThomas氏のルーチンは削除して構造をすっきりさせる。サイズは200KBに減ったが（10KBばかり節約）、びっくりするほどは減らない。

　もっと減らすには、気圧計では使わないFatFSとファイラーを消せば良いのだが、これからグラフのコードを作るときに、グラフィック機能の確認のために残しておきたい。コンパイルに時間がかかってしまうが、あえて残したままにする。

ソフトの仕様を詰め始めた。例の擬似コーディングである。測定途中でパラメーターを変えたりしないで良いのなら制御構造は、とても単純だ。10分に一回、EEPROMにデータを蓄積して、2日分のグラフを描き直すことをひたすら続けるだけである。予報は、このときに過去のデータをもとに更新する。

　ただ、グラフを現在時刻を起点に過去2日分をダイナミックに表示していくしかけは、結構厄介である。　オブジェクト指向的に実現すべき機能とデータ構造をまとめてソフトを構造的に分割できるようにする。だいぶん骨格ができてきた。

　文字の大きさが問題だ。この間大きくしたファイラーの10ポイントの文字は、グラフの中の目盛り数字には良いが、現在の気圧値や時刻を遠くから見えるようにするには、まだ小さすぎる。といって、12ポイント以上はフラッシュが小さすぎて(実装したSTM32F107は256KB)、入らないだろう。まあ、漢字を使わないで英数字だけでも入れたほうが良いかもしれない。

　そんなこともあって、グラフィック機能の勉強のため、今動いているファイラーで、DOS画面のようにテキストが表示されるよう、ソースに手を加えてみた。しかし、思ったようにうまく動かない。ソースの一文字出力関数にはスクロールの機能が組み込まれているのに、文字の表示が最終行まで来ると重複して表示されるだけである。画面全体が上にスクロールしていかない。

　調べたところでは、スクロール関数の縦横の指定がどうも逆さまになっているような感じだ。ねむいさんは、最近、このファイラーに、ファイルのテキストを表示するブラウズ機能を追加された。ソースも公開されている。恐らく、ここの部分は直っているのだろうけれど、少し意地になってそれを見ないで修正することにする。自分の推理が正しいことは自分の手で確かめたい。

　X軸とY軸を逆さまにすると画面は見事スクロールするようになった。自分の推測があたって気分が良い。ただ、2バイト文字の漢字は、スクロールした時両端が残ってしまう、それに最終行にはゴミが残る。ただ、スクロールは今度の気圧計では使わないので急いで直す必要は無い。

　でも、気になるのでもう少し調べてみた。要するに、全角文字の表示のために画面の両端は、半角サイズあけて文字を表示しているのだが、スクロールの際に両端の全角のフォントの半分が次の半角文字表示では更新されないので、そこが残ってゴミになる（次の行も全角なら塗りつぶされOK)。

　2バイト文字が使っていたエリアをスクロールしたあと、空白の全角文字1字を書き込めば、良いはずなのだがこれがうまくいかない。このあとの行全体の文字すべてが化けてしまう。こうなると意地になるのがいつもの癖である。別の画面関数(Display_FillRect_If)を使って、この部分をレクタングルで消してしまうようにした。

　これで、ゴミは消えて漢字も出た。しかし、半角英数字は問題なくても、一部の漢字がスクロールで化ける（すべてではないのが不思議）。　黒の1文字分のレクタングルを両端に描いているだけなのだが、どうも漢字コードの表示ルーチンと何らかの関連があるらしい。

　奥が深そうなのでこれ以上の深追いはやめた。今回のグラフではスクロールは使わない。ただでさえ遅れているプロジェクトをこれ以上迷走させるのはやめよう。潔く諦めて先に進めることにする。

直線を引くことに成功(4/19/2012)
　グラフ表示に必要な機能をさらに詳しく調べる。画面操作関数(ファイラーts.cの下部関数群のソースファイルdisplay_if_support.c)を調べて行って、実際のグラフ表示に必要な機能（点、直線、領域の描画）は、すべて関数が既に開発済みでそれを利用すれば良いだけであることがわかった。これは楽だ。ただ、スクロールがうまく行かなかったように、文字関数との関連が、いまひとつわからないので不安は残る。まあ、しかしこれはやってみるしかない。

　試しに、画面に直線を描く関数(Display_DrawLine_If)を使って、縦、横の直線を引いてみる。これは、あっけなく引けた。今回は使わないが斜め線もOKである。これは有難い。難しいことを考えない限り、気圧のグラフは思ったより簡単に引けそうである。

　調子に乗って、JPEGを横位置に表示するテストもやってみた。オリジナルはTFTの画面を縦位置で使っているので、スケールファクターが大きくなり、折角の画像が小さくしか見えない。これを横位置にすれば、画像が大きくなるはずだ。

　ChaNさんのTinyJPEGが使われている。描画はIJGと同じように、1ラインづつ24ビットRGBデータを出力し、これを繰り返している。この細いレクタングルの座標を変えるだけで画の方向が変わるはずだ。

　ソースの解析を進めて1ライン表示のレクタングルに出力しているところを突き止め、この縦横を逆にしてみた。おおお、倍のサイズのJPEG画像が出た。しかし、画像を良く見ると1ラインずつわずかだが画像がずれており元の画像になっていない。

　これも今回のプロジェクトとは関係ない。もうこのあたりで止めよう。どうも今回は、余計なところに目が移ってなかなか先に進まない。詳細な画面仕様を作り始める。作ってみると枠線とか目盛り線など本来のグラフと関係ないところの描画が結構面倒なことがわかる。特に日付線が動いていくところをどうスマートに描画していくか頭を悩ませる。小道具の方が手間がかかる。

激安テスターの通信機能追加に道草(4/20/2012)
　そうこうするうちに、すんさんの掲示板で耳寄りな話を聞いて、プロジェクトは大きく脱線してしまった。shuji009さんが上げたテスターのトピックで、きぃたんさんが秋月の激安￥1000テスター、P-10にRS232C通信機能がついていることを教えてくれたのである。

　ウェブで探してみると、あったあった。少なくとも2つのサイト（こことここ）で、それを実際に試して動かしている。しかも、PCのテスターのロガー（フリーソフトのTs Digital MultiMeter Viewer)にも接続できるらしいのだ。あろうことか、現在、愛用中の秋月のP16（6000カウント）のマルチメーターにも、このRS232C機能がついているらしい。

　くわしくは、これらのページを見てもらえばわかるが、要するに、ICチップが元々持っていてコストの関係で省略されたデータ送信機能がちょっとした工作で、使えるようになるということである。

　以前から、測定結果のログをとりたくて、シリアルでデータを取り出せるテスターを物色していた。電池の充放電や、DC-DCコンバーターの長期テストなど、電圧などの長期間の推移は、これまで方眼紙に、手でプロットしていたが、そろそろ効率的に行いたい。

　ロガーそのものの自作も考えたが、アナログ部の制作と較正が面倒で、今ひとつ、作るところまでは行かなかった。既存のテスターからデータが取り出せれば、ロガーの部分だけ自作すれば良いので、都合が良い。

　しかし、通信機能のあるテスターは秋月にもたくさんあるが、値段はともかく、みな大きくて取り回しが面倒である。秋月もの以外の国産や著名な欧米製品（Flukeなど）も調べてみたが、通信機能のあるクラスは、みな結構な値段のうえ、ごつくて自分の好みに合わなかった。

　そこへ、この情報である。電子工作をするための測定器を電子工作してどうするのだという声もあるが、なにしろ￥1000の値段には勝てない。もし、不幸にして壊しても精神的打撃はわずかである。しかもPCにはフリーソフトのロガーまで用意されている。ロガーを作る必要も無い。掲示板でこれを知った翌日、仕事の帰りに、早速手に入れてきた。

フォトカプラーに簡単にデータが出力された(4/21/2012)
　ウェブには写真つきの改造手法が出ているので、作業に迷いがない。問題は、ピンから引き出したワイヤーをどう始末してRS232Cまでつなぐかである。ウェブには直結してRS232Cを引き出している改造例もあるが、ここは測定器なので絶縁して引き出したいところだ。

　しかもデータシートの参照回路は、フォトカプラー出しの形が用意されている。これを利用しない手はない。フォトカプラーは手持ちが沢山ある。2400bpsということなので、汎用品（PC817Cなど）で十分なはずだ。在庫整理にもなる。

　ただ、基板とケースを介して、どう実装するかが問題だ。考えた結果が、前にもやった、基板にピンヘッダーを瞬間接着剤で固定し、そのあと、普通の撚り線で配線する方法である。これなら保守性も高いし、見栄えも良い。

　カプトンテープで基板表面を保護してから（SparkFunのときのようなリークの心配をしたくない）、接着剤で3ピンのヘッダーを固定する。よーし、少々力をいれても取れないくらいの強度になった。

　グランドをどこから出すか、ウェブサイトの方法はまちまちで迷った。ピエゾスピーカーがグランドだというが、テスターでどれだけ調べてもつながっていない。参照回路はグランドだが、このP-10ではそうなってはいないようだ。

　しかたがないので、手当たり次第にグランドと導通するポイントをテスターで探し回り、基板の近くに適当なところを見つけて配線した。チップのピン(0.65ミリピッチ）へのハンダ付けは、これまでの経験がものをいって、あっけなく上手くいった。経験はつむものである。

  ケースの工作も進める。まず、前のP16でもやった、直付けになっている測定プローブのコネクター付けから始める。この工作は、数年前やって、とあるサイトに紹介され、当ブログのアクセス数の増加に寄与している。

　久しぶりにミニルーターをドリルスタンドにつけて穴あけ工作をする。穴は簡単にあいたが、ピンを止める段になって、ネジ止めポストと干渉することがわかり、周辺を削るのに手間取る。ピンの外だしは、ケースの一部を削って窓を作る。コッピングソー（糸鋸）が欲しいところだ。

　フォトカプラーの部分を、ブレッドボードに仮組みし、いよいよ、テスト。いくら￥1000の投資とはいえ、電源ONはいつものように緊張する。スイッチを入れる。あれえ、RS232Cの表示が出ない。ちゃんとグランドに落としたのになぜだ。

　配線図をたしかめる。うーむ、このテスターには2種類グランドがあって、使い分けている。何々？さっき見つけたグランドはAGNDだ。いかん、AGNDは、Vccの1/2の電圧のでている中間値のグランドだ。

　これをデジタルグランド（電池マイナス側）にして、めでたくLCDのRS232表示が出た。フォトカプラー代わりにしたブレッドボードのLEDが点滅し始めた。よーし良いぞ。とるものもとりあえずオシロに電源を入れて波形を観測する。出た出た。ちゃんとしたUART波形だ。

　フォトカプラーの配線で、また悩む。参照回路は、単にグランドと送信ライン(TXD)の間にフォトカプラーの出力を抵抗をはさんでつないでいるだけである。しかも回路図は、出力側もダイオードの形をした部品で、どうもフォトカプラーではないみたいだ。

　いろいろウェブを探し回る。こんな接続は見たことがない。フォトカプラーの出力はたいていがオープンコレクターで、これを動かすには電源がいる（フォトカプラーそのものが電源を要求するのもある）。

　この電源を本体のテスターからとることは出来ない。何のための絶縁かということになる。USBにするとVBUSが来るが、この程度の出力に、USBアダプターをつけるのも何か抵抗がある。

　しつこく、「RS232C　フォトカプラ-」でウェブを探し回った。あるページで、出力側をTxだけでなく別のピンに配線している回路を見つけた。あっ、そうだ、RS232Cにはホスト側から色々な制御信号が来る。これを電源に使うんだ。これは頭が良い。感心した。

　早速、これを真似る。DTRを使う。これはホスト（PC)から端末（モデムなど）に、装置が使用可能になったことを教える制御線で、OKが+15V、NGが-15Vである。念のため、今のPCのCOM1で確かめる。確かに、電源を入れると、-15Vに下がり、ターミナルプログラムを立ち上げると見事+15Vに上がった。

　逆の-15Vが心配なので、ダイオードをかませ、ブレッドボードで実験する。出た出た、TeraTermから、次々に送信データが表示される。ロジアナをつないで中のデータを確認する。よーし、データシートどおりの14バイトの測定データが順調にUART出力されている。

データフォーマットが違うので、PCのロガーに出せない(4/24/2012)
　ここまでは順調だった。しかし、このIC(FS9711_LP3)のRS232Cは、フリーソフトのTs Digital MultimeterViewerがサポートするテスターに入っていないことがわかった。　ウェブでWENS20Tと互換というのは、最近のP10のバージョンでは、変わっているようだ。動かしてみると、一番それらしい挙動はするが、正しくは動かない。

　14バイトコードのフォーマットはデータシートに完全に出ているので、あとは単なる力仕事だ。ただ、ややこしい。数値データはすべて7セグLEDのエレメントなので、翻訳してやる必要がある。これは、WENS20Tも同じなのだが、測定レンジや、V、Aなどの表示単位コードが、かなり違う。mAとかkΩなどは、合成しないといけない。そんなことでPCのロガーはうまく動かない。

　選択肢としては、Tiny2313あたりで変換して、もういちどUARTでPCに流すか、いっそのことマイコンの方でLCDとSDカードでロガーを自作してしまうかである。とにかく、すぐ出来る話ではない、とりあえずはブレッドボード上の回路を、P-10に組み込んでけりをつけることにした。

　RS232Cコネクターをつけるには、P-10は小さすぎる。そのうちBeagleBoardのとき作ったRS232Cケーブルを思い出した。10ピンのコネクターでBeagleBoardにつながっている。
これだ、これだ。小さな基板を切り出し、そこへフォトカプラーと10ピンソケットを実装することにする。

　P-10へは接続コードを収容する空間を使ってアクリル小片で押し込むようにする。うまくできた。これで一応ハードの工作はおしまい。コードの解析は一時おあずけである。

　気になっていることがある。フォトカプラーのRS232出力は、本来のRS232C仕様(±15V)ではない。TeraTermは、問題なく文字を出力し、Ts_ Digital MultimeterViewerも、データ入力まではしているようなので動いていることは動いているが、信号Lがマイナスになっていない。これをマイナスにするには、フォトカプラーのオープンコレクターの部分のグランドをマイナスにしてやる必要がある。

　これは、ChaNさんのサイトであっさり解決した。最近のRS232CのLowとHighの閾値（スレッシュホールド）は、マイナスではなく大抵の機器は、+1～+1.5Vなのだそうだ。そういえば以前、ChaNさんの簡易RS232Cを作ったときも、マイナス電圧は使っていなかった。

擬似コーディングに恰好の課題をみつけた(4/26/2012)
当ブログのホーム、ココログは、何処からブログに飛んできたかを調べることができる。このあいだ見ていたら、嬉しいことにこのリストから当ブログを紹介してくださる擬似コーディングのページが見つかった。

「擬似コーディング」でGoogleしても、このページは上位に登場する。ソフトウエアを職業とする方のようだ。自分の考えに共感してくれる人が少しでもいるということは生きている喜びのひとつである。素直に喜ぶことにする。ご紹介ありがとうございました。

　ただ、ウェブを見ていると、色々誤解があるようだ。「どうやって書くの？文法は？」というのが多い。何のために擬似コーディングするのかを考えれば、こういう発想にならないと思うのだが、どうも日本人は形式にこだわりすぎる。

　擬似コーディングはあくまでも論理思考（ロジック）をまとめるものであって、コードそのものに意味があるわけではない。どんな書き方でも良いわけである。書いたことによって頭の中が整理され見通しの良いソースコードを完成させることが本来の目的である。

　そういうわけでもないが、もう少し擬似コーディングにこだわってみた。このあいだは擬似コーディングの講釈ばかりで、実例は失敗例という恥ずかしい結果に終わったので、汚名返上の題材を探していたが、恰好の例をみつけた。気圧計のグラフをEEPROMのデータから描画するルーチン(オブジェクト）である。

　要求される機能は、EEPROMに入っている気圧と時刻データを最初から読んで、現在より2日前に遡って気圧推移をグラフに描くことである。入力は、現在時刻と気圧のEEPROMストリームデータ、出力はTFT液晶の気圧値プロットを打つXY座標である。

　描画するべき時間帯のレコードがおあつらえ向きに連続してきれいに並んでいるわけではない。電源を切ったり、過去のデータが残っていたりして歯抜けになっていることも予想される。読んでみたらデータがないということも有りうる。

　どんなときにでも、グラフが（歯抜けでも）所定の範囲（現在時刻から2日間）に描くにはどうしたらよいか。EEPROMに全くデータがないときでも暴走しない頑丈（Robustness)な構造が望ましい。

　EEPROMのデータは可読性を高めるため、実際の年月日、時分秒で保存されている。実際の処理は、すべて、ある時刻からの総経過分で計算する。

　何回も、擬似コードをメモ上に書き散らし、ロジックを検討した。最初は、描画の順番を重視して、複雑な処理を考えていたが、ある時突然、気圧値のプロットはランダムに打っても問題ないことに気付き、一気にプログラムは単純になった。

　定石どおりEEPROMのデータを最初から読み始め、レコードに入っている総経過分に応じて所定のY座標を計算し、2日間の範囲の時だけ、プロットすることでEEPROMを最後まで読みきれば、それで良いのだ。

　擬似コードは、文法にこだわらず、自由な発想でロジックを考えることが出来るため、ロジックの整理に大きな力を発揮する。これが実際の計算機言語でロジックを作っていると、それに縛られてなかなか飛躍した発想ができない。擬似コーディングのおかげで、すっきりした形のロジックになった。

グラフを描くのにこんなに手間がかかるとは(4/30/2012)
　描画ロジックに見通しがついたので、すぐ完成すると思っていたが、そうは問屋が卸さなかった。年月日時分から、ある時刻を起点とした、総経過分（プロットは10分単位）を出したり、ある年月日から何日か前の日付を求めたりすることが、こんなに大変とはやってみるまでわからなかった。

　自力で考えることはすぐ諦め、ウェブを探索する。いやありがたい。色々な方法で日付を求めるサンプルコーディングを即座にたくさんみつけることが出来た。そう、最初にとりいれたこの方法などは、テーブルを使わずに特定の年月日を、経過日数に見事に変換してくれる。

　ところが、グラフに日付線などの補助線を引く段になって、この方法では、ある年月日から1日前、2日前の日付を求めることができないことがわかった。結局、月の日数テーブルを使った普通のやり方に戻った。

　気圧の推移をEEPROMから1レコードづつ読み出して、2日間のデータをプロットさせることは、先ほどの擬似コードの通りそう難しくない。それより、グラフを見やすくするための補助的な日付線や日付の表示を描画するロジックの方が難しいというのも皮肉なものである。

　擬似コードのロジックがだいぶ溜まり、グラフの詳細な仕様もメモに書きとめて、これでグラフを描く準備が整った。あとはこれをCソースに書き直す作業が待っている。このあたりでブログに報告しておこう。