« 2012年4月8日 - 2012年4月14日 | トップページ | 2012年5月13日 - 2012年5月19日 »

2012年4月29日 - 2012年5月5日の1件の記事

2012年5月 3日 (木)

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

 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日分をダイナミックに表示していくしかけは、結構厄介である。 オブジェクト指向的に実現すべき機能とデータ構造をまとめてソフトを構造的に分割できるようにする。だいぶん骨格ができてきた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

激安テスターの通信機能追加に道草(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を引き出している改造例もあるがS_p4194827、ここは測定器なので絶縁して引き出したいところだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P10_logiana 逆の-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のロガーはうまく動かない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (10) | トラックバック (1)

« 2012年4月8日 - 2012年4月14日 | トップページ | 2012年5月13日 - 2012年5月19日 »