2012年5月15日 (火)

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

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

S_p5154893

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

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

S_p5134874

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

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

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

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

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

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

S_p5114871

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

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

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

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

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

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

アクリル曲げ器の最初の実用品(5/10/2012)

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

S_p5114868_2

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

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

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

S_p5114867

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

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

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

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

マイクロステップ制御はお手本が少ない(5/12/2012)

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

S_p5134875 それより、マイクロステップ制御である。今ブレッドボードにあるマイコンは、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液晶で枠線を引くことが出来て、最後の仕上げ、グラフ描画のソフト開発の段階まで来た。

S_p5104866

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

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

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

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

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

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

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

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

S_p5134873

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

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

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

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

S_p5144889

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

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

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

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

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

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

 カプトンテープで基板表面を保護してから(SparkFanのときのようなリークの心配をしたくない)、接着剤で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月13日 (金)

気圧センサーMPL115出力補正とI2C EEPROMの動作まで

 STM32とTFT液晶のグラフィック気圧計は、I2Cインターフェースの気圧センサーがひとまず動いて、未完成のハード機能は、測定データを蓄積する同じI2CのEEPROM(フラッシュROM)だけとなった。このハードが動けば気圧計に必要な機能はすべてが揃う。

 I2CシリアルEEPROMは、秋月で買ったMicroChip社の24FC256(¥90)である。1Mhzで動き32KB蓄積できる。チップそのものは、MPL115をつけるときに一緒に基板上に実装してしまってある。必要な作業は、このEEPROMのソフト開発だけである。

P4124824   I2Cインターフェース(マスター)は、既にMPL115のための関数群が開発済みでこれを利用できる。EEPROMそのものは、AVRで既に何度か経験しているので、最初は軽く動くだろうと嵩を括っていた。ところが、これがまともに動かないのである。ソースコードは、STマイクロの標準ライブラリを利用して、お手本どおりに書いている。間違えようの無いコードである。それなのにどうにも安定しない。甘く見過ぎていた。

 この前の記事より、そろそろ20日が経とうとしている。何かにこだわりだすとそこから抜けられない性格が仇になって、先に進めなかったが、悪戦苦闘の末、数日前、ようやく想定どおり動くようになった。これでやっとブログに報告することができる(2012/4/13記)。

センサーから出てきた気圧値の補正は大変だった(3/28/2012)
 I2Cインターフェースの気圧センサーMPL115A2は思ったより簡単に、データを吐き出してくれた。しかし、このセンサーは出てきた気圧と温度のデータを複雑な演算式で計算しないと求める気圧値がでてこない。大気圧はその場所の温度によって変わることは承知していたが、こんなに複雑な式で実際の気圧を求めているとは知らなかった。

S_p3254815  大気圧というものが、空気の密度であり、そもそもの天気図の低気圧、高気圧というものは、冷たい空気と暖かい空気の集団の振る舞いであることは理屈ではわかるが、気象観測上の気圧を、何の基準で決めて測っていくのかと言うことになると俄然難しくなる。

 このセンサーの補正係数というのは、気圧ADコンバーター(ADC)が出してくる値を温度で少し補正するだけのものと思っていたが調べてみると、そんななまやさしいことではなかった。第一、係数は負数で、ADCが出してくる数値は、気圧が高くなれば低くなるのだ。しかも補正係数は、16ビットで6つもある(O-familyさんのサイトの邦文マニュアルがおすすめ)。

 さらに係数は固定小数点で、出てきた数値を9ビットも右シフト(数値の1/512ということ)する係数もある。こんな係数は無視できるのかと思っていたらとんでもない。しっかり計算して入れ込まないと正しい気圧値にならない。

 係数値そのものは、どうもダイナミックに変化している様子はない。恐らく工場で出荷の時に個別の石に応じて補正値を入れているだけと見られる。マニュアルにもあるように、用意された係数の2つ、32ビットは、最初から0である。

 自分が入手した石だけが0かもしれないので、プログラムを汎用化するためにはここも計算してやらなければならないところだが、結果を早く見たいので、とりあえずこの2つの係数は無視して、コーディングを続ける(ウェブサイトで見る限り、この石の係数は全部0のようだ)。

 固定小数点の計算方法を勉強し直す。加減算は、小数点の位置を揃え、乗除算は、そのまま整数とみなして計算したあと、小数点をつけなおせば、普通に演算できることがわかった。ただ有効数字に注意していないと正しい値を失う。

 そういえば、O-Familyさんが、この気圧計を作っているときに、あれこれぼやいていたことを思い出す。そう、こんな苦労しないと実際の気圧が求められないとは思っていなかった。こうなったら意地である。途中でやめるわけにはいかない。

 有効桁に気を遣いながら、 少しづつデータシートにある計算式をコーディングしては、電卓で計算し直して実際の値を確かめ先に進む。精度はみなさんと同じ5桁を目標とし、hPaの小数点一位までが有効数字となるようプログラムを作っていった。

 ロジックが殆ど出来上がった頃、インターフェースのI2Cのご機嫌が悪くなった。ADCからの気圧・温度と係数値を取り出すとき、別々なら問題ないのに連続してにデータをとるとおかしくなる。測定の間に待ち時間を入れたり、スタートコンディションを入れたりしてみたが、前のように解決しない。I2Cって、こんなに不安定なのか。色々調べる。Mpl115

 いーえ、悪いのは全部私でした。連続したデータ取得の最後にNACKを送るため、ACKをdisableするコマンドを送ったまま次の通信を始めていた。通信の始めに、ACKをenableするコマンドを追加したら、ぴたっとこのトラブルは解消した。不安定だと決め付けたMPL115さん、I2Cさんごめんなさい。

 このあいだ係数値がおかしくなるのも実は、原因はこれだったのだ。あのときはI2Cインターフェースそのものを初期化していたので直ったように見えただけである。例の「STM32マイコン徹底入門」のI2Cの説明(P301あたり)にはこれが抜けている。最後のデータを受け取ったあとは、必ず、

 I2C_AcknowledgeConfig(I2Cx, ENABLE);

で、ACKを有効に戻しておかなければならない。一旦、DISABLEにしてしまうと、スタートコンディション発行でもENABLEに戻らない。注意が必要だ。

Photo それはともかく、MPL115から、やっとそれらしい気圧がでるようになった。UARTで測定値を出しながら、ウェブの天気図と見比べる。当研究所の標高が45m(Google標高マップで確認)で、補正(高度差8mでおよそ1hPaとして5.6hPa)をするが、どうも出てくる値は低すぎる。

 ウェブを探し回って、気象庁の気圧データを見つけて驚いた。大手町(標高6m)の測定値と標高差で換算すると正しいのである。大手町の測定値と、天気図の公式海面気圧値とは、4hPa近い差がある。つまり、9hPa余りを足すと天気図にでている気圧値と等しくなる。

 どうも良くわからないが、とにかく補正は上手く行ったようである。10秒ごとに気圧値を延々とUARTに出して暫く楽しむ。すんさんは数値が安定しないという話だったが、気圧、温度ともADC値の変動は±1から2の範囲である。特に大きくぶれることもない。これなら安定していると言えるではないか。ブレッドボードでなく、基板に実装したからかもしれない。

フラッシュROMの読み書き関数を工夫する(4/2/2012)
 開発は、EEPROM(フラッシュROM)のソフト開発に移った。I2CはMPL115で既に動いている。とはいえ、今度のEEPROMは、わずかなデータの読み出ししかしていないMPL115と違って、沢山のデータを読み書きする。

 気圧計でのEEPROMの使い方は、これまでの温度ロガーや、ガイガーカウンターのログと全く同じである。測定レコードを次々にシーケンシャル(順次)に記録して行き、読み出しは最初のレコードから連続して読む使い方である。ランダムアクセスはまずやることはないだろう。

 それなら、AVRをはじめた頃に作った、標準入出力的なストリーム関数を、STM32で作ってやればよい。ただ、EEPROMのアクセスは普通のメモリと違って、ページというブロック単位でしか読み書きできないので、そのしかけが必要だと当初は考えていた。

 ところが、EEPROMのデータシートを見て間違いに気づいた。ディバイス固有のページ単位(24FC256では64バイト)でしか読み書きができないのは、連続したアクセスのときだけで、1バイト単位の読み書きなら、ページの途中の任意のアドレスからでも読み書きができることがわかった。

 それなら、1バイト単位の読み書き関数を作ってしまえば、即、ストリーム関数ができあがる。これは簡単だと思った瞬間、いつもの「へそ曲がり」がむくむくと起き上がった。

 バイト単位のアクセスがEEPROMで出来るからといって、1バイトごとにEEPROMにアクセスしていては、少しデータ量が多くなれば、とんでもない時間がかかってしまう。EEPROMは1回のI/Oオペレーションの後は、書き込みでは数ms、読み込みでも数百μsの待ち時間が必要になるからだ。

 もちろん、今度のプロジェクトは速度のことは全く気にする必要がない。気圧データの収録はいくら早くても分単位である。しかし、そこは、それ、長年の経験で身についた職人気質が許さない。ちょっと工夫すれば、何十倍も早いアクセスが出来るものを、それをしないで通り過ぎることは自尊心が大きく傷つくような気がする。

 今は必要なくても将来のために作っておくべきだろう。それに、いかにも1バイトづつアクセスしているようで、実は裏でバッファーのようなものに貯めておいて高速化するしかけは、創作心(ごころ)を、強く刺激する。

 さらに、このあいだから気になっているソフトウエア開発手法の丁度良い題材でもある。もともと、ページ単位に読み書きして1バイトづつ出し入れする関数を考えていたのだ。当初の路線どおり、少し難しい方法で、EEPROM関数を開発することにした(これが、このあと大変な目に逢うことになるとは知る由もないのだが)。

再々擬似コーディングのすすめ(4/5/2012)
  当研究所では、これまで度々、擬似コーディング(Pseud Coding)について紹介してきた。
http://gataro-avr-ken.cocolog-nifty.com/blog/2009/07/post-a68c.html
(擬似コーディングの実例を載せて紹介)
http://gataro-avr-ken.cocolog-nifty.com/blog/2009/11/xbee-dbc0.html
(やりかたについて詳しく解説)
http://gataro-avr-ken.cocolog-nifty.com/blog/2011/08/sparkfun-0d8b.html
(凡人が規模の大きいプログラムを書ける手段として)

 電子工作の世界に入って、意外にもソフトウエア開発の苦手な人を数多く見つけ、こういう方のために、何かお役に立ちたいと考えた結果のことである。

 電子工作、特に組み込みコンピューターを使った工作の面白さは、無機質な部品を集めて命があるかのようなしかけを作るハード工作の面白さ(プラモデルのようなものでも)だけでなく、ソフトウエアによって自分が考えたとおりに、しかけを思うがままに動かす喜びにあると思っているが、これが他人のソースコードに頼っているだけでは、楽しみは半分しか味わえない。

 ソフトウエア開発は勿論、プログラミング能力以外に、さまざまな別の技術と経験を必要とする専門分野だが、少なくともプログラム開発力、ロジックや、アルゴリズムを作る能力養成には、擬似コーディングがその大きな手助けになると確信している。この話をまたする気になったのは最近の次の出来事がきっかけである。

 AVRの入門サイトでは有名なkumanさんの掲示板が一時閉鎖されたときのことである。心無い人の多重書き込みが閉鎖の直接の原因だとは思うが、実はそれまでに気になっていたことがある。この掲示板に初心者が、プログラムのソースコードをひんぱんに書き込み、それに対して色々な人が助言しているのだが、話がどうもかみあわない。

 問題なのが、すべてがソースコードレベルで議論が進んでいることだ。プログラムの議論なのだから極く当たり前のように思えるが、私に言わせるとこれはまずい。

 ソフトウエアの中で、最も論理性の高いソースコードは、また、最も人間にとって理解しにくい言語だからである。このレベルでプログラムについて議論することは、余程熟練した人でないとお互いの言おうとしていることが先方に伝わらず、おかしなことになる可能性が高い。

 これは、計算機言語を、機械語->アセンブラー->C言語->JAVA(FORTRANやCOBOL)->BASICという順番(最後の2つは議論があろうが)に並べてみると私の言っていることが少し理解されるかもしれない。

 高級言語という言い方もあるが、上の順番が、右に行けば行くほど人間に理解しやすい形になっている。しかし、この右端といえども一筋縄ではいかない。書いてあることを短時間で理解することが難しい。「プログラムは考えた通りには動かない。書いたとおりに動く」という格言が生まれるゆえんである。

 考えた通りにプログラムを作ろうと思うなら、自然言語、つまり普通の言葉で、完全に論理(ロジック)を確認してからコーディングに入れば良い。ところが、ソフトウエアの開発の経験が浅い人になればなるほど、ロジックをコンピューター言語で検証したがる。これが長年ソフトウエアを開発してきた所長の疑問である。

 コンピューターは簡単に言えば用意されたロジックをただひたすら忠実に実行する電気モーターのようなものである。何か知的な賢い判断をするように見えても、それはすべて中に入っているロジックがやるのであって、他に何か別の機械が入っているわけではない。OSなどとえらそうな名前で呼ばれているプログラムでも、全部ユーザープログラムと変わらないロジックのかたまりである。

 ロジックさえ間違いなければ言語は何であっても実現可能である。それなら日本語でこれからやろうとすることを全部説明できるのなら、プログラムは成功したのも同然なのだけど、どうも、このあたりが理解されていない。

キャッシュ方式のEEPROM関数開発で大苦労(4/8/2012)
 そんな能書きを垂れながら、EEPROMのページをキャッシュして1バイトづつアクセスする関数を作り始めたのだが、これが難義した。擬似コーディングの講釈ばっかりで実際にやらなかった「とがめ」が出たのである。

  始めに白状してしまえば、今度の開発では、擬似コードを実際には真面目に作っていなかった(理由はあとで説明)。そのため、プログラムの完成まで、とんでもなく長期間を要した。

 あまりにも思ったとおりに動かないので、てっきりハードか、STマイクロのライブラリに原因があるのではと疑っていたが、わかってしまえば全部、こちらの単純なミスであることが判明した。情けない。

 こういう開発はしてはいけないという見本のような開発だったが、恥を忍んで全部、正直に事実を述べ、今後の問題解決の題材にしていただこうと思う。このブログにも、このあたりをさぼって開発に苦労した話は何度も登場しているが、また同じことをやってしまったのである。

 擬似コードは書いたことは書いた。しかし、コンセプトレベルの擬似コーディングで細かいところまでつめなかった。弁解がましいがこのあたりのソフト開発は現役時代を含めて無数の経験がある。細かいところのロジックは頭の中にあるとばかり、いきなりソースコードを書き始めたのが敗因だった。

 基本ロジックそのものは簡単だ。EEPROMをアクセスするときに、実際にはページ単位にしか読み書きしないようにソフトを構成する。トップレベル、すなわちレコードを記録したり読み出したりするアプリケーションレベルは1バイト単位の読み書き関数でデータを扱う。

裏で、そのデータの存在するページ全体をキャッシュ(単なるバッファー)に読み込み、同じページにあれば、それを返す(read)か、そのキャッシュに書き込み(write)、別のリクエストがあったときは、このキャッシュをEEPROMに書き戻し、リクエストされたページを読み込んで、何食わぬ顔でデータを返す(またはデータをキャッシュに書き込む)。

 ソフトの処理が終わるときには、必ずキャッシュを書き戻す(closeまたはsync)。ディスクファイルなどのアクセスでは定番の方法である。特に珍しい方法でもない。こういうときの常道として関数を3階層に分ける。

 最初のユーザー向けの関数が、EEP_Write EEP_Openなどの、一文字入出力、ストリームの初期化などの関数で、次のレベルが、pg_init,pg_writeなどの、キャッシュページをハンドリングする中間関数、一番下のI2Cを直接動かすところが、I2C_1_の接頭辞をつけた、MPL115と共用しているI2Cの原始関数である(巻末のソースコード参照)。

何が悪かったのかを検証する(4/10/2012)
 コンセプトは固まっている。擬似コーディングは、本来、これをさらに逐次的に細かくロジックをつめる。そして各関数の入出力と機能を整理して詳細に落としていく。ここが肝心なところなのだが、今回は、慣れていることもあって、殆ど省略してコーディングに入った。

 これがやっぱり結果として、大失敗だった。細かい顛末は煩雑になるので省略するとしてどんなところで落とし穴に落ちていたか、列挙してみる。

・STM32がリトルエンディアンであることに気がつかなかった。構造体にmemcpyでデータを移し、これのHigerバイトとLowerバイトをEEPROMアドレスにして、でたらめなアドレスになっているのに暫く気がつかなかった(ロジアナを見て、びっくり仰天)。

・EEPROMの最初のページはデータではなく、ストリームの始点と終点アドレス(リングバッファーなので移動していく)や、シグネチャー(ストリームが有効かどうかを識別する特定の文字)を入れるページにしていたが、ここのデータを正しくプログラムの変数に移していなかった。特にファイルのクローズのとき。

・グローバル構造体の名前が、別のローカル変数と重複していることに気づかず、全く違う変数になっていた。Cコンパイラーは、構造体名と変数名が重複していてもコンパイルエラーにしない。構造体名を使っているつもりが、重複したローカル変数の方になってしまっていることに気づかず、動作が完全に狂っていた。

こうした誤りは、もし擬似コーディングを念入りにやっておけば、それぞれの各部の機能が明確になっているので間違いが初期の段階で見つかるのだが、この整理が出来ていないと、何となく動いたあと、どこに原因があるのか突き止めるのが非常に難しくなる。

Eeprom いやあ、時間がかかった。まあ、四六時中コーディングしていたわけではないが、コーディングを始めて安定してデータが出入りするのを確認するまで、ほぼ1週間かかった。C言語で200ステップ余り。たいした量でもないのに最近になく手間のかかった開発となった。

 途中で泥縄の擬似コーディングを書いたりして大騒ぎの結果、やっと安定してEEPROMにデータが入るようになった。UARTの書き込みコマンドでデータを次々に追記していき、別のコマンドで貯めこんだデータを一気に吐き出す。もう大丈夫なようだ。ただ、このストリーム関数は、リングバッファーになっているので、これを確かめなければならない。

 ヘッダーファイル(I2C_eeprom.h)で設定しているEEPROMの最大バイト数を、256バイトまで縮めてオーバーラップのテストをする。よーし、最初のデータから消されてデータが次々に入り、テストステートメントの開始カラム数が増えていく。念のため2巡させる。これで安心だ。

 次は、待ち時間でごまかしているEEPROMの書き込み終了をチェックするルーチンのデバッグだ。「STM32マイコン徹底入門」で「このとおり忠実に書かないと動かない」と言われていたところだが(P298)、その通りに書いても動かなかった。仕方がないので1msのループを10回やってタイムアウトでごまかしている(10msも待てば十分という計算)。

 上手く行くときというのは、こういうものだろう。腰を据えて1ラインづつステートメントを確認して行って、本と違うステートメントを見つけた。スタートコンディションを自前の関数で出している。

 この自前の関数は、ステップ数を減らすため、スタートコンディションのあと、ステイタスが変わるのを待つステートメントを加えてある。確かに本に書いてある通りではない。これを裸のスタートコンディションを出すだけのステートメントにする。おお、ちゃんと指定どおりのビットに1が立つようになった。

 やっとのことでEEPROMまわりは片付いた。これで気圧計を構成するハードはすべて揃ったことになる。次は、いよいよ本来の気圧計にするためのソフトウエアの再構成と気圧グラフの描画ルーチンの開発である。気圧計プロジェクトは山場を迎える。

 EEPROMのライブラリソースコードをいつものとおりZIPで固めたファイルにして以下におきます。I2C_eeprom.c I2C_eeprom.h I2C_1.c I2C_1.hがそれぞれソースコード、ヘッダーファイルです。なお、MPL115の出力補正や、eepromの読み書きについては、ff.support.cのコマンド'u'や、';','p'のところにあります。このままではコンパイルできませんが、参考にしてください。また、前回記事での、I2C_1.cとは異なっていますので注意してください。

eeprom_lib.lzh」をダウンロード


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

2012年3月25日 (日)

STマイクロのライブラリでSTM32F107のI2Cを動かす

 STM32F107とTFT液晶でグラフィック気圧計を作るプロジェクトは、ベースになるファイラーの使用文字を作者のねむいさんの支援で元の8ドット文字(美咲フォント)から少し大きい10ドット文字(M+フォント)に換えることに成功した。文字を見やすくするためと、グラフィックの勉強を兼ねた修正である。

 プロジェクトの目的は気圧計なので、そろそろ気圧センサーの実装を始めないといけないのだが、はやる気持ちを少しおさえて、さらにTFT液晶の画像処理の勉強を続ける。画面仕様はおおよそ出来ているが、どれだけのことがこの液晶コントローラーで出来るか見極めておかないと先の工作の効率に響くからである(昔の仕事時代を含めて何度も痛い目にあっている)。

S_p3254809

ファイラーを繰り返し動かすことに成功(3/13/2012)
 前にも書いたが、ねむいさんから頂いたTFT液晶のファイラーのソースは、大元はChaNさんのFatFSをSTM32に移植したMartin Thomas氏のソースがオリジナルで、ねむいさんが開発されたファイラーは、このThomas氏のFatFSブロックに間借りする形で入っている。escキーでこれを一旦抜けると、FatFSの機能テスト部に入ったままになり、ファイラーには戻ってこない仕様になっている。

 気圧計は、このファイラーを使うのか、全く独自に作り直すのかまだ決めていないが、このあたりをもう少し動かしてプログラム全体の解析を進めることにした。ファイラーを度々動かしたいので、とりあえずFatFSからファイラーに戻るようにしたが、そのままではファイラーはエラーを吐いてreusableになってくれない。このトラブルシューティングが先だ。

 ファイラーのFatFSあたりの処理を詳しく解析する。各種のサイズの液晶にコンパクトにファイル名やファイルサイズを表示し、ディレクトリ項目でのエンターキーでサブディレクトリに表示を換える手法、ファイルの数が画面を越えたときのスクロールなど、今度の気圧計にはこんな複雑なことはしないで良いのだが、読んでいるだけでとてもためになる。

 ファイラーが、最初は動いて2回目にエラーになる原因は見当がついている。ソースコードをさらに追う。その結果、当初の予想通り、ルートディレクトリを指示するデータエリアが汚れたまま最初に戻るのが原因であることがわかる。ファイラーを動かす前にディレクトリパスを収容するエリアに文字列の終端文字\0を

Line[0] = '\0';

で、クリアすると、ファイラーは何度でも繰り返し実行が可能になった。こんな感じで中味がわかって来ると、ソースの解析は楽しくなる。それぞれの関数が何をやっているのか明確になってくる。ちょうど濃い霧が晴れて周りが見え始めると、急に全体が見通せるようになるのと同じである。

 BMPファイルを読んで描画するところなどが特に参考になる。だいぶ理解が進んだので、グラフを描くための実際の関数の開発計画をたてて、気圧グラフ描画に必要な機能の組み合わせを考える。今のところ直線(縦横)と領域の薄い塗りつぶし、任意の位置での文字出力、画像の重複の処理(重ねるか、描き直すか)などの機能があれば大体思ったようなグラフは作れそうだ。

 直線は、1ラインのレクタングルで描くことになるが、性能的には直接GRAMに書き込む方法もありそうなので、色々調べる。気圧のグラフは、およそ2日間のデータを画面の上部に表示し、その下をテキストエリアにする予定である。更新は今のところ10分に一回で、動画的な要素は全く考える必要はない。しかし、まあ、そこは、凝り性の所長の習い性である。あれこれ調べるのが楽しい。

気圧センサーMPL115A2とI2CフラッシュROMを実装する(3/16/2012)
 グラフの描画に目処がついたので、いよいよハードウエアの実装を始めることにした。既に買ってあった気圧センサーMPL115を基板に取り付ける工作である。取り付ける場所は、2層目のSDカード基板である。

 グラフを出すための気圧データの蓄積はSDカードでも良いが、気圧センサーのインターフェースがI2Cなので、I2CフラッシュROMも実装して、そこにデータを入れることにした。I2CフラッシュROMは以前、フォトフレームの時に買って使っていないのが余っている。丁度良い機会である。

S_p3254818

 手持ちのI2CフラッシュROMは、いくつか種類がある。最初、千石でROHMの16KビットのBR24S16(¥100)を買い、その後、秋月でもっと安くて大容量のチップを見つけて入手した。マイクロチップの24FC256と、24FC1025である(256Kbitで¥90と1Mbit!で¥250)。今度の気圧計では300ドットくらいのグラフにする予定なので、16Kbit(2KB)は小さすぎ、256kbitの24FC256が適当だろう。

 次は気圧センサーである。部品箱に大事にしまってあったMPL115A2を取り出す。この石は、去年の11月、O-familyさんが掲示板で、メーカーのサンプルソースに疑問を投げかけられたときに、ちょっとコメントしたのが縁で、自分も欲しくなり、秋月で衝動買い(キット¥700)したまま4ヶ月以上放置されていたものである。

 気圧センサーとしては、市場にはこれより数段精度の高いBMP085というICがある。これはMPL115より、精度が2桁近く高い(MPL115が±1.5hPaに対し、±0.03hPa)。高度計としての利用を考えているようで、この精度だと1mの高度差まで測れる。

 スイッチサイエンスで基板つきで¥1990で売っている(現在売り切れ。共立エレショップが同価格で売っている)。digikeyでは単品が¥677で買える。ただし、パッケージが面実装のLCC8ピンなので、電極が外面に出ていない。まともに基板にハンダ付けしようと思うとクリーム半田またはホットガンが要る(裏返して実装すれば配線可能だが)。

 精度の高い石にも食指は動くが、こちらは高度を測るのではなく、長期の気圧変化を調べて、天気の予報をしようというのが目的である。ここまでの精度は不要である。当初の予定通りMPL115で実装を進める。

気圧センサーの実装は、この基板以外への移設を考慮してソケットをつける。秋月でおまけに付いているヘッダーピンは、少し長すぎて丸ピンソケットからはみ出るので、ニッパーでピンを短くする。I2CフラッシュROMも、8ピンのソケットにする。

 配線は、2線のI2Cなので簡単である。データとクロックラインに、気圧センサーとフラッシュROMに共通のプルアップ抵抗を入れる。STM32F107のI2Cは2つあり、I2C1につなぐ(PB6とPB7)。アートワークを描くまでもなかったが、念のため作っておいたので、実際の作業は、あっけなく終了した。ちょっと物足らないくらいである。電源のLPFなどはあとで様子を見ながら入れることにする。

グラフィック気圧計の仕様を考える(3/19/2012)
 気圧センサーMPL115を使った気圧計としては、既にO-FamilyさんがAVRを使って実装され、サイトには、ケースに入った立派な時計つき天気予報計が既に作品としてラインナップされている。基板、回路図、ファームまで全て公開されており、至れり尽くせりの措置だ。すんさんもこのセンサーを使ってグラフィック気圧計を作られている。

 当研究所の気圧計は、この二番煎じ、三番煎じということで特に目新しいところは何もない。しいてあげればSTM32を使っていることが違うだけである。高度計として使うのなら電池式や、可搬性を考えるところだが、2日間のデータをもとに出す天気予報計が動き回ることは通常考えられないから、電源は最初から、ACアダプター仕様と割り切ることにする。

 画面仕様は、TFT液晶の解像度240X320で、当面は開発ベースのファイラーと同じ、縦型として使い、グラフは上から下へ時系列として一番下部を最新データとする。

 時間が経過すれば、グラフがそっくり上へ移動して行き、2日間程度の気圧推移を常に表示する。電源を切って測定していない間のデータは出さないで、あるだけのデータが表示される。つまりグラフを表示する時は、現在時刻よりさかのぼってあるだけのデータのドットをグラフに表示する(歯抜けになっても、存在するデータは範囲内であれば表示する)。

 移動平均くらいは表示したいところだ。グラフの縦のドットは下に30ドット(3行)のテキストエリアをつけるとすると280ドット、2日間として1日あたり140ドット24時間とすると、1時間が6ドット足らず。つまり10分に1ドットで48時間で288ドット。テキストは、現在日時に1行、現在気圧の表示に1行、現在の予報に1行で計3行というところか。全体的な画面仕様は決まった。

 制御するところは余りない。データログはUARTから出せばよいだろう。電源を入れれば、10分ごとにデータを記録し蓄積していく。年月日時分単位にデータを蓄積してROMに入れていき、最大まで蓄積すれば、古いものから消していく。

STマイクロのI2Cライブラリを使う(3/22/2012)
 大まかな仕様はかたまった。細かいところは先の話として、次にやるべきことは、MPL115A2を動かすことである。MPL115A2のインターフェースはI2Cで(SPIのA1というのもある)、最初はねむいさんが開発された例の超小型LCD用のGPIOで構成した簡便な手作りソースコードを流用させて貰おうと思っていた。

 しかし、フラッシュROMをつけることもあるし、せっかくだから、STマイクロの提供するライブラリを使って、少し本格的なI2Cインターフェースを構築することにした。

 意外なことに、STマイクロのI2Cライブラリの応用例がウェブ上では余り見かけない。ただ、こちらには、恰好の参考資料がある。例の弁護士さんの書いた「STM32マイコン徹底入門」である。ここには、STマイクロの提供するI2Cライブラリを使った制作例が詳しく18ページかけて載っている。

 ただし、ウェブには、このSTマイクロのライブラリを疑問視するこんなサイトもある。http://www.yza.jp/blog/2010/03/stm32_i2c/ どうもエラー処理がまずいようだ。「徹底入門」もこのとおりにしないとうまく動かないと注意書きがある。

 まあ、ここは忠実に、作例にならってプログラムを組むことにした。長たらしい変数と関数を地道に書いた。ただ、「徹底入門」の提供するソースには初心者にとって致命的な問題がある。機種依存のハードウエアの設定部分が、すべて未定義エラーになる。

 こちらは、既にSTマイクロのライブラリを何種類か利用しているので、何を使えば良いか、すぐわかったが、これをどうするかは、本文のどこにも載っていない(こちらが調べた限り)。初心者は恐らくこのソースコードを忠実に写しても、この未定義変数をどうすれば良いのかで途方に暮れるだろう。

 テストはロジアナを積極的に活用した。まずFatFSの各種の機能を動かすメニューに、UARTのコマンドを追加して、スタートコンディションだけを出すプログラムを組む。それをロジアナでSDA,SCLの2ラインを監視して動作することを確かめる。いつも愛用させてもらっているkuman流の逐次開発手法である。

 次に、マスターWriteリクエストのデータ送信のところまで入れて、スレーブ(MPL115)からのACKが帰ってくることをロジアナで確かめる。ロジアナはI2Cプロトコルが見えるような設定にしておく。

Mpl115i2c おお、ちゃんとACKが帰ってきた。続いてMPL115の測定開始のコマンド、データの受け取りと少しづつコマンドを増やして、無事、気圧と温度データが送られてくるのを確認した。

 ここまで来ると、あとは楽だと思ったのが落とし穴だった。最後の12ヶの補正用の係数データの受信がどうもうまく動かない。最初のデータは来るが、あとはみんな0xFFばかりで、正しいデータを送ってきていないようだ。

 スタートコンディションを再発行(restart)したり、ACKのdisableコマンド(最後のデータ受信のときにNACKを返す)を出す位置を替えたりしているうち、突然、データが正しく送られてくるようになった。何が悪かったのか良くわからないというのがつらいところだが、うまく動くシーケンスになったことは間違いない。まあ、あまり深く追求するのはやめよう。

ここに、MPL115A2を動かす、STM32F107用のI2Cライブラリをzipファイルにして置きます。
I2C_1.cとI2C_1.hが、I2Cの汎用部、MPL115.cと、MPL115.hが、MPL115固有の関数です。
MPL115_Init(); MPL115_Start();で計測が始まり、MPL115_getdataとMPL115_getcoefで、データが
MPL115.hで定義した構造体に収容されます。


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

 とりあえずは順調にMPL115A2からすべてのデータが送られてくるようになった。あとはあの膨大な係数で観測値の補正をすることだが、それにしてもこれだけ簡単に動くようになったのは、O-FamilyさんのMPL115の日本語マニュアルが助けになったことは間違いない。これがあったお陰で開発は迷うことなく一本道だった。あらためて感謝を申し上げておきたい。

Mpl115 マニュアルには、12個もある係数値による測定値の補正ロジックが紹介され、O-Familyさんは、律義にBASCOMで全部の係数の計算式を入れておられるようだが、どうもここまでやる必要があるか迷うところである。だいいち係数の最後の4つはいつ出力しても0になっているし、サンプルソースも小数点以下はすべて切り捨てているようだ。

 そもそもセンサーの測定誤差が、1.5hPaと小数点以上であり、ADコンバーター(10ビット)の分解能そのものが、0.635hPaとかなり大きいので、細かい小数点以下の補正をする意味が余りないような感じもする。すんさんが掲示板で書いていたように、サンプルを多数測定して平均をとる方が精度が高くなるような気もする。

 これらの補正や、フラッシュROMへの蓄積など、気圧計の完成までにはまだ道のりは長いが、気圧センサーからの測定値が出たところで、とりあえずブログに報告することにする。

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

2012年3月13日 (火)

STM32F107のTFT液晶のフォントを大きくする

 東日本大震災から1年が経った。かけがいのない人を失った方々をどうお慰めしてよいか言葉が見当たらない。せめて何かお役に立つことをしてあげたいという気持ちは当然のこととして、生きのびた我々の努めは、貴重な自分の命を、亡くなった人の分まで有意義に使うことだろう。

 そういう意味で、本来、生きている楽しみと喜びのためにやっている趣味の世界で、一部の心無い人のために、長年のみんなの交流の場であったkumanさんの掲示板が閉鎖された出来事は、残念でならない。

 昔の飲み屋には、人のやっていることが気になって何にでも首を突っ込みたがり、訳知り顔で見当はずれの講釈を得々と披露する常連の爺さんが一人や二人必ず居たもので、みんな適当にいなしたり、時には話を聞いてやり(右から左に聞き流すだけだけど)、愉快に一緒に飲んでいた。

 たまに話がこじれて危ない場面になると、さりげなく店のお姐さんが割り込んで、話題をそらし、その場をおさめる。場が荒れれば店の売り上げに響くからである。しかし、それでも言うことを聞かない客を追い出すときの姐さんの迫力は凄かった。なまじのチンピラなら震え上がるタンカを聞いて、姐さんを惚れ直したものである。

 全く対価も得ず単なる好意で開設している電子掲示板の管理人にここまで期待することは酷というものだろう。参加する人々全員が、自覚を持って場を盛り立てる意識を持たないと、結局みずからの楽しむ場所を失うことになる。

S_p3114789 それにしても、社会全体が、雰囲気として「不寛容」になっていることを感ずる。モンスターペアレントや、徹底した嫌煙、極端なまでの「臭い」に対する潔癖などの、最近の風潮は、昔の大人(おとな)の条件、「清濁併せ呑む度量と、悪に対する毅然とした個々の自律した行動力」が失われていることを物語る。

 それはともかく、ブログの更新が20日以上滞ってしまった。3月はいつものように多忙なシーズンで、例年通りの所属団体の全国集会の準備と、恒例のスキー行、確定申告などの、雑用、遊び、仕事のほかに、今年は、娘の嫁入り準備(え、いやアッシーを引き受けるくらいですが)に時間をとられて、電子工作にまとまった時間がとれない。

 TFT液晶でグラフを表示させる気圧計プロジェクトは、やっと液晶に画面が出たことで一気に肩の力が抜けてしまい、先に進む意欲を失った。そんなこともあって落穂ひろいのような工作を細々と続けている(3月12日 記)。

RTCの電池バックアップとリマップされたUART2を基板のRS232Cに接続する(2/20/2012) 
 Aitendoの生基板から作ったSTM32F107基板は、240X320ドットの2.4インチTFT液晶(YHY024006A)にSDカードのファイラーが動いてプロジェクトは一段落した。しかし動いたと言っても、単にネットから人さまの作ったソースコードをダウンロードしてきてビルドしたものが動いたというだけのレベルである。

 今回は、細かい計画を立てずにあてずっぽうでプロジェクトを進めているので進捗が悪い。まあ仕事ではないので、大げさに考えることはないのだが、こういう作業の進め方は確かに効率が良くない。今後の反省材料である。

S_p3124801 次のステップは、気圧の推移を表すグラフを画面上に表示することだが、このTFT液晶での描画ロジックはまだ全くわかっていない。コントローラーのデータシートは手に入れているが、ソースコードは何層にも階層化されており、ちょっと見ただけで修正が出来るレベルではない。ハードルが高い。それでもコードを少しづつ辿ってロジックを勉強しはじめる。それと一緒に気圧計を動かすための周辺のハード機能の整備も始めた。

 まず、気圧の表示では実際の年月日が必須なので、RTCをまともに動かしてやらねばならない。Vccと直結されているVbatをボタン電池でバックアップする工作を始めた。この工作は前に何度もやっている。手馴れた工作だ。

 CPUチップの背中にカプトンテープと瞬間接着剤で、ボタン電池フォルダーをつける。UEW線で基板のVbatパターンと接続する。問題なく動いた。これで電源を切っても、時刻を刻んでくれる。

 次は、リマップされたUART2まわりの整備である。リマップされたUART2のPD5,PD6は別のピンヘッダーを追加して、そこに出しているが、せっかくRS232Cインターフェースがついているのに(AN3202)、元のUART2ピン(PA2,3)が使えないのは無駄である。基板上で接続換えをする。

S_p3124803 基板上のパターンを切り、0.2mmのUEW線を裏に配線する。シリアルへのパターンを切られた元のPA2,PA3は基板上のソケットに出ているのでこれらのピンは汎用GPIOに使える。

 こういう細かい作業をしていると時間を忘れる。これも一種の中毒かも知れない。テストする。始め、動かなくて焦ったが、ハンダ不良がみつかり(例のUEW線のハンダ不良)、これも問題なく動いた。シリアルアダプターがひとつ減らせて机の上が少しすっきりした。

描画のロジックの分析を進める。だいぶわかってきた(2/24/2012) 
 ソースの解析を少しづつ進めている。このねむいさんのソースは、どうももともとはMartin Thomas氏のSTM32版のFatFSがオリジナルなようで、これが構造上残っている。そのため少し無駄な動きがある。mainループは2つの大きなプロセスをUARTからのコマンド入力でスイッチするようになっているが、調べた限りでは、もう一方の部分は動いていないようだ。

 TFT画面のコントロールは、filer()というモジュールにつめこまれている。その下の画面の操作関数は、ほぼ全てがts.cにある。filer()そのものは、FatFSのプロセスの最初に入っていて、一旦これを抜けると、それ以降はすべてUARTでの操作に限定されてしまい、元へ戻ることが出来ない。グラフィック気圧計に向けて大まかな制御をどうするかで頭を悩ます。

 そのうち、BMP(ビットマップ形式)ファイル表示のソース解析をしていて、キーボード入力で画像をずらして全体を表示できる機能を発見した。これは便利だ。いくつかのBMPファイルを入れて楽しむ。ただ、速度はこのコードでは余り速くない。BMPでの全画面の動画は無理なようだ。

S_p3104778 shuji009さんから画面の横向け表示をお願いされた。それもやりたいが、こちらの不満は、今の8ドットの美咲フォントが小さくて視認性が良くないことである(年をとると細かい字が苦手になる)。Makefileとソースを見ると、10ドット×10ドットのM+フォントが実装されているようなので、これを入れようとあれこれいじるが、これがどうもうまく動かない。

 やっとビルドが通ったと思ったら、フラッシュサイズオーバーフローで振り出しに戻る。FatFSをReadOnlyにしたり、不要と思われるファイラーのコマンドを減らしたりしてメモリを縮めるが、あと10KBが減らない。ChaNさんのコードはさすがである。コードの効率が高い。ロジックをなくしても、フラッシュは思った程減ってくれない。

 徐々にTFT液晶の描画ロジックがわかってきた。始めは、リニアーなVRAMアドレスを2バイトごとにアクセスしてなどと大層に考えていたが、コマンドで方形の描画領域(rectangle)を指定すれば、そのなかでのデータをピクセル単位に線形に送るだけで描画できることがわかった。

 しかも、このとき方向と始点を指定して描画が出来る。ひとつひとつビットマップデータを細工しなくても文字が縦横表示できる理屈だ。これは楽だ。グラフや、JPEGなどの行単位のデータは、細いレクタングルを指定すればよい。

本題の電子工作は一時お休みしてLM2735のDCDCコンバーターをつくる(2/26/2012)

 レクタングルで縦横の描画が出来ることまでつきとめると、また、すっかり安心してしまって、先に進まなくなった。いつもの悪い癖である。しかも、確定申告の日程がせまってきたり、次女の縁談の行事があったりして、気持ちが集中できない。こういうときは、何も考えずに手を動かす工作をしていると気が紛れる。

 これまでメインの工作とは別に、少しづつ準備していた工作を本式に開始した。リチウム電池を使った9Vの乾電池006Pの代替品を作る計画である。

S_p3114783 006P乾電池は、楽器のチューニングメーターや、このあいだ手に入れた秋月のDCM、ストロベリーリナックスのLCメーターなど、ちょっと古い電子機器では定番の電池だが、結構消耗が早く交換がばかにならない。これと同じ大きさで、リチウム充電池とDC-DCコンバーターで9Vをだす装置をつくろうというものである。

 リチウム電池は扱いが一般には極めて難しい。ゲーム機やデジカメのバッテリーとしては売られているが、部品の形で一般の市場に出回ることは殆どない。特にリード線の出た電子工作に使えるような汎用品が店頭に出ることは滅多にない。事故がこわいのだろう。

 もちろん全く売ってないわけではない。売ってはいるがべらぼうに高い。秋葉原あたりの大手の部品店にあるリチウムバッテリーは保護回路がついているらしく小さなものでも¥1000以上する。

 しかし、こちらはこれまでLPCMプレーヤーで、充電用のICを何種類か使用してノウハウが溜まっている。充電用のICで充電している限りはまず安心だ。去年、インドアプレーンの通販サイトで端子タブのついた手頃なリチウムバッテリーを見つけ3個ほど買ってあった。

S_p1074568 届いたリチウム電池の写真である。郵便で届いた。350mAhふたつと240mAhひとつ。この店では、それぞれ¥450と¥350。但し端子タブがでているだけで、リード線などは自分で付けなければならない。

 開封して中味を確かめる。おや、この端子、アルミではないかい。どういうつもりだろう。素人にいじらせたくないということか。実際に試してみる。フラックスを十分つけて慎重に半田ごてをあててみた。いやアルミではなかった。簡単にハンダが乗った。2つの電池にリード線をつける。カプトンテープで絶縁し、2Pのコネクターでリード線を出す。

 DC-DCコンバーターのICはLM2735である。CHANEYのガイガーカウンターキットの電源にこの前使った。元々は、ストロベリーリナックスで買った9~20VのDC-DCコンバーターで使われていたICである。フォトフレームの時にこれを使って調子が良いのでDigiKeyでICだけ入手した。

 今度もDigiKeyで、このあいだのDragonを買うときの送料のゲタに3つ買ってあった。これを006Pの電池サイズにリチウム電池と一緒に実装できる大きさの基板につめこまなければいけない。

 久しぶりにアートワークを真面目に作ってあれこれ検討する。楽しい。ガイガーカウンターのときのコンバーターと違って、リセットICを使った過放電防止回路まで内蔵させる。苦労の結果、前より大分小さくすることが出来た。006Pのスペースにコネクターごと入りそうだ。嬉々として実装に入る。こういう何も考えずに小さな部品を基板に詰め込む作業は理屈ぬきに面白い。

S_p3114786 出来上がった。気楽に通電する。この前は一発で動いたので軽く見ていたが、今度はピクリとも動かない。そのうち配線間違いを発見して(補償コンデンサーの位置まちがい)、修正したがなおも動かない。ストレス解消の工作が、かえってストレスを増加させる工作になってしまった。

 あちこち触った挙句、わかった原因はLM2735の不良だった。どこかで壊したのだろうか。補償コンデンサーの配線違いだけで壊れるのだろうか。いずれにしてもチップを取り替えたら、何の問題なく9Vが出た。逆電圧をかけたのかもしれないが、気分が悪い。

ねむいさんに助けられてフォント大型化に成功(3/11/2012)
 団体の全国集会(といっても大阪と名古屋だけだが)で出張先の京都から帰ってきた。そろそろ、TFT液晶のプロジェクトも再開しないといけない。過放電防止回路のついたLM2735の長期テスト(電圧低下のときのリセットICの振る舞いの確認)をやりながら、久しぶりに工作室にこもってEclipseを開き、TFT液晶の10ドットフォントの表示に挑戦する。

 グラフィック気圧計は画面仕様も確定していない。そうなると、やるべき方向が具体的に決まらず、散乱した調べ方になるので非常に効率が悪い。こういう開発をしてはいけないという典型的なパターンだが、もう今さら元へ戻るわけにもいかない。既定路線で行くしかない。

 そうこうするうち、問い合わせていた、ねむいさんから朗報が届いた。メモリリダクションの手順である。コンパイラー最適オプションは、オリジナルは速度重視で、フラッシュ節約重視ではなかったこと、FatFSの日本語ファイル名表示で必須と思われていたLFN(LongFileName)は、必ずしもそうではなく64KBのコードブックは省略できることなどを教えられた。

S_p3114800

 喜び勇んでMakefileを修正する。コンパイラーオプションは残しておいて、LFNだけ無効にする。祈る気持ちでビルド。おおー、通った。サイズは220KBばかり。そりゃそうだ、64KB丸々減ったのだから。

 テストする。よーし、10ドットのM+フォントが出た。うーむ、思ったほど大きくならないな。しかし、肉眼でファイル名は読める(8ドットでは虫眼鏡が必要なくらい小さい)。やれやれ、やっと懸案のひとつが片付いた。中途半端だけれど、このあたりでブログに報告することにする。

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

2012年2月19日 (日)

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データを送って割り込みを開始するようにした。何とか大量のデータ送出は問題なくなったが、前の記事をアップした後も、これが気になっていろいろと考えていた。

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

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

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

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

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

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

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

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

Usb11 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ドライバーに、いそいそとつける。ありゃあ、全く動かない。シャフトをさわると電源を入れるたびにピクピク動いているので配線間違いの可能性が高い。

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

S_p2124625 スペック通り、つなぎなおすと無事、勢い良く廻り始めた。逆転も停止も順調。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、タッチパネルなど沢山のハードを盛り込まねばならない。

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

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

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

S_p2124633 はじめに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.1%以下の誤差だ。殆ど正しい。クロックは問題ないようだが、それでも字が化ける。おかしい。

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

遂にTFT液晶(YHY024006A)が正常に表示された(2/17/2012)

 良いぞ。端末にソースコード通りのメッセージが戻ってきた。入力も受け付ける。RTCも動いているようだ。ソースコードはなるべくいじらないようにした効果が出たようだ。SDカードからデータを読んでとりあえずはファイラーまでは動いた。

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

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

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

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

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

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

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

S_p2184658

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

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

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

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

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

2012年2月 4日 (土)

STM32F107でやっとUSB仮想端末が動いた

 前回の記事以来、もう20日近くが経ってしまった。何故か2012年の電子工作は遅々として進まない。特に他の事で忙しいというわけでもない。ただ、どういうわけか意欲が湧いてこないのだ。とりとめもないことばかりに時間が過ぎて気分が乗らない。いわゆるスランプというやつだ。

 まあ、こういうときもある。人生にはまだまだ時間がある(そうゆっくりもしていられないが)、たいした成果も上がっていないけれど備忘録を兼ねてこの間の経過報告をしておくことにする。

S_p1314614

やっとDFUが動いてプログラムが書けた(1/16/2012)
 生基板からのSTM32プロセッサー基板がやっとのことで動いて、プロジェクトは次のステップ、ファームの開発に移った。統合環境Eclipseを立ち上げる。EclipseでのSTM32のソフト開発は、フォトフレーム以来ほぼ1年ぶりだ。

 半年前にはFreeRTOSをやっていたが、同じARMでも石はNXPのLPC2388で微妙に環境が違う。情けないことにEclipseはともかく、STM32のプログラミング環境などは見事にみーんな忘れていた。

 リハビリのつもりで、少しづつ以前のプロジェクトのソースコードを見ながら、ブートローダーから先の手順をゆるゆると進める。CPUは、前の騒ぎでSTM32F103に戻ってしまっている。103と107はピンコンパチで、こんどのグラフィック気圧計は、特に107でなくてもかまわない。何しろ100ピンのCPUの換装はおおごとだ。とりあえずは103のままプロジェクトを進めることにする。

 まずはCQ-STARM基板の状態にもどそうと、ブートローダーからDFUを焼くことにする。ファーム書き込みの手段は増やしておきたい。中華シリアルプログラマー、MCUISPは好調だが、いつ何時動かなくなるかわからない。STマイクロ純正のライターFlushLoaderは、103に戻したら動かなくなっている。用心に越したことはない。

Ws000000

 もう4年も前になる付録の雑誌号を引っ張り出して全体を復習する。DFUそのものは、以前ねむいさんのところから頂いたソースを使う。MCUISPは快調にプログラムを書き込んでくれるが、一向にUSBが動かない。PC側のプログラマーDFUseが基板を認めない。

 そのうち、DFUモードというのがあって、I/Oピンのひとつをグランドに落とさなければDFUにならないことに気づいた。基本的なところをすっかり忘れている。お馬鹿な話である。早速、PB9を1kΩでプルダウンする。ただ、このソースがこのピンで良いのか確認するのにえらい時間がかかった。考えてみれば、このDFUはCQ-STARM基板用なので確認する必要もなかったのだが、何しろ昔のことで周りがすっかり見えなくなっている。

 最初、動かなかったが、何度かUSBを抜き差ししたり、リセットを押しているうちに、PCのディバイスマネージャーのところにDFUのアイコンが出た。 コネクターに抵抗を差し込んでいたのが接触不良だったらしい。DFUseを立ち上げると、ちゃんとボードを認識した。

 しかし、このあとも難儀が続いた。DFUで適当なプログラム(仮想UARTモニター)をファームに書き込んだのは良いのだが、このプログラムが動かない。さっきのピンをはずしてもプログラムモードに行かないのである。

 これも、このピンをプルアップしなければならないことを忘れていた。Vccから1kΩをつないで無事、USBを通した仮想UARTモニターが動いた。やれやれ、これで一段落である。¥450のCPUボードがやっと日の目を見た。

103から107へまた換装しなければならない(1/19/2012)
 勢い込んで、ねむいさんが最近、集大成してくれた、STM32ファミリーでこのTFT液晶が動くソースコード一式をネットからダウンロードした。当初はスクラッチからTFT液晶のコマンドレベルのドライバーを書こうと意気込んでいたのだが、ウェブで上記のソースを見つけた途端、意欲が一気に失せた。

 へそ曲がりではあるが、意気地のないへたれである。折角、先人が苦労して作ったものを使わない手はない。何も無理をすることはないと勝手な理屈をつけて、ありがたくソースを頂戴する。このソースは、ChaNさんのFatFSが入っており、ファイラーにもなる。

 ハードはまだ未配線だがビルドだけでも通してみようとEclipseにソースチェーンを展開して、コンパイルの準備をする。このソースは、107用のソースなので103向けに換えてやらなければならない。MakeFileで103の環境変数を設定する。しかしmakeは何故か最初のところで門前払いである。

 ファイルではなくコマンドがないと怒っている。暫く悩んでいたが、MakeFileに新しく追加されていたシェルの置換ステートメントを訳わからずにコメントアウトしていたことがわかり、これをはずしてやっとコンパイルが進み始めた。

 いくつかのライブラリ定義漏れを修正して、これは通りそうだと思っていたら、見かけないエラーでビルドが止まった。エラーメッセージを読む。あっちゃー、フラッシュサイズオーバーだ。このTFT液晶+FatFSモデルは、要求メモリとSRAMが大きく、フラッシュ128KB、SRAMが20KBのSTM32F103VBT6では動かないことがわかった。「振り出しに戻る」というやつである。

 仕方がない。折角つけて正常に動いていた103をはずすしかない。107に移し変えなければ先に進めない。3回目のLQFPのハンダ付けはさすがにきつい。一度外した面実装のICチップは、ピンをいくら目視で揃えても、あちこちが微妙に歪んでいるので、ハンダ付けをルーペで見直すと、冷や冷やするところが続出している。

 下手にやり直すのは危険だ。前やったようにパターンごとはずす恐れがある。この基板は安いだけあって、パターンが弱い。気楽にはいじれない。それでも、どうしようか迷うところが数箇所ある。ハンダ付けは問題ないようだが、ピンと隣のパッドが近接して危ない。

 何度もルーペを換えてチェックしたが、結局そのままにすることにした。テスターでショートだけはしていないことを確認する。思い切って通電する。よーし、ブートローダーまでは通った。各ピンが本当につながっているかどうかの確認は実際にそのピンを使ってみないとわからない。とりあえずは、これで行こう。

STマイクロのUSBライブラリが大きく変わってしまった。(1/20/2012)

 103のときと同じ手順で先に進む。まずDFUのソースをSTM32F107で動くようにMakeFileを調整する。何とかビルドが通った。テストする。順調にMCUISPと、フラッシュローダーが107を認め、DFUの書き込みに成功した。DFUSeが107で動いた。ねむいさんが以前ブログで指摘していた107のブートローダーのERRATAは幸い発生しなかった。まあ、まだ何もペリフェラルをつないでいないからだろう。

 次はDFUそのものの動作確認である。103で動いたUSB仮想端末モニターのファームをロードしてみた。何の問題もなく書けた。しかし、モニターは動かない。PCでは不明なディバイスと表示されるところまで動くが、仮想UART端末としては認めないのである。

 動かない理由はすぐわかった。USBライブラリが古すぎて107では動かないのだ。2年前に開発したUSB仮想UARTモニターは、雑誌についていたSTマイクロのUSBライブラリV1を使っている。107はV1では動かない。

 それなら仮想UARTモニターのUSBライブラリを107が動くV3に換えれば良さそうなのものだが、これが難しい。STマイクロのUSBライブラリーはV1からV3で、大きく変わっている。というより、103と107では、USBそのもののハードが変わっていて(107はUSBのOTG機能が追加されている)、ユーザープログラムで使っていた関数や変数が殆ど変更されている。ライブラリを単にV3にしただけでは、次から次に未定義エラーが出る。

 こうなると意地になるのがいつもの癖である。冷静に考えれば、元々は気圧計のためにSTM32F107を動かそうとしている。そこでUSBが動こうが、動くまいが本筋とは関係ない。さっさとやめて本来の開発に戻れば良さそうなものだが、これが出来ない。

 103で快調に動いていたダブルバッファーを使った仮想UART端末が新しいチップで動かない(動かせない)というのが、しゃくなのである。変なこだわりがある。このまま放置して先に進めないのだ。まあ、このへんがアマチュアの特権である。やりたいようにやる幸せ(?)をかみしめて、こだわることにする。

 暫くEclipse上で苦闘する。未定義変数を検索して必要なドライバーを探す。Eclipseのサーチ機能は強力なので、どこで定義しているかはすぐわかる。あれえ、ちゃんと定義されているのにエラーになる。おかしいな。そのうち気がついた。ソースコードにあっても、107を選んだ時に#ifdefなどのプリプロセッサーでなくなってしまう。ひとつひとつのソースレベルまで見ないとわからない。

 半日近く、ソースをいじりまわして納得した。これはやっぱりあきらめるしかない。107には、103と違うハード(USBのOTGなど)がついているので、ライブラリの構造が大きく変わっている。今までのやり方の手直しぐらいでは動きそうもない。USB仮想UARTは道半ばだが、諦めることにする。ロードが大きすぎる。それにこれが目的ではない。

 ようやく、あきらめた頃である。何とウェブでまたも、ねむいさんの記事がヒットした。STM32F107でVCOM(USB仮想UART端末)を動かしたデモプロジェクトである。なんだ、なんだ、ちゃんと動いているソースがあるじゃないか。またまたねむいさんである。ありがたくソースをいただいた。

STM32F107の仮想UARTのソースでも泥沼(1/23/2012)

 ねむいさんのソースは、STマイクロのV3ライブラリのVCOMのデモがベースになっているようである。実はこれを探していたのだが、自分では見つけられなかった。みんなが言っているようにSTマイクロのサイトは欲しい情報が実に探しにくい構造になっている。誰のためのサイトなのだろう。

 ビルドそのものは、前に一回通しているので、Makefileの修正は楽で、順調にビルドは進んだ。MCUISPでファームを焼く。このSTマイクロのVCOMデモソースは、標準のUART1とUSB仮想UARTをつなぐブリッジ機能のデモである。USBケーブルを差し込んで電源を入れる。良いぞ、PCが107のUSB仮想UARTを認めた。これで一歩前進だ。

 次に、PCのシリアル端末ソフト(Teraterm)で、通常のCOM1のシリアルコンソールも立ち上げる。2枚のシリアル端末を前にしてキーボードを叩く。しかし、どちらから打ってもデータは行き来しない。

 うーむ、ビットレートが合っていないのか。ソースコードの通りUSB-UARTを11520bpsパリティ無し、ストップビット1、COM1を9600bps、奇数パリティ、などとするが、うんともすんとも言わない。

 こちらの目的はCOM1とつなぐためではなく、前やったように単にUSBの仮想UARTを動かしたいだけである。不確定要素のあるハードのCOM1のUARTの方は余計だ。コードを削って、前にやったような仮想UARTモニターにしようとソースをいじり始めた。

 しかし、このVCOMのソースコードは何かおかしい。特に、USBのエンドポイント周りのコーディングは、同じような処理が複数あって混乱する。新しく加わった新機種(STM32F107クラス)のために#ifのプリプロセッサーで分けて機種ごとにコードを追加しているので余計読みにくい。ソースコードが年を経て劣化するというやつである。安易な#ifの使用は、あとが大変で、こんなコードを書いていると、書いた本人でもこの先メンテナンス不能になるのではないかと心配になる。

 それにしても、UARTとUSBのバッファーの間のデータ移動ロジックは稚拙としか言いようがない。受信したUARTデータのサイズとUSBのパケットサイズを比較しながら無理やりデータを移している。まるで素人が書いたようなプログラムである。

 要するに目の前のデータの形に気を取られて、本質がわかっていない。こういうときは、ストリームの概念を持てばプログラムは非常に簡単になるはずで、少し大きめのリングバッファーかFIFOに一旦データを移して、そこからUSBのエンドポイントのパケットサイズ分を採っていけば良い。

 それにしても、ひどいコーディングだなあと思っていたら、違う視点でこのコードの不安について書いているサイトを見つけた。

全く同感である。USBの割り込みが2箇所あって、排他処理しているのは良いが、全く同じような処理が重複している。バッファーの終端処理が考えられていない。このページの通り、バッファーを使っているのに、リングバッファーとして使わず、2048バイトという大量の容量にして、その管理をサボっている。

 そもそも、オリジナルのソースでは、UARTの速度が9600bps、USBが115200bpsなのに、USBからのデータは受け取るばかりで、ソースには何らかのフロー制御をしている形跡がない。フロー制御をしなければバッファーをどんなに大きく(2KB以上)とっていても、持続して送受信を続けることは出来ない。

 こんなソースを書いてはいけないという見本のようなものだが、悪態をついたところで正しい修正が行えるわけではない。黙々と、少しづつ直していくしかない。しかし、スランプなので、集中してデバッグする気力がなかなか生まれない。

やっとのことでVCOMが動いた。しかし不安定(1/28/2011)
 やれやれ、やっとSTM32F107の仮想UARTが動いた。しっかし、えらい時間がかかった。やっぱり、ヤキが廻ったとしか言いようがない。モチベーションが低い時に作業を無理に進めると、こういうものである。

 USB仮想端末は、実行のたびにUSBケーブルを抜き差ししないと動かないことを思い出し、動き始めた(最初から動いていた)のは良いが、どうしても文字化けが解決しない。1文字のエコーバック程度なら問題ないが、複数データの送信では正しく送られない。

 ねむいさんのブログにも、このソースについての不安が同じように出ていたが、わかってしまえば、いつものように自分のお馬鹿な基本的ミスで、とりあえず問題は解決した。USBのエンドポイントバッファーに書き込む配列の番号がオリジナルのままになっていた。これでは、常にデータを送り終わったところが始点で、いつもゴミを送ることになる。字化けするはずだ。

 これをバッファーの最初、&EP_Buffer[0]にすることで字化けしていた複数データは一応正常に表示された。やれやれ。しかし謎が残る。何故1文字の時、正しく出たのだろう。1文字のときでも化けるはずなのだが、1文字の時は正常に送出される。謎である。

 とにかく、前のV1のライブラリを使った103の仮想UARTと同じような動きはするようになった。ただ、まだsystickを使ったタイマーは動かないし、ちょっと多量に送ると半分以上欠落するし、頻繁にハングする。まだボロボロでとても完成と言える状態ではない。

V3から導入されたハードのエンドポイントバッファーに書き込む関数SIL_WRITE()が不調である。パケットサイズ一杯に送ると、データを半分以上落としてしまう。パケットサイズの半分にすると、大体動くが、それでも4 KB以上を一気に送ると、ハングしたり、データの欠落があり安定しない。それにしても、このVCOMのコードはV3になっても色々なところでたたかれているようだ。

 でも、まあ、とにかく、USB仮想UARTは動いた。これでやっと、VCOMの縛りから逃れられた。そろそろ本筋のTFT液晶の工作に移らなければいけない。

脱線ついでにSTM32でタイマーを実装(1/31/2012)
 と、意気込んでは見たものの、一向に工作の意欲が湧かない。CPU基板の上にのせる液晶、SDカードソケットなどを載せるサブ基板のレイアウトがなかなか気に入った構成にならない。モジュラージャックは、べたアースの基板を使いたいが、そうすると基板が三重になってみっともないしと、あれこれ迷っているだけである。

 で、相変わらず、また脱線してしまった。タイマーの実装である。経過時間を示す1ms単位のTickタイマーは、USBの新バージョンでsystickを使われてしまって動かなくなっている。ちょうど良い機会だ。今まで面倒なのでやってこなかったSTM32のタイマー実装に挑戦してみた。予想通りこれがどうして、手ごわかった。

Stm32

 弁護士さんの書いた参考書「STM32マイコン徹底入門」は、このあたりが100ページ近くにわたって詳細に紹介されていて、なかなか役に立つが、それにしても設定パラメーターが恐ろしく多い。とても最初からやってられない。結局、自分でいちから書くのをやめ、ひとさまのソースを拝借して、0.5秒のタイマーを作った。

 ソースの丸写しである。LEDチカチカで成功を確認する。単純なオーバーフロー割り込みのタイマーだけで16行の定義である。いやあ、これは大変だ。まあそれだけ機能が多いということなのだが、どうみても入門者には無理だ。

 しかし動かしてみると、USB仮想UARTがタイマーで字化けする。本来あってはならない状態なのだが、理由がわからない。このあたりでその日の気力を使い果たした。
何かの参考になるかと思い、コード例をお示しする。

void TIM2_start(void)
{
NVIC_InitTypeDef NVIC_InitStructure;    //割り込みベクタのインスタンス定義
TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; //タイマー定義構造体
TIM_OCInitTypeDef TIM_OCInitStructure;  //コンペアマッチ構造体(今回不使用)

RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); //クロックを起動

NVIC_InitStructure.NVIC_IRQChannel = TIM2_IRQn;      //TIM2割り込み定義
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;

NVIC_Init(&NVIC_InitStructure);         //割り込みベクターの初期化

TIM_TimeBaseStructure.TIM_Period = 14280-1;    // カウンターの上限値
TIM_TimeBaseStructure.TIM_Prescaler =360-1; //プリスケーラー値
TIM_TimeBaseStructure.TIM_ClockDivision = 0; //キャプチャークロック分周
TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; //増加カウント

TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); //上記定数でタイマーを設定

TIM_PrescalerConfig(TIM2, 4,TIM_PSCReloadMode_Immediate);//プリスケール再設定

TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE);  //上限値で割り込み許可;

これは設定だけで、このほかに割り込みハンドラーのコーディングがある(略)。
オリジナルは、ここのページである。

S_p1314617


ダブルバッファーにしてSTM32F107の仮想UART端末完動(2/4/2012)

 V3の仮想COMデモをベースにしたUART仮想モニターは動いたとはいえ、データは欠落するし、たまにハングし、まだ使い物にはならない。もともとソースがひどく読みにくかったので、リングバッファーを使った処理に殆どの部分を書き換え、見通しが良くなったのだが、どうにも安定しない。Sof_

 タイマーを入れて文字化けする問題は、タイマー割り込みが計算違いでマイクロ秒単位で起きていたことがわかり、1ms単位になるようにして解決したが、不安定なことは変わらない。

 こうなると意地である。ロジアナを持ち出して、本格的なデバッグ体制に入った。基板についているLED、2 ヶをロジアナのプローブ点にして、各ルーチンの動きを探る。USBの資料も読み直して、ロジックを勉強しなおす。

 STM32のUSBライブラリは、V3でUSBホストにもなるOTG機能がついた。このためにUSB制御の階層がさらに増え、エンドポイントのバッファー操作が直接出来なくなっている。そのため、このV3のVCOMでは、データ送信のキックは、送信エンドポイント(USBにとってはIN方向)の書き込み後の割り込み(EP1_IN_Callback)ではなく、USBの定期的な割り込み、SOF割り込みで行われるようになっている。

 このため、マイコンの中での送信要求は、このSOF割り込みがms単位と長いので、実際にUSBを通してPC側に送られるデータが多量に溜め込まれて待たされることになる。片側がUARTならそう問題ないが、マイコンの中の送信要求は、べらぼうに早いので、これがハングやデータ欠落の原因になっているようだ。

 未送信のデータでバッファーが一杯になれば、マイコン側の送り込みを待たせ、そこからエンドポイントバッファーに書き込んでいくロジックになってはいるが、この多重処理をしているうちに、ハングアップしてしまうようだ。

 だいたい、この新しいSTマイクロのエンドポイント書き込み関数SIL_WRITE()は、パケットサイズの64バイトまでフルにデータを入れて、エンドポイントに立て続けに書き込むと、それだけで確実にフリーズする(半分くらいだと大体大丈夫)。どうも下位ルーチンがバグを抱えているようだ。恐らくエンドポイントの処理中に入るハード割り込みを止めていないのでレジスターが壊されているのだろう。

 思い切って、このV3のやりかたを捨て、前に成功しているダブルバッファー方式に換えることにした。この方式は、ユーザーの送信要求をパケットサイズ単位で待たせることになるので、USB側に多くの負担をかけることがない。SOF割り込みは使わない。最初のキックは、前と同じように、片側のバッファーでダミーデータの空打ちをする。

Photo

 V1のコードを丸々、こちらに引き込む。大した作業量ではない。ビルドする。おお、フラッシュサイズも4KB以上小さくなった。ファームを書き込む。さあ、どうだ。動くか。よーし、オープニングメッセージが出た。エコーバックも大丈夫なようだ。次は問題の大量メッセージ送信である。

 まずは、1000バイト。問題ない。次は、2000バイト。オリジナルのVCOMでは滅多に成功しない量だ。問題ない。いいぞ、いいぞ、送信量を増やして行く。遂に13KB(リターンキーだけだとx0Dで13)でも全くハングもデータ欠落もなく画面に出力が表示された。速度は前と同じ2Mbps(前のV3オリジナルでは、とりあえずすべて受け入れるので4Mbps以上だったが、動かないことには意味がない)。

 なーんだ。最初から、このダブルバッファー方式にして置けば良かったのだ。久しぶりに解決したときの興奮を味わう。やっぱりこれが味わえないと電子工作らしくないな。気分が良くなったところでブログに報告することにする。

Vcom

 以下に、Eclipseのプロジェクトフォルダーとして入ったソースコード一式のzipファイルを置きます。STマイクロV3のペリフェラルとUSBライブラリは、5MB近くあって、このブログの容量制限で載せられないので、正規サイトなどで落とし、フォルダー名を上記プロジェクトフォルダー直下のlibとして下さい(um0424のSTM32_USB-FS-Device_Lib_V3.3.0内にあります)

詳しくは、同梱のmakefile参照。ねむいさんのソースから変更したのは、main.c usb_endp.c hwconfig.cの3本だけです。

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

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

2012年1月15日 (日)

STM32基板が動かなくなった意外な原因とは

 前記事から2週間近く経ったが、電子工作の進捗ははかばかしくない。今年も新年早々からまたお馬鹿な失敗をご紹介することになった。なぜか当研究所の電子工作は、いつも、はらはらどきどきのドラマの連続である。

次のプロジェクトはグラフィック気圧計か(1/4/2012)
 お正月が明け、Dragonのデバッガーもとりあえず順調に動いて一段落である。今すぐやらなければならない工作は当面なくなった。次のプロジェクトだが、これが、何にしようか迷っている。O-Familyさんと、すんさんが始めた気圧センサー(MPL115A2)の実装をそろそろ始めようと思っているが、いまひとつ意欲が高まらない。

 どうせ、作るなら単なる後追いではなく、何か少し面白いしかけを加えようと欲張っているので、具体的な計画がなかなか考え付かない。そのなかで思いついたのが、大分前にAitendoから買った2インチTFT液晶モジュールと、STM32用の生基板を活用するアイデアである。

 この2つの基板は、確かガイガーカウンターの高圧用部品を買うときの送料コスト低減のため特にあてもなく買った基板で、具体的な目的がないのでそのままになっている。2インチTFT液晶モジュールは、去年のトラ技誌2月号で記事になったYHY024006Aである。 一方のSTM32基板は、部品の載っていないプリントだけのCPUボードで、CPUは、100ピンのSTM32F103用である(¥450)。

S_p1154588 すんさんが、このあいだグラフィックLCDで気圧の遷移をグラフに表示した気圧計を掲示板で発表されたのを見ているうち、この液晶を使うことを思いついた。気圧のグラフは更新単位がほとんど時間レベルなのでTFTのドライブは8ビットのAVRでも十分だが、ここはSTM32基板を一緒に使おうと思う。

Ws000000_2 今やSTマイクロのARMプロセッサーは、STM32F4XXシリーズの時代になってしまっているが、実は当研究所にはSTM32F103とSTM32F107の2つのCPUチップの在庫がある。

 2年前、FPGAでフォトフレームを作ったとき、JPEGのデコードでSRAMが足らないので、雑誌付録基板(CQ-STARM)のCPUをSRAMが64KBあるSTM32F103-VE6に換装し、ついでにその頃は新製品のSTM32F107をDigiKeyで買った(¥1365)。DigiKeyの送料のゲタに使ったので具体的な用途は決まっていない。Aitendoで生基板を手に入れたのは、これを実装しようと考えてのことである。

 この石は、LPC2388と同じようにEtherNetの論理層(TCP/IP層)や、I2S(デジタルオーディオインタフェース)を持っているし、フラッシュ256KB、SRAMも64KBある。がた老AVR研究所ではまだまだ旗艦クラスの立派な32ビットプロセッサーである。

 気圧センサーMPL115A2を動かすだけには、少々役不足(もったいないという意味)だが、在庫整理ということでは申し分がない。すんさんが実現させてしまっているが、気圧の変化をグラフにすれば人間も天気予報に参加できる。カラー表示が出来るし、ネットワークで飛ばすことも出来る。先の長い話だが、これをプラットホームに進めていこうと考えた。

 STM32基板の方はこの基板で使っている表面実装の3端子レギュレーター(AMS1117 ¥100)をAitendoで見つけて、半田付けしたり、チップコンデンサーをつけたりして少しづつ実装を進めてきた。手を動かしていないと落ち着かない性分になってしまっている。これが結構、楽しい。ただ、このSTM32基板はXtalを除いた部品がすべて表面実装品で、そう簡単には部品は揃わない。

100ピンLQFPのハンダ付けで冷や汗(1/5/2012)
 チップ抵抗などの表面実装部品は、以前、千石で買ったジャンクのギターアンプ基板から採集し、コレクションの蝶よろしく紙に貼り付けてあった。パルストランスをはずしたNIC基板からも、このあいだ採集した。こういう作業は、やり始めると止まらなくなる性質がある。かれこれ30ヶ以上のチップ部品が集まってきた。

P1154586 基板の配線図をショップのウェブから入手し、部品リストを作る。そろそろCPUチップをこの基板につける機運が高まってきた。何度目かの0.5ミリピッチ、100ピンLQFPのハンダ付けである。もう何度もやって成功しているので、気楽にとりかかった。

 厳重なDigiKeyの防湿袋から秘蔵のSTM32F107を取り出し、位置を何度も確認しながら、ハンダ付けに入る。フラックスをたっぷりつけると位置が固定し易くなる(フラックスが粘ってくる)。順調にハンダ付けが出来たので、ルーペでチェックする。おやあ、角の1ピンがもともと歪んでいて歪んだままハンダがついてしまった。ついてはいるようだが、見栄えが悪い。修正に入る。

 ところが、ハンダごてで、ハンダを溶かしながらピンセットでピンを元へ戻そうとしたらパタンが基板からはがれて宙ぶらりんになり真っ青になった。ルーペで慎重にパタンを戻し、ピンを元へ戻して、慎重にハンダを盛る。ああ、何とかつながった。

 いやあ、油断するとろくなことがない。それにしても¥3000も出せば、CPUチップのついた完成品のCPUボードが簡単に手に入る時代である。この基板が¥450。チップのSTM32F107は¥1365。¥2000近くかけて、生産性から言えばこんな苦労までするのは割が合わない。

 それはその通りだけれど、完成したCPU基板を使うだけでは何となく面白くない。人と同じことをするのが嫌いな「へそ曲がり」である。表面実装部品の取り付けには格好の練習にもなると自分に言い聞かせる(まあ、ケチなだけだけど)。

1608LEDのハンダ付け練習(1/6/2012)
 部品リストと、採集した部品をチェックしてみると、殆ど買いに行かずに基板が完成しそうである。多量に使う10KΩのチップ抵抗などは足らないと思っていたが、NIC基板に沢山あるのが見つかり、足らないのは、RTC用の32.767khz水晶のコンデンサー(10PF)くらいのものになった。これは今すぐ必要がない。買い物に行かずに基板の動作テストまで出来そうだ。

 パターンが出来ている時の表面実装部品のハンダ付けは、DIP部品などよりはるかに早い。次々にハンダ付けが進み、LEDの部分が出てきた。よーし、これまで買ってあって使う機会のなかった1608サイズのLEDをつけるチャンスである。

1608led_

 これまで買ったLEDの最小部品である。ピンセットで恐る恐る取り出す。これは小さい。ちょっとみたところでは、どちらがアノードなのかわからない。印がないのだ。ルーペで見ると電極が見える。電極が半導体に刺さっている方がアノードらしい。

 つけてから修正するのは面倒なので、実際の小さな基板の切れ端にLEDをつけて試してみる。ハンダ付けの練習を兼ねている。いや、1608クラスのチップを汎用基板にハンダ付けするのは大変だ。

S_p1154585

 ブレッドボードに差してテスト。めでたく点灯した。いやいやこんな工作でも明かりがつくと楽しい。しばらくこれまでに作った各色のLEDテスト端子をつけて遊ぶ。

CPU基板のブートローダーが動いた!(1/8/2012)

 お正月休みの間に、少しづつハンダ付けを続けて、今夜半、殆どの部品を遂につけ終えた。結局すべて在庫のパーツで間に合った。JTAGのところの抵抗がひとつ足らないが、JTAGを動かさなければ問題ない。

S_p1084574

 こういうときの通電はいつも緊張し、中々決断がつかないのだが、思い切ってUSBケーブルを挿して通電する。電源をUSBバスから貰う接続にしてある。よーし、緑のLEDが点灯した。CPUチップは全くの新品である。BOOTモードをシステムメモリから立ち上がるようにして、ねむいさんに教わった例の中華製シリアルプログラムライター、MCUISP.exeで動作を確かめる。

 システムブートで内蔵のブートプログラムが動くはずである。しかし、全く反応がない。タイムアウトでライターが接続をあきらめた。試しに、オシロでクロックを確かめるが、全く出ていない。ありゃあー、これじゃあ駄目だよね。

 いや、待てよ、これはこのままで良いはずだ。STM32あたりになると、内蔵のCRクロックでまず動き、あとはインストラクション(命令)で主クロックを起動させるはずだ。

 動かないのはハードが原因だ。いや、プリント基板なのでハンダ付け不良が最も疑われる。ルーペでCPUチップまわりを仔細にチェックするが、問題になるようなところは見つけられなかった。

 そのうち、BOOTモードを決めるピン配置が気になった。どうもプルアップをスイッチでショートするような回路になっていない。配線図と実際の結線を確かめる。やはりそうだ。ピンから抵抗をとおして、Vccか、GNDにつながるようになっている。つまりプルアップかプルダウンをするような設定だ。となると今のショートピンの設定は0と1が逆だ。

Stm32f107_start

 設定をちょうど逆にする。MCUISP.exeのread chipボタンを押した。やった。CPUを認めた。256KBのフラッシュ、64KBのSRAMの表示。やれやれ、とりあえずハンダ付けはすべてうまくいったようだ。これで表面実装のハンダ付けにも少し自信がついた。

Flushloader

 このあと、STマイクロの提供するFlushLoaderでも動くことを確認した。以前はあんなに気難しかったローダーが、STM32F107ではすんなりチップを認めた。この基板にはまともなシリアル変換チップ(ADM3202)が載っているからかもしれない。

突然動かなくなる(1/11/2012)
 どうしたことだ。STM32基板は、JTAGコネクターまわりや、RTCの発振子のコンデンサーなどの残りのパーツを付け終わって、2日ぶりに動作させてみたら動かなくなった。MCUISPがチップを認めない。勿論FlushLoaderも拒絶する。

 追加した部品は、そもそもブートローダーの動きに関係ないと思われる部品ばかりである。もしあるとするなら、JTAGのリセットピンに関係する抵抗で、店のサイトから落とした回路図には、"don't at"という奇妙な注釈があって、NRST(システムリセット?)と、NJTRST(JTAGのリセット?)の間をつなぐ230Ωである。

 回路的には、システムリセットをしたときに、JTAG側もリセットしようという意図で付けたと見られる抵抗だが、この注釈が意味不明である。つけるなという意味にも取れる。ただ、この注釈は隣の定数が書いていない抵抗のことかも知れないので何とも言えない。

 そもそも、JTAGコネクターには何もつながっていないので、問題になるわけがないが、新しい要素はこれくらいしかないので、ハンダごてを出してはずしてみる。勿論、事態は変わらない。

 他に関係のありそうなところはない。RTCの発振子のドライブコンデンサー(10PF)をつけたが、これでおかしくなることなど普通あり得ない。念のため、Vbatへの0オームをはずして、Vbatの電源供給を止める。もちろん変わらない。

 あとはJTAGのソケットをつけただけだ。これで動かなくなる。そんな、信じられない。さすがにこの取り外しは止めた。しかし、ブートローダーが動かない限り、今のところ何も先に進めない。頭を抱えてしまう。

やっぱりCPUが壊れているのか(1/12/2012)
 新年早々、久しぶりに暗い気分に落ち込む。世の中すべてが自分に敵対しているような感じになる。家人との応対も上の空である。大したことでもないことにめげて、そういう自分が嫌でまたさらに落ち込むという負のスパイラルに陥っている。

 実装して一旦動いたSTM32基板が突然動かなくなったのだ。思い当たるところがない。これまでの調べでは、CPUへの電源供給は異常なし(10mA程度)。各部の電圧も規定どおり。シリアルの送信も間違いなくCPUのシリアルピンに届いている(オシロで確かめた)。しかしレスポンスがない。

 STM32は、ブート時は内蔵クロックで動くので、CPUが正常に動作しているかどうかを外部から知ることが出来ない。ところが、オシロで各部の電圧をチェックしているうち、異常な部分を見つけた。リセットピンにパルスが出ている。リセットすると一旦グランドに落ちるが、プルアップの状態で、400Hzくらいの矩形波のパルスが出ている。電圧は電源電圧の半分程度。

 そんな馬鹿な。リセットピンは入力ピンで、こんなパルスが出るわけがない。試しにプルアップ抵抗をはずしてみた。同じようにパルスが出る。リセットスイッチに並列に入っているコンデンサーもはずす。きれいな矩形波になっただけで変わらない。10kではなく、1kでプルアップしてみるも効果なし。Vcc直結はさすがにやめた。

 これはCPUの内部からの電圧だ。そう思いたくはないが、これは、やっぱりCPUのどこかが壊れた公算が強い。そうでなければリセットピンに電圧変化が出るわけがない。しかし、どうして壊れたのだろう。静電気だろうか。オシロのプローブなどをあてたこともなく、ショートさせるような作業はやっていない。

 CPUチップの替えは、あることはある。このあいだのCQ-STARM基板のCPU換装の時にはずしたオリジナルのSTM32F103だ。しかし、原因不明で動かなくなったというのが悩ましい。これをつけてまた壊してしまうかもしれない。原因がわかるまで下手なことは出来ない。

 しかし、このままでは工作が続けられない。思い切って取り替えてみるか。まだ決断がつかない。まわりをうろうろするばかりである。たかだか¥1000ばかりの石であるが、値段というより0.5ミリピッチの100ピンのQFPのハンダ付けの作業ロードを考えると気が重い。

益々混迷を深める(1/13/2012)
 暫く迷ったが、意を決してCPUを交換することにした。苦労してつけたSTM32F107を低温ハンダをたっぷりつけて取り外す。壊れたとは限らないので、ハンダ吸い取り線で丁寧にピンからハンダを取り除く。低温ハンダは、このあいだ買ったストロベリーリナックスのものである。サンハヤトの1/3の価格(一時、品切れだったが、最近戻ったようだ)で、効果は変わらない。

Chipwick

 しまってあった雑誌付録のオリジナルCPU、STM32F103をとりだしハンダ付けに入る。こういうこともあろうかと、チップを綺麗に掃除してあったので助かった。順調につけられた。

 配線パタンは、前に、無理に付けようとして1ピンのパタンをはがしている。そこも何とかハンダを盛って接続する。気がせくが、ここであせって失敗しては元も子もない。慎重にテスターで確かめる。よし大丈夫だ。ルーペでハンダブリッジがないかもう一度良く確かめて、通電する。

 さあ、どうだ。シリアルローダーの反応はない。動く気配はない。しかも何ということだ。依然としてリセットピンに矩形波が上がっている。苦労してCPUチップを取り替えても同じ現象である。

 これはCPUチップが悪いのではない。別のチップで同じ現象が生まれることはあり得ない。基板がおかしいのだ。やれやれ、100ピンのハンダ付けが無駄になった。まあ、STM32F107が生きていただけでも救いなのだが、原因がわからないことに変りはない。

フェライトチップビーズのハンダ付けが原因とは(1/14/2012)
 この3日間、悩まされてきた問題は、あっけない原因で解決した。真の原因は未解明だが、AitendoのSTM32基板は、正常な前の状態に戻った。しかし未だに信じられない。ハンダ付け不良が、リセットピンの発振を招くとは。いやそれにしても恐ろしい話である。

 最初はシステム内蔵のブートローダーが動いていたのに、残っていた部品をつけたら動かなくなった。リセット電位を測ると、400Hzくらいで発振している。Vccは3.3Vで安定している。消費電流も10mA以下で問題ないが、リセットピンがこんなに上下していたら動くわけがない。

 追加した部品はすべて基本的な動作に関係がありそうなものはない。それでもJTAG関係は微妙なので、ひとつひとつ部品をはずして調べたが、全く事態は変わらなかった。CPUを疑って、昨日、意を決して交換したが、これでも事態は前と変わらない。がっかりすると同時に少し安心する。STM32F107が壊れていたわけではないのだ。

 さあ、こうなると基板のどこかが悪いということになる。全く関係ないと思われるRTCのコンデンサーをはずす。これもだめ。次はJTAGの20ピンのソケットだ。こんなわけはないが、動いたところまで現状を戻していくしかない。多ピンのソケットの取り外しは厄介だ。低温ハンダの助けを借りる。結構手間取って外した。テストする。当然のように事態は変わらない。

 もう、やるところがなくなった。基板を上を何度もチェックする。これ以外にいじったところはない。しかし何気なく基板を裏返して気がついた。そういえば裏には、アナログ系に電源を供給するフィルターのフェライトビーズがついており、これを手持ちの大きなチップから、この間秋月で見つけて買ってきた2012の小さなチップに取り替えた。

 こんなものが変化をもたらすとは考えられない。しかし、もうこれしか動いた時からいじった部品は、基板上のどこにもない。これだけが残っている。しかし、この部品はこのあいだ導通をテスターで確かめて問題ないことを確認している。これが原因とはとても思えない。

 やってもしようがないとは思うが、残っているのはこれしかない。ハンダごての電気を入れて、前のものに取り替えようとした。すると、片側のパッドにハンダごてをあてた途端、チップがポロリとはずれた。うっ、これはおかしいぞ、ちゃんとハンダ付けされていなかった?

 うーむ、何か匂う。もしかしたらもしかするかもしれない。念のため、前のフェライトビーズにとりかえて、シリアルケーブルをつないでブートローダーのテストをした。うわお、これだ。シリアルプログラマーMCUISPにレスポンスが返ってきた。

 STM32基板は前の状態に復帰した。何だ何だ。これは一体どうしたことだ。リセットピンは問題なくVccに上がったままになった。MCUISPの画面には、STM32F103の情報がしっかり表示され、基板は生き返った。

 こんなことってあるんだ。フェライトビーズが悪かったのか。いや、フェライトビーズを前の2012のものに取り替えて、しっかりハンダ付けすると、このチップでも問題なく動いた。フェライトビーズが悪かったからではない。早い話がハンダ付け不良である。

 恐らく、ハンダが微妙な半導通状態で、ここがコンデンサーかダイオードの状態になってアナログ基準電圧が不安定な状態になり、リセット系に悪さをしていたと考えられるが、正確なことはわからない。いずれにしても、基板は、CPUチップを認識する状態に戻った。やれやれ3日間は完全にこれにふりまわされた。

 このあと、正規に動かそうとするが、中々動かないことは次回に紹介するとして、とりあえずこのあたりで報告しておこう。このあいだ、「七転八倒、四苦八苦」とコメントされて、ちょっとむきになっていたけれど、いやいやそんな偉そうなことは言えません。その通りです。はい。

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

2012年1月 3日 (火)

AVR Dragonのデバッガー機能 debugWIREにはまる

みなさまあけましておめでとうございます。

 がた老AVR研究所は、ブログ公開以来、4回目の新年を迎えました。

 始めは備忘録のつもりで、気ままな電子工作の記録を残そうと始めたのですが、根が凝り性なもので興味に任せて色々手を出すうち、どんどん店が拡がり、昨年はガイガーカウンターを2台も作ってしまうほどのはまりようです。

 いつのまにか電子工作と、このブログが、すっかり生活の一部になり、おかげさまで昨年末には遂にブログの累計アクセスが40万件を越えました。応援していただく人も増えて、いつも沢山コメントを頂戴し、何やら自分勝手なことができない雰囲気です。

 あ、これは困ったと言っているのではありません。昨年は世界中で大きな天災が続いて、人と人の絆がこれほど強く意識された年はありませんでした。その点で、本来、孤独な趣味である電子工作をむしろ、こうしてみなとつながって続けられることは本当に得がたいことだと感謝する気持ちで一杯です。

 そういうことでもありませんが、新年初ブログのお題は辰年にふさわしく、要望のあったAtmelの純正プログラマーAVR Dragon(龍、辰)のデバッガー使用報告です(2012年1月3日記)。

P1034563今年(2011年)の暮は猛烈に忙しかった(12/25/2011)  それにしても、今年は11月末あたりから行事の連続でめちゃめちゃ忙しかった。50年ぶりの小学校の同窓会から始まり、年末の法事まで1ヶ月の間に2回も関西を往復した。忘年会は全部で6回。これに恒例のフルートの発表会や、テニスの納会、属している団体の研究会の幹事、さらに人間ドック、よせば良いのに、パソコン用の地デジのチューナーを買ったりしてそのセットアップ。ジャンクのHDDを買ってPCの環境整備(160GBが¥400という安さで思わず購入。Cディスクを取り替えた)などなど。のんびり半田付けをやっている時間がほとんどなかった。

 それでも、暇を見つけては、このあいだ完成した熱電対で温度制御するアクリル曲げ器を実際に使ってみたり、細かい電子工作はやっていた。アクリル曲げ器は少し厚いアクリルの小片などを使って、テストしている。230℃くらいで表面が150℃になる(放射温度計で測定)。温度が安定しているので工作しやすい。

 このあたりの温度で、アクリルを曲げる線に合わせてパイプに当てていると、うまい具合に焦げずにパイプにあてた直線部が柔らかくなってくる。適当なところでパイプから離し、手で曲げると実に簡単に曲がる。

S_p1034551 練習用のアクリル端片をコの字型に曲げただけだがけっこう綺麗に曲がった。ただ、正確に曲げるには何か治具に当てて曲げる必要があるかもしれない。暫く練習を続けて、ゆくゆくはケースを自作しようと思う。

Dragonのデバッガーに手軽に手を出してはねつけられる(12/28/2011)
 そうこうするうち、前から欲しかったAtmel純正パラレルプログラマーDragonがDigiKeyから届き、その使用記をブログに載せたら、思わぬ反響があった。Dragonを買った目的は、フューズビットを書き損なったチップをパラレルプログラミングで救済するのが主で、デバッガーについては正直なところ殆ど考えていなかったのだが、複数の方からDragonのもうひとつの機能、デバッガー(debugWIRE)のテストをお願いされてしまったのである。

 所長は、前から記事やコメントに書いている通り、デバッガーは余り使ったことがない。大型汎用機の出身なので、そもそもデバッガーに縁が薄かったということもある。ICEや、デバッガーは本来、UNIXやPC、組み込み系コンピューターなど、比較的規模の小さいCPUを対象とするツールで、汎用機ではCPUを止めてデバッグすることなど思いもよらず、オンラインシステムのデバッグの武器はコア(メモリー)ダンプリストとトレースが主であった。

 何度も言うように、ペリフェラル(周辺機器)を含めた実機のデバッグ(オンチップデバッグ)は、タイムアウトでペリフェラルが止まってしまわないような周到な準備が必要だ。しかしバグは大抵こうしたペリフェラルとのやりとりのタイミングにひそんでいることが多く、ここを別の仕掛けで補っても、実際の実機での不具合をつきとめることは難しい。

 単にロジックの部分でCPUを止めてみても、あまり意味がない。変数を見たければprintfをはさむだけで十分用は足りる。当研究所のシステムには本番でUARTを使わないものでも必ずUARTを内蔵しているのは、いつでも内部の変数や、動きが外に見えるようにするためである。UARTが遅くて系に影響を与えるなら、空いているポートを叩いて、そのピンをロジアナで見ればよい。

 そんなわけで、オンチップデバッガーの機能を動かすことには余り気が進まなかった。しかし、ウェブを見ていると、このDragonは、極めて廉価で実機によるソースデバッグができる優れものなのだそうだ。ウェブサイトには、このデバッグの様子を動画で公開しているところもある。一度は経験しておかないとやはりまずい気がしてきた。

S_pc284516 で、パラレルモードでなく、ISPモード(debugWIREモードを兼ねる)のジャンパーを作り始めた。パラレルの20本近くのジャンパーではなく、こんどはたかだか6本の配線である。あっというまに出来あがった。起動も簡単である。AVRStudioを立ち上げて、DEBUGメニューからstart debuggingを選ぶだけである。

 途中、debugWIREモードにISPを通して入るかというダイアログが出て、そのラジオボタンを押すと、プログラムがロードされデバッガーが簡単に動き始めた。ちゃんとCのソースコード画面にブレークポイントの矢印が出て、プログラムの最初のところで止まる。ステップ動作を指定すると、ひとつづつ実行し、サブルーチンに行けば、そのソースリストの画面に替って矢印が移動する。おお、中々やるじゃないか。

Dragon1

 しかし、動かないシステムのステップ動作は、わくわくするが、動いているシステムの動きを見ていても正直あまり感動はない。それに案の定、ピン割り込みのループで待つところで延々とループを始め、先に進まなくなった。CPUはDragonのプロトタイプ基板で動かしているので、ピンは裸だ。先に進みようがない。

 まあこんなものかと思ってとりあえずstop debuggingを選んでデバッガーを止める。ところが、次からガンとして言うことを聞かなくなった。CPUを認めないのである。編集/プログラム画面は出るが、start debuggingを選んでも、デバッガーモードにも戻らない。

 ええー、どうしてだ。メッセージは「ISPモードでない」と言っている。なにー、デバッガーモードから戻る時に、フューズビットをリセットしないのか。パラレルモードでないと変更できないと言っている。これは不便だ。パラレルモードと、ISPモードでは配線が違う。デバッグに入るたびに、ジャンパーの配線換えをしなければならないのではたまらない。

Dragon2

 何か手順があるはずだ。こういうことになると、すぐに意地になるというのがいつものパターンである。自慢にもならないが「へそ曲がり」の性格なら誰にも負けない。こいつをちゃんと動かせるようになるまで、他の事にかかわれなくなってしまった。

やっとdebugWIREを動かせるようになった(12/31/2011)
 Dragonは当初考えていた以上に、多彩な機能をそなえている。まず、ファームの書き込みやフューズビットの書き換えなど、プログラマーの機能としては、ISP、パラレル、HVSP、JTAGとなんと4種類ものインターフェースで動く(ジャンパーの接続と、IDE(AVRStudio)で選択)。

 さらに、オンチップデバッガーは、JTAGとAtmel独自のプロトコル、debugWIREでソースコードレベルのデバッグが出来る(デバッガーソフトはAVRStudioで、チップによりJTAGが使える)。

 ところが、前にも書いたように、このあたりの実際の操作法は、マニュアルに余り詳しく出ていない。日本語のマニュアルはあるが、この翻訳がデータシートに較べると、あまり上手でなく意味がとりにくい(PDI物性などと書かれると意味不明。PDI physicalなのだが、これはPDIハードとでも訳すべき)。原文にもあたるがJTAG周辺の専門用語に馴染みが薄いので、どうもよく理解できない。

 現在のトラブルを整理してみる。要するに、デバッガーモード(1wireデバッグ、debugWIREモード)から、単に、stop debuggingで抜けると、フューズビットのDWENが元へ戻らず、そのチップはISPモードでなくなり、しかもstart debuggingでデバッガーモードにも戻れない。

 こうなると、ファームの書き込みまでできなくなってしまい、パラレルプログラミングでフューズビットを換えないと元に戻れない。これでは連続したデバッグに大きな支障がでてしまう。

 いくつかのウェブサイトの実行報告も、このあたりは、いまひとつはっきりしない。みんなどうしているのだろう。あれこれ、AVRStudioの中を探し回る。その結果、やっとマニュアルの中で手順を発見した。「デバッグWIREインターフェースを通した目的対象への接続」の一番下の記事に、「ISPインターフェースの再許可」というところである。DEBUGメニューの中の「AVR Dragon Options」を開き、そのなかの、disable DebugWIREボタンをクリックしろとある。

 やってみた。ちゃんと出来た。ダイアログに答えていくとISPモードに戻った。マニュアルを読まないのが悪いと言われればそれまでだが、タイトルが「ISPインターフェースの再許可」では初めての人にはわからない。それにソフトの設計としてはこれはまずいだろう。stop debuggingのときに、ダイアログを出して聞けばすむ話だ。不親切なことおびただしいと八つ当たりする。

 そのうえ、このオプションを操作せずにうっかりstop debuggingしてしまったチップは、この方法をとれない。デバッガーモードに戻れず、このメニューが有効にならないからだ。パラレルプログラムで、DWENフューズビットをいじらないと元へ戻らない。

 なおも、しつこく探し回る。そして遂にISPモードの結線のまま、DWENフューズをリセットする手順を見つけた。その方法とは、コンパイルのとき、BUILDではなく、BUILD&RUNを選ぶのだ(ボタンはBUILDの右どなり)。こうすると、コンパイルをしたあと自動的にデバッガーモードになるので、DEBUGメニューの「AVR Dragon Options」が有効になる。ここでdebugWIREモードをキャンセルしてISPモードに戻れば良い。

 いやあ、気分が良い。これで面倒な配線換えをしないでも気楽にデバッグと編集/プログラムの画面を行き来できる。このあたりをわかりやすくするため、図を用意した。青い矢印で書いたところが、所長が発見した手順、赤がマニュアルに出ている復帰手順である。本来は3段目のステートに行かないようにしておくべきだろう。

Dragon_statemap

 気難しいDragonを飼いならして、ようやくデバッガーが快適に操作できるようになった。手が空いたのでTiny2313とTiny861専用のパラレルプログラミングのジャンパーをフラットケーブルから作る。これで、少々フューズを書き損なっても安心だ。これまでメモで書き散らしていたブログの原稿を整理し、新年のために工作室を片付ける。そうこうするあいだに、2011年はとうとう大晦日を迎えてしまった。

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

2011年12月17日 (土)

Atmel純正プログラマーDragonで書き損じたCPUチップを救う

AVR DRAGON来る(12/10/2011)
 とうとう、この研究所にもAtmelの純正プログラマー(プログラムライター)が来ることになった。ATmel AVR Dragonである。4年近くAVRとつきあっていながら、これまで当研究所のAVRのライターはすべて互換品ばかりで、それもシリアルだけである。

 作ることが目的ではなく、何かの役に立つ「しかけ」を作ることを電子工作の目的(何度もしつこく書くけれど)にしているので前から、プログラムライターは道具と割り切っていて余り興味はない。しかも、ケチなので安価で互換ライターが作れるのに、わざわざ純正品を買う気持ちは全くなかった。

S_pc164453 それが、何故買う気になったのか。フューズビットを書き損なった石が増えてきたこともある。それならパラレルライターを自作すればよい。制作例はいたるところにころがっている。実はブレッドボードで2回ほどリセッターらしいものを作ったが、何故か2回とも動かなかった。これがどうもトラウマになっている。

 めげ易いタイプである。リカバリーのための「手段」に不具合があるのか、対象そのものが不具合なのかの判別ができない状況というのが、どうも不安であった。これ以上追求しようという気力を失った。特にパラレルプログラミングは、12Vの高電圧を使う。ちょっと間違えば、簡単にチップを壊してしまう。このあたりが、パラレルプログラマーは純正を買おうと大分前に心に決めた理由である。

 Dragonはデバッガーとしても使える。こちらはAVRではデバッガーやICEを使うつもりがなかったので、実感がわかないが、ICEとしての価格$49(現地価格)は破格の廉価なのだそうだ。日本で買えば、¥7000以上するが、DigiKeyでは¥4400である(ちょっと前は¥4305だった)。

 ただ、DigiKeyは安いかわり、買い物代金の合計が¥7500以上にならないと送料が¥2500かかる。いつもこれが悩みの種である。今度は、あと¥3100分の電子部品を買わねばならない。無理して買って使われない部品が次々に溜まっていく。これが工作のプレッシャーに拍車をかけることになる。この前書いた「電子工作の無限地獄」である。

それはとにかく、今回の送料のゲタは以下の通りである。

①LM2735(DC-DCコンバーター)
このまえ一つ高圧で失い手持ちがなくなった。9V電池の充電版を作るため、さらに3ヶを注文する(@¥308)

②MAX6675(熱電対インターフェースIC)
このICはすぐれもので、冷温端センサーを内蔵していて出力は何と、SPIのデジタルデータである。熱電対温度測定は、とりあえずオペアンプですべて自作したが、これと、どれだけ差があるか、比較したくて買ってみた。¥1219 1ヶ

③DP83848C(イーサネットのPHY層チップ)Aitendoで買った2インチのTFT液晶を動かす予定のSTM32F107 CPU基板のLANインターフェースのため。この基板はmbedと少しかぶるが、安かったのとCPUチップが余っていたので。¥587 1ヶ。

④ATTiny85(8ピンのAVRチップ)
パラレルプログラマーが揃うので、前から欲しかった8ピンAVRを買ってみた。今のところアプリケーションの予定はないが、¥195と安かったので2ヶ買う。

 これで924+1219+587+390=3120、ゲタはめでたく¥3120となり、合計¥7520と無料合計に到達した。喜び勇んで発注する。

 さて、Dragonである。ウェブには沢山の購入記があるので、予備知識はいくらでも手に入る。何しろCDや説明書は一切なくて基板だけが届くようだ。気持ちのよい割り切り方である。ただ、本体のサイトには情報が少ない(というよりこのサイト、情報の引き出し方がとてもわかりにくい)。

 最近、秋月でも売り出した極小のチップTiny10もサポートしているはずなのだが、直営のショップの情報ではサポートとなっているのに、既存のAVRStudio(4.19)の正規のマニュアルにはない(AVRStudio5は、Dragonはまだフルサポートではない)。

 DigiKeyにしては珍しく、到着に3日以上かかった。クリスマスが近いからかもしれない。日本語マニュアルは、例のavr.jpで発見した。ただ、これもバージョンが古いのでTiny10のサポートは入っていない。

ZIFソケットを買ってきた(12/12/2011)
 Dragonは、ISPピンが実装されているだけで、他のパラレルや、肝心のターゲット基板はパターンだけで何もついていない。ユーザーが何らかのソケットを実装する必要がある。初心者には手ごわいだろう。

 本体が届く前から実装レイアウトを色々検討していた。仕事の帰り久しぶりに秋葉に出て秋月に寄り、ゼロプレッシャーソケットを買ってきた。ずっとAVRチップを使って、基板につけたままプログラムできるISPを愛用してきたので、電子工作では定番のこういうソケットに縁がなかった。小さな汎用基板に取り付けてメスのソケットをつけ、Dragonとのあいだをフラットケーブルのジャンパーでつなぐことにする。

S_pc164452 沢山の人が様々な方法で接続している。Dragonのボードそのものをプロトタイプ部で切り取って、Dragonを小さいケースに入れてしまった人もいる。ターゲットチップごとに、ピン接続を固定したプラグインを用意する方式が一番安全で確実だが、ひとつひとつ準備しなければならず手間がかかる。ジャンパーで接続するのが最も手軽だが、間違う確率は高い。

 こちらがやりたいのは、パラレルプログラミングで、ISPでデバッグをすることは余りないだろう。Dragonの基板にZIFソケットをつけてしまうことも出来るが、ジャンパーを扱うには手狭でやりにくい。ということで別基板に移すことにした。実装は、40ピンのソケットとZIFとの配線がけっこう面倒で時間がかかった。同じことの繰り返しなのであきてしまう。

Dragonの動かし方が難しい(12/14/2011)
 プロトタイプ基板の実装をしながら、Dragonの使い方を学習する。マニュアルはあるが、Dragonは多種多様の書き込み法をサポートしているので、やり方は一本道ではない。これが始めての人をまごつかせる。どうもやりかたが頭に入ってこない。

S_pc164451

 しかも、AVRStudioを動かしているうち、いつのまにか画面からプログラムアイコンが消えて、大騒ぎになった。Dragonが起動できないのである。要するに、AVRStudioは最初、プロジェクトを立ち上げる前に使用するプログラマーを指定しなければプログラムアイコンが出てこない。それをしないで既存のプロジェクトを読み込むと、プログラムアイコンが消える(そのプロジェクトは別のプログラマーを指定していたので、それがないので消える)。

 言われてみれば、そのとおりで、最初から手順通りプロジェクトを立ち上げ、プログラマーを指定して開発をしていれば、問題はないのだろうが、こちらはAVRStudioの変則的な使い方を長年している(コンパイルだけAVRStudioで、ファーム書き込みはChaNさんのシリアルプログラマー、エディターはTeraPadなど)。これに気がつくまでえらい時間がかかった。

 こういうIDE(統合開発環境)というのは、決まった手順を忠実になぞっていかないと、うまく行かないことが多い。8ビットのマイコンの環境だと馬鹿にしているところがあったのだろう、一時は半べそをかくほどあせっていた。

 さらに、とんでもないことが起きた。やっとのことでDragonが動き出して、Tiny2313のリカバリーをしようとしたとき、何故かチップが暖かい。へえー、Dragonの高電圧プログラミングってこんなに電力を消費するのかと思いながらチップを良く見たら、こいつはTiny2313ではなくて、もうひとつの動かないチップ、Tiny861の方だ! 顔が青ざめる。2313と861はピンアサインが全く違う。チップを壊した可能性が高い。

 Dragonを買った目的の大部分は、この動かなくなったCPUチップのリカバリーである。それがリカバリーする前に壊してしまったら、何のために買ったのか意味がなくなる。とにかく慌てて861をはずし、2313に入れ替える。ジャンパーを2313用にしてあるので861が壊れたかどうか確認するのは先の話だ。2313の方をすませてからだ。

 気を落ち着かせ、再度Dragonを立ち上げる。Main画面で、シグネチャーバイトの読み出し。よし、2313と認識した。ジャンパーは間違ってなかったようだ。フューズビットの読み出し、よーしこれもOKだ。うむ、Higherバイトが0xFEと、SPIENが不許可になっているだけでなく、RSTDSBLが0、つまりリセットピンも無効になっている。念の入った壊し方をしたものだ。

 とりあえず、工場出荷時の0xDFにして書き込む。よーし、書けた。念のため、チップをブレッドボードのテスト環境に戻し、シリアルで読んで見る。いつものAVRSPがチップを認めてディバイス情報を返してきた。やったやった、良いぞ。ファームを書き込む。テスト環境のステッピングモーターが静かに廻り始めた。ヒャッホー、動いた、動いた。

 いやあ、Tiny2313は生き返った。¥100の石だけれど、資源は無駄にならなかった。嬉しさがこみ上げる(本当に安い娯楽だ)。しかし、手放しでは喜べない。高電圧で駄目にしたかもしれないTiny861のテストが待っている。

Dragonfuse見事に2つとも生還(12/16/2011)
 861のためにピン接続を替える。あせっているので中々うまく接続できない。ただ、861はこのDragonのプロトタイプ基板のリファレンスチップだったらしく、HVSP/パラレルとのピン接続は順番どおりで2313ほどばらばらでなく助かった。

 さあ、ジャンパーがつながった。861が生きているか、生還寸前で倒れたか、緊張の一瞬である。念のためジャンパーの接続をもう一度確かめる。間違いない。意を決して通電し、シグネチャーバイトを読む。おーし、良いぞ。861のシグネチャーが戻ってきた。861はまだ生きていたようだ。思わず拍手が出る。

 次はフューズビットの読み出しである。これも無事読めた。予想通り、クロックの設定ビットが未定義と出ている。これを直して書き込む。書けた。エラーはない。良かった。861は死んでいなかった。HVPPの高圧(といっても12Vだが)はかかっていなかったのだろう。ファームを書いてみよう。Dragonは勿論ファームを書くことも出来る。

 直近のプロジェクト、熱電対のHexファイルを書き込んでみる。うーむ、途中の作業メッセージは全部OKと出ているが、最後のVerifyで何かエラーが出た。高電圧で何かおかしくなったのだろうか。

 2313と同じように、チップをはずしてシリアルの環境に移す。ここでのテスト。フューズビットの読み出しOK。ファームの書き込み。これも順調に終わった。エラーメッセージはない。ふーむ、こちらは大丈夫だ。しかし、高電圧がどこかにかかってI/Oピンがやられている可能性はある。

 こうなったら、とことん調べないと気がすまなくなってきた。全部のピンを確かめるのは大変だが、このあいだの熱電対システムは、861の殆どのピンを使っている。こいつが動けば、完全復帰をほぼ証明できる。

面倒だけれど、アクリル曲げ器に実装された温度表示・制御部でテストすることにする。こいつは、台板、ケース、さらに基板の3組のネジをはずさないとチップが出てこない。行きがかりでもう止められない。ネジを手近な皿に盛って中味を出す。うわー、だめだ。チップは2階建ての基板の下の段だ。もう一段ネジをはずさねばならない。

 ここでやめたら、今までの作業は全く無駄になる。もう止めるわけにはいかない。2ミリセルフタッピングビスを4つはずす。Tiny861Aを取り出した。ファームをテストベンチで書き込んだ。石をセットする。さあどうだ。電源を入れる。ああー良かった。動いた。7セグLEDが数字を表示してヒーターが加熱されていく。暫く動かしてみる。全く問題なし。

 これで、フューズビットを書き損なって動かなくなったCPUチップがパラレルプログラミングで2つとも生還した。見事に生き返ったのである。AVR Dragon導入の当面の目的は完全に達成した。投資対効果から行けば、¥300/¥4400、6.8%の元はとったことになる。

 まあ、それはとにかく、今までの胸のつかえがいっぺんに降りた。はたから見れば何のことかと言われそうな、ささやかな出来事だが、この上なく爽快な気分である。少し短いけれど、ブログにこの喜びを報告することにしよう。

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

2011年12月 8日 (木)

熱電対によるヒーター制御:まずまずのPID制御。ソースの公開

小学校のクラス会(11/26/2011)
 所長は関西出身で大学卒業まで京都で過ごした。高校や大学時代の友人は東京に結構たくさん出ていて東京での同窓会も多い。最近は共にリタイアした同級生と頻繁に交流して、今や生活の一部となっている。しかし小学校の同窓生は地元に残った人が多いので同窓会は地元で開かれ、滅多に顔を出したことがない。

 高校の同級生で同じ小学校のクラス生から、前から「たまには出なさいよ」と強い要請があり、今回、場所が大津の石山寺と珍しいところだったので、それこそ50年ぶりくらいの感じで出席した。

S_pb264419

 石山寺は、琵琶湖の水が京都・大阪に流れ出す風光明媚なところで、会場はその石山寺の近くの料理屋(昔は川魚料理店だったのだろう)であった。石山寺は紫式部が源氏物語を書いた所ということでも有名である。

 50人のクラスで集まったのが15人。男は4人だけで女が11人。やはり女が元気である。久しぶりの同窓会は、いわば自分探しの場でもある。自分の知らなかった(忘れていた)一面を教えられ、人生観が変わる。今回もいくつかの収穫を得て新幹線の日帰りで京都から帰ってきた。最初は泊まるつもりだったが、京都は紅葉シーズンの最盛期で宿が全くとれなかったのである。

S_pb264433

 帰ってから、熱電対を使ったヒーターの温度制御のためのPID制御をあらためてお勉強する。現在、P(比例)制御まで動いている。対象は自作のアクリル曲げ器である。比例制御だけで一応の制御ができて(前記事参照)、アクリルを曲げるくらいならこれで十分なのだが、「凝り性」の性格で、やりだすと止まらない。それにPID制御は、中断しているライントレーサーなどのロボット制御には必須の技術なので、何とか自分のものにしておきたい。

 温度制御を実際に動かしたあと、前に読んだ全く同じ資料を読み返してみると、不思議なことに何故か新しい発見が増える。面白いものである。視点が変わっているからだろう。見晴らしが良くなって制御技術全体の理解が深まったように思う。

具体的な方法がわからなくて落ち込む(11/27/2011)
 とはいえPID制御の具体的な手順はまだ良くわからない。I制御もD制御も時間成分をどの範囲でどれだけとりいれるのか、その目安を書いている所がないのだ。それにこのところ仕事と行事が重なって電子工作にかけられる時間がなかなかとれない。

 そのうち気の滅入ることが続いて、制作意欲ががた落ちした。まず、エアコンのリモコンの液晶部分が壊れた(尖ったものでぶつけたらしい)ので代替品を買おうとした。ウェブで調べたところ純正品は¥5000以上するが、多種類エアコン対応を謳う互換リモコンの方がはるかに安い(1/3)のでアマゾンで取り寄せてみた。ところが、どのコード(うちの三菱だけでも10種類以上)でも動かず、一気に落ち込む。安物買いの銭失いを絵に描いたような話である(これはこのあと別の部屋のエアコンに使えて無駄にならなかった。やれやれ)。

 続いて、帯状疱疹(ヘルペス)という病気にかかる。顔に水疱のような吹き出物が出来て、最初、うるしにかぶれたのだろうと放置していたら段々広がり、医者に行くと「これは立派な帯状疱疹です」と宣言された。全く痛みはない。帯状疱疹は痛いと聞いていたので最初は半信半疑だったが、薬を飲んだらすぐ良くなったので医者の見立ては正確だったようだ。

Amalia

 結構、怖い病気らしいが痛くないので深刻感がない。しかし、顔が張れているので、気持ちが集中しない。しかも、そのころ知人がスペインで買ってきたという「Amalia Rodrigues」のCDを借りて何気なく聞き出すと、このポルトガルのシャンソンと言われるファド(Fado)の世界がとまらなくなった。暗い情念の溢れ出るCDを聴き続け、余計何もする気がなくなった。ということで、電子工作の進展は完全に止まってしまった。

自己流のPID制御を試みるがいまいち(12/2/2011)
 欝(うつ)には必ず終わりがある。Fadoを聞き続ける事でどん底まで落ち込み、かえって回復が早まったようだ。再び意欲が回復し、気がつけば、PCの前で温度制御のロジックをいじっていた。ハードは殆ど完成しており、やることはもう殆どない。2つのケースをアクリル曲げ器の台板に固定するだけだ。残る作業はもっぱら制御ロジックを作るソフト開発となる。

 1秒ごとのメッセージをUARTに出して、温度制御のプログラムテストを繰り返す。ウェブのPID制御のページを片っ端から拾い上げて参考になりそうなところを探す。殆どのページは基本の話の繰り返しばかりで、肝心の実践的なことが載っているページはほとんどない。後閑さんのPICのページはさすがで、少し参考になる式が載っている。

 微分積分と言っても、どうも多数のポイントをとっているのではなく、前回データの差分を見ているだけのようだ。微分の方がわかりやすいので、まず、こちらからやる。しかし、文献での説明と、自分の感覚がどうもずれているような気がする。

 こちらは急激なオーバーシュートを避けたいので、目標温度に突っ込んでくるような温度上昇を緩和させるのに微分係数を使いたいが、どうも逆の説明である。同じようなことを疑問に思っているページも見つけた。

 それと実際の係数をどう決めるかは何も書いていない。積分制御は比例制御との区別が良くわからない。目標温度との温度差が大きい時に積分制御を適用すると、ヒーターの加熱の効果が、かなりあとから出てくるので、猛烈なオーバーシュートになってしまう。これも適用する範囲を限定しないとおかしくなる。

S_pc084447

いまいちよくわからないが、自己流のPID制御ロジックを次のように決めた。

・まず比例制御帯を目標温度の1/2からとする。全体にすると、目標温度付近の勾配が少なくなりすぎ、効果が遅れて出てハンチング(値の振動)が大きくなるのを避けるためである。

・比例制御帯に入ったら、常に前の温度と比較し(1秒ごと)、一定の温度以上の上昇があるときは、ヒーターの制御定数を1/2にする(当面固定)。これが(d)制御にあたる部分である。

・目標温度の90%以内に現在温度がなったら、(I)制御帯に入り、1秒ごとに目標温度との偏差(オフセット)を積み上げる。制御定数はすぐに反映せず、次の手順でまとめる(温度変化が遅れることを考慮)。

・5秒ごとに、足し上げたオフセットの温度値の平均をとり、そのときの温度に応じた制御定数に一定の倍率をかけて、100段階の制御定数に足し込む(200℃なら1℃あたり2が基礎数)。

・温度が目標温度を上回ったら、途中まで積み上げていたオフセットはすべてクリアする。

・微分制御のもうひとつ、温度が目標温度以上になったあと、下がってきた時は、(d)制御として、そのときの比例で決まったヒーターの制御定数を2倍にして、現在温度が目標より高くてもヒーターを加熱し必要以上の温度低下を事前に食い止める。

 しかし、色々工夫しては見たが結果は比例制御とあまり大差がない。パラメーターを変えてみても(2倍を1.5倍とか)グラフなどで余り顕著な効果は出てこない。オフセットの解消については、(I)制御が非常に効果があったが、相変わらず目標温度を上下するハンチングをとめることはできない。

 ヒーターが点いてから、温度に反映されるまでの時間が長すぎて、PID制御が効かないのである。ウェブ情報にも、遅れ時間の大きい制御はPIDでは難しいという記事がある。

もういちど最初からPID制御(12/4/2011)
 やっぱり我流は先が見えない。それにパラメーターの調整がしにくい。もういちど制御ロジックを最初から作りなおすことにする。パラメーターで制御できるようにするため、変数をunsignedから符号付きのsignedにかえ、マイナスを導入して制御定数を計算しなおすことにする。

 勉強をもういちどやりなおす。伝達関数とPID制御の関係もやっと理解出来てきた。PID制御の伝達関数はちゃんと存在するのだ。PIDが理論以前の実践的手法から始まったことが良くわかった。

 ソースコードを大幅に見直すことにした。本格的なPID制御にするため、各種定数を#defineであらためて定義し、忠実に式をたててプログラムを作り直す。1以下の定数は、10倍(1から10)で定義しあとで10で割る。これで小数点の操作が整数データで出来るようになる。

 これまで符号無し変数とifでやりくりしてきた演算を、マイナスを含んだ符号付き変数にしたので、計算が面倒になったが、楽になったところもある。温度がオーバーシュートしたあと、目標温度の下に突っ込む時のヒーターの加熱指示が計算式だけで出来るようになった。

 あわせて、このあいだの空焚き警告のエラーメッセージが出るようにコードも追加した。汎用性を持たせるため固定数値は持たないようにしようとしたが、これは無理だった。高温の時は、いくらヒーターが連続で加熱されていても温度変化しないのですぐエラーになってしまう。

 結局、「計測温度が35℃以下で、長時間(当面20 秒)ヒーターが点きっ放しになっても温度変化が2℃以内」という固定条件で、ヒーターをただちに止めるロジックになった。解除は、リセットか、ロータリーエンコーダーの回転で戻る。

PID制御はパラメーターの調整がポイント(12/7/2011)
 この3日間、PIDのパラメーターをあれこれいじって、ヒーターの熱制御をスムーズにしようと頑張ったが、結局、目の覚めるような改善は出来なかった。しかし、まあ、こんなものかという程度までは制御が出来るようになった。グラフがその苦労のあとである。

Pid

 比例制御に較べれば、圧倒的にオーバーシュートは少なくなり、このパラメーターで280℃くらいまでオフセットは補正される。思い切って比例制御の比率を減らし、微分と積分制御の成分を大きくしたのが効果があったようだ。アクリル曲げ器は、内部230℃でアルミパイプ表面がアクリルを曲げる最適温度150℃程度になるので、これで十分である。ハンチングは残るが比例制御より心持ち少なくなっている。

 弁解になるが、こういう時間遅れの大きい制御は、本当に難しい。試しに、このあいだ作った調光器(無段階調整可能)で人間の手で所定の温度に止める制御をやってみた。放置しておけばこの前の記事のようにどこかで一定の温度に落ち着くが、決められた温度を手動で一定に保つことは実は極めて難しい。

 温度が下がってきたとき、ボリュームを上げて温度低下を防ごうとする。ところが温度は急には上がらない。暫くしてから徐々に温度は上がりだし、このとき慌ててボリュームを下げても、温度はどんどん上がっていく。

 結果として目標温度を大幅に上回ってしまう。さっきボリュームを下げたので、再び温度は低下しはじめる。しかし低下に気がついてボリュームを上げてももう遅い。少々ボリュームを上げても温度はいつまでも下がって目標温度をあっさり割り込んでしまう。そして、これの繰り返しになる。

 人間の手ではとても一定には出来ない。負け惜しみになるが、このマイコンの制御などうまくやっているほうだと思う。あまり自信はないが、ここまでの成果のソースコードを公開することにする。ハードはこの前と全く換えていないので回路図は前記事を参照していただきたい。

 まだ改善すべきところは多々あると思うが、あまりこればっかりにこだわっているわけにもいかない(面白いけれど)。このプロジェクトもこのあたりで一段落つけることにする。

 以下に例によってAVRStudioのプロジェクトフォルダーの形で、PID制御のソースコードを置きます。 フォルダー名が替っているだけでソースファイル名は同じなので注意してください。修正したコードはコメントの形で残っています。参考になれば幸いです。

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

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

2011年11月25日 (金)

熱電対によるヒーター制御:比例(P)制御だけで十分か

電源とAC制御部の制作(11/16/2011)
 熱電対を使ったヒーターの温度制御は、SSR(ソリッドステートリレー)によるAC制御部とマイコンの電源を、ケースの都合で温度表示・設定部と別にすることにしていた。ところがあらためて調べてみると手持ちのケースの中に、電源部などが入る適当な大きさのものが見つからない。

 結局、何か買ってこなければならなくなった。何だ、それなら最初から両方が入るケースを買えばよかったのだ。やっぱり思いつきで工作はするものではない。ケースが2つになってしまう。効率が悪い。

 久しぶりに秋葉原に出て、千石で適当なケースを探す。温度表示・設定部のテイシン(TB-65B)と同じメーカーのTB-73(60×90×29 ¥220)にした。こちらの方が新しいシリーズらしく、固定したままケースをはずすことができるように改良されている(前のはケースを開けるのに、固定板をとりはずす必要がある)。

S_pb184378 ただ、前に較べるとちょっと背が低い(高さ29mm)。SSRに手持ちのヒートシンクをつけたので入るかどうか心配だ。ヒーターは300Wくらいだが、連続通電はまずしない。ヒートシンク無し(2Aまで)でも大丈夫だとは思うが、念のためつけてある。これで連続400Wくらいまで大丈夫なはずだ。しかし、ヒートシンクの高さは出先なので、その高さがわからない。

 秋月で、手持ちのものよりもう少し小さい(と思う)シンクを念のため買った。家に帰って確かめる。おお、うまいぞピッタリか、いや、このヒートシンク(高さ18mm)でもSSRのキットをそのまま基板の上に載せると入らない。うーむ、どうすれば良いか。そうか、キットの配線をベース基板に移せばそれだけ低くなり、このケースに入りそうだ。

 いや待てよ。トライアックだけベース基板に移せば、キットの基板配線をそのまま使える。リード線でトライアックを主基板に移す。ちまちました作業だが、少しでも合理的な工作が出来ると嬉しいものである。はたからみれば、何のことで一喜一憂しているだといぶかることだろうが、自分の知恵で課題が解決するというのが快感なのだ。

S_pb184382 ソフト開発の方は、だいぶ前にon/off制御のステートメントを入れ、テストが済んでいる。単に1秒ごとに、温度が設定より高くなればoff、下がればonになるという滅法簡単なロジックをいれただけだ。もちろん、あとで、PWMなどで比例制御をやるつもりだが、これはあくまでもテスト用である(これでうまくいけばという下心もある)。

 工作を続行する。マイコンの5V電源は、このあいだLAN電源制御コントローラーで壊れたACアダプターを分解してセットする。あのあとパンクしたコンデンサーを取り替え、割れたケースを接着して使えるようにしていた。資源の徹底活用である。

 ここの自慢は、このアダプター基板の固定だ。外側のモールドを、サーキュラーソーで4ミリ程度に輪切りにし、これを基板に接着した。ちょうどモールドには基板を固定する爪がついており、これを生かしたのでちょうどピッタリ固定される(最終的にはホットボンドで固定)。

 いやいや好調である。「俺は天才ではなかろうか」などとうそぶきながら、機嫌よく工作を進める(単にケチなだけだが)。ACコード(何でAC用はどれもこんなに太いのか)のハンダ付けが少々面倒だったが、キットを組み合わせるだけである。大した手間もかからずAC制御と電源の配線は終了した。

 むしろ外回りのAC線の引き回しが厄介だった。ACをいきなりon/off制御をするのは、何となく怖いので、最初は調光器を経由してやろうと考えている。これから予定している比例制御(P制御)の感触をつかむためもある。 

 しかし、そのままつなぐとマイコン電源アダプターに調光器で落とされた電圧がかかってしまいまずい。はじめは、ハンダ付けか何かで制御部と、電源部のAC入力を仮にわけようと考えていたが、AC制御部の出力のピン差込端子(車の電装用と思われる)に、ピン差込端子を経由してアウトレット(ACコンセント)を用意すれば、調光器をヒーターだけにかけられることに気づいた。こうしておけば、仮配線はしないですむ。早速、余ったピン差込端子を使ってこしらえる。

S_pb224399 ピン差込端子は、もしかするとAC配線用ではないかもしれない。しかし振動の激しい車で何十アンペアという大電流に耐えられる端子である。全く大丈夫と判断している。もちろん自己責任である。アクリル曲げ器を動かしたまま、家を留守にすることはあり得ないし。

 熱電対がニクロム線に触れぬようガラス繊維チューブを切って細いキャップを作り、接合点に被せ、アクリル曲げ器のニクロム線のコイルの中に差し込む。バラックも良いところだが、とりあえずヒーターの温度制御の実験環境はととのった。

on/off制御では温度差が激しすぎる(11/18/2011)
 いよいよ、AC電源を入れたテストである。始めは怖いので、ヒーターではなくスタンドの白熱灯を負荷にする。勇気を出して電源部のACコードを差し込む。緊張の一瞬だ。よし、温度測定・設定部の7セグLEDが点いた。正常に5Vは供給された。しかし電灯は点かない

 う、温度設定はONのはず(設定温度が現在温度より高い)なのにおかしい。慌てて電源を切る。スタンドを確かめる。はっはっは、スタンドのスイッチが入っていなかった。スイッチを入れて再度通電。おめでとうございます。スタンドのクリプトン電球が点灯した。S_pb224396

 設定温度を下げれば電球は消える。リレーではないので全く音はしない。たいした回路でもないが、すべての部品がちゃんと機能して、思い通りに動いてくれているのを見ることは無性に嬉しい。子供のようにロータリーエンコーダーをぐりぐり回し、点けたり消したりして暫く遊ぶ。

 さあ、次は本番のヒーター制御のテストである。温度推移を記録するため、UARTを復活させ、ケースから出してISPケーブルをつけ測定に入る。ふむ、ISPピンを外に出しておかないと不便だな。また穴あけをしなければ。10秒ごとに温度をUARTに出力させてグラフを作る。

Photo 結果はグラフを見てもらった方が早い。最初のグラフの山は、調光器を入れて設定温度を100℃にしたときのカーブである。調光器のセットは、以前連続で150℃近辺になるよう調整した電圧である(テスター見るとRMS40Vくらい)。オーバーシュートもほとんどなく、温度の差は20℃内外で、on/off制御でも、まあまあの性能である。

 一方、次の大きなカーブは、調光器なしに直接100Vをon/offした結果である。生の100Vでは250Wのニクロム線でも(例のCT電力センサーで測った)、温度は一気に上がり、100℃に設定しても、温度の慣性が高い(というより熱電対と発熱源が離れすぎているのだろう)ので、電源がoffになってからも200℃近くまで上昇し、そのあとも激しく温度変化を繰り返すことがわかる。

 調光器で加減すれば、20℃内外の温度差で落ち着くが、設定温度を変える度に、調光器で調整する必要がある。まあ、アクリル曲げ器くらいなら問題ないだろうけれど、これでは自動制御とは言えないだろう。完成度が低すぎる。もう少し手を入れてやる必要がある。

 温度が測れるので、色々試してみた。調光器による温度設定は、加減すれば一定の温度にとどまり、うまくやれば安定した温度が得られることがわかった。負荷をかければもちろん駄目だが、アクリルの曲げるところを当てるくらいでは余り影響がないだろう。もうひとつのグラフは、この安定した温度が得られる様子を示している。温度が安定する度に調光器のボリュームを上げて温度を段階的に上げている。

Photo_2

 さあ、これに負けない制御にしなければならない。なるべく単純なロジックで最大の効果が出るしかけを作りたい。あれこれ考えをめぐらす。紙にメモをとりながら可能性を探る。電子工作の醍醐味のひとつである。

しゃれた二次曲線の比例制御ではうまくいかない(11/21/2011)
 とはいえ、on/off制御の次にやるべきは、やはり定番の比例制御である。設定温度との差に応じてヒーターにかける電力を上下させる。今度の温度制御は、アクセル(ヒーター)だけで、ブレーキ(強制冷却など)のようなマイナス方向の制御はしないので、精密な制御はもともと無理でするつもりもない。

 電力の制御は、秋月のSSRキットである。本来は、on/off用だが、このSSRはゼロクロス制御機能を持ったフォトトライアックを使っているので、電源周波数(50Hz)分50段階の電力制御が可能だ(正確には半サイクルごとの100段階まで、長周期にすればいくらでも多段階にできる)。

 お手本は、前記事に紹介した、このハンダごての温度コントローラーの記事である。全く同じキットを使われている。音、LEDなどの光と違ってヒーターという非常に時定数の大きい制御対象なので、この程度のゆるいスイッチングでも全く問題はない。

 ただ、問題は通常のマイコンのPWMにこんな低い周波数でPWMが出来るものがないことだ。しかし、マイコンの便利なところは、このあたりを気楽にタイマーの割り込みで作ってしまえるところだ。

 タイマーで、50Hzのタイミング、20msの割り込みを発生させ、割り込みの都度、制御係数を見て、適当なパルス幅を決めてやれば、1秒間隔(1Hz)の自作PWMが完成する。カウントは50で繰り返す。対象の周波数との同期をとる必要はない。少し遅れるがフォトトライアックの部分で同期する。

 比例制御の実行部分は、これで整った。次は、制御仕様の部分である。ウェブには色々な方法が紹介されているが、とりあえず、比例制御の部分を設定温度の1/2から始めることにする。それまでは全力(100%)でヒーターを加熱する。比例部分は、単なる直線では面白くないので、2次曲線で比例するように趣向をこらしてみた。時定数の大きい熱制御なので、最初は激しく、後半は慣性が効いて来るので小さく加熱というくらいのつもりである。

 難しいコーディングでもない。ただ、2次曲線で比例制御するために2乗の計算を整数でやるのは、ちょっと大変だった。16ビットではなく、32ビットの変数が必要である。桁あふれをしないよう、割り算で有効数字がなくなってしまわないよう、気を遣う。久しぶりに方程式を立てて制御係数が0から50になるようにする。

 手作り1秒PWMはオシロでうまく動くことを確認した。さあ、いよいよテストである。温度設定を100度にしてスイッチON。おお、順調に比例制御が出来ているようだ。UARTに刻々と比例制御の係数が出力され、温度の1/2から、PWMが効いてパルスが細くなっていく。

 ただ、最初の突っ込みは比例制御の範囲ではないので、猛烈な立ち上がりとなる。ヒーターと熱電対の間が離れているので、遅れが大きい。目標温度を感知した時は、既にこのパイプを倍の温度近くまで加熱する熱量を出した後だ(調光器を通さず、250Wの全電力がかかる)。比例制御は最初からやるべきか。

10

 おやあ、150℃の設定で140℃にしかならない。100℃でも10℃近い偏差が出て目標温度に達しない。二次曲線なので、目標温度付近の比例制御値は0に近く、この程度の加熱では、100℃以上の高温にならない。

 そうか、積分制御(I制御)というのは、こういうときのためなのか。段々わかってきたぞ。PID制御というのは徹底した実務的な制御なのだ。色々な系の状況を吸収して、合わないときは所定の目標値に強引に合わせるというのが、I制御なのだ。こうやって制御を実際に動かしてみると良く理解できる。

 感心していても、解決策は生まれない。PID制御まで行かないで、もう少し簡便な方法で制御ができるはずだ。やはり基本に戻って、普通の一次比例制御(直線制御)でやってみよう。

単純な比例制御と倍周波数のPWMで予想以上の成果(11/24/2011)
 直線制御にするついでに、制御段階をさらに細かくしてみることにする。交流なのでゼロクロスするところは1サイクルに2回ある。50段階ではなく、100段階のPWMが可能だ。

 割り込みの間隔を1/2にし、比例値を0~50でなく、0~100にする。今度の比例分を出すのは、さっき苦労して計算した2乗など必要ない。32ビット変数もいらないくらいだ。あっけなくロジックも出来た。

 勇躍、テストに入る。目標温度を150℃に決めてヒーターONする。よーし、今度は、比例制御を目標の1/2ではなく最初から比例するようにしたので、立ち上がりがおだやかになった。オーバーシュートも50℃以内におさまっている。良いぞ。

 比例制御を最初からやっているので高温の時は遅くなるかもしれないが、この程度のパイプを熱するだけなら全く問題ない。しかし、150℃の目標温度に近づかない。うーむ、一次比例でも駄目なのか。やっぱり積分制御が必要なのかなあ。

 どうしようかとオシロのPWM波形を見ていたとき、閃いた。目標温度に近づかないのは、失われていく熱に対して、供給する熱が少ないからである。この量を増やしてやれば良い。PWMの間隔を50Hzでなく倍にしてみてはどうだろうか。

P

 理論的には、比例制御の勾配を倍にし、1/2のところから比例制御するのと同じだが、まあ、だめもとでPWMの間隔を半分にしてみる。ビンゴ!であった。150℃はもちろん、100℃、50℃でも±10℃の間でピッタリ納まった。立ち上がりこそ、最初が全力で立ち上がるのでオーバーシュートが100℃以上になるが、それ以外はもう文句のつけようのない制御である。いやあ、比例制御だけで十分か。

S_pb224393

 このアクリル曲げ器のニクロム線(250W)とアルミパイプなどの機器の熱容量にだけに通用する制御だけれど、比例制御だけで、こんなに安定して温度が制御できるとは思っていなかった。30℃や40℃の設定でも結構OKである。余裕が出来たので、CT電流センサーの出力をオシロに入れ、SSRの制御波形を観測してみた。50Hzの波形が見事に、立ち上がりからスタートしているのがわかる。AC制御・電源部のケースも完成した。電源がONのときは赤LEDが点灯してパイロットランプ代わりになっている。

S_pb224392

 お約束の回路図とソースコードを公開することにする。電源部とSSRは既製品とキットの活用である。ソースコードは今後、(I)(D)制御を加える予定なので、あくまでも途中経過のコードであることをおことわりしておく(エラー表示も未実装)。また当然のことであるが、回路図、ソースコードとも全くの無保証であるのでそのつもりでご利用頂きたい。

S_pb244405

以下に例によってAVRStudioのフォルダーでかためたソースコード一式を置きます。回路図ファイル(bsch3V)も入っています。ソースコードは、参考のために、あえて試行錯誤の後をコメントアウトで残してあります。

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

Thermocouple_3

 

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

2011年11月14日 (月)

熱電対によるヒーター制御:温度測定と設定部の実装完成

 Tiny861のバグ騒ぎが一段落して、ブレッドボード上では熱電対による測定温度の表示と、温度の設定までの機能が完成した。7セグLEDは、FPGAのときに使った6桁のテスト基板なので1列の緑単色と味気ないが、実装版は緑と赤の2段の7セグLEDでそれらしくなるはずだ。

 温度設定のロータリーエンコーダーも余程、高速で回さない限り割り込み方式で確実に回転を捉えている。ただ、値が変わる度にEEPROMにデータを書き込んでいると、とりこぼしが多い。EEPROMは書き出しに4ms近く待たされるからだ。まあ、そんな高回転でまわすこともないし、大勢に影響はない。

 実装版は結局、当初案どおりアクリル曲げ器のスイッチ用の小さなケースに表示・設定部を組み込み(というよりここの工作が先行してしまっている)、SSR(ソリッドステートリレー)などのヒーター制御部は分離する方向で計画が進んでいる。どちらも曲げ器の台板に固定して使う予定なので、分ける必要はないのだが、部品在庫一掃のねらいもある。

久しぶりのハンダ付けが楽しい(11/6/2011)
 実装版は、ケースが決まっているが構成は確定していない。いつもと順序が逆である。今回の工作は2階建ての基板で、上に7セグLEDとエンコーダー、シフトレジスターが載り、下の基板がCPUとオペアンプなどのアナログ部が載る予定である。

S_pb064326

 いつものようにアートワークを始める。下の主基板のCPU部や、アナログ部はスペースもあり、アートワークを描くまでもないのだが、上の7セグLEDの方は配線のスペースがない。7セグLEDのダイナミック表示のため並列配線も簡単なように見えて重ならないようするのは、そう簡単ではない。おかしいな。こんなに大変だったっけ。

 まあ、簡単でないから面白いということもある。そうか、このあいだはLEDはわずか2つだけだったし、FPGAの時に作った6ヶの7セグLEDは、ピンが縦位置で、並列配線が楽だったのだ。今度は、ピンが横位置でしかも3ヶづつ2段。面倒なわけである。

 アートワークの面白いところは、工夫次第で配線が一気に楽になることがあることである。そういえば、Eagleでは日がな一日、これをやってあきなかった。他の事もやりながら(気分を換えて見直すと、良いアイデアが浮かぶ)、2日間かけて主基板とLED基板2枚のアートワークは完成した。

 いよいよ、実装だ。久しぶりのハンダ付けが楽しい。まず、主基板のアナログ部から配線を始める。アナログ部の配線はわずかですぐ完成した。例によってkumanさん流の逐次開発方式で、ブレッドボードでやった調整をもう一度、実装版で繰り返す。

 アナログ部は、冷温端の温度を計測する温度センサーLM60の出力電圧を、熱電対の発生起電圧(1℃あたり、40.7μV)に合わせる分圧抵抗の調整と、熱電対と合算した電圧を、Tiny861のADコンバーターの測定範囲(最大2.56V 10ビット1024段階)に合わせて増幅するオペアンプの増幅率の調整である。

 LM60 は半田付けせず、調整のためソケットにしてある。まずLM60をつけずにソケットに適当な電圧をかけ、熱電対との分圧回路の補正を行う。ここは室温の補正なので数百度の温度を扱うときは、それほど神経を遣う必要はない。抵抗を分離して片側を固定抵抗にしたので調整は簡単に済んだ。 

 次は、オペアンプの増幅率の調整だ。ここはオフセット電圧もからむので、熱電対をはずして、また別の電圧をかけ、方眼紙を取り出して慎重に測定を開始する。

 うーむ、オペアンプのリニアリティが余り高くないな。どの電圧域でも同じ増幅率というわけにはいかない。電圧の高いところで、所定の増幅率61.425(1℃あたり2.5mVにするため、2.5/0.0407)にすると、低い電圧(0.1V以下)では大きくずれてしまう。

 オフセット電圧が悪さをしているのだろうが、補正の仕方がいまいちわからない。このあいだのグラフはオフセット電圧がマイナスに行ってしまった。こればっかりやっているわけにもいかない。補正はあとでも出来るので、アナログ部は一応これで良しとして、次に移ることにする。

7セグLEDの配線は相当な密集度だ(11/8/2011)
 ハンダ付けは、7セグLED基板の方に移った。面倒である。7セグLEDを組み込んだ基板だけが結構な値段で売られている理由が良くわかった。7セグLEDがたくさん並び、エレメントを始めから並列に配線したダイナミック表示用のユニットもあるが、3つのはないので今度の工作には使えない。ただ黙々とつないでいくしかない。

S_pb114330

 凝り性なもので、気楽に線を交叉させて配線するのに抵抗がある。アートワークはそうならないように引いてはあるが、現実にハンダ付けがその通りできるかというと、線が重なってそううまくはいかない。一回のハンダ付けの集中の限度は限られている。少しやっては、何か別のことをやって気を紛らし、また半田ごてを握るという繰り返しである。

 そのかたわら、そろそろ温度制御のことについて検討し始めた。まだ先の話ではある。でも、単なるon/off制御だけでは面白くない。モーター制御のころから考えているロボットやラインセンサーなどの制御より、温度制御はゆるくて勉強にはもってこいである。色々ウェブを探し回ってわかりやすいサイトを探す。

 PID制御の復習をした。Dは良くわかるが(前回との偏差で比例量をいつもより増やすか減らす)、Iはどうするのだろう。設定値と現在値の差分を足して行って、一定のタイミングで比例量を増やすのだろうか。P制御だけでは、オフセットはとれないのだろうか。

 今まで習った制御の伝達関数とはどういう関連があるのだろう? PID制御との接点が見つけられない。2次応答の時間変化を周波数成分変化にするような変換だったような気がするが、その記憶は遠い彼方に消えている。

Tiny861のフューズビットを書き損なう(11/10/2011)

 すべての配線が終了した。しかし、なぜかすぐ電源を入れるのが怖くて何となく別の作業しているうちに、またショックな事件がおきた。実装版のCPUを用意しようとして、もうひとつのストックのTiny861を初期設定しているとき、フューズビットを書き損ったのである。

Tiny861a フューズビットのハイバイトとローバイトを間違えて書き込んだ。コンソールのメッセージを見ると、SEL0~3にデータシートにないビットを書き込んだことになる。これだけで、全く反応しなくなった。やれやれ、¥200(秋月)の石だけれど、まだ新品だ。一度も使わずに部品箱に死蔵されてしまう部品をまたひとつ作ってしまった。不憫でならない。

 パラレルプログラミングの出来るAVR Dragonなら、こういう石を救えるのだろうか。DigiKeyでは¥4,305である。円高でまた少し下がったようである。この前、Tiny2313(¥100)を救おうとした時は、1対47(当時4700近辺)の投資対効果だったが、今度は、300:4300と1対14まで上がった。そろそろ買っても良いか。

 ただ、送料無料にするためには、もう少し買うものを増やす必要がある。あと、¥3000ばかり。こうして電子工作無限地獄が続いていく。

電動ドリルのスタンドを買う(11/11/2011)
 何か、ものを失うと、無意識のうちに何か別のものを揃えようとする癖が今度も出た。久しぶりにDIY店に行って、無性にドリルスタンドが買いたくなった。CPUチップの代わりというのもなんだが、前から欲しかった工具である。

Pb144355 普通の電動ドリルをボール盤にする(まあ、ドリルスタンドです)工具である。¥2,980の超廉価だが結構しっかりしている。電子工作のプラスティックケースの穴あけ工作くらいならこれで十分だ。プロクソンのミニルーター用のドリルスタンドは既にあるが、少し大きい穴を開けるのは今までの大工工作用の昔の大きな電動ドリルを手で支えて開けていた。

 買って帰って早速、ドリルのテストをする。うん、これは楽だ。値段が安い割にはがたつきも少なく強度も問題ない。しかし、出来上がった温度計の実装版に電源を入れる気力がまだわかない。たいした機械でもないのに結構苦労した。動けばともかく動かないときのショックを味わうことを恐れている。

 というか、色々なことを思いつく(やりたくないための無意識の行動だろう)。実際の熱電対の高温測定実験などもそうである。本来の用途、アクリル曲げ器の温度測定のため、ニクロム線を入れたパイプの中に熱電対を入れて温度を測ってみた。なぜ、今までやらなかったのだろうと思うぐらいの基本的なテストだ。熱電対の発生電圧は例のDVM(秋月のデジタル電圧計)で測る。0.1mVまで測れる。

 どの程度の制御で温度を一定に保てるかというのが実験の当面の目的である。とりあえず調光器で下げた電圧を与えて様子を見る。通電すると見る見るうちに電圧が上がり、切ると、結構早く温度が下がって行く。on/off制御でも何とかなりそうだ。

S_pb114333

 ただ、パイプの中と外では、100度近い温度差があることがわかった。表面温度を熱電対で確実に測るには、熱電対を表面に固定する必要があるが、固定の仕方がわからない。それにパイプの場所によって結構温度に違いがある。中の方が安定して測れることは確かだ。換算する方が信頼性が高いかもしれない。

 このあたりをウェブで色々調べるが、熱電対の世界は、圧倒的にプロの世界で、当研究所のような遊び半分の温度測定のケースは全くない。うーむ、参考になる情報が少ないなあ。手探りで作っていくしかないようだ。

やっと実装版に通電。何とかLEDまでは出た(11/12/2011)
 出来上がったものをいつまでも置いておくわけには行かない。意を決して、出来上がった実装版のテストに入った。残っていた電源コネクターをつけて通電する。おお、7セグLEDが点いた。おーし、このあたりは大丈夫なようだ。ただ、フォントは無茶苦茶だし、エンコーダーも動いていない。

 少し調べて、原因はすぐわかった。エンコーダーが動いていないのは、制御線をプルアップしていない。フォントがおかしいのは、スキャンが逆方向だったり配線間違いが見つかった。不具合の場所はほぼ特定できた。そりゃそうだ。ブレッドボード版と何も変えていない。良かった。これでゆっくり寝られる。

 次の日、きのうまでの究明経過をメモに書きだし、確かめながらひとつづつ、つぶしていく。直すべきところがわかっているこういう作業は、むしろ楽しい。CPUソケットの内側にプルアップ抵抗を入れようとして苦労する。シングルラインではない梯子型のソケットでやりにくい。

 最近の当研究所のCPUソケットはすべてシングルラインを使っている。中にパスコンなどが入れられるので便利である。それに気づく前に買った梯子型のソケットが部品箱にだぶついている。

 ここも在庫一掃のためなのだが、マーフィーの法則とはこういうものである。こういうときに限って、ソケットの中に部品を実装しなければならなくなる。梯子のような支持部が邪魔だ。プルアップ抵抗2つを無理やり押し込む。

 次は、7セグのエレメント違いである。9番と10番をテレコにしていることが、昨日のテスト結果で判明している(1から9までの数字を表示させて見つけた)。これはうっかりミスだ。基板配線を確認する。あれえ、間違っていない。どうしてだろう。ソースコードのコメントを見て驚いた。

 これまで動かしてきた7セグLEDは、ピンの順番がabcdegfと最後の2エレメントがfgと並ばずgfと逆になっている。こういうものだと思って3種類の7セグLEDをこれまで問題なく動かしてきた。ところが、今度買ってきた(千石電商)7セグのデータシートは、abcdefgとアルファベット順になっている! 

 予備の部品をブレッドボードに差して実際に確かめる。そうだ間違いない(あたりまえか)。ふーむ、7セグLEDのピン配列は統一されていないのか。一つ勉強した。解決は?四の五の言わずに半田付けでひっくり返しただけである。

 さて、最後は7セグの表示位置がずれている件である。もういちどピンナンバーとドライブしているトランジスターとの結線を確認する。どうしたことだ。全くの勘違いも良い所で、全然順番になっていない。一体、どういうつもりでこの配線をしたのか疑いなくなるデタラメぶりである。

S_pb124339

 1本のドライブをシフトレジスターのパラレルピンの残りの1ビットでつけているので、これに何か縛られておかしなことになったらしい。いずれにしても、ソフトをいじっても解決する話だが、あんまりハードが目茶目茶なものをソフトで吸収すると、あとで苦労しそうで、わかりやすい形に順番をそろえる。

熱電対による温度制御は、表示部と設定部まで完成した(11/13/2011)
 さあ、細かいところは、まだいくつかあるが、大所はこれで大丈夫なはずだ。ChaNさんのISP-UARTを使っているので、デバッグ->ソース改修->テストのサイクルが早い。PC(UART)端末の接続を切れば、AVRは自然にISPモードになり、プログラムをただちに書き込める。書き終わった後、端末を立ち上げると、デバッグ用のUARTメッセージが流れてプログラムがスタートする。

 2Kばかりのフラッシュなのでコンパイルは一瞬で終わる。端末を立ち上げる。よーし、7セグLEDが光った。緑と赤なのできれいだ。ちゃんとした数字になっている。エンコーダーを回す。良いぞ、ちゃんと数字が上下する。

S_pb114331

 勢いに乗って、ケースの完成を急ぐ。早速買ったドリルスタンドが大活躍する。大きな穴もリーマーではなく、3ミリドリルあたりで連続して揃えて開けていけばどんな形にも簡単に切り抜くことが出来る。正確な位置に開けられるのでこういうことが楽に出来る。やっぱり工具には金をかけるものだ。熱電対のコードのソケットと電源ケーブル(制御線を含める)ソケットの穴が短時間に正確に開いた。好調だ。

 電池を仮付けして持ち運びが出来るようにしたら、やることがある。台所に機材を持ち込む。基準温度として我が家で最も正確な温度、100℃を計測するためである。我家の標高は、40mで今日は天気も良い。沸騰点は殆ど100℃のはずである。

S_pb124350

 家族に内緒で、鍋に水をいれ沸騰させる。熱電対をそこに入れる。温度は順調に上がって、100℃を越えた。暫く沸騰を続け、105~110℃の範囲に納まることを確かめた。平均は107℃あたりのようだ。鍋の底の火のあたるところが高く、沸騰面の水面近くが低い。お湯はこっそり捨てる。

 ふむ、7%の誤差か。もう少し校正したほうが良いかもしれない。しかし、アクリル曲げ器の温度設定のリファレンスとしては、これでもう十分なような気もする。

少し、ゆとりが出来たので、温度制御で空焚きをしたときに出すエラーメッセージを7セグLEDに出して遊ぶ。温度センサーが発熱体からはずせるので、これは必須の機能だ(昔、熱帯魚の飼育でひどい目にあったことがある)。

S_pb124338

 いずれにしても、これで温度制御の第一ステップ、温度測定部と温度設定部はほぼ完成したようだ。次の課題は、いよいよSSRを使ったヒーター制御だ。

 回路図やソースコードの公開は、簡単なヒーター制御が出来てからにしよう。

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

2011年11月 5日 (土)

熱電対を使ったヒーター制御の野望実現へ

 ガイガーカウンターの工作は2台作ってやっと少し熱がさめた。2台目のガイガー(GM)管SBM-20がベータ線で時間とともにパルスカウントが増加してしまう問題は解決されていない。しかしケースに入れてガンマー線を測っている限り、全く問題なく安定して線量が測定できる。これをさらに追求する必然性は薄れた。

 当研究所のモットーは「実用」である。名目でも何でも良いから実用的な目的がないと工作をしないことにしている。実用目的無しに始めたのはLEDマトリックスの電光ニュース基板くらいなものである。

 これも最初は、ネットにつないでメールの受信メッセージを掲示するという仮の目的を作ってあった。Xbeeを使ったラジコンなどは、実用というには少々おこがましいが、ラジコンそのものが実用という強引な解釈である。

 最近流行(はやり)の小さなTFT液晶やMbedなどは実は自分も欲しくてひそかに買ってある。天邪鬼でへそ曲がりの割には他の人の工作が気になる、いやな性格である。しかしこのあたりの機器の目的が見つからないのでやりたくてもなかなか手がつけられない。

 工作のための工作というのは可能な限りやらないことにしている。いまさら小さな画面に画像を出したり、タッチパネルで操作ができても、スマートフォン全盛の時代である。どれだけ頑張って完成させても「で、それがどうしたの」と無邪気に馬鹿にされておしまいである。これまでの苦労と自尊心がズタズタにされてしまうのが怖い。

 電子工作を始めて、かれこれ4年、やりたいテーマ、出番を待っているICチップ、基板は(雑誌付録まで入れるともう)それこそ山ほどあるが、どれも役に立ちそうな応用が見つからない。何かわくわくするものがない。食指が動かないのである。

 ということで次のテーマがなかなか見つからなかった。8つくらい候補をリストアップしてみたが、どれもいまひとつ魅力に欠ける。GM管の外部クェンチ回路などはこれまでの記事で何回か候補に上げているが、この回路が動いたとしても、SBM-20のベータ線によるCPM増加が止まる保証は全くない。うまくいかなかったら空しいだけだ。

S_pa234310熱電対温度計に決める(10/23/2011)
 迷った挙句、選んだのは熱電対の温度計だった。ガイガーカウンター工作が混迷していた時、きまぐれにここのサイト(http://mgw.ti-da.net/e3171197.html)を参考に、ミニブレッドボードに多回転VRとオペアンプを載せて熱電対をテストしている(前記事参照)。これをそろそろ実装してみることにした。この温度計の先には、このあいだ作ったアクリル曲げ器などのヒーターの温度制御が待っている。

 立派な実用目的である。7セグLEDで、現在温度と設定温度を色を変えて表示する。温度設定は、これまで用もないのに面白がって秋月で買ったロータリーエンコーダー(たったの¥200)で、ぐりぐり動かして決める。面白そうだ。

 この前の熱電対の実験は、単にオペアンプで所定の電圧が作れるか試しただけだったが、今度は、手持ちの温度センサーLM60をつけて実際の温度変化を試す。手で持つと手の暖かさで確実に電圧が上がっていく。このLM60は、0℃で424mVと大きなオフセットを持っているので、補正しないと正しい温度が得られないが(その分低温が測れる)、正常に動くことは確認できた。

 次は熱電対だ。熱電対のソケット(サイトにならって平型端子を流用)を汎用基板の切れ端にハンダ付けして端子基板を作り、これをブレッドボードに差して測ってみた。熱電対のプローブを手で触る。電圧は上がった。しかし倍以上の電圧である。しかも激しく変化する。熱電対の上昇は温度センサーに較べるとはるかに小さく、オペアンプで増幅しているにしても、こんな値になるはずはない。

 何か、おかしい。オシロを取り出して出力電圧を見てみた。おやおや、盛大なノイズが上がっている。オペアンプが発振しているのだろうか。いや違うようだ。ウェブで色々原因を探し回る。

 的確な答えはなかったが、要するにオーディオアンプの入力と同じで人体に乗っている微小なACが悪さをしていると考えるのが一番妥当なようだ。つまり熱電対の出力のところがハイインピーダンスだと言うことである。

 実際には、熱電対の接点を手で触ることはなく、耐熱チューブで包んでヒーターの中に入れるだけだから問題ないとは思うが、手で触っただけでおかしくなるというのは何とかしなければいけない。

 そうか、ハイインピーダンスというのなら、交流的にコンデンサーを入れてバイパスしてしまえば良いのではないか。温度変化は、殆ど直流と考えてよいので少々のコンデンサーを入れても影響はないはずだ。早速実験してみることにする。

 100pFから、10μFまでのコンデンサーを次々に入れていく。やった。4.7μFあたりからピタリとノイズが止まった。表示電圧に変化はない。仮説に基づいて対策を考え、それが想定どおりの動きをする。いやいや、こんなささいなことでも思ったように動くというのは嬉しいものである。

 とりあえずはブレッドボード上で熱電対を含めて温度が測定できるところまでは確認できた。試しに百円ライターで熱電対の接点をあぶると、盛大に電圧が上がる。アナログ部はこれで問題がないようだ。

 オペアンプはまだLM358。電源は5V単電源で良いだろう。様子を見てレールツーレールのLMC6482に行く(買ってある)。そろそろデジタル側のことも考えなければいけない。CPUは最近の定番,Tiny2313ではADコンバーターを持っていないので面倒だ。Tiny861あたりだろうか。Megaまで行くことはあるまい。Tiny861なら、大分前に使う当てがなかったが秋月で安かったので買ってある(¥200)。想定しているケースは少し小さいので、7セグLEDを含めたレイアウトが悩ましい。

S_pa254311

ケースの製作だけが進んでいる(10/25/2011)
 主だった構成は決まったが、細かいところの仕様はなかなか固まらない。それなのにケースの制作だけは進んでいく(これは命取りになるときがあるが)。今、考えている仕様は、7セグLEDを2段にして一つの段に現在温度、次の段に設定温度を表示させ、ロータリーエンコーダーで設定温度を決めると、その温度差を見てニクロム線ヒーターをON/OFFする。ACの入り切りは、SSR(ソリッドステートリレー)で行う。

 ケースは、千石で買ったテーシンのTB-65B(54×84×35)である。底はアルミプレートになっており、これでアクリル曲げ器の台板に固定する。少し小さいが、これはもともと電源スイッチをつけるためだけに買ってあったものである。このケースも、このあいだの電子ボリュームと同じように、基板の固定用の柱が中に出っ張っていて、配線用の基板は隅を切らないと入らない。

 ここに全部入るだろうかとケースを手にとって眺めている間に、急に作りたくなり、サーキュラーソーで、ケースに入る汎用基板の隅を切り始めると、もう手が止まらなくなった。7セグLEDの固定をどうするか考えて、保守性を上げるため主基板にポストを立てて固定するアイデアが浮かぶ。

S_pa254313 するとまたこれも作りたくなり、以前買ってあったABS樹脂の外径4ミリ内径2ミリのパイプを切って、2ミリセルフタッピングネジをねじ込んでみた。おお、結構強く固定できそうだ。ちょっと様子を見るだけの工作がどんどんエスカレートして、2階建ての基板が出来上がってしまった。そう、最近は頭より手の動きの方が早い。

アナログ回路はほぼ確定した(10/27/2011)

  そうは言っても、アナログ回路の検討は続けている。ウェブの情報を頼りに熱電対のセンサー部分のテストを進める。これまで参考にしているサイトの回路は、簡便に可変抵抗器の中点を、分圧点やオペアンプの入力にしているが、これだと変化が大きすぎて調整しにくい。片側だけ可変にして、一方を固定抵抗にし、調整し易いようにする。

 冷温側の測定センサーは手持ちのLM60である。このセンサーの1℃あたりの電圧は6.25mVで、参考にしているサイトのセンサー(LM61)とは異なる。補正値を修正する必要がある。5VをVRに入れ、32.5mVが出るように多回転VRをまわす。うまくいった(0.0065倍)。

 微小電圧なので周りの外乱が心配だが、実際は、数百度(今のところ150℃近辺)の制御なので、余り気を遣う必要はないだろう。ブレッドボード(ミニ)だけれど結構安定している。

 次は、オペアンプの調整だが、その前に全体仕様をかためた。秋月で入手したK型熱電対は、1200℃まで測れるが、もちろんこんな高温まで測るつもりはない。アクリル曲げ器に特化するなら200℃程度までで十分だ。欲を出して7~800℃くらいにしておけば、半田ごてなどの温度測定にも使えるだろう。

 CPUチップは手持ちのAVR ATTiny861で決まりだ。2313はADコンバーターを持っていないし、温度制御のロジックを考えると、2Kのフラッシュでは少し不安だ。Tiny861のADコンバーターの基準電圧は、2.56Vと1.1Vの2種が選べる。オペアンプが使えるので当然2.56Vにする。

 分解能は、10ビット、1024ポイントある。一度単位で、0度から1024度までカバーできる。そのときの分解能は1℃、2.56/1024= 0.0025V で、1度あたり2.5mVである。

 つまりオペアンプは、熱電対の1℃あたりの電圧、40.7μVを2.5mVにしてやると良い。増幅率は、2.5/0.0407 = 61.425倍である。オペアンプ1段ではちょっと不安な倍率だがやってみることにする。

 ブレッドボードで少しづつ慎重に測定する。このあいだ作ったDVMが思わぬところで役に立った。こいつは200mVフルスケールを4桁表示してくれる。つまり分解能は0.1mVもある。これは助かった。

S_pa234308 しかし、入力オフセット電圧の測定でつまづく。ボルテージフォロワーでそれぞれのオフセット電圧(LM358は3mv、LMC6482は6mV)をだしたのは良いが、方眼紙に描いたグラフで入力電圧と出力をプロットしたら、オフセット電圧がマイナスになってしまう。

 この2つのオペアンプ以外のオペアンプは、どういうわけか微小な入力が入ると、出力が電源電圧まで上がる奇妙な現象に悩まされる。アナログは本当に難しい。

レイアウトは出来た(10/28/2011)
 選んだケースはやはり小さすぎてAC電源の制御まで一緒に入れることは無理なようだ。5Vの電源を、この小さなケースに組み込むことはとても不可能だ。5Vの電源と、SSR(ソリッドステートリレー)などのAC制御部は別に作ることにする。出来たら、すでにある調光器キットのケースに入れたい。

 ヒーターの制御をどうするか迷っている。手持ちに秋月のSSRキットがあるので、これで制御するつもりだが、単なるon/off制御ではなく、折角マイコンで制御するのだから、もう少しエレガントな制御をしてみたい。あれこれウェブで情報を漁った。

 すると、ゼロクロスのSSRを50HzのPWMでドライブして電源制御をやっているウェブサイト(http://www.geocities.jp/neofine9/work/solder2/solder2.html
)を見つけた。これこれ、まさしく所長がねらっていた制御の方法だ。on/off制御では、温度のようなやたらに時定数の大きい制御は、よほどうまくやらないと制御不能になる。しかしPWMで電力を自在に変えられれば制御はずっと楽になる(はずだ)。

 これで秋月でずいぶん前(3年前)にLAN電源制御用として買ったSSRも存在意義を認められることになった(リレーではPWMできない)。 用もないのに買ったロータリーエンコーダーも、これで遂に日の目を見る。今度のプロジェクトは部品箱に眠っていたTiny861も含めて、当研究所の在庫一掃セールのような感じになってきた。

 いずれにしても温度設定と温度制御のところは、まだ先の話である。まず、温度測定を完成させよう。それでもレイアウトは、温度設定のための空き地を考慮しながら配置する。

ピンが足らないことに気づく(10/29/2011)
 プラットフォームのCPUをTiny861に決めて、アートワークに入ってから大事なことに気づく。7セグLED(7ピン)の現在温度3桁、設定温度3桁の6ヶをドライブすれば、それだけで13本。Tiny861で自由になるGPIOは、11本しかない。2本も足らない。これに、ここまで気がつかなかったとは、お馬鹿な話である。

 Mega168あたりでもぎりぎりだ。7セグLEDのドライブ以外に、ヒーター制御出力、ロータリーエンコーダ、あわせて15ピンはいる。Mega168のGPIOは17本でなんとか入るがこの程度のアプリにMegaを使うのは抵抗がある。

 というので、持ち出したのが、このあいだの電光掲示板の予備にとってあったシフトレジスター74HC595である。これだと、セグメント7ピンを、ラッチ、クロック、データの3本でドライブできる。

 LED基板のほうに置けばケーブルも減らせるのだが、スペースが意外とない。ロータリーエンコーダーが結構、かさばりなかなかうまくいかない。やっとのことでレイアウトを決定する。いやあ、ますます、在庫一掃の工作になってきた。

またまたピンが足らない(11/1/2011)
 HC595を使うことになったので、いきなり基板に組むのを止めてブレッドボードで、この前のFPGAの練習のため作ってあった6ヶの7セグLED基板を使ってソフトのテストをすることにした。

 ソフトそのものは、これまでの寄せ集めでそれほど時間をかけずに作ることが出来た。とりあえず3つの7セグLEDだけで測った温度が表示されるように組む。動かしてみる。ありゃあ、UARTから字化けしたゴミデータが延々と出力されてしまう。あ、あ、あ、いかん。ISP-UARTの受信ピンがHC595の制御データの出力になっている。デバッグ用のUARTは受信をエコーバックしているので、UARTそのものを大きく変えないとこのままではテストにならない。

 困った。単にマイコンからの出力をPCコンソールに表示させるだけだから構わないと思ったが、エコーバックを忘れていた。UARTを改修して、このまま進めることもできるが、温度制御のところまで考えると、PC側から何らかの指示で動作を選べるようにしておきたい。

 色々対策を考えているうちにふと気づいた。HC595の8ビットのシフトレジスターは、7セグなので1ビット余って、空振りしている。これが使えないか。

 この1ビットのところに、7セグのコモン側の制御を入れてやれば、1ビットを押し込められそうだ。8回まわっている7セグのエレメントの拾い出しを7つで止め、最後のシフトに、コモンのピンのon/offを入れてやる。ふむ、うまく行きそうだ。

 ソフトを改修する。よーし出来たぞ。喜び勇んでテストする。よしよし、3つの7セグLEDがデタラメながら点滅しはじめた。ここまで来たらあともう少しだ。

S_pb024319 このあと、HC595のスペックを勘違いするなど(ラッチとOEを間違える)、まともに動くまでえらい時間がかかったのだが、このあとの苦労の方がもっと大変だったので全部省略する。とにかく悪戦苦闘の末、3つの7セグLEDで現在温度(今のところ単なる補正前の3桁のADC値)を表示することに成功した。しかし、本当の泥沼はこれからだったのである。

ロータリーエンコーダーの入力が2本だったとは(11/3/2011)
 7セグの表示が何とか動き始めたので、ブレッドボードで、ついでに温度設定までのテストをすることにした。出来上がってから頭を抱えるより、ブレッドボードでバグをつぶす方が楽である。ロータリーエンコーダーを持ち出して、スペックを調べ始める。

 ここでまた重大な誤りに気づいた。ロータリーエンコーダーの入力は1本ではないのである。うっかりしていた。折角押し込めたピンがまた足らないことになったのである。

 CR内蔵クロックにすれば、もう2本空くが、CRクロックは、UARTが9600bpsを超えるだけでも不安定になるので余り使いたくなかった。しかし、もうここしか空きは残っていない。涙を飲んで、クリスタル発振からCR内蔵発振に切り替える。

 ロータリーエンコーダーの制御法を勉強する。調べたところでは、やはりChaNさんの方式が主流なようだ。2入力を2ビットとして記録し、前後4ビットのテーブルを比較して正転か逆転を判断する。

 しかし、オシロで波形を調べているうちに気がついた。どちらかのデータの立ち上がり(立下りでも同じ)で割り込みをかけ、そのときのもう一方の入力を調べれば、一発で正逆転が判断できることがわかった。割り込みなので、タイマーでサンプリングするより正確である。

 ウェブで調べたが、これを明記している記事は見つからない。しかし、チャートを確かめてもこれで出来る筈だ。間違いない。意気揚々とコーディングに入る。

 さあ、どうだ。ふーむ、回転は認識するが、正逆転しない。どちらをまわしても正転するか逆転するか一方向だけである。おかしい、オシロのデータはちゃんと正転と逆転では値が違うのに、入力ピンが1を認めない。常に0としか読まない。

 最初、元のXtalのピン(PB5)で入力を調べているのでこれが何かまずいのかと思い、別の空きピンに入力を移してみる(7セグLEDはまだ全部実装していない)が、同じ。???である。何故か、入力ピンが動かなくなってしまった。INT0(PB6)などの割り込みピンは何の問題もなく動いているのにおかしい。

Tiny861のバグ(だろう)に振り回されてふらふら(11/5/2011)
 とんでもないことになっている。Tiny861で入力ピンが0のまま読み取れない。PINポートをデータに取り込んで、表示させても0のままだ。考え付く限りの入力ピンの状態を調べるコードを入れてテストするが、がんとして入力は1にならない。

 しかも1ピンだけではない。残っている全部のピン入力が言うことを聞かない。受信割り込みや、外部割込みのINT0(PB6)は動いているというのに何故だろう。何かとても基本的なことを間違えているのかもしれない。不安がよぎる。

 頭の中が混乱してきた。いつものAVRのピン入力が突然動かなくなったのだ。PINとPORTでは今まで散々悩まされてきた。昔買った、AVRのリファレンス本まで取り出して、基本から読み直す。手がかりは得られない。おかしなことをしているわけではない。全く見当がつかない。完全に暗礁に乗り上げた。

 こうなると、どうもハードを疑うしか考えられなくなった。ピンそのものが生きているか、ピンの割り込みだけでも生きているのか調べてみることにした。というよりこれくらいしか調べるところがなくなった。

 Tiny861のピンチェンジ割り込みは、すべて共通の割り込みエントリーである。今のプログラムは、UARTの受信割り込みに使っている。ここへテストピン(PA4)の割り込みが来ても識別できるようなコードを加え、UARTに影響がないようにする。

 ピンチェンジのテストをする。うーむ、テスト用のLEDがついて動いたようだが、本当にPA4の割り込みがどうかは確認できない。何気なくロータリーエンコーダーを動かすと、何と何と、UARTに表示しているピンの状態に変化がでた! 該当するビットに1が出た! 7セグLEDの数字はエンコーダーの動きに応じて、増えたり減ったりしている。直ったのだ!

 何ということだ。ピンチェンジ割り込みをenableにしないと、入力ピンが動かないとは。こんな話は今まで聞いたことがない。少しづつコードを減らして行って、「入力ピンにするには、グローバル割り込みマスクレジスターGIMSKでそのピンに対するピンチェンジ有効のビットを立てる必要がある」ということがわかった(出力は問題ない)。

 いやあ、これはバグだろう。ウェブで探してみるが、それらしい記事は見つからなかった。本家のデータシートにもERRATAの記述はない。昨日の夜からほぼ半日これにふりまわされた。

 わかってしまえば、回避は簡単である。Tiny861は、ピンチェンジ割り込みは2段階で設定する。まず、GIMSKレジスターで範囲(PCINT8~11までは、ビットPCIE0に、PCINT0~7とPCINT12~15までは、PCIE1という変則な設定)で割り込みを可能にする。

 次に、個別のピンの割り込みは、さらにそれぞれのピンに応じてPCMSK0レジスターかPCMSK1レジスターにピン単位に設定する。ややこしいやり方である。2段階なので、ERRATAを回避するには、こちらの方を未設定にしておけば良い。これで割り込みは起きない。入力ピンは正常に動く。

 いずれにしても、これで6ヶの7セグLEDを想定どおり動かせる見通しが立った。このあと、ADコンバーターの設定でPA3がおかしかったり(AREFを使う設定が、レジスター2つにまたがっている!)、ステートメントのコピーミスで同じ数字を2箇所に出したりするようなトラブルはあったが、とにかく無事にブレッドボード上で、6個の7セグLEDが点って、それぞれ動くところまで来た。

S_pb044321 やれやれ、これで一安心である。このあたりでブログに報告することにしよう。いやあ、今度もドラマの連続だったなあ。

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

2011年10月20日 (木)

やっと出来た。ガイガーカウンター2号機の回路図・ソース公開

 ソフトパワースイッチを使ったCHANEYキットのガイガーカウンター2号機がやっとのことで完成した。思った通りソフトパワースイッチの電源制御が手間取り、GM管(SBM-20)の不安もあって、着手からここまでほぼ2ヶ月近くかかってしまった。

 GM管の問題が完全に解決したわけではないが、とりあえずは安定して測定が出来るようになった。ひと区切りがついたので、ソースコードと回路図を公開することにする。

S_pa094282

ツェナーダイオードは効果があった(10/11/2011)
 大苦労の末CHANEYのガイガーカウンター2号機は、何とか共通のひとつの電源で動き始めた。少し余裕が出来たので、ガイガーカウンターの高圧部をもう少し改善することにした。

 CHANEYの高圧回路は、GM管の寿命を考慮して改造してあるが(バイアス抵抗100K->10M、平滑コンデンサー470pF追加)、電圧をデジタル電圧計(秋月DVMキット)で測ると500Vもある。ガイガー管SBM-20の推奨電圧(400V)をはるかに超えている。このまま使っていくのは不安である。

 時間とともにパルスカウント(CPM)が上がってしまう問題は、オリジナルの回路の390V近辺でも起きることが確認されているので、電圧を下げたからと言って、この問題を解決できるか余り期待は持てないのだが、ものは試しである。やってみなければわからない。

 これには、180Vのツェナーダイオードを2つ使って電圧を下げる。この電圧のツェナーダイオードは鈴商で入手した。鈴商は高圧関係のコンデンサーや、インダクターの種類が多く、このところ頻繁に訪れている。最近は通販もしているようだ。

S_pa204305 例によって、小さな基板をキットの基板の上にリード線を使って固定し、ここにダイオードと負荷抵抗(100KΩ)、ついでに直付けしていた平滑コンデンサーを載せる。なかなかうまくいった。こういう小さな基板の加工は、サーキュラソーでなく糸鋸(コッピングソー)だと、もっと楽に綺麗にできるのだがなあと思いながら、ミニルーターで凹部を少しづつ削って整形する(いずれ買うぞ)。

 テストする。電圧は正確にぴったり360Vを指した。おお、この電圧計(秋月DVM)もたいしたものだ。検知パルスも問題なく出ている(350~420Vがプラトー電圧)。2時間測ってみた。ふーむ、全く安定している。これは良いぞ。このままで新たな対策(外部クェンチ回路など)は考えなくても良いか。

S_pa204299 しかし、日を替えてテストしてみると同じ管でも、一定にはならず1時間程度で倍に上がってしまう。ケースの中に入れるのと外では大分様子が違うようだ。ガンマー線あたりは問題ないが、SBM-20はベータ線も感知する。それが影響しているのかもしれない。いずれにしても360Vにしたことで、全て大丈夫になったわけではなさそうだ。

電源は共通になったけれど問題山積(10/12/2011)
 ガイガー管はさておき、本体の実装の方である。仮配線を正式に直し、ケースに入れる前に念のため動作テストをしてみた。ややや、(1)UARTをつながないと動かなくなる。しかも、(2)待機時の電流があろうことか、mA以上だ。4.3mAもある。これでは使い物にならない。共通電源にするときに何かいじったのか。ペリフェラルの電源線をはずしてみたが変わらない。これはおかしい。CPUがパワーダウンモードにならなくなったのか。

 (1)UARTの方はもっと不審だ。今までAVRでデバッグ用のUARTを残して本番時に動かなくなったことは一度もない。それなのにUARTを端末につながないとLCDにオープニングメッセージが出なくなる。そして暫くすると動き出すが、LCDの表示が極端に遅くなる。この遅くなると言うこと自体が良く理解できない。困った。こいつはデバッグができない。別の出力ルーチンが要る。

 ところが、この不具合はI/Oポートをいじっているうちに、いつのまにか解決してしまった。面白くない。いつのまにか直るというのは、またいつのまにか起きるということだ。後味の悪い解決である。しかし、こればっかりに関わっているわけにも行かない。先に進もう。

 (2)の待機時の消費電流が増えてしまう不具合には参った。4.3mAでは使い物にならない。ブレッドボードから、こちらに移動しただけで何もいじっていない。ハードかと思って、ペリフェラルの電源線をはずすが同じだった。プルアップ抵抗もすべてはずすが、何の影響もない。ポートの初期設定で、6mAになったり、8mAになったりするので、やっぱりハードでなくソフトを疑う。

 I/Oポートのピンひとつひとつの初期設定をしらみつぶしに変えてファームを作り直しテストする。しかし改善の兆しはない。パワーダウンモードになっていないのかと、アイドルモードにして止めてみると、スペック通りに待機電流が増加する。スリープモードの手違いでもなさそうだ。

 だいたい、前に測って10μAだったときと大きく変わったところはない。替えたところはすべて元に戻してテストしてみた。それでもおかしなところは見つからない。犯人追跡の手がかりがどうにも見つからない。

やっと犯人を捕まえた(10/15/201)
 ここ数日、悩んでいた問題がやっと解決した。パワーダウンモードの待機電流が想定の数十倍になる不具合である。わかってしまえば、これも何ということはない、ごく当たり前のことだったが、つきとめるまでにえらい時間がかかってしまった。

 至るところの接続を半田ごてではずしまくり、I/Oポートの設定を換え、sleepモードをいじる。考えられる限りの対策をしてみたが、どうしても下がらない。ポートの初期化の状態で、すぐ数ミリAが流れているので、I/Oポートの設定が原因だと思うが究明できない。

 そのうち、UARTをはずすと、電源ディップが復活していきなりリセットに戻ったり、わけのわからない状態になった。頭を少し冷やして状況を整理してみることにした。まずすべてを疑って基本的なところから調べる。

 そう言えば、まだ確認していないユニットが残っていた。過放電を防止するリセット回路である。リセットICがおかしくなった? そんな馬鹿な。これが壊れる可能性は極めて薄い。これが壊れるのは最大定格6V以上をかけたときだけである。

 そんなわけはないとは思うが、もう調べるところはここしか残っていない。半田ごてを持ち出してリセットICを電源から切り離す。おおおー、こいつだった。これまでどうしても下がらなかった電流が、パワーダウンモードの10μA以下に下がった。やれやれ。 

 テスターをマイクロアンペアのレンジにして測ると、0.6μAだ。このデバッグの最中に、WDT(ウォッチドッグタイマー)を止めるステートメント、 wdt_disable(); (ライブラリ<avr/wdt.h>をinclude)を入れてあったので、以前の10μAよりさらに1/10以上下がった。スペック通りだ。いやあ、嬉しい。リセットICが原因だった。思わずガッツポーズが出る。

 喜び勇んでリセットICを取り替える。ありゃあ、電流が変わらない。相変わらず4mAが流れる。何い、リセットIC不良ではないのか。とするとリセットICがドライブしているFETが悪いのか。だいたい、何故こいつらが不良になるのか思い当たる節がない。ただリセットICを通じて電流が流れていることは確かだ。

 FETを取り替えた。これでリセットICはスペックどおり20μAの消費電流で正常になった。そうか、段々わかってきたぞ。このFET(2N7002K)の最大電流は200mAで、こんどのガイガーカウンターは電圧が下がってくるとDC-DCコンバーターなので70mA以上消費する。

 最大瞬間電流は、2Aだけど、もしかすると突入電流がこれを越えて壊したのかもしれない。他に考えられるのは、リセットの原因を調べるため、FETの入力と出力を(ドレインとソース)をショートさせてテストしたことがある。信じられないけれど、これで壊れることもあるのかもしれない。

 リセットICはリセットをした状態のまま動いていて、FETのゲートを通じて電流が流れていたのだろう。とにかく、ここのFETはもう少し大きな電流に耐えるものに換えたほうが良いかもしれない。

 その後、LCDの制御線(Enable)の一本のハンダ付けがとれているところを見つけた。LCDが表示されなかったり、異常に遅かった理由はこいつが犯人だった。これらを修復して、ガイガーカウンター2号機は、やっと安定して動くようになった。ソフトパワースイッチも好調である。

管を替えて長期測定。ケースに入れると増えない?深まる謎(10/17/2011)
 高圧部の方である。ツェナーを使って電圧が安定したので、手持ちのGM管を少し長時間動かして状況を見ることにした。3つのGM管すべてを2時間づつ動かして、驚くべき事実が明らかになった。

2 結果から先に言えば、3本とも、全く問題なく一定の環境放射線量を記録した。ガス漏れかと疑った最初の管も問題ない。ただし3本ともすべてケースの中に入れての測定である。

 SBM-20はガンマー線だけでなく、ベータ線を感知できるということで、ベータ線は、プラスティックのケースで覆うと殆ど遮られる。ということは、時間を経過するとCPMが2倍から3倍になるというのは、ベータ線を感知したからだということである。

 ベータ線は、物の本によれば、飛んでも精々が数m。この地下室にベータ線を出す線源があるということになる。あるとするなら、あのランタンのマントルしかない。まさか。それにどうしてCPMが増えていくのだ?理解できない。LND712だってベータ線を感知する。

 SBM-20をむき出し(ケースの外にだす)にして測ると、前と同じように1時間経つと確実にCPMは2倍になる。これをすぐにケース内に入れて再度測ると図のように、落ち着く。ケースの遮蔽が何らかの影響を与えていることは間違いない。

Photo この一般の住宅の部屋の中にベータ線をだす物質が浮遊しているということなのか?謎は深まるばかりである。一般の環境放射線量の調査では、ベータ線は除くようにという指示が多いのは、こういうことがあるからか。いずれにしても、元のSBM-20が壊れていないことだけは確認できた。

Photo_2

例のマントルを近づけると、ケースの中に入れたSBM-20でも、せわしない音とともにLEDは絶え間なく点灯し、500CPMやそこらは簡単に到達する。シーベルト換算だと、このあいだ大騒ぎのあった世田谷の3μSv/hくらいである。何の規制もされていないこのマントルが余裕で出す線量に世間は大騒ぎしているが。

 このマントルも1メートルも遠ざければ全く反応しなくなる。ここからベータ線が出ていた?まさか。念のため、別の部屋にマントルを遠ざけて測定してみる。当然、前と変わらずむき出しにするとCPMは増えていく。まあ、この問題は外部クェンチ回路を実験するまでお預けである。

リセットICの消費電流もケチって遂に待機時0.6μAを実現(10/19/2011)
 公開に向けて回路図を描き始めた。実はまだ気がかりなことがある。リセットICの消費電流が20μA近くと馬鹿にならない。何しろMega328の待機電流は1μA以下なのだ。折角省電力化したのに、その20倍の電流が常時流れるのは気分が良くない。ただ、電池の電圧を常に監視している必要があるのでFETのスイッチの後などに置く事はできない。

 しかし、電源回路を描いていて思いついた。常に電圧を監視していなくても良い。FETのハイサイドスイッチのあとでも構わない。ペリフェラルに供給される電源電圧を、CPUがチェックしてやれば良いのだ。

 いや待てよ、リセットICもいらない。CPUのADCか何かで監視して、一定の電圧以下になれば、ペリフェラルを切って、パワーダウンモードに入れば良い。そうか、こちらの方が簡単だったか。なんだ、最初の案が一番合理的だったのだ。

 そうは言っても、ここまできたのだから、せめてこの回路でも待機電流をμA以下にしてやろう。ケースの中の主基板を取り出し、電源系をあらためて検討する。リセットICの回路をFETスイッチの出力側へ移す。電源系統の誤配線は怖いので慎重に結線を接続しなおす。通電。良かった。一発で動いた。消費電流は?すごい。やった。0.6μAだ。

 電源を入れようとボタンに手がかかって、あわてて手を止めた。このところテスター(マルチメーター)のヒューズを誤接続で立て続けに飛ばしている。μAオーダーの計測レンジで不用意に、スタートボタンを押すと数百mAレベルの突入電流で簡単にヒューズが飛ぶ、それもあるが大抵は電圧計のつもりでプローブを当ててしまいショートさせたことの方が多い。

 しかし、ちょっと怖いことがある。長いテスターリードで電流を測ると、何故か電源のディップが復活してリセットしたり、突入電流が1A近く流れたりすることがあるのだ。心配である。スイッチの切り替えのタイミングで大電流がCPUのポートなどに流れると、石を壊してしまう。

 寝床についてからもあれこれ考えていた。結局、すべてはDC-DCコンバーターの突入電流と結論付けることにした(悪い方向は考えたくない)。それより、今のリセットICをトリガーとしてペリフェラルの電源をFETで切っているが、これも必要ないことに気づいた。

 リセットICのトリガーをCPUのI/Oピンに入れて、これを監視すればよいのだ。FETでローサイドで電源を切っているが、そもそもペリフェラルの電源はハイサイドで切っているのでわざわざここでも切る必要がない。

 しかもLCDに電圧不足のメッセージを出すことも出来る。今までの方法だと、何の挨拶もなく落ちるので、故障なのか、電池不足なのか判断ができないので困っていたのだ。これは一石二鳥だ。

 良い方法を思いついたときは、寝つきも良い。この日はぐっすり眠ることが出来た。

Chaney_geiger_ctr

ソフトパワースイッチのガイガーカウンター2号機のソースと回路図を公開(10/20/2011)
 翌日、機嫌よく地下の工作室に戻る。電源制御の小基板に折角苦労してつけたFETだが、思い切ってはずし、ドレインとソースのところをショートする。ゲートに入っていたリセットICの出力をMega328の入力ピンに入れる。大した作業量ではない。

 次はソフトである。ピンを初期化し、メインループの最後で、常にこのピンを監視し、論理0になったところで、LCDに警告メッセージを出し、一定時間後、パワーダウンモードに移行する。コードとして10ステートメントもない。あっという間にソフトも出来た。

 テストである。電源を単3二つの電池フォルダーから供給する。3.0Vである。リセットICは3.3V以下で動くはずだ。よーし、最初立ち上がるがすぐ「デンチデンアツ フソク」のメッセージを出してシャットダウンされた。良いぞ。元のリチウムバッテリーで正常に動くことを確かめて、テスト終了である。

 ふー。やれやれ。時間がかかったが、これでソフトパワースイッチと、過放電防止の回路はすべて順調に動いたようだ。ケースにUARTのケーブルを差す口を空けて、ケースを開けなくても、貯めたデータを吸いだせるようにする。これでさらに実用に近づいた。

 きのう事務所の往復に持ち歩いたが、3時間以上全く問題なく測定できた。地下鉄と地上の線量の違いも明確に区別が出来る。ガンマー線だけ測っている分には全く安定しているようだ。

S_pa204306

 このプロジェクトも、このあたりで少し区切りをつけよう。 電源制御は予想にたがわず難物だったけれど、ソフトパワースイッチにはだいぶ自信がついた。経験値も上がったように思う。

 ソースコードと回路図を公開することにする。ガイガー管がベータ線でCPMが増加する問題は先の課題にしよう。

以下に、AVRStudioのフォルダーでかためたソースコード一式を置きます。タクトスイッチの仕様がSparkFunのと異なっているので注意してください。回路図のBSch3Vファイルもフォルダーの中に入っています。

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

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

2011年10月10日 (月)

ソフトパワースイッチ難航: ガイガーカウンター2号機完成へ

 暗雲がたれこめている。CHANEYのキットを使ったガイガーカウンター2号機がもう少しで完成というとき、ガイガー管(以降GM管)、SBM-20不良の可能性が出てきた。

 通電時間が長くなると(30分以上)、検出パルスがどんどん増えてきて、数時間で当初の3倍から4倍になってしまう。このところの東京の環境放射線量は全く安定しており、この変化は機械以外考えられない。

S_pa104288 初めは改造による電圧の高すぎ(約500V)によるものと思っていたが、オリジナルのキットの状態(390V近辺)に戻しても同じ状況であることを確認した。電圧は時間が経っても変っていない。

 あらためてウェブでGM管の情報を詳しく調べる。それによるとGM管には内部クェンチといって、一旦放電が起きたあとの連続放電を避けるためガスが封入されていると書いてある。もしこのガスが抜けると、クェンチがうまく行かなくなって、パルスの数が増えてしまうという。

 そういえば、工作の途中、ケースに入れようとして管壁を少しへこませてしまった。これでガスが抜けたのかも知れない。しかし、本当にガスが抜けたのなら、最初からパルスが派手にでるはずで、時間とともに増えていくというのは良くわからない。

 ウェブをさらに探し回るが、こういう現象を報告しているサイトは見つからない。放射能を持つマントルを近づければ派手にカウントが上がるし、放射線を検知していることには変りはないので、検知器としては使えるが、測定器としては、電源をいれたままにすると線量が2倍とか3倍になるというのでは、数値を出す測定器としては意味をなさない。

 CHANEYのキットは、小中学生向けの教材ということだが、使っている管は旧ソ連製とは言え、市販の線量計にたくさん使われている定評のあるGM管である。こんなことが起きるとは考えられない。やはり、自分のSBM-20がおかしくなったというのが順当なところだろう。

 これはやはり、管を替えて調べてみるしかないか。ひところに較べると、GM管も入手し易くなった。さすがにまだ一般のショップでは売っていないが、オークションなどで見ると結構、品物がでまわり、値段も落ち着いてきている。このSBM-20あたりは、3千円近辺で買えるが、いまさらガイガー管でもないような気もするし、すぐには決断がつかない。

 既に1台、ガイガーカウンターはある。もうあまり放射能計測にこだわることはない。しかし、このキットのために、ちょうど合うケースをみつくろい、LEDの窓も開け、工作を進めて、あと一歩で完成するところまで来ている。このまま、引き下がるわけにも行かない。

SBM-20を新しく2本入手。しかしGM管の不良ではなかった(9/30/2011)

S_pa104287

 迷った挙句、SBM-20を初めてのヤフオクで2本入手した。恐る恐るの取引だったが、順調に品物が届いて胸をなでおろす。テストの結果、意外な事実が判明した。入手したGM管は2本とも、最初の管と同じように、程度の差こそあれ、すべて時間が経つにつれてパルスが増加していくことがわかった。最初の管はガス漏れしていなかった。このSBM-20という管そのものが、こういう性質を持っているのだ。

 もちろん、最初のガス漏れの疑いのある管は、1時間程度の連続測定でカウント数は2倍になるのに対して、新しく手に入れた管は、2時間近く連続しないと増えていかないという差はあるが、一定時間後、増加し始めることに変りはない。最終的には3倍から4倍になり、そのあたりで落ち着く。

Sbm20_sample このSBM-20を使った市販の線量計は沢山売られている。これらは大丈夫なのだろうか。それとも、この性質を補正する回路にでもなっているのだろうか。いずれにしても、今の回路のままでは、長時間測るのは無理がある。精々が1時間単位に測らないと正確な数値を求めることはできない。こういうものなのか。それとも買ったのが2本とも不良品なのか(まさか)。さあどうする、である。

とにかく機器としては完成させよう(10/2/2011)
 GM管の不安は残るが、工作としては中途半端なまま終えるのは面白くない。電子機器の定番、ソフトパワースイッチやペリフェラルの電源制御など新しく試みたものもある。とりあえずケースの中に入れて動くところまで工作を続けることにする。

 何かとても無駄なことをやっているような気もするが、まあ我慢して、黙々とLCDまわりの配線を続ける。テストしてみるとLCDの配線は一発で通ったが、あろうことか、表示が逆にでた。LCDを天地逆さまに取り付けてしまった。基板に貼られたシールで画面の天地を判断していたのだが、シールが逆に貼られていたとは気がつかなかった。やれやれ。

 LCDの表示の天地の修正は結構面倒である。接着したところをナイフではがす。強力な接着剤である。なかなかはがれない。ケーブルの出るところが逆になったので、押さえのアクリル板をミニルーターで一部削り落とす。ケーブルのとりまわしが変になるが仕方がない。何とか接続を終えた。よーし、SparkFunと同じ画面が出てきた。CPMからシーベルトなどの換算は、まだそのままだがLCDは問題なく動いた。 

 ファームは、まだソフトパワースイッチを実装していない。以前テストしたときのコードを参考にコードを追加していく。電源スイッチは画面制御用のタクトスイッチと兼用である。この処理が意外に面倒だ。長押しの時間を測るタイマーは、Mega328がタイマーを3つも持っているので、空いていたタイマーをこれにあてることが出来、コーディングの手間が省けた。

 動かしてみる。全く動かない。まあ、こんなものだ。printfステートメントを至るところに入れて動きを追う。少しづつ動き出すが、ボタンの長押しで、システムが立ち上がった直後、リセットがかかって前に戻ってしまう状況から抜け出せない。

 最初は、無印Mega328の割込みルーチンのエントリー先が違うのではとか、コンパイラーのライブラリが変わってしまった(AVRSPの再ビルドのときライブラリーチェーンが一時おかしくなった)ためではとか、ソフトを疑っていたが、原因はやはり、ハードだった。

ソフトパワースイッチは一筋縄では行かない(10/3/2011)
 ペリフェラルの電源をFETで入れるとき、突入電流でVccがディップし、CPUがリセットしてしまうのが原因だった。始め、オシロで調べてもVccのディップは見つからなかったし、インダクターや大容量コンデンサーなどを入れても全く改善されなかったため、ハードではなくソフトだとばかり思いこんでいた。

 ソフトで考えられることを全てやっても解決しないので、もう一度ハードに戻り、電源そのものを独立させたら、すんなり動いた。これに気づくのに、丸々1日かかった。ブレッドーボードを使っているといっても、DC-DCコンバーターは既に基板にハンダ付けしてしまってある。ハードをいじるのは面倒なのでつい不精していた。

 とにかく、ガイガーカウンター2号機のソフトパワースイッチは、ブレッドボード上でペリフェラル電源をCPUと別にしてはいるが、とりあえず動くようになった。スイッチの長押しで電源を入り切り出来、これを繰り返しても止まらない。いやあ、ソフトパワースイッチは予想通り面倒だ。まだ電源の共有が解決されていない。最悪の時は、電池を2つ用意しなければならない。

 それに、GM管の表示が増えてくる件については未解決のままである。この問題は、外部クェンチ回路の雛形を入手したので、ソフトパワースイッチの完成後、テストしてみようと思う。連続パルスをある程度除去すれば使えそうな気もする。

バグがとれていく過程が楽しい(10/4/2011)
 ソフトパワースイッチが動き始めたので、少しづつ先にステップを進める。まず最初の懸案は、パワーダウンモードが本当にそれにふさわしい消費電流になっているかの検証である。これをやっておかないと何のために苦労したのかわからなくなる。以前、Xbeeでも本当のパワーセーブに苦労した。

 電流計で測定する。あれえ、電源を切っても電流が1.3mAも流れている。少ないとはいえ常時この電流が流れていたら電池はあっというまになくなってしまう。パワーセーブどころではない。何だ何だどうしてだ。プルアップ抵抗からはピンがHighなら電流は流れないはずだが。

 おや、プログラムが動く一番最初は10μA以下だ。ところが一旦動かした後は、同じパワーダウンモードになっても、1.3mA以上になる。不思議である。どこかのI/Oポートの設定で電流が流れてしまうようである。

 ここにばかり時間をとっておられないので、プログラム開始直後の初期化を、電源ONループの中に入れてもういちど初期化をすることにした。これでこの問題は解決した。副作用は、UARTが少しおかしくなるが大勢に影響はない。とにかく待機中の消費電流は9.7μAになった。

 データシートに出ている6μA(5V WDT許可)に較べると、やや多いが、まあこんなものだろう。フューズビットで、WDT(ウォッチドッグタイマー)を禁止にすれば、もう一桁下がるはずである。

 次は、電源用のタクトスイッチのI/Oピンが、作動状態になると機能しなくなるバグである。おかしい。同じことをやっているのにI/Oピンが立たない。何故なのか。しかし、これも面倒なので、対症療法だが、スイッチフラグの変数を増やして、I/Oピンを見ないですむようにする。

 これはのちほど、原因が判明した。プログラムは考えたようには動かない。書いたように動くという格言を地で良く失敗である。メインループの最後に、電源OFFのためのルーチンがあり、ここでしっかり、パワーダウンボタンの押下が終わるのを待っていた。

 作動中は必ず電源OFFのリクエストをチェックするために、ここを経由する。従って、このボタンをいくら押しても、実際のチェックでは、このボタンが離れてから到着する。考えてみたら当たり前のことだが、頭に血が昇っているときは、目の前のルーチンに気を取られて「おかしい、おかしい」ということになる。情けない。 

 少しづつ問題点が解決されていく。ささやかなトラブルだが、どんな小さな問題でも解決されていくというのは気分が良いものである。今までの暗い気持ちが晴れる。

レギュレーターで解決したと思ったのも束の間(10/6/2011)
 バグがなくなったとはいえ、まだ電源は独立電源である。このままでは2つ電池が要ることになる。電源を共有するための方策をブレッドボード上で、あれこれ考える。インダクターと大容量コンデンサーの電源のデカップリングは前に試して効果がなかった。次は定電圧レギュレーターである。以前LPCMプレーヤーのときに大量に買い込んだロードロップのXC6202の出番である。

 CPUのVccは現在、生のリチウムバッテリーに直結してある。レギュレーターを通せばペリフェラル電源投入時のディップをなくすことが出来るだろう。やってみた。うーむ、これでも駄目だ。おかしいな。もしかするとリセットするのは別の原因なのか。

 ペリフェラル側にレギュレーターを入れるのはどうだろう。4Vのリチウム電圧を一旦3.3Vに落とし、それをDC-DCコンバーターの入力にするのは、とても無駄な気もするが、この際だめもとである。

 ややや、動いた。何ということだ。DC-DCコンバーターの突入電流をレギュレーターが緩和したのか。CPUは共通電源で何事もなく立ち上がり、ガイガーカウンターの高圧部にも電源が入った。わけがわからないが、理屈はどうでも動けば良い。ブレッドボード上の回路を意気揚々と、基板に組み込む。これで解決だと機嫌よく実装テストをする。と、これが何故か、またリセットして先に進まない。えっえー、どうして?ブレッドボードでは動いていたのに何故?信じられない。

 泥沼が続く。回路をハンダごてで次々にはずしてテストを続ける。どうもノイズを拾っているのか回路が近接していると、電源を独立させていても入り切りのタイミングでリセットする時がある。SBM-20の外部クェンチ回路どころではない。人生が暗い。

オシロでVccのディップ波形を遂にとらえた!(10/9/2011)
 ソフトパワースイッチの電源制御のところで迷走が続いている。あろうことか、電源を独立させても、CPUがリセットしてしまうようになった。こうなったらリセットの原因を徹底的に究明しないと解決しない。(今度の回路はリチウム電池の過放電防止回路がついているが、これをバイパスさせても起きるので、これが原因ではない)。

S_pa094276

 幸い当研究所にはオシロがある。回路を元に戻し、慎重に基本的なところからCPUのVccディップを探すことにした。その結果、遂にディップを捉えることに成功した! そう、入力をACモードで受けて、倍率を上げ小電圧の差分でトリガーできるようにする方法だ。経験者には極く当たり前のことだろうが、こちらはオシロの素人である。

 ただ、捕捉できなかった原因は、1div 10ms以上の長いスキャン時間でパルスを捉えようとしていたためではないかと思う。デジタルオシロなので、短いパルスは長いスキャンでは分解能がたらなくてトリガーできなかったのではないか。

S_pa094277

 波形を捉えた時は嬉しかった。電源投入時のディップは鋭い下向けのパルスで差は1.5V以上、幅は60μs以上ある。4VがVccなのでVccは2.5Vまで下がり、幅もCPUをリセットさせるに十分な長さだ。電源を独立させてもリセットされたのは、この鋭いパルスで誘導電流でも流れたのか、いずれにしてもDC-DCコンバーターの立ち上がりは猛烈な突入電流が流れるようだ。

S_pa094278

 ディップを観測できてから、解決は早かった。画面の写真を載せたが、最初は、電源投入時の元のパルスで、次は電源に大容量(100μF)のコンデンサーとインダクター(22μH)のデカップリングを入れたときのもの、3枚目が、4.7μFである。これが一番浅い。実機にはこれを採用した。面白いことにコンデンサーが大きいと、ディップはなまるがかえって深くなりまずいということがわかった。これが最初、この対策をして効果がなかった理由であろう。

 この定数のCLを電源回路に入れて、めでたくソフトパワースイッチは、共通電源で実現した。いやあ、およそ一週間これにかかりきりだった。可哀そうなのは、このあいだのレギュレーターXC6202である。今度も基板に載ったけれど採用されずに低温ハンダではずされ、ジャンク箱に逆戻りした。余程運のないやつである。許せ。

S_pa094280

 残るは、いよいよGM管の外部クェンチ回路である。これでうまくいけば万々歳なのだが。

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

2011年9月27日 (火)

2台目のガイガーカウンター(CHANEY)が完成しない

 ブログの更新が滞っている。前回から2週間以上になる。何もしてなかったわけではない。いくつか前進はあったが、やはりCHANEYのガイガーカウンターキットのアナログ部に問題が出て、2台目がなかなか完成しない。日がたつと忘れてしまいそうなので、これまでの経過報告をしておく。

S_p9274271CHANEYガイガーカウンターはソフトパワースイッチにする(9/13/2011)
 今度のCHANEYのキットを使ったガイガーカウンター2号機の電源回路は、ソフトパワースイッチを使うことにしている。マイコンCPUのパワーダウンモードを使って、スイッチの長押しで電源を入り切りする今時(いまどき)の携帯機器に多いやりかたである。

 最近のマイコンは省電力化が進んでいて、パワーダウンモードに入ると、消費電流は、一般の二次電池の自己放電よりはるかに少ないところまで下がる。AVRシリーズの最近の型名で最後にPがついているのは、省電力をうたったピコパワーをあらわす文字で、スペックによればMega328Pで0.15μA(5V)と、まさしくピコアンペアクラスの消費電流だ。今度の石は皮肉にも無印のMega328だが、それでもパワーダウンモードは0.6μAである。

 しかしいくらCPUを微小な消費電流で止めたにしても、周辺機器の電源もこのとき同時にFETか何かで切らないと意味がない。CPUより消費電流の多い周辺機器はいくらでもある。ところが、この周辺機器の電源制御が意外と曲者なのである。

 当研究所ではソフトパワースイッチはこれまで何回か試みて、結局、本番では使うのを止めている。これは、この周辺機器の電源制御が面倒なためで、これまでの機器はすべてレガシーなスライドスイッチを使って物理的に電池の電源を切った。所長が古い人間で、どんなにわずかでも機械に電気が流れ続けるというのが生理的に落ち着かないというのもあるが、周辺機器の正しい電源の切り方が実はまだよくわかっていないのが大きな理由だ。

 周辺機器が独立していれば問題ないが、大抵はCPUと制御線でつながっている。これが悪さをする要因となる。待機状態になっているCPUから、電源を切ったはずの機器に電流が流れ込み、機械がこわれたり誤動作することがある。これとは逆に以前、SDカードスロットの電源をローサイドで切ったところ、SDカード制御線から大量に電流がCPUのGPIOピンに流れ込み、Mega168を2つも失うという悲劇を起こしている。

 ハイサイドで切ると大丈夫かと言うと、今度はCPUからSDカードへ電流が制御線を通して流れ込み、壊れはしなかったが周辺機器が幽霊動作しておかしなことになったことがある。パワーダウンモードの時のCPUのI/Oピンの状況がどうなるかは厳密に調べておかないと機械は予期せぬ動きをする。油断がならない(厳密にはフォトカプラー接続するのだそうだ)。

 これが、どうしてその気になったかと言うと、レガシーなスライドスイッチを楽だからと使い続けていたのでは、いつまでたっても進歩がない。これでは経験値を上げることが出来ないなあ、と思っていたところに、リチウムバッテリーの過放電防止回路や、この前のUSBとバッテリーの電源切り替え回路を実際に作る機会に恵まれた。これでFETの扱いに大分慣れてきて自信がついてきた。

 このときコメントを寄せてくれたeNastyさんからダイオードの代わりにチップFETを使うテクニックを教えてもらったことも後押ししたように思う。このとき、秋月でn-MOS、p-MOS含めて大量のチップFETを買い揃えた(といっても¥100内外だが)。何しろ、豆粒のようなチップで3Aの電流が流せるのである。確かにON抵抗がミリオームレベルなので通過させるだけならOKだ。トランジスターとは大違いである。

S_p9204268 今度の電源制御は、CHANEYのガイガーカウンター部と、LCDの2つの電源を切る。それに前記事で紹介したリチウム電池の過放電防止回路も組み込まねばならない。主基板は、片面基板にしてしまったので、チップ部品を載せにくい。小基板に部品を載せて、これを取り付けることにする。過放電防止回路はブレッドボードでOKになっているので、小基板に作り直す。これは順調に出来た。

DC-DCコンバーターのENABLE端子は使えない(9/15/2011)
 周辺機器の電源制御はFETでやると張り切って始めたが、考えてみれば周辺機器はすべてDC-DCコンバーター経由であることに気づいた(LCDの5Vも既成のDC-DCコンバーターを使う)。それなら何も自前のスイッチをつけなくても、DC-DCコンバーターに必ずついているシャットダウン端子(ENABLEピンともいう)で出来るではないか。勢い込んではみたものの、これで制御できれば何もわざわざ作ることもない。早速ブレッドボードでテストしてみた。

 既製品のコンバーターはあとにして、まずは自作のLM2735を使ったDC-DCコンバーターを手始めに試してみる。CHANEYのキットを動作させながら、ENABLEピンをグランドに落とす。これでシャットダウンされるはずである。60mAほど流れている。

P9274275

 ありゃあ、電圧計は0にならない。しかも、コンバーターからは「チーッ」という音が出る。インダクターからの音だろう。ガイガーカウンターも何か動きそうな雰囲気だ。LEDを点けるくらいなら、音も出ず、ピタッと0Vになるが、数十mAを消費するガイガーカウンターでは駄目である。

 いかん、おかしい。誤配線か。自作のコンバーターだったので、自分を疑って色々調べた。いや、リファレンス回路と違いはない。どこも悪くない。仕方がない。フォトフレームにつけてあったストロベリーリナックスの同一の石を使った既製品をはずして動かしてみた。何と何と、全く同じように音が出て機能しないではないか。なんだなんだ。どうしてだ。

 ストロベリーリナックスの説明書を読んで問題は氷解した。ちゃんと説明書に「ENABLEピンをグランドに落とすと、チップの動作が止まるだけで電圧は余り下がりません」とある。変な仕様である。要するにチップの動作(発振)を止めるだけの端子なのである。この回路(メーカー推奨)では、電流が負荷に流れ込むからだそうだ。何のためのENABLE端子なのだろう。

簡単な回路が動かない。チップが燃える(9/19/2011)
 友人に誘われて東北の温泉に一泊旅行をしてきた。行きかえりにサービスエリアなどで放射線量を測った。自作の良い加減なガイガーカウンター(SparkFunのもの)なので数値、場所の公表は差し控えるが、確かに、ホットスポットと呼ばれる地域の線量は高かった。時間がなくて寄れなかったが、別の友人の別荘地に近い高速道路上で、東京あたりの4~5倍。最も高いところでは10倍以上を記録した。反面、仙台あたりは東京よりBG(バックグラウンド)線量が低い。どこまでも0.05μSv/h以下が続く。

 旅行から帰って久しぶりの電子工作が楽しい。すっかり中毒になっている。DC-DCコンバーターのシャットダウン端子は使い物にならないことがわかったので、自前のシャットダウン回路を、電源周りの小基板に作っている。FETとチップTRで組む。お手本はここのページである。

 このページによると、マイコンCPUのGPIOピンは、電源OFFのときはグランドに導通するのだそうだ。今回は、Mega328はパワーダウンモードで、I/Oピンの状態は保持されるはずだ。パワーダウンモードはすぐには作れないので、とりあえず実際にMega328をつないでテストしてみた。

 やはり負論理では、電源OFFのときは、プルアップしておく必要があり、もし、パワーダウンモードでI/Oピンが保持されていなければ、電源が入ってしまいそうだ。このページの通り、トランジスタをひとつ入れて正論理にしておくと、CPUが生きた時だけONになって安心である。

S_p9204251 ところが、ありあわせのTRをブレッドボードにつけてOKになり、チップTRで実際の回路を組むと、おかしい。FETが異常に熱を持つ。ゲートをジャンパーでグランドに落として問題なくONになるのに、ここにチップTR(2SC4116)のコレクターをつないで、Vcc(論理1)を入れると、見る見るうちにFETが熱くなる。2回目の通電では薄い煙が出てあわてて電源を切る。いかん、壊れたか。TRをはずしてFETだけでテスト。良かった。FETはまだ生きていた。しかし、どうしてだ?わけがわからない。発振でもしているのか。

電源制御回路がやっと出来た(9/20/2011)
 結局、チップTR2ヶを失って電源制御回路は完成した。原因は、今度もなんともお馬鹿な単純なミスだった。TO92と違って、チップTRは誤接続に弱い。間違えてベースに直接Vccをかけていたのに気づかなかった。前にフォトカプラーに制限抵抗をつけずにVccをかけたのと同じである。

 最初、FETの方から煙があがり、FETが持てないほど熱くなったと思ったので、こちらばかり調べていた。実はこれは完全な勘違いで煙がでていたのは隣のチップTRのほうだった。いやいや申し訳ないことをした。

 電源回路の構成は当初から相当変えた。最初は、DC-DCコンバーターの5V出力をCPU(Mega328)とLCDに使おうと考えていたが、コンバーターは無負荷でも相当な消費電流が流れることに気づいたので、コンバーターの5VはLCDだけに使うことに変更した。考えてみれば、今度のCPUは定電圧にしないとだめなADCなどの機能は使わない。4V程度で少々変動しても十分動くはずだ。

 小基板を完成させてそこからピンのようにリードを出し、ブレッドボードにさしてテストする。それが終われば、そのリード線を使って主基板に固定し、その間を配線する。この方式はなかなか合理的でうまくいった。

ガイガー管SBM-20のパルス数が段々増えてくる(9/26/2011)
 CHANEYのガイガーカウンターキットは、マイコンと接続されて、カウントをUARTに表示するところまで進んだ。ファームは前のSparkFunと同じでLCDとの配線はまだやっていない。しかしUARTに出されたカウント数は、人間がこれまでストップウオッチ片手に集計したCPMより明らかに多い。しかも、時間がたつに連れて増えてくる。

Longtest

 CHANEYのキットのGM管は、ロシア製のSBM-20である。ウェブの情報を元に、平滑コンデンサーを入れ、バイアス抵抗を100KΩから10MΩに換えて、電圧は、350Vまで下げた。ところが、測ってみると、500V近くが出ている。おかしいけれど、何度測っても(DVMで)同じだ。

 これには心当たりがある、オシロで高圧電源を見ると派手なパルスである。電圧計はこの平均を出しているので、正確な電圧を出しにくい。それに、CHANEYの高圧部は、SparkFunのより更にインピーダンスが高く、1GΩの負荷でも影響があってオシロでは正確な値が出てこない。

 とにかく電圧を下げてみることにした。平滑コンデンサーをとると、バイアス抵抗が10MΩでは、全く電圧が出なくなる。1 MΩまで下げると出たが、電圧は同じ。今度は、NE555の発振周波数を下げてみる。NE555のパルス間隔を決める抵抗を、12kΩから20kΩにする。発振周波数は280Hzから170Hzまで下がったが、電圧降下には余り効果がない。

 電源電圧を5Vくらいまで下げても変わらない。5Vまで下げると、パルストランスがうなりだす。色々なことをしても、420~480V近辺で、これ以下にするとパルスを検知しなくなる。明らかにプローブをあてると様子が変わり(スピーカー音が変わる)、どうもこれが本当の電圧か疑わしい。

 SparkFunのLND712との比較では、SBM-20のCPMの数は、電源投入直後が最も、スペックに近い。図を見てもらえばわかるように、CPMは時間が経つとともに、増え始め、だいたい2倍から3倍のところで落ち着く。どうも不安定だ。始めは少なくて、時間がたつにつれて徐々にカウント数が増えていくのは、どの状態でも同じだ。測定器としてはとても使い物にはならない。

 調整している間にスピーカーから音が出なくなった。こういうときは、だいたいプローブがどこかに当たってICチップを飛ばした可能性が高い。スピーカーをドライブしているのは何のチップだ。ああ、FETだ。おお、こいつはこのあいだ秋月で沢山買った2N7000だ。早速とりかえる。予想通りFETがこわれていた。音が戻る。今回は犠牲者が多い。チップTR2ヶも失っている。少し気を引き締めなければ。

 思い切って、これまで改造で加えていた平滑コンデンサーなどの変更を全部やめて、オリジナルに戻してみた。スピーカーからのクリック音は、大きくなりLEDの光も強く、パルスも見たところ一番少なくなったように見えた。

S_p9274270 ところが、マイコンが示すCPM数は、パルス音などよりはるかに高い数値になる。オシロでみると一目瞭然である。平滑コンデンサーがないため、電源の脈流パルスが、放射線で発生した大きなパルスの度に複数のパルスになってカウントされている。人間が音やLEDで知るカウントが正しくても、マイコンでは副次的なパルスを識別することができない。チャタリング防止のようなソフトで解決する方法もあるが、近接して本当のパルスが発生した時と区別がつかなくなる。

 困った。安定を求めて平滑コンデンサーをとり、電圧を下げると(350V)、電源ノイズでパルスがとれなくなる。電源を平らにしてパルスをとれるようにすると、電圧が上がってしまって(420V以上)、パルスカウントがどんどん上がり、正常な測定が出来なくなる。一時間で2倍から3倍では、話にならぬ。

 しかし、オリジナルのまま、手動でパルスをストップウオッチ片手に、1時間以上測定してみて、愕然となった。オリジナルでも、明らかに時間とともにパルスカウントが上がることが確認された。パルス増加の原因は、電圧が高いためではなかった。

Chaney_org となると、これはGM管そのものに問題があると言うことである。ただ、このGM管は色々な線量計で使われている定評のある管だ。元から不良だった?オリジナルで長時間、測定したことがないので何とも言えない。あっ、そういえば、ケースに入れるテストをしているときGM管を少し凹ませてしまった。これが原因なのか。

 パルスが出るので問題ないと思っていたが、ウェブの情報を良く読むと、内部クエンチと言って、一旦放電したあとに連続放電を止めるのは内部に封入したガスによるものであり、このガスが少なくなればパルスがどんどん増えてしまう結果になるのはおかしくない。

S_p9274272 うーむ、GM管を取り替えねばならないか。最初は、いっそのことこの回路をあきらめて自作してみようか、電流消費も多いことだしと思っていたが、それ以前に問題があったとは。

 少し頭を冷やして、善後策を考えることにする。もう、今さらガイガーカウンターでもないのだが、なにしろ「負けず嫌い」「へそ曲がり」の性格である。完全に手段が目的化しているが、止められない。

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

2011年9月11日 (日)

もうひとつのガイガーカウンターの制作など

K型熱電対と遊ぶための準備(9/2/2011)
 SparkFunのキットの後始末が一段落しブログにその顛末をアップしてから、高揚した気分が一気に落ち着いた。モチベーションが下がり暫くは何もしたくない気分である。ところが不思議なことに、頭は休養を要求していても、手は何か動かしていないと落ち着かない性分になってしまった。本当に困ったものである。

 というわけでもないが、これまでちょっとづつ準備し、部品を集めてきた熱電対の温度測定の回路をブレッドボードで作り上げる。このページに触発されたアナログ回路である。少しアナログづいているのかもしれない。アナログが楽しい。最初は、温度測定だけだが、最終的には、SSR(ソリッドステートリレー)を使った温度制御をやる。強電工作第二段である。

 そもそもは、このあいだ作ったアクリル曲げ器の温度制御がやりたくて、秋月でK型熱電対を衝動買いしたことが始まりである。昔から炎など普通の温度計では測れない高温を測定したいと思っていた。偶然、同じ動機を持った人がサイトにわかりやすい熱電対の使い方を解説していて、チェックしてあった。

S_p6183963 熱電対による温度測定には専用のICが用意されており、これを使えばこれから作る回路は全く必要ない(以前の記事参照)。しかし、そこは凝り性の性格である。この面倒な補正をやってみたというこのページを見逃すわけには行かない。

 アクリル曲げ器の方は、このあいだ実際にオッシロの高圧測定の分圧器の端子盤を作るのに使ってみた。うすっぺらいアクリル板(CDケース)を使ったやっつけの簡単な加工だが、結構それらしく出来た。まともなケースを作るところまでになるにはまだ先が長いが、こういう簡易なしかけをつくるくらいは簡単だ。回数を重ねればもっと上手くなるだろう。このアクリル曲げ器にもう少し資本投下してみることにしよう。

S_p8224146

 温度センサーと熱電対を組み合わせた温度計のアナログ回路そのものは、記事にあるように至極簡単である。多回転ボリューム2つで倍率を調整する。温度センサーと熱電対の熱勾配を一緒にしておけば、温度センサーと熱電対の検出電圧の和が、実際の温度になるという理屈である(熱電対は2電極の温度差しか出さないので、冷極の温度が必要)。合算された電圧をオペアンプで増幅してADコンバータにかける。

S_p9094170

 結構、これが面白い。反転増幅器の2つの抵抗を可変抵抗でやるので変化が激しすぎるのが難点だが、オペアンプの理屈が良くわかる。オペアンプのオフセット電圧の計算などは、連立方程式を解くと出てくる。それらしい値が出てくる。計算値は、データシートを見るとちゃんとLM358のオフセット電圧と同じ範囲(7mV)にあったりして結構、感動した。

 熱電対はまだ使わない(ブレッドボードへの固定が難しい)。出来上がった回路は、mVの単位だが、温度センサーを手で触るとオペアンプの出力には、ちゃんと規定どおりの電圧の変化が観測できる。ただ、実際の温度への換算は簡単ではない。温度センサーそのもののオフセット(0℃のとき600mV)も計算に入れなければならない。校正もさらに必要だ。

 どうも、このあとはマイコンを動かし、値をADコンバーターに入れて、実際の数値をハンドリングした方が早そうだ。余っている7セグLEDを使って表示すれば温度計が出来上がる。さらにSSRを使ってヒーターを制御し、現在温度と設定温度の2段重ねに表示すると見栄えがするかもしれない。妄想はいくらでもふくらむが、不思議なことに、このあたりで先に進む気力が切れた。

 ということで今度は、CHANEYのガイガーカウンターキットのケースを作り始めた。この移り気の速さは自分でも驚くばかりだ。まあ、アマチュアの工作だ。許してもらおう。ケースはタカチのSW-125(125×70×40)。レイアウトに頭を捻る。このあたりもやり始めると面白くて止められない。

CHANEYガイガーカウンターキットの改造は済んでいる(8/19/2011)

 実は、SparkFunにとりかかる前に、CHANEYのキットの方も改良工作をすませてあった。このキットもウェブで散々叩かれ、改良記事が沢山出ている。ありがたく頂戴する。

 まず高圧回路に平滑コンデンサーがない。確かに入っていない。脈流ではノイズも撒き散らすし、不正確にもなるだろう。記事では、4700pFだが、手持ちは、例のSparkFunのときに買った耐圧1kVの0.01μFである。試しに、これをつないだら、600Vまで上昇する。これは少し高すぎる。

S_p9114189 もうひとつの指摘はGM管(SBM-20)のバイアス抵抗100KΩである。派手なパルスは出るが、耐久性に問題があると言われている。100Kから、10Mに取り替えてみる。不思議なことに、この変更で電圧が500Vに下がった。それでも定格より100Vも高い。心配なので、コンデンサーを0.01μFから、もうひとつの手持ち470pFにしてみた。定格より少し低い350Vになった。しかし、問題なくパルスが出ている。改造はこの程度にして、暫くこれで様子を見ることにする。

 次は、このキットからデジタル信号を出す回路の追加である。パルス信号の出力点を探す。青LEDをドライブしているダーリントントランジスタの出力(エミッタ)あたりが一番簡単なようだ。リード線を半田付けして外へ出し、オシロで波形を確認する。出た出た。6.5Vがパルスの度に1V近くまで下がっている。うーむ、パルスは一つではなく、20ms、長い時は40msの間にいくつもの付随的なパルスが出ている。

 そのまま測るべき(カウントする)なのか、無視するのか今の段階ではわからないが、LND712との換算からみれば、付随パルスとしてチャタリング防止のようなマスクが必要のようだ。それに6.5VをTTL用に5Vに下げる必要がある。

CHANEYのケース制作に忙しい(9/4/2011)
 こんどのガイガーカウンターのGM管はロシア製のSBM-20で、LND712に較べると少し長い。ケースは細長のタカチのSW-125のグレイである。SparkFunは、秋月のケース112-TS(117×84×28)を使ったが、これより気持ち小さい。透明ではないのでLCDスクリーンの窓を開ける必要がある。

S_p9014164 LCDの固定は少し工夫してみた。これまで、LCDの固定は、基板からポストで固定して化粧板には窓だけ開ける方法か、化粧板にネジで固定して基板とコードでつなぐかの、どちらかの方式だった。今度の基板は、CHANEYのキットが入って2段になり基板からポストを立てるのは難しい。とすると、化粧板に固定する方式だが、ネジが表から見えてしまうのは、みっともないなと前々から思っていた。

S_p9034165 裏からネジを当てれば良いが、のりしろが少ない(基板1.6ミリ、ケース厚2ミリ)ので小さいネジでは不安だし、少し大きくすればネジが突き抜ける心配がある。そこで、2ミリのアクリル小片を3枚使い、中にLCD基板をはさむ方式を考えた。

 こうするとLCDパネルが化粧板から大きくはみ出るのも防げる。サーキュラーソーがあるので、アクリルの小片は簡単に正確なものがいくらでも作れる。接着剤も、接着面が広いので滅法強い固定ができる。ちょっとのことでははがれない。

 出来上がりは予想以上にうまくいった。片側は枠を作るだけでネジを使わない。はさむだけである。もう一方も同じような枠を作り、上蓋を2.6ミリのタッピングネジで止める。簡単に出来て、しかも確実にLCDが固定できた。嬉しくて何度もつけたりはずしたりして出来上がりを喜ぶ。他愛ないものである。

 主基板の工作も進める。CHANEYのキットは高さ10ミリのポストで主基板上につけ、パルス検出LEDが化粧板になるべく近くなるようにする。主基板には、電池と、CPU基板などが入る。最初、ケースの上蓋をうっかり逆にして、蓋を閉めようとしてLCDがガイガー管にあたり、管をわずかだがへこましてしまう。一瞬、肝が冷えたが、問題なく動いて胸をなでおろす。

S_p9094169

 電池は、例のLPCMプレーヤーで余っている任天堂DSの互換リチウムバッテリーを使う。充電はとりあえず外部。脱着可能にしなければいけない。ついでに振動で外れないような仕掛けがいる。

kumanさんのリセットICを使ったバッテリー電源制御(9/6/2011)
 電源に頭を捻っている。CHANEYのキットの電源9Vは、DC-DCコンバータを自作したが、CPUとLCDの電源が悩ましい。リチウム電池の4.1Vをシリーズレギュレーターで3.3Vに落とせば、LCDのドライブには、何らかの負電源が必要になる。

 最初は、前のリニアPCMプレーヤー1号機のときの予備のLTC1144を使おうと思っていたが、電源関係のICチップが3つも必要になるのは、どうも気に入らない。そこで思いついたのが、ストロベリーリナックスのDC-DCコンバーターである。面白がっていくつか買って、電源可変のやつは、フォトフレームの12V電源では重宝した。もう一種類の0.9Vから3.3Vと5Vまで昇圧できるコンバーターは、特に使う予定もなく、使い終わった単4電池(ワイヤレスマウスに使ったのが多量に残っていて捨てられない)ひとつで白色LEDをつけて遊ぶくらいにしか使われていない。

S_p9114187

 そうだ、これなら、リチウムバッテリー(4.2V)からなので5Vに高効率で昇圧できる。200mAまでとれるので全く余裕だ(LCDはバックライト無しなので全部で10mAも流れない)。シリーズレギュレーターよりはるかに地球に優しい(おおげさな)。これで、電源ICを2つに出来る。

 しかし今度は、リチウム電池の過放電が心配である。これまでは、シリーズレギュレーターなので電圧が下がればLCDが薄くなったり、音が割れてきたりして電圧低下がすぐわかったが、DC-DCコンバーターは、ギリギリまで電圧を維持し電源から電気をしぼりとる。こいつは何らかの予防手段をとらないと危ない。

 そこで、あらたに電源電圧が一定以下になれば供給をストップする過放電防止回路を検討した。最初は、AVRのADコンバータかなにかで調べてなどと大層なことを考えていたが、ウェブですごく簡単なものを見つけた。リセットICを使う方法である。リセットICは電圧が規定以下になると、論理0を出力する。こいつは簡単だ。

 でも、このページ何か前に見たようなページだなあと、良く見たら、何と何とAVRを始めたころお世話になったkumanさんのサイトだった。ローサイドでnMOS-FETをリセットICの出力でスイッチし、リチウム電池の過放電を防止する方法である。部品はたったそれだけ。

Photo

 ただリセットICは閾値が2.6V(3.3V用)なので、リチウム電池の下限まで上げてやる必要がある。kumanさんは、ダイオードを使っておられたが、ここは半固定か何かの抵抗で分圧した方が良いかもしれない。いずれにしても、以前、電子リモコンボリュームの電源を切る時に1ヶ使ったきりで遊んでいたリセットICが役に立つことは有難い。kumanさん、ありがとう。

Windowsのプログラム開発に手を出す。AVRSPの再ビルド(9/10/2011)
 可能な限り敬遠していたPC上のプログラム開発をどうしてもやらなければならなくなり、久しぶりにコマンドラインでChaNさんのAVRSPをソースからビルドした。

 そのきっかけは、DigiKeyから買ったTQFPのMega328である。CHANEYのキットのCPUにするべく、鼻歌まじりで、秋月で買った変換基板に取り付け、クリスタルやパスコンなどを基板上に表面実装し、機嫌よくブレッドボードで動作テストを開始した。

S_p9114178

 ところが、愛用のプログラムライターAVRSPがこのチップを認識しないのである。配線間違い?いやあ、そんなことはない。エラーメッセージをよく見ると、"Unknown device"となってDeviceIDが出ている。ふむ、いつものエラーとは違うなあ。ありゃりゃー、もしかするとAVRSPはTQFP版のMega328をサポートしていない?いや、SparkFunのもTQFPのMega328だった。何の問題なく認識した。

 あわてて型番を確認する。SparkFunの石は、Mega328P(DeviceID 1E-95-0F)で、DigiKeyから買ったやつは、良く見るとMega328(同 1E-95-14)。迂闊だった。全く意識していなかった。何い、AVRSPのサポートは?ええー、何と、何とMega328Pはサポートしているが、無印のMega328はサポートされていない!(avrsp -h で確認できる)。

 スペックで見た限りでは、328と328Pは電源消費量が違うだけで、後は殆ど何も変わらない。恐らくこのAVRSPのサポートディバイスリストに一行足すだけで良いのだろうとは思うけれど、AVRSPはPCのプログラムである。修正はWindowsのプログラム開発環境が必要になる。

 ふーむ、困った。AVRSPはソースコードまで公開されているが、所長は、Windowsの開発環境が大嫌いで、これまで可能な限り近づかないようにしていた。昔、MFCか何かで少しWindows95のソフトをいじろうとして、その長大でおどろおどろしい開発環境に恐れをなして以来、敬して遠ざけている。まだ、Macintoshのアセンブラーを使った面倒な画面制御の方が精神衛生上よほど落ち着ける(昔、何本かパッチをあてて遊んでいた)。

 だからといって、これしきのことを大騒ぎして、ChaNさんの手を煩わすのも気が引ける。DIP版のMega328Pはストックがあるので、これで作り替えれば良いのだが、ここまで変換基板に作り込んだものが無駄になるのも悔しい。

 他のプログラムライターも必ずしも無印328をサポートしているとは限らない(78K0のAVRISPもサポートしていなかった)。秋月で安くなった純正のプログラムライターAVRISP MkⅡを買えば解決するだろうが、これも何か抵抗がある(どうせ純正を買うなら、パラレルのDragonが欲しい)。

 しばらく悩んでいたが、ここまできたらAVRSPを自力で直すしかないだろう。ゆるゆるとウェブで方法を探し始めた。調べて見たら都合の良いことに、コマンドラインだけの開発環境があるようだ。これなら簡単そうだ。特に、このページは、AVRSPそのもののコンパイル法が詳しく出ている。

 土曜のお昼過ぎから、このサイトを頼りに、ボーランドの無償Cコンパイラ(BCC5.5)を手に入れ、本格的な開発環境を整え始める。修正を加えて(avrsp.cのディバイステーブルと、avrsp.hのenum変数宣言)、恐る恐るコンパイルしてみる。

S_p9114177

 いやあ、沢山コンパイルエラーが出る。念のため修正前のオリジナルでコンパイル。なーんだ、最初からエラーが出ている。ふむふむ、_outpとか、_inpというダイレクトにポートを叩く関数がライブラリーにないようだ。GiVEIO用のライブラリが見つからない。

 おや、このページは、本来はAVRSPをユーザーモードで動かす方法(GIVEIOを使わない)の紹介で、別のフリーのライブラリをリンクすれば、これが出来るようなことが書いてある。店をこれ以上広げたくはないけれど、この際これに乗っかってみよう。言われるとおりのライブラリをダウンロードしてリンクしてみる。

Avrsp_bcc

 よーし、コンパイルは警告だけになった。うむ、EXEファイルが出来たようである。だめもとで、こいつを動かしてみた。おおー良いぞ。無印のMega328を認識した。フューズビットは変えられるか。よしよし、これも大丈夫だ。オシロには勢い良く8MHzのクリスタルの発振波形が確認できた。勢いに乗ってSparkFunで動かしているファームを焼いてみる。問題なく焼けた。LEDなどがブリンクし、UARTからメッセージが出る。これで万全だ。

 いやいや、こういう抜け道のようなコンパイルでAVRSPが作り直せた。こんなに簡単にWindows(まあ限りなくDOSですが)のプログラムがコンパイルできるとは正直、思っていなかった。それにしても、ソースコードがあるというのはありがたいことである。 このページの作者、木村 真也さん、それにChaNさん、ありがとう。

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

2011年9月 1日 (木)

SparkFunのガイガーカウンターを正しく動かす

 前回の記事の反響は大きかった。次の日、研究所開設以来の最大アクセス(一日866)を記録したかと思ったら、週明けの月曜はその記録もあっさり抜いて一日のアクセスが1200を越えた(1244)。いつもの3倍である。

 「ゆきの研究室」という著名なサイト(ここの作品は見事と言うしかない)や、所長もお世話になっているsimさんあたりが話題にしてくれてアクセスに拍車がかかった。有難いことだと思うと同時に何か責任の重さを感じる(あまり好き勝手なことが出来なくなってくる)。

 ただ、SparkFunのキットの問題は、前回ですべてが解決したわけではない。もう少しこのキットにこだわってみることにした。それにしても、つっこみどころ満載のキットである。

時々動かなくなる原因を見つけたか(8/26/2011)

 ブログの初日のアクセス急増はツイッターによるところが大きい。アクセスログに見慣れないリンク先が出てくるのでアクセスすると、自分のブログが出てくる。Googleで検索しても見つからない。おかしいなあと思って、このあたりに詳しい娘に聞くとツィッターの短縮URLというものらしい。ツィッターのページからは検索できる。所長もあわててツィッター登録し、震源地を調査した。これが不慣れで、どなたが最初にtwittしたのか見極められない。とりあえず、この場を借りて御礼申し上げておきたい。

S_p8244149 それはともかく、過大電圧でガイガー管を壊してしまう危険は回避した。しかし、そもそもはそれが問題ではなかった。最初のトラブルは時々動かなくなることだった。この原因は解明されていない。 このトラブルシューティングのために部品を次々にはずし、結果としてブレッドボード上に別の部品で配線図どおり組み立てて動かすところまで行った(トランスだけは、基板から取り出した同じもの)。この状態では高圧が出なくなることは一度も起きていない。

 時々動かなくなるのは、基板上の発振回路のパターンに、接着剤でスペーサーをつけたためと結論付けたが、どうも納得できていない。接着剤そのものは絶縁物だし、基板の上にはかなり厚いレジストが塗られており、これが原因とは考えにくい。トランジスターは2つともはずしてブレッドボードにつけなおし、正常動作を確認している。

 原因究明はさておき、このキットを実用品に戻さなければいけない。ケースのLCDとスイッチを無駄にするわけには行かないのだ。 ブレッドボードで作った回路を小さなサブ基板に作り直し、ケースの中に入れて動かそうと考えた。まず、ブレッドボードにはずしてあったトランスを正規の場所に戻して、そこからサブ基板に行くリード線を出す。

 念のため、これでちゃんと動くか確かめる(用心深くなった)。おやあ、動かない。どういうことだ。トランスと基板の接続がおかしいのか。テスターで測る。何い、Vccがトランスにかかっていない。トランスはハンダ面でしっかりついているが、良く見るとVccのパターンは部品面にある。

 えー、このホールはスルーホールじゃないのか。うそだろう。最初にトランスを取り外す時、例の低温ハンダが部品面まで行かずパターンを傷つけてしまったのかもしれない。しぶしぶ、トランスをもういちど外す。パターンは一部がはがれているだけでVccとの間は切れていなかった。ルーペで仔細に調査する。やっぱりそうだ。穴の中は、エポキシ基板の生地が出ている。スルーホールじゃない。

 わかったぞ、接着剤でおかしくなったのではない。このトランスの固定が問題だ。スルーホールではないので、ハンダ面からハンダを余程たくさん盛って、部品面まで流し込むか、クリームハンダか何かで前処理しておかないと、ここの接続は不安定になってしまう。

 ハンダがそこまで行かなければ、このトランスの端子(幅1.5ミリほどの平ピン)と、部品面のランドは物理的に接触していることしか期待できず、金属表面が酸化してしまえば、ちょっとしたショックや温度差などで簡単に接触不良になる可能性は十分ある。

 そういえば思い当たる節がある。最初に動かなくなったのは、車に持ち込み、急ブレーキを踏んだときに、座席から落とした衝撃から動かなくなった。そのうち復旧したけれど、ここの接触が不安定だと、こういうことは起こりうる。コンデンサーを取り替えて、全く戻らなくなったが、これは接触点の近くに熱を加えたことで、状況が固定的になったのだ。

 ふむむ、もしかすると、このトランスのところを完全に接続し直せば、元の基板パターンに部品を戻しても動くのではないだろうか。どうもスペーサーの接着剤が原因ではないような気がする。迷ったが、だめもとである。全部のパーツを元の位置に戻してみた。電源を入れる。やった。順調に高圧が上がり、パルスを検出するようになった。

 パルスは、当初より少し多い環境放射線量を記録するようになった。以前は、0.08程度だったが、0.11μSv/hくらいに上がる。過大電圧の時のパルスは、オシロにあったように相当派手なパルスにならないとカウントしていない。こちらの方が本当の値なのかもしれない。

 ちょっと心配になり、電圧を測ってみた。おやおや何と800Vもある。ブレッドボードのときは、600V近辺で、ちょっと高いがまあいいかと思っていたが、これではいくら何でも高すぎる。回路の効率が良くなったからかもしれない。それにしても、定格の倍だ。何とかしないといけない。

検出回路もインチキだった(8/28/2011)

 電圧を下げるには、電圧制限回路を追加するのが一番確実だが(部品も買ってある)、とりあえず発振回路のコンデンサーを1μFから、さらに0.47μFに落としてみた。電圧は、400~450Vに下がった。しかし、今度は、パルスを拾えなくなってしまった。今まで効果のあった出力回路にあるコンデンサーの値をいくら小さくしても駄目である。

 試しに、このコンデンサーをはずしてみた。さすがにこれでパルスを拾うようになったが、オシロで見てみると、このパルスは、反応パルスが起きた後の電源の変動のピークも拾っている。多数のパルスが起きる。電圧が下がったせいで本来のパルスが小さくなり区別がつかなくなっている。

S_p8294153 どうもおかしい。トランジスターのベースに入る入力パルスが負電圧なのだ。GM管の反応パルスは、高電圧から一気に0Vに落ちるパルスなので、コンデンサーを通すと逆方向に電流が流れ、ベースが負電圧になるのは納得できる。ところが、どういうわけか今までの検出は、このパルスのオーバーシュートの部分でベース電圧がプラスになるところで、コレクター電流が流れてパルスが落ちる。結果として、正論理のままの出力になる

 これは明らかにおかしい。オーバーシュートの部分をトリガーにしている。考えてみれば、GM管の反応が負論理なのに、トランジスターの出力も負論理のままである。本来のトランジスターバッファーは反転しなければならない。

 これまでの過大電圧(1500V近く)のときは、GM管は10ms以上の間、立て続けにパルスが発生し、派手なオーバーシュートが出ていたので、コンデンサーでなまらせて1パルスにしていたが、定格のパルスでは、このままでは正規のパルスと電源変動のパルスの区別がつかない。

 パルスが負電圧なので、いわばプルアップしてやれば良い筈だと、ベースに交流増幅のように分圧抵抗で持ち上げるが駄目。パルスが消えてしまう。ウェブで「負電圧 ベース入力 プルアップ」などのキーワードで調べるが埒(らち)は明かない。トランジスター回路の応用なのだが、アナログの素人の悲しさ、どうしてこれを解決すれば良いのか方策が見当たらない。

先人の回路を真似る。見事なパルス(8/29/2011)
 そのうち気がついた。自分で回路を開発しようというのが無謀なのだ。他の人がどうやっているか調べてみるべきだ。これまでの集めてきた自作ガイガーカウンターのサイトをしらみつぶしに検出回路について調べてみた。

 すると、ここのサイトの説明で、謎がすっかり解けた。ここには簡潔に書いてある。「アノード検出回路は、負パルスなのでPNPトランジスターを使います。」なるほど、そういうことなのか。NPNで一生懸命プルアップしても、ベースとエミッターの間の電圧は一定なので動作点が変わってしまい、負電圧は拾えないのだ(少し勉強した)。

 SparkFunの検出回路はGM管のアノードからなのに、NPNを使っている。そもそも根本的なところから間違っている。これではまともなパルスは検出できないわけだ。しかし、市販のキットでもこんなことがあるのかとちょっとあきれ気味である。しかも、クリエイティブコモンで、回路図もボード図もEagleで公開している。暇があったら英訳して送ってあげたいところだ。

S_p8304156

 検出回路をブレッドボードに移して、このサイトの回路図や、別のサイト(ここやここ)でも見つけた回路図を参考に、回路を組んでみた。ブレッドボードなので簡単に組みあがる。オシロで波形を見る。おおお、何と言う美しさだ。見事な検出パルスが出た。サイドのノイズは、回路図にある100pFのコンデンサーで綺麗に消えた。素晴らしい。教科書にでてくるようなパルスだ。マイコンは立下りでとっているはずで、ソフトは全くいじらないで、この正パルスで動くはずだ。

S_p8304155キットの実装に熱中する(8/31/2011)
 ブレッドボードの検出回路は見事に動いた。次はキットの基板への実装である。頭を捻る。検出TRのパッケージはチップでなくお馴染みのTO-62(MPSA18)だ。NPNからPNPに換える必要がある。PNPは手持ちの2SA1015で、キットの石のピンアサインは、CHANEYのときと同じ、EBCである。注意しないと前の二の舞になる。

 こういう改良は、なぜか心が躍る。いかにこれまでのパターンを活用して簡潔に回路を完成させるか。メモ用紙に実体図を描いて検討する。ほどなく空中配線にならず、一番合理的な方法を考え付いた(おおげさな)。

 まず、カッターでTRのエミッターの接地部分を切り離す。ここは感心にもスルーホールになっていた。そうか、トランスのところも最初はスルーホールだったが、トランスのピンが大きすぎて広げた結果、そうでなくなってしまったのかもしれないと勝手な推理をする。

 当初のエミッターのピンはご丁寧に両面ともベタアースにつながっており、ここはPNPになるとVccにつながるので余裕を見てカットしておかないといけない。切り離しに時間がかかる。ルーペで何度も確認する。

S_p8304158

 次は、部品面にある1KΩのダンピング抵抗を47Kに変更し、プルアップ抵抗(1M)とノイズ防止コンデンサー(100pF)をハンダ面に固定する。Vccラインを遠方から引っ張ってトランジスター(エミッター)のところへ配線する。最後は、当初のVccからのプルアップ抵抗(1K)を除去し、4.7μFの載っていた大きなランドにコレクターの負荷抵抗(100K)をつければ完了である。

 何度も配線をなぞって間違いがないか確かめる。よーし、問題ない。これで動くはずだ。S_p8304160念を入れて電源をONする。暫くたって赤いLEDが消え、LCDに「ケンチシマシタ!」のメッセージが出た。いやあ、SparkFunのガイガーカウンターは、これでやっと本来の機能を取り戻した。GM管の高圧は、400~450V。問題ない値だ。

 回路図はいくつかのサイトを参考にさせてもらったが、著作権の問題を避けるために、そのまま掲載することはやめることにする。リンク先の回路図をご覧になっていただきたい。回路図がなくてもこれまでの説明と画像で変更はできる。ただし、トランジスターのピンアサインにはくれぐれもご注意(前々回記事参照)。

S_p8304163

 ついでに、ソースコードの修正をしておく。正規のパルスにしたせいでタイマーの1tick 128μs以内に複数回起きるパルスを拾うようになった。LND712のデッドタイムは、90μsなので、128/2=64μsは、独立したパルスとみなさないほうが良い。これを無視するように修正してある。

ここに、AVRStudioのプロジェクトになったソース一式を置きます。

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

S_p8304162x

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

2011年8月24日 (水)

遂にSparkFunガイガーカウンターの不具合を解決した

 とうとう、SparkFunのガイガーカウンターキットの不具合(と言って良いだろう)の原因を解明した。もし、同じこのキットをお持ちの方は、この記事の最後に出てくる改修を出来る限り早く実施された方が良いだろう。さもないと、虎の子のガイガーミュラー管LND712を失う可能性が高い。

S_p8244149なぜ高電圧のまま出荷されていたのか理由がわかった(8/22/2011)
 SparkFunのガイガーカウンターキットの高圧部は、高入力抵抗の電圧計でも1500V近く、分圧器(1GΩ)を使ったオシロでも同じくらいの電圧がかかっていることが確認された。2種類の測定で同じ値だ。この電圧に間違いないだろう。このキットのガイガー管(以下GM管)はLND712で定格は500V、この電圧は余りにも高すぎる。

 Sparkfunのフォーラムには、以前の記事でも紹介したように、900V以上電圧が出ているよというユーザーの投書があり、Sparkfunから調べておくという返事があってそのままになっている。

 しかし、発振回路を調整して500Vに下げると、こんどは放射線パルスを感知しない。ガイガーカウンターとしての機能を果たさない。仕方がないので、元へ戻すと、高圧部から、異音が発生して電圧が断続的に低下し、正常な観測が出来なくなる。このブログにも同じような悩みを持っている人からのコメントがある。

 こちらで最初、高圧がでなくなったのは、当方の原因(配線パターンに接着剤をつけた)のようだが、電圧が高すぎることについては全く思い当たる節はない。フライバックトランスの出力は、オシロで見た限りでは、p-pで160~180V、3倍圧整流回路を通って、500V近辺になるはずだが、ウェブ情報などによると、フライバックトランスによる発振は安定でなく共振すると突然上がったり下がったりすると言う。

 そのため、Sparkfunがお手本にしたらしい回路には、ツェナーダイオードを直列にした電圧制限回路が入っており、一定の電圧以上では、ドライバーに制限がかかって出力が下がるようになっている。ところがSparkFunの回路は、なぜかこの部分が省かれている。

 いずれにしても、定格にすると機能しない。高圧に戻すと検知はするものの、異音が出て電圧が下がる。進退窮まって、もうSparkfunのキットは諦めようと思っていた(前記事にはそう書いた)ときのことである。

S_p8214123 GM管からの波形をオシロで見るともなしに見ながら、ふと、このGM管の放射線検知によるパルス波形が、これまでのウェブで見たお馴染みのパルス波形でなく、えらく派手なのに気がついた。

 ふーむ、ウェブで見るパルスは一回限りで、こんなに20ms近い連続したパルスではない。500Vではこのキットでは検知しないが、もしかしたら、このGM管はパルスを出していても回路が認知していないだけなのではないかという感じがしてきた。

S_p8224124 500Vに電圧を下げる。前のようなパルスは発生しない。つまり検知しない。オシロのスキャンの時間を一旦長くしておいてから、様子を見る。おっ、何か非常に短いがパルスが出ている感じがする。少しづつスキャン時間を短くしていく。そうだ、1現象ではなく、GM管から引き出されている信号出力にもオシロをかけてみよう。さらにトリガーをAutoでなく、検知したらそこで止まるNormalモードにしてみた。

S_p8224125 ビンゴ!である。トランジスターのベースには綺麗なパルスが入っているのが確認できた。間隔は、環境放射線の線量に近い間隔だ。なーんだ。ちゃんと検知しているではないか。それなのに何故マイコンの方には伝えられないのだ?

 回路図を見る。おおお、検知トランジスターのコレクターに4.7μFのコンデンサーが入っている。今まで気がつかなかったけれど、こんなに大きな時定数では、GM管の短いパルスは吸収されてしまうはずだ。

 わかったぞ、わかったぞ。このコンデンサーを使っていると言うことは、さきほどの派手なパルスを1パルスにするための定数だったのだ。今までの事実の断片が、次々につながって確かなストーリーが出来上がっていく。全部の謎がずるずると解けていくのがわかる。このコンデンサーの定数が動かぬ証拠だ。

 Sparkfunの開発者は、何らかの理由で電圧制限回路を省略し、電圧が1500V近くに上がっていることに気づかず、そのときのGM管の高圧でのパルス挙動を通常のパルスと勘違いし、このパルスで1カウントになるように、このコンデンサーを調整したのだ。

恐らく内部抵抗の低い計測器で高圧を測ったのだろう。高圧部の測定値が実際よりかなり低く、フライバック発振の電圧を見ているので3倍圧整流回路を通っても500V以下と確信していたに違いない。

 1500V近辺のLND712の放射線感知の波形は、多数のパルスが長時間でる(20ms以上)。設計者はこれに合わせて、信号検知の時定数を大きくし、結果として、通常のGM管の反応の時はパルスを拾わなくなってしまった。本来のGM管の反応パルスは、非常に短く(100μs程度)、この定数では隠れてしまう。

 アメリカでは余り問題にならず、日本のユーザーで「動かなくなった」という声があるのは、アメリカが日本に較べれば、圧倒的に湿度が低いため、数倍の電圧でもおかしくならなかったのだろう。

 日本の湿度はアメリカでは想像できないほど高い。これによって、LND712の絶縁が限度を越えてしまった可能性が高い。カンッカンッと音がしていたのは、定格の3倍近い電圧を喰らってリークしているGM管の悲鳴だったのだ。危ない、危ない。

 謎が解ければ、対処の方法は簡単だ。基板上の4.7μFのコンデンサーをはずし、少し極端だが、0.1μFに減らしてみる。よーし、良いぞ、500Vでも、しっかり反応をするようになった。オシロでみると少し少なすぎてパルスを余分に集めてしまいそうだが、これはあとで調整できる。

S_p8234148 500Vに下げれば、当然GM管からは全く異音はしなくなる。良かった。GM管は壊れていなかった。それにしても、GM管というのは丈夫な機器のようだ(冷戦という戦時仕様だからかも)。

Sparkfunのガイガーカウンターキットの修正方法(8/23/2011)
 Sparkfunのこのキットを持っている人は、早急に次に説明されている部品を交換したほうが良い。そうでないと、GM管がこわれるか、測定不能になる。

(1)発振回路のC2の10μFを1μFに替える。
  これで、GM管の電圧は、1500Vから600V程度に下がる。このままでは、パルス
  を拾わ ないので、次の(2)を行う。

(2)SIGをとりだすバッファートランジスタコレクタにあるC9 4.7μFを0.1μFに下げる。
    これでLND712の正規パルスを拾うようになる。ただし、この定数は調整する
  必要があるだろう。余り小さいと主パルスに付随する弱いパルスを独立した
  パルスとして拾ってしまう可能性がある。

Sparkgeigertop823 (1)は1μFより、0.5μFにした方が良いかもしれない。( 1μでも定格の500Vを超える)。一番良いのは、前回記事の海外サイトのオリジナル回路のように、ツェナー(またはバリスター)で高圧電圧を測りフィードバックして制御するのが一番確実だ。ブロッキング発振は、調整が難しい。原作者はそれを知っていて電圧制限回路を加えていた。これならツェナーダイオードで設定した以上の電圧はかからない。

 面実装の部品を取り外すのは通常では難しい。10μFのチップコンデンサーは2012クラスで、この程度なら、半田ごて一本で辛うじてはずせると思うが、4.7μFのコンデンサーは大きくてパタンが離れているので、はずすのは苦労するだろう。半田ごて2本あればとれると思うが、簡単にとるには、所長の愛用しているサンハヤトの低温特殊ハンダをお勧めする。少し高い(千石電商で¥4200)が、こういう表面実装部品のとりはずしはうそのように簡単になる。

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

2011年8月22日 (月)

ガイガーカウンター制作は迷走が続く

DC-DCコンバーターの製作(8/17/2011)
 SparkFunのガイガーカウンターの修復はともかく、CHANEYのキットの方も実装を進めなければならない。同じケースに入れるとしても、CHANEYの9Vの電源が問題だ。9Vを供給する006Pの電池は、少し古い電子機器には良く使われているが、容量が小さく、交換の頻度がばかにならない。

 ここからMega328などの5V電源を単に電圧降下で熱にしてしまうレギュレーターで作るのは地球資源に優しくない。特に006Pについては、前からリチウムバッテリーとDC-DCコンバーターで代わりになるものを作ってやろうと、DigiKeyでICチップを買ってあった。

 LM2735という石である。ストロベリーリナックスの5~20V可変のDC-DCコンバーター基板に使われている(そこでこのチップを知った)。この基板は、このあいだのフォトフレームの12V電源に使ってとても具合が良かった。大電流(最大500mA)が供給できるし、シリーズレギュレーターと違って効率が良い。熱を持たない。

 すっかり気にいったが基板の価格が少々お高い(¥945)。そこでチップだけ買って(¥322)自作しようと思っていた。買ったのは大分前で、なかなか実装する機会がなかったがちょうど良いチャンスが巡ってきた。ブレッドボードではうまく動かないという話を聞いていたので(発振回路が微妙なのだそうだ)、直接、基板を切り出して作りこんだ。

S_p8224141 誤配線もなく、DC-DCコンバーターはスペック通りの電圧を出力し始めた。半固定の抵抗をまわして電圧を調整する。うむ、問題ない。100Ωのダミーの負荷をかけて電圧を見る。よーし、100mAでも、電圧降下も少なく、無負荷のときと変わりがない。これでSBM-20の電圧も調整してやろう。

 CHANEYのキットは、9Vから少しづつ下げていって、結局コンバーターなしの裸の5Vでも辛うじて動作することがわかった。ただし、トランスが小さくうなりだし、余り機械には良くなさそうだ。7Vくらいが一番省電力レベルか。

大惨劇が起きた(8/18/2011)
 機嫌よく、DC-DCコンバータの可変抵抗器を動かしながら、最適な動作電圧をテスターで測っている時である。大事件が起きた。コードを少し引っ張ってCHANEYのキットが机上を滑った途端、突然、連続するガイガーカウンターのパルス音とともに激しく青色LEDが点滅するのが目に入った。

 ややや、何が起きた。とりあえず電源をコンバーターから抜く。うわあ、いけない。机上の金属製ピンセットが基板の裏側に入り込んでいる。高圧部が電源回路に触れた可能性がある。頭の中から血が引いていく。これは大変なことになったぞ。

 まず、ピンセットを取り除き、キットの外観に何も起きていないことを確認し、気を鎮めてから電源を入れ直す。DC-DCコンバーターの電圧が上がらない。何い、こちらがやられている? Vccに高圧が触れたのだ、当然こちらにも影響があるだろう。予期せぬ事態にさらに気が動転する。

 LM2735が死んでしまったようだ。やれやれ予備は買ってあるが、どうもついていない。この石は、我家の9V電源の機器(音楽演奏用チューニングメーター、予備のテスターなど)の代替電源用に使うつもりだったのに、替えがなくなってしまう。

 背に腹は代えられない。チップを取り替える。よし、ちゃんと電圧が戻った。電源を入れ直す。うーむ、全く動作する気配がない。やっぱり本体も大分やられているようだ。おお、NE555が熱い。ここがやられたか。

 NE555を昔々買ってあったセカンドソースのTA7555に取り替える。熱は持たなくなったが動かない。ふむ、ドライバーのトランジスター(以下TR)も熱を持っている。そうか、ICはことごとくやられたか。

 部品表を見ると、TRの2N3906は汎用の2SA1015(2SC1815のコンプリメンタリー)と殆ど同じということなので、これもとりかえる。再度、電源ON。おお、LEDが点いた、と思った瞬間、2SA1015のところで「パチッ」と大きな音がして、淡い煙が見えた(ように思う)。うわあー、何だ何だ。まだ他にも悪いところがあるのか。もう、完全に気が動転して頭の中が真っ白だ。何をして良いのかわからない。

何とかCHANEYガイガーカウンターキットを元へ戻す(8/19/2011)
 暫くして、少し落ち着いたので回路図を確認する。Vccに高圧がかかったといっても、微小電流である。抵抗器やトランス、コンデンサーが壊れる可能性は少ない。壊れる可能性の高いのはICだけである。それでどうして交換したTRが爆発する? そんな馬鹿な。気を落ち着けて資料を読み直す。2N3906は日本でも売られているようだ。あああ、そこの説明に「ピンアサイン注意!」とある。

 しまった。2N3906は、ピンアサインがEBCなのだ。ここへ2SA1015をそのままつけると、ECBなのでベースにコレクタ電圧がかかってしまう。良かったー。これが原因だ。ピンを歪めて(これ結構、難しい)、もういちど半田付け。恐る恐る電源を入れ直す。もう、異常なことは起きない。

 しかし、高圧は発生しない。他のICも疑わしいが、こいつらが動かないにしても高圧が出なくなることはない。うーむ、SparkFunに続いて、CHANEYも壊してしまったか。夜ももう遅い。今日はこれくらいにしておこう。暗い気持ちで作業を終える。

 俺もこりない男である。次の日の午後には秋葉原に立っていた。最後の可能性、NE555を買いにやってきた。ついでに独自の高圧回路を作るための部品も調達する。ウェブを渡り歩いて、大分、高圧回路にも詳しくなった。自前で作れそうだ。鈴商では、壊れているかもしれない高耐圧トランジタ(2SC4003)も手に入れた。高圧用のコンデンサーもここで買う。この店は目が離せない。千石、秋月にない商品が揃っている。

S_p8144114 部品を持ち帰って、まずはTA7555をはずしてNE555にしてみる。仕様的にはセカンドソースといわれるとおりピン互換のはずなので動かないことに変りはないとは思うが、ものは試しである。それこそ祈る気持ちで念をこめてスイッチを入れる。これで動かなければ自前の回路開発に行く。さあ、どうだ。やったー、青色LEDが瞬き、スピーカーからクリック音がしてSBM-20のガイガーカウンターは生き返った。

 そうかTA7555はCMOSなので動かないということもあるのか。秋月で、LMC555(これもCMOS)にするか、NE555にするか迷い、結局オリジナルのNE555にしておいて良かった

一瞬、SparkFunが生き返るが、すぐに動かなくなる(8/19/2011)
 CHANEYのキットは生き返った。今度は、SparkFunの修復である。前回の記事でドライバーTRの高耐圧トランジスタが壊れたのではないかという仮説を立てた。まだ諦めきれない。その代替品を買ってきてある。

 面実装の件のTR(MPSA42)を念のため特殊ハンダではずし、そのフットパターンに苦労してリードタイプ(SC-64)の2SC4003を取り付けた。余り期待しないで電源を入れる。これが何と、「ジィーッ」という高圧が出たときに出る音とともに、SparkFunのガイガーカウンターは生き返ったのである。

 ウオーッ、やったぞ。仮説が的中した。暫く通電する。何事もなかったかのように自然放射線の数値をLCDに刻んでいく。よーし、これでガイガーカウンターは2台とも復帰した。ただ、高圧が高い(1500V近い)ことには変わりはない。これを解決しないことには、いずれこのTRも壊れるだろう。

 それはともかく、上機嫌で仮止めのTRのリード線を切って正式に付け直し、LCDのソケットを元の位置に戻して(作業の邪魔になるのではずしてあった)、正規の状態に戻した。

 ところが、何と、元へ戻したらまた動かなくなったのである。ありゃあー、ハンダ付けが悪かったのか、いやルーペで仔細にチェックするが問題ない。もう壊れたのか。電圧を測る。やっぱり高圧が出ていない。歓喜の頂点からまっさかさまに奈落に落ちた気分である。いったいあの動いたときは何だったのか。

 泣く泣く、実装したTRをはずして予備のテスターで正常かどうかを確認する。殆ど使っていない昔のテスターだがTRをチェックする機能がついていて、リード線を差し込んでhFEを測定することが出来る。何い?TRは壊れていない。hFEは120以上を指す。

 ふーむ、これはおかしい。もしかしたら前のTRも壊れていなかったのかもしれない。チップTRを苦労して汎用基板の3ピンにつけてリード線を出して測ってみた。予想通り、このTRも壊れていなかった。hFEは何と150を越えた。

S_p8224137

 トランジスターが原因ではなかった。しかし、それなら何故、交換で動いた? やったことは、面実装のTRを取り外したことと、LCDへつなぐソケット基板を、固定するスペーサーから浮かしただけである。スペーサーの片側はまだはずしていない。鉄(ステンレス)ネジが基板に近づいたから?まさか。 謎は深まるばかりである。

 ただ、このスペーサーをなくすことは出来ない。ソケット基板の固定が出来なくなってしまう。もう、何がなにやらさっぱり見当がつかなくなって呆然自失の状態である。

SparkFunの回路のモデルを発見。ブレッドボードで作り直し(8/21/2011)
 そうは言っても、ころんでもただでは起きない性分の所長である。しつこいことには自信がある(自慢にならないか)。完全に手段が目的化しているが、このまま黙ってSparkFunのキットを見捨てるわけには行かなくなった。ここまで来れば、何とか原因を解明しないことには気がすまない。

 来週、旧友に会ってガイガーカウンターを持ち込んで自慢しようと思っていたが、それどころではなくなった。事態を冷静に見直して、やはりプリント基板の上に、気楽にスペーサーを接着したのが原因ではないかと感じ始めた。基板は、かなり厚いレジストが表面に塗られているが、発振回路なので微妙だ。

 それを確認するのは、もういちど回路を別のところで作り直すしかない、と思っていたときに、偶然、SparkFunの高圧回路のオリジナルとおぼしい回路を海外のサイトで見つけた。これ、これ。間違いない。全く同じように音響トランスをフライバックトランスに使った回路だ。

 あれ、この回路には、高圧からツェナーダイオード2ヶを使った回路がついていてTR一個でドライバーTRの出力を制御する電圧制限回路がついている。しかし、SparkFunではこれが省略されている。

 ふーむ、謎が解けてきたぞ。やっぱりこの回路はほっておくと500Vでは納まらないのだ。だから、制限回路がついている。1500Vを観測しているが、やっぱりこれだけの電圧が出ていた可能性が高い。とすると、GM管は、過電圧を長時間かけられたために、正規の500Vでは動かなくなったのか(800Vでは動かなかった)。

S_p8224131 このあたりは、あとで調べることとして、今は、接着剤で回路がおかしくなったという仮説を証明するのが先だ。ブレッドボードで同じ回路を組んでみることにした。こういうこともあろうかとこのあいだ行った秋葉原で小さなブレッドボードを入手してある。SparkFunのキットから音響トランスもとりはずす。

 ブレッドボードはやはり便利だ。あっというまに音響トランスを使った高圧ドライバーが完成した。こんどは、オシロで観測もしやすい。このドライバーだけで動かしてみる。波形を観測した。すごいパルスだ。P-Pで140V、3倍圧の整流回路にかければ、500V近くが取り出せるしかけのようだ。

S_p8214122 元のチップTRをブレッドボードに差し込んで実験してみる。何のことはない。これでも全く同じ電圧、波形が観測された。TRが原因でないことは明らかになった。やれやれ。

 いよいよ、本体に接続。少し賢くなって、オシロで高圧が測れるように、もうひとつの1Gオームで分圧器を作った。このあいだのアクリル曲げ器で、CDケースの切れ端で簡易な端子盤を作る。

S_p8214121

 オシロで1.3Vの直流がでた。1000Xなので、1300Vが軽々でている。ほう、フライバックトランスのときは派手な脈流だったが、コンデンサーでこんなに平坦になるのか。

 SparkFunのガイガーカウンターは、また動き始めた。ところが、そのうち、カンッ、カンッという例の音がし始めた。電圧がその度に急激に下がる。この音、初めはトランスかと思ったが、場所が離れたので、そうではないことがわかる。

S_p8224146

 すると音の発生元はGM管しか考えられない。これがプラトー電圧を超えた上限での連続放電の音かもしれない。電圧は、オシロでもDVMでも同じ電圧だった。この電圧で間違いないだろう。500Vでは反応しないが、現在の電圧はGM管を壊す可能性がある(もう壊れているかも)。心配になってきたので、とりあえず実験は中止する。

 さて、このあとである。残念ながらSparkFunは、これ以上の実験は無駄のような気がする。GM管の替えはないのである。これが悪いのなら、もう先には進めない。これまでの経過では、電圧がでなくなったのは、ドライバー回路のプリントパターンの上に接着剤でスペーサーをつけたことが原因であることは、ほぼ間違いないようだ。ただ、1500Vの高圧が何故かかっていたのかという最も根本的な原因は解明されないままである。

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

2011年8月19日 (金)

ガイガーカウンター制作で思わぬ道草

 高入力インピーダンスのDVM(デジタル電圧計)を作ったり、別のガイガーカウンターのキットを組み立てたり、このところすっかりアナログの世界にはまっている。ガイガーカウンターの高圧発生回路は、所長の最も不得手なアナログのハードウエアの世界である。調べれば調べるほど知らないことが出てきて、これがまた面白くて横道に入る。つい調べる目的をそっちのけにして、ウェブサーフィンに時間が経つのを忘れてしまう。まあ、これが楽しいのだから仕方がない。いつになったら本題(ってなんだっけ)に戻れるやら。

SparkFunガイガーカウンターキットの不具合(8/7/2011)
 そもそもの原因は、SparkFunのガイガーカウンターキットの不調である。突然、パルスが出なくなるかと思うと、暫くすると何事もなかったように復旧する。これが電圧計の完成直前、とうとう動かなくなった。これまでは数分か数十分放置しておくと自然に戻っていたのだが、今度は1時間以上経過しても回復しない。

 折角、ボタンをつけて完成!と思っていたのにこれである。ウェブを見ると、SparkFunのキットが動かなくなったという記事を散見する。何か販売元でも交換に応じているようなのだが、こちらのキットは、既に14本も線を追加しており、いくら高圧部は触っていないと主張しても交換や修理に応じてもらえる可能性は低い。

S_p8074086 と暗い気持ちになっていたら、また復活した。ガイガー管そのものが壊れていることは考えにくい(希望的観測)。恐らく高圧発生部だと思う。その理由として、ガイガー管がパルスを出す度に、トランス近くから「ジイッ」という小さい音が段々大きくなり、最近は、パルスに関係なく1秒程度の間隔で、小さな「カンッ」「カンッ」という音まで出始めた。どこかで回路が放電して電圧が出ていない感じだ。

 入力インピーダンスの高い電圧計(秋月のDVMキット)はまだ完成していない。本体が正常に動いているあいだに動作電圧を測っておこうと、あわててDVMキットを組み立て始める。組み立てている最中に気がついた。1Gオームの抵抗があるのだから、その分圧部(ローサイド)では普通のテスターで測れるのではないか(内部抵抗の低いテスターを分圧部に入れても入力インピーダンスは1Gで変わらない)。

 早速、試してみる。1Gオームを慎重に袋から取り出し、1MΩと空中配線し、恐る恐る、ガイガー管のアノードにリードを差し込む。1Mの低圧部も安心できない。グランド側が万が一外れれば、一気にここも高圧(まあ、極小電流の500V程度だが)がかかる。テスターに接続して、電源をONにする。

 ありゃあ、テスターで1.28V。1Gと1Mだから1280V以上かかっていることになる。これはどうしたことだ。念のため、1Mを2Mに換えると、0.58V。ほんとだ。倍にすれば1160V、これでも1KV以上の高圧だ。SparkFunのガイガー管はLND712で適正電圧は、460~500Vとある。

 以前、SparkFunのガイガーカウンターの掲示板で、「電圧が900V以上出てるぜ。コンデンサーを変えたら500Vに戻ったけど」という書き込みがあったのを思い出した。このとき、SparkFun側は、「そんなことあり得ないが、調べるから詳しい状況を教えて」ということでそのままになっている。

 ところが皮肉なことに、1Gオームの回路をつけて測っている間に、音が出るのが直ってしまったのである。何の音も出ることなく高圧は順調にでている(測定値は1200V近辺)。やれやれ、おかしくなった時の電圧を確かめて修理しようと思っていたが、現象が起きないので、おあずけである。

デジタル電圧計(DVM)の組み立て(8/7/2011)
 秋月キットのベストセラー商品のようである。相当古い歴史を持っているようだ。色々なキットに応用されている。ユニバーサル基板に配線したパターンをそのまま基板に起こしたような、ちょっと変わったプリント基板である。1テラオームに近いという内部抵抗が自慢で、今度の1GΩの分圧抵抗100Kに並列にするには十分な性能を持っている(つけたことを殆ど無視できる)。

S_p8114095

 組み立ては造作がない。数時間で半田付けは終わった。ただ、キットのICとLCDは2つとも40ピンの大きなDIPパッケージで、ソケットにつけるのは慣れないと緊張する。少し力を入れると歪んでLCDの画面が一瞬黒くなったりして慌てる。

 最初、LCDを逆さまにつけてLCDにデタラメな文字が表示され頭を抱えた。冷や汗をかきながらやっとのことではずし、正しい位置に付け直してめでたく数値が出た。いやいやお恥ずかしい。わきの下にたっぷり汗をかいた。

 さて、バラックでは電圧が測れるようになった。次はケースへの組み込みである。前からどうするか、あれこれ悩んでいる。仕事の帰り、秋葉原を巡回して高圧用の端子(テフロン製)を探す。ウェブではマックエイトなどのブランドで色々あるが、単品で売っているところを見つけられない。

 ネジで有名な西川で、やっとみつけたが、テスターのプローブジャックになるような大きめの端子は売っておらず、小さいのはあっても、10ヶ¥2300とかの値段で手が出ない。

 ロータリースイッチは、はなから高圧用はあきらめている。ロータリースイッチは200V以下の測定レンジと高圧のローサイド側に使うことにする。高圧用に独立の端子を設ける。考えてみればケースは金属ではなく、プラスティックなので、普通の端子でも1000V以上に耐えられると判断した。

 ロータリースイッチに、電圧計キットについている1%の抵抗を直付けし、小さな基板を足して、ここに残りの抵抗や、高電圧分圧の半固定抵抗をつける。この小基板には、さらにLCDの数字のドット表示用の回路が乗る予定だ。

別のガイガーカウンターキット到着(8/9/2011)
 SparkFunのガイガーカウンターがおかしな動きを始めたので心配になり、前から目をつけていた別のキットを発注してしまった。現在使っているものが危うくなると、あわてて代替品を衝動買いする癖がある。今度もそうである。

 ウェブ上で試しにお買い物籠に入れている間に、思わず「買う」ボタンをポチってしまった。これもアメリカの電子キット会社CHANEYのものである。GM管は、日本のウェブでも高性能と定評のあるロシア製のSBM-20。今度のキットはスピーカーとLEDがついているだけでマイコンは付属していない。多数の応用例があり、日本でも売り出されている(値段は¥12,000程度)。

S_p8094090 直接買えば、価格が94ドル。30ドルの送料をつけても、超円高の時代、1万円を切る。ここは会員登録も要求しない。メールアドレスと住所を知らせると素直に注文を受け付けてくれた。今度は、何のメールの問い合わせも来ない。問題のSparkFunのキットが回復し、うーむ、はやまったかと思う間もなく品物が届いた。何と発注から4日しか経っていない。

S_p8094092

 今度も記念撮影しておく。エアバックのような包装ラップから部品セットがビニル袋に入って登場した。おや、今度は組み上がっていない部品がアイロンで分割した袋にまとめて入ったキットだ。GM管だけはさらにエアマットにくるまれている。基板の作りは雑である。基板の切断面は手を切りそうな荒っぽい切り方だ。SparkFunに較べると、素人のプリント配線と余り変わらない。これで本当に動くのかちょっと心配だ。

DVM(電圧計)ケース完成。LCDドット表示回路にはまる(8/13/2011)
 CHANEYのガイガーカウンター組み立ては、すこしお預けにしてDVM(電圧計)キットのケースの工作を続ける。秋葉原からさらに部品を調達し、実装に色々工夫する。これはこれで結構夢中になる。

S_p8144102 仮組み立てをして、待ちきれずに端子経由で高圧を測ってみる。端子の絶縁を確認する目的もある。えー、1495Vもある。嘘だろー。いや、間違いなさそうだ。コッククロフト・ウォルトン回路になっているところを測ると、忠実に半分づつ電圧が低下していく。間違いないだろう。しかし、何故こんなに高いのか。

 DVMのケースの実装が完成した。キットについていたケースは、偶然にも現在のSparkFunのガイガーカウンターと全く同じケースである。これに入れるのも芸のない話なので、もう少し小さいケースに入れようと探したが、なかなか適当なものが見つからない。電池(006P)とロータリースイッチが意外とかさばり、小さくまとめられない。結局、最初のケースよりほんの少し小さい、タカチの透明ケース(PB2 110×80×33)でがまんする。

S_p8134099 ロータリースイッチで、電圧のスケールが換えられることを確かめる。うまく動いた。ここまできたら、やっぱり数字の下にドットを表示させたい。説明書には、このドットの点け方が載っている。これが微妙な書き方である。このLCDは設計が古く、液晶を交流ドライブしている。従って単に電圧をかけるだけでは、液晶が劣化してしまう(今のLCDにはコントローラーが内蔵されていて、この配慮は不要)。

 説明書には「ドット焼けを起こすけれど移動させなければ制御ラインを0にすればOK」って書いてあるが、これってやっぱり焼けてしまうことを言っている。ドットが移動するDVMでは、これでは点灯していないドットが焼けてくるので、いずれはどこのドットの表示かわからなくなる。

 これを回避する正式な方法が説明書には出ている。しかし、このEX-OR回路が良くわからないのである。理屈が理解できない。ウェブをさまよって、遂にロジックを見つけた。LCDのベース電位が50Hz近辺(オシロで測ったら47.7Hz)で0,1に動き、ドットの点灯用のロジックが逆相(EX-OR)なら、ちょうど-1 +1の交流で点灯、同相なら0Vで、LCDには電圧がかからない(消灯)ということなのだ。

 ドット一つにEX-ORのICをつけるというのも大げさだ(基板にはスペースを確保したが)。何か上手い方法はないかとあれこれ思案する。このあたりが面白いところである。逆相なら単にインバータだけで良い。同相にするならドライブ(バックプレーンBP)端子をFETか何かでつなげばよい。この2入力を切り替えれば、EX-ORと同じロジックができる?

 あ、ドットはロータリースイッチで切り替えるので、同相は不要だ。BPにインバータをつければ良いだけではないか。早速ブレッドボードでインバータを持ってきてオシロで測る。見事、BPの逆相が得られた(あたりまえか)。

S_p8114098

 これをDVMのドット表示ピンに与える。よーし、ドットが表示された。こりゃ何もインバータ(74HC04)も持ち出すことはない。トランジスタ1石で十分だ。これもテストする。問題なし。いやあ気分が良い。

 これは後日談があって、組み上げてみたら、ドットが最初つくがすぐ消えてしまう。説明書にはグランドをテスト端子にしているので、そうしてみたがやはり同じ。ふとした弾みで、トランジスタのグランド側を触るとドットが消えずに残った。

 あれこれいじって解決したのは、インバーター(トランジスタ)のアース側を浮かすことだった。どうもLCDとのグランドの関係が良くわかっていないので、あまり気分の良い解決ではないが、そのままにした。まあ、こわれてもトランジスタ一ヶなら悔しくない。

とうとうSparkFunのガイガーカウンターが動かなくなった(8/14/2011)
 遂に、SparkFunガイガーカウンターが息を吹き返さなくなった。やっぱり高圧発生回路の不具合のようだ。電圧が全く上がっていない。まだ元気な時、苦労して10μFのチップコンデンサーをはずし、SparkFunの掲示板にあったように1μFにとりかえた。電圧は800Vまで下がったものの、まだ高い。しかしこの電圧では不思議なことにGM管は動作しない。電圧計がおかしいのか。

 ところが、元のコンデンサーを戻し、電圧が回復した(1500V近辺)のも束の間、ローソクの火が消えるように電圧が下がり始め、このあとは何をやっても回復しなくなった。コンデンサーを換えるストレスが何かのスイッチを押したらしい。このあとは全く目覚める気配がない。

 やれやれ、代替品を用意してあるにしても、動かないとなると気分が落ち込む。ガイガー管がこのキットの価格の大半を占める($154のうちの$94で2/3、¥7200)ようなので、ガイガー管(LND712)をはずし、高圧回路の基板を作り直すか、高圧回路をはずして(トランスがやけに大きい)、ここに別のインバーター基板でもつければ、今までのMega328まわりの修正は生かせるが、どちらにしても気が重い。まあ、原因が特定できただけでも、この1週間の電圧計の工作は無駄ではなかったと、自分で自分を慰める。

CHANEYのガイガーカウンターはあっけなく稼動(8/14/2011)
 思いは残るが、SparkFunのキットにこだわるのはこれくらいにしておこう。LCDを動かすためにMaga328から多量のピンを引き出した基板を簡単に捨てるわけには行かないが、このままでは先に進めない。

 高圧発生回路そのものの解析が必要である。この回路、色々なウェブの高圧回路を見ているが、どこにも同じ例がない。トランジスタは日本製ではないので、代替品が難しい。特に、オーディオトランスをドライブする高耐圧(300V)トランジスターは手持ちにない。解析の足がかりに不足している。少し休もう。

 となると、次は、届いたまま何もしていないCHANEYのガイガーカウンターキットである。早速組み立てにとりかかる。親切な3枚の実体配線図つきの説明書があるので、組み立ては至極簡単である。

S_p8144105 とりかかって小一時間で半田付けを終える。早速通電。よし、スピーカーからクリック音、青いLEDが瞬いて正常に動き始めた。例のマントルを近づけると派手な音と点滅が始まる。間違いない。正常に動いている。

 手で測ったところでは、いつもの地下室で20~28CPM、SparkFunのLND712が12CPM程度だったから、ウェブの情報どおり、2倍ほど感度が良いようだ。電圧を測る。いかん、LEDが点きっ放しになる。それでも300V程度は観測できた。

 今度は、この基板からデジタル出力を出す方策だ。9Vのバッテリーも邪魔なので、これまでのエネループを利用し、DCDCコンバーターで9Vに上げてやろう。CPUは同じMega328を使ってやろう。ちょうど面実装のMega328の予備がある。

SparkFunの故障の原因は異常寄生発振か(8/17/2011)
 結局、SparkFunのガイガーカウンターキットはその後も息を吹き返さない。時折、電源を入れた直後、1000V近くまで電圧が上がるが、すぐ電圧は下がり始め、今度は何時間ONしたままでも5Vから上に上がらない(以前は、急に戻ったりした)。

 測定した電圧が1400Vというのが正しいとすると、共振による異常発振(テスラー発振?)かなにかで倍の電圧が発生し、これにより出力トランジスタが破壊されたという仮説をたてた。これを裏付けるためウェブで色々探すがめぼしいものは見つからない。

 超高圧というと必ず出てくるのが、磁気の単位にもなっているテスラーである。彼に関してはオカルトっぽい話が沢山あって暫くこれに熱中した。1980年代にテスラーの研究を元に超高圧を研究するグループが、300キロもある変圧器が浮上させたとか、通常の反応では作れない合金が出来たとか、米軍がこの研究成果を全部独占して、これをなかったことにしようとしているとか(ハチソン効果)、どうも眉唾ものなのだが面白い。

 もっとすごいのになると第二次世界大戦当時(テスラー存命時)、超高圧をかけてレーダーから姿を隠す実験をしていた米軍駆逐艦一隻が瞬間移動したなどという(フィラデルフィア実験)、とんでもない話まである。ウェブはこういう話は大好きなようで、情報が溢れており、見始めるときりがない。本題の異常発振の解明は先に進まない。

 それはともかく、この先の具体的な方策を決めなければいけない。GM管は無事なようなので、基板をそのままに発振回路の部分を作り換えるか、CHANEYの基板をここに持ち込んで、新しくCPU基板を追加するか。

 色々な選択肢があるので迷う。それにしても、SparkFunのキットはどこが壊れたのだろう。外見上は、全く変りはない。Mega328から引き出したLCDへのソケット基板をこの高圧のドライバー回路の上に瞬間接着剤で固定しているのが悪いのかもしれない(接着剤は高絶縁体と思っているが)。

 壊れて元々である。接着剤をカッターで削り(結構丈夫についている)ソケット基板をはずして、配線パターンを出してみた。期待は空しく状況は全く変わらなかった。もっともパターンの溝まで削らないと意味がないかもしれない。

 そのうち、有力な情報を見つけた。リンギング発振(寄生発振)で高電圧を出しているページである。 ベースの周波数とは全く違う高い発振を起こさせ、簡単に2倍、3倍の電圧が出るという。もしかすると、SparkFunの発振回路は、これを起こしていたのではないか。この高電圧で、出力トランジスタの耐圧が不足して壊れたのかもしれない。

 いや待て、この回路は、ステップアップトランスではなく、単にインダクタンスだけなので、そもそもこのリンギング発振で高圧を出しているように見える。ただ、それにしても、どうして出力電圧が想定より高くなったのだろうか。よくわからない。

 DVMが測った電圧が正しいとすると、高圧で壊れる部品を考えると、やはりICが一番こういうのに弱いはずだ。トランスをドライブしているトランジスタを換えれば復旧するかもしれない。このトランジスタの型番はMPSA42である。

 アメリカでは定番の石らしく、オーディオアンプのドライバー部やLCDディスプレイの水平出力に使われている。コレクターエミッター間の最大電圧が300V、最大コレクタ電流が0.1Aのいわゆる高耐圧トランジスタと言われるやつである。

 互換品はいくらでもあるが、みなTO92とかTO126などのごついやつばかりで、今のキットについているSOTサイズのものは手に入らない。まあいずれ大きいものでも良いから手に入れてテストしてみよう。値段はどれも¥100しないから気が楽である。やることが色々増えてきた。

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

2011年8月 5日 (金)

SparkFunガイガーカウンターに操作ボタンをつける

USBと電池切り替え回路の改良(7/28/2011)

S_p8054061 ブログに記事を上げてから、ずっと気になっていたことがある。SparkFunのガイガーカウンターキットに手を加え、電池駆動で動くようにしたのだが、USBをつないだとき、USBバスに電池の5Vが入りこまないよう、FETで電池からの供給を止めるのは良いとしても、逆に電池の電源をレギュレーターの前のスイッチで切るとレギュレーターの入力側が0になるのに、レギュレーターの出力側はFETのソースにつながっていて、ドレインはUSBの5Vがつながったままになる(ゲートは0Vだが)。

 最初、回路が出来たときドレインからソースへ電流が流れていなかったので(誤測定だった)安心していたのだが、ウェブの記事を見ると、FETは内部的にドレインからソースに順方向の寄生ダイオード(Body Diode)が入っている。それなら、ドレインの電圧はそのままソースに反映されてしまうはずだ。電池ならさほど問題ないが、レギュレーターはまずい。本来ならもうひとつFETがいるところをさぼっている。

 ぐだぐだ言っているより、試してみたほうが早い。出来上がっているのをテストするのは、GM管の高圧が近くにあって怖いので、ブレッドボードに新しく2SJ377をブレッドボード用にハンダ付けして、テストしてみた。

S_p8054076 おお、やっぱり心配していた通りだ。ソースに何もつながないで、ドレインに5Vをかけるとソースは4.5V近くを指す。レギュレーターをつけると電圧は2Vくらいまで下がるが、電流は直結のときと同じ0.6mAが流れ込む。何だFETというのは遮断の役に立たないのか。レギュレーターをはずし、4.5Vかかっているドレインに試しにLEDの負荷をつけると、同じ程度に電圧は下がったが、電流は殆ど流れないので点灯はしない。接続されたレギュレーターは全く熱も持たないが、やっぱり心配だ。FETは電池からUSBバスに導通するのは防いでいるが逆はだめなのだ。

 本来の回路に2つFETがあったのは、この逆流を防ぐためだったのだ。この場合は、FETが対称に配置されるので、USBからの電流は、電池へ流れ込まない。しかしFETを追加するには、電源小基板のスペースはもうない。幸いダイオードくらいなら入る余地があったので、SBダイオード(1S4)を、レギュレーターとFETの間に入れた。よーし、これでレギュレーター出力での電圧は0.5V以下に下がった。ただ、レギュレーターからの電圧は、5Vから4.7Vに低下した。まあ、これは仕方がない。

 逆流電流は0.6mAくらいなので、もしかしたらレギュレーターは大丈夫(内部の逆接続防止ダイオードが必死に支えている?)なのかもしれないが、正規外の状態であることは間違いない。まあ、これで安心して眠れる。いやいやそれにしてもアナログは難しい。(前回記事の2つの回路図は、この修正が反映されています)

S_p8054084やっぱり屋外で平均値が見たい(7/30/2011)
 今日は久しぶりにテニスをやってきた。雨を覚悟していたのだが、結局、降らず。真夏にしては快適にテニスが出来た。雨模様で参加者が少なかったので、順番が早く廻り、ほとんどプレイしっぱなし。さすがに疲れた。ガイガーカウンターをテニスコートに持っていくのを忘れていた。自慢できなかったのは残念だったが、このところ、ことあるごとに持ち出しては測定の機会を増やしている。

 週2回出かける事務所は日本橋にある。ここでの平均は、ビルの3階のせいか自宅よりやや少ない放射線量である。ある政党の調査結果によると、東京都内は東部にかけてかなり高くなるという。確かに事務所近辺の地面近くでは一気に線量は増える(0.1μSv/hを常に超える)。といっても、まあ、海外旅行を1回した程度の線量だ。大騒ぎする量には程遠い。

 ある場所を測定したあとは、最寄のPCにつなぎ、蓄積値(平均値)を出しているが、やっぱり蓄積データをリセットして個別の平均値をだす操作が出先で自由に出来ないと、使い勝手が悪いことがわかる。頭で考えるより、こういうフィールドテストが操作仕様を決める最善の方法だ。ということでやはり、タクトスイッチをつけてガイガーカウンターをボタンで制御できるように改良することにした。

 そのためには、スイッチだけでなく、CPUチップからさらにI/Oピンを引き出す必要がある。引き出した線の固定やスイッチの実装も考えなければいけない。最初は今までの工作と同じスタイルで、パネルにあけたLCD固定用ねじを使って付属追加基板を固定し、そこにスイッチを実装しようとした。しかしフロントパネルにスイッチの穴を開けると、ちょっとした雨でもケース内に水が入ってしまう。

 すでにUSBのコネクターの穴が横に空いているので、防滴仕様にもなっていないが正面に穴があくのはやっぱり避けたい。ということになるとタクトスイッチはパネルにネジで固定しなければならない。あいにく部品箱にはネジで止めるタクトスイッチの在庫がないので、部品の調達が出来るまでハードの工作は一休みである。

ATMega328の全部のピンを引き出す(8/1/2011)
 仕事の帰り、久しぶりに秋葉原に出る。秋月、千石界隈は、相変わらずメイド喫茶の客引きが煩わしい。目立ったところでは、定点観測しているSDカード2GBの値段が遂に¥300を切った(¥250)ことと、安売りショップにやたらとガイガーカウンター売出しのポップが増えたことである。大抵のショップには1つや2つの案内がある。値段はウェブ上と同程度だが、一時に較べると安くなった。この分で行くと秋には、完成品でも1万を切るかもしれない。

S_p8024056

 今日の買い物の中心は、やっぱりガイガーカウンター関係である。パネルに直付けするタクトスイッチをまず探す。タクトスイッチは、ねじでパネルに固定し、しかも小型のものというと意外に種類が少ない。下の電池や基板に干渉しない、低背(ローハイト)のものを探すが、見つけられなかった(結局、千石で前と同じようなものを買う)。

 次は、1GΩのいわゆるハイメグ抵抗(これはタクマンの商標らしいが)と、秋月のDVMキットである。これはガイガーカウンターの高電圧測定が目的である。我々が取り扱える高圧は、微小電流が殆どなので(大きければ命にかかわる。こんな呑気に扱えない)、相当高い抵抗で分圧しないと正しい測定ができない。

 このSparkFunのキット、たまに長時間パルスを出さない(暫くすると何事もなく復帰)ときがあり、原因がGM管か高電圧発生回路か特定するために準備している。もともと高入力インピーダンスの電圧計は前から欲しかった計器でもある。

 ウェブの情報では、秋月のDVMキットが一番安価で手軽のようなので、電圧計の方は心配ないが、フルスケール0.2Vの電圧計で1000V近い電圧を測るのには、ギガを超える分圧抵抗が必要だ。これもウェブ情報にもとづいて、高電圧用の特殊部品専門店という山王電子というラジオデパート2階のショップに行く。

 タクマンの1GΩ(¥850、誤差1%のものは¥1000、1%のものは千石の方が安かった¥920)を手に入れる。どうせ校正しなければいけないので5%の安いほうを選ぶ。秋葉原特有の偉そうなショップの親爺だったが、感心なことに抵抗を素手では触らなかった(指紋の油でリークするらしい)。

 家に帰って、高電圧測定はあとにして、タクトスイッチのハードウエアを準備する。キットのMega328はLCD用に6本I/Oピンを出したが、さらに2本は余計に必要になった。この際なので、使うあてはないが、いっそのこと残っている全部のピンを引き出すことにする。

 空いているI/Oピンは6本である。受け側も用意しなければいけない。これまでの2ミリピッチのピンヘッダーの小基板を作り直す。0.8ミリピッチCPUチップからの引き出しは大分慣れてきて、ほどなく全部引き出し終えたが、問題はこの小基板への接続である。

S_p8024049 これまでのLCDの8本(Vcc、GNDを含む)に加えて6本、あわせて14本のソケットへのハンダ付けは、欲張ってこの小基板にタクトスイッチ用のプルアップ抵抗までつけたものだから、ちょっとした手品のしかけを作るような気分である。2段になったピンソケットへのハンダ付けの手順をあらかじめ確認し、ピンセットで慎重に0.2ミリのUEW線を、2段になったソケットピンの位置に合わせて切りそろえ、先端をハンダあげする。 

 始める前は、本当にこれで全部ハンダ付けできるか自信がなかったが、やってみると意外にうまく行った。こういうときのハンダは、みんなが推奨する日本アルミットのKR-19ではハンダの流動性が高すぎて、むしろ以前まで使っていたGootの普通の糸ハンダの方が仕上げが綺麗に出来る気がする(これに慣れているだけかもしれないが)。

 全部の配線を終わった。恐る恐るソケットを定位置に戻し、テストする。良かった。LCDがちゃんと動いた。新たにつないだ線も、チップのピンとソケットの導通テストでちゃんとつながっていることが確認できた。全部出来たとなるとすっかり気が抜けて次のステップに進む気力を失う。

タクトスイッチをつけてハードは完成。残りはソフトの開発(8/2/2011)
 自分は左利きだが、タクトスイッチは右利き用にLCDの右側につける。5ミリの穴2つである。念のため養生テープをつけたので、気楽に3.3ミリのバイトで大きなドリルを使って開けたら、しっかりずれてしまった(キリで下穴をあけていたのに)。気を抜くとろくなことがない。リーマーで何とか揃える。

S_p8054082

 スイッチのプルアップ抵抗はソケット基板に既につけてあるので、3本のコードをハンダ付けするだけで、スイッチをつけてしまえば、ハードウエアの作業はあっけなく終わりである。次はソフトである。スイッチ制御は、何度もやってきているので簡単に考えていたが、仕様を確定するのに少々手間がかかった。

 ボタンだけのユーザーインターフェースは電化製品では珍しいことではないが、使いやすいボタンのインターフェースというのには中々お目にかからないものだ。マニュアルを見直さなければ時刻合わせも出来ないデジタル腕時計や、何度やってもやり方を覚えられないPCビデオモニターの設定スイッチ、押しているうちに、何故か必要もないのに必ず統計ページが印刷されてしまうレーザープリンターなど、使いにくい例をあげだせばきりがない。

 使いにくいボタンインターフェースに共通することは、個別のボタン(スイッチ)の機能がフェーズによって変わってしまい、固有のシーケンスを覚えていないと操作が出来ないというやつである。何とか使えるのは、それぞれのボタンの機能が整理され、しかも個別のボタンの役割が固定されていて、全体の機能が階層的に整理されているインターフェースである。

 今度の場合はボタンは2つしか使わない。うまく機能を配分しないとわけがわからない操作になってしまう。ユーザーインターフェースの設計は所長のかっての専門分野でもある。これまでの経験を生かして使いやすいものにしないと笑われる。色々考えた結果、ガイガーカウンターのボタン設定は次のように決まった。

Aボタン(セレクト機能)  ボタンを押すたびに、表示が移動平均値->累積平均値
               ->累積データ消去選択-> と循環する。

Bボタン(決定機能)  Aボタンで選択する局面ごとに、その局面で行う処理を決定
              するボタン。
              この機械では、Aボタンで累積データ消去選択を選んだとき
              だけ機能する。
               ただし、消去のような重要イベントの時は、確認を促す
              表示が出て、再度Bボタンを押すことで、それが実行
              されるものとする。

               このとき、Aボタンを押せばキャンセルとなる。

      なお、Aボタンで表示するだけのフェーズのときは、Bボタンは機能
      させない(ここで欲張って何か機能を持たせると操作性が悪くなる)

 こういう仕様を決めるまでが、本来一番時間をかけるべきところである。良い加減な仕様でプログラムを書き始めてから、プログラムに合わせて仕様をいじると大抵使いにくいものが出来上がる。と、能書きを垂れながら、コーディングを開始する。

 こうして宣言しているのは、ともすると安易に流れて仕様をいじることをやらないよう自分に言い聞かせるためでもある(何度も失敗している)。

擬似コーディングの勧め、再び(8/3/2011)
 コーディングは例によって、擬似コーディングから始める。擬似コーディング(Pseud Coding)が何度も当ブログに登場するのは、電子工作の世界で、ソフト開発の不得意な人が意外に多いことに気づいたからである。上から目線でちょっと僭越だが、みなさんソフトウエアを少し気楽に考えすぎていると思う。

 LEDの点滅とか、"Hello World"のLCD出力くらいなら、いきなりコーディングして何の問題もないが、C言語でステップ数が200を越えるあたりからは、周到な準備を事前にやって開発にかからないと完全な動きをするプログラムを完成させることは難しい。

 もちろんこの世界にも向き不向きがある。1000ステップを越すプログラムを楽々とドキュメントもなしに完成(バグなしということ)させる人がいるが、こういう人と自分を一緒にしてはいけない。

 今はもう別の会社に吸収されたが、Delphiや、Turboシリーズで有名なボーランド社のフィリップカーン社長は、Pascalコンパイラーのソースを全部記憶していて、何かエラーが起きるとたちどころに修正点を指摘できたそうである。ここまでいかなくても、いわゆるハッカーと呼ばれる人たちは大抵常人を超えた能力を持っている人たちである。この人たちを真似ようと思ってはいけない。

 こうした名人達に、我々凡人が対抗できる数少ない手段が擬似コーディングだと思っている。プログラムの動きを普通の自然語(我々なら日本語)で徹底的に記述し、矛盾点を洗い出す。

 矛盾するところがなくなったら、これを少しづつコンピューター言語に移していく。この手順を踏むことで、プログラムがどれだけ複雑になってもメンテナンスが可能になる。もちろんプログラム開発には、言語に特有の文法や、モジュール構成とか、構造化するとか専門的なテクニックを多々求められるが、これは必要に応じて身に着けていけばよい話だ。

 肝腎なところは、バグのない(論理矛盾のない)プログラムをいかに作るかで、それは自然語である日本語でも、プログラム言語でも基本的には変りはない。このあたりをおろそかにして開発をコーディングから始めると、大抵の人はバグを取りきれずに挫折してしまう。

S_p8054073 擬似コーディングの例は、これまでにいくつか(ここや、ここに)お示ししているが、ただ形や決まりにこだわることは無意味である。自分が納得するまで紙の上で何度も書き直して(アートワークと同じで、ボールペンより鉛筆、消しゴムがおすすめ)、ロジックを整理することである。

 開発したソフトウエアが思ったとおりの動きをするのを見ることは、もの言わぬ小さな部品を集めて特定のハードウエアを作り上げるのと全く同じ喜びである。電子工作の醍醐味のひとつだ。これを読んだ方々が、擬似コーディングの手法でソフトウエア開発のレベルを少しでも上げられることを願っている。

操作ボタンをつけたガイガーカウンター完成(8/5/2011)
 てなことを書きつつ操作ボタンの開発である。擬似コーディング数枚を費やして、ガイガーカウンターの操作ボタンのソフト開発は終わった。タクトスイッチの制御は、ピンチェンジ割込みをトリガーとして、ボタン処理ルーチンで一手に行う。ここではチャタリングの待ち時間を入れたあと、スイッチの押下でディスプレイモードを切り替え、そのあとの表示ルーチンで、モードに応じたLCDの画面を用意する。

 表示タイミングは1秒ごとか、状態が変わったときなのだが、今度は、スイッチで表示モードが変わるというタイミングでも表示しなければならない。最初の擬似コーディングでは、このことを考慮していなかったので、1秒ごとにLCDがチラチラし見にくい。

 本来はもっと前に戻るべきなのだろうが、ずるをしてフラグ(表示モード変更フラグ)を追加し誤魔化す。ちょっとフラグが多すぎるなあ。UARTも残してあるので7ヶもある。余り褒められたコードではない。

Photo それに誤算がもうひとつあった。AVRのピンチェンジ割込みは、立下りや立ち上がり、レベルなどの割込みのモードが指定できない。ロジアナで見ると、このタクトスイッチは押すときも離す時も派手なチャタリングが出るので普通のロジックではまともに動かない。

 仕方がないので、チャタリングを待つ時間は割込み禁止にして割込みフラグをクリアしてから割込み許可にする苦肉の策をとった(main.cの239行付近)。やっとこれでボタン操作が落ち着く。それまでは、いきなり確認ボタンを2つ連続して押すようなときがあって使い物にならなかった。

 まあ、それはともかく、SparkFunのガイガーカウンターは、ほぼこれで完成形に近づいた。ピンは余っているし、フラッシュはまだ10KB以下なので、RTCでも何でもつけられるが、こればっかりやっているわけにもいかない。それより、このガイガーカウンター時々、高圧が出なくなるのかGM管そのものなのか、時々計測不能になる。デジタル電圧計(DVM)の開発を急ごう。

ここにボタンで制御するSparkFunガイガーカウンターのソース一式を置きます。回路図は前回のものに、PD4、PD5にタクトスイッチを追加しただけなので省略しました。
8/5/2011に公開したソースにバグがあったので修正した版を以下に掲載します(EEPROMをボタンで消去するとデータが蓄積されない)  8/7/2011

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

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

2011年7月26日 (火)

ログ機能を持ったSparkFunガイガーカウンターのソース公開

内蔵EEPROMでも実用的な量のデータ保存ができる(7/18/2011)
 SparkFunのガイガーカウンターキットは、データを残すのに内蔵EEPROMでは小さすぎて現実的でないと思っていたがフラッシュROMを外付けしなくても、結構実用レベルまでログを溜められることがわかった。

 勘違いをしていた。最初はGM管のパルス間隔時間を記録することしか考えていなかったので、Mega328の1KバイトのEEPROMでは、僅かの時間(30分くらい)しか記録できないと思っていたが、パルス幅でなく1分ごとのパルス数(CPMそのもの)を記録することにすれば、1バイトづつ(256CPMまで)だと、17時間分も蓄積できる。

 1バイトを越える256CPM以上というと、18μsV/h以上ということだ。この数字は年間では157mSvというとんでもない値で、とてもこんな悠長なことはしておれない事態だが、測定器でこれ以上が測れないというのはもっと不安である。どんな大きい数字でも記録できないといけない。

 ということでデータサイズは2バイトにする。これでも512分(正確にはポインターが必要なので508分)、8時間以上残せる。その都度、平均も出すようにすれば、同じ場所に30分ほど置くだけで、その場所の環境数値らしいものがとれる。

 早速、プログラムの改修にかかった。EEPROMの操作は、4年近く前、初めてAVRを使って温度ロガーを開発したときに、EEPをストリームのように使えるライブラリを作ってあるので開発は楽だが、貯めたデータの表示や、消去したりする操作が自由にできるようにしなければならない。

 タクトスイッチかUARTで、こうしたユーザーインターフェースを実現していくわけだが、タクトスイッチはハードがからむのですぐには無理である。ということで、UARTの受信機能を作り始めた。USBを差せば仮想UARTコンソールが動く。当面はUARTのキーボードから指示を出すので十分だ。LCDと違って沢山のデータも出力できるし、画面をCOPY&PASTEすれば、PCですぐグラフ化も出来る。

UART受信が動かない。ロジアナの極小プローブを使う(7/19/2011)
 幸いオリジナルのソースにはUART受信関数がついており(使っていないが)、これを使ってコマンド入力機能を作る。ところがこれがうまく動かない。データシートを何度も見直し初期化のソースコードなどを調べるが、ガンとして動かない。割り込みもバッファーも何も使わない単純なUART受信関数である。コードの上ではもう調べるところがなくなった。

 通信機能というやつは、ALL OR NOTHINGで動かないとなると難儀である。どうもこれはハードを疑うしかない。USBシリアルアダプターのFT232RLから入るMega328の受信ピン(PD0)の信号をロジアナ(Zero Plus)で見ることにした。

S_p7234036 このロジアナは標準プローブでも0.8ミリピッチを挟めるそうだが、ここは販売元のお店(ストロベリーリナックス)が、少し高い製品以上に(LAP-C16128)におまけにつけている、0.5ミリピッチでも挟めるという極小プローブを使う良い機会だ。

 これだけでも買えば一万円以上するという触れ込みのプローブである。ケースから、プローブをとりだす。買った当座、ケーブルをつけておいたが、あらためて見てみるとこれは本当に小さい。ピンに挟み込むには拡大鏡なしでは無理である。ヘッドルーペをつけて送受信ピンに取り付ける。

 測定の結果は予想通りだった。受信ピンにPCからのデータが来ていない。これまでのピンの引き出し工作で不具合が起きたのだろうか。いや、ハンダ付けしたところはUARTピンから遠く離れている。この基板はFT232RLでUSBとつないでいる。ここがおかしくなったのだろうか。いや問題ない。

S_p7234034 あれこれ悩んでいたが、動かない原因は意外なところだった。PCのUARTコンソールのフロー制御だったのである。これを「なし」にすると全く問題なく動いた。えー、送信はフロー制御(ハードウエア)を設定していてもちゃんと動いている。それなのにどうして受信だけが駄目になるの?FT232RLの初期設定の関係だろうが、人騒がせな設定である。

EEPROMに多バイトデータを1バイトづつ記録するのは難しい(7/21/2011)
 とにかく、動けば問題ない。EEPROMのソースコードは、これまでのライブラリを少し手直しして使う。EEPROMサイズを512バイトから1024に広げるだけである。書き込みのタイミングは、1秒毎の処理イベントルーチンでカウンターを回し、1分単位にEEPROMにパルス回数を書き込む。難しい話でも何でもない。コードとしてはすぐに完成したが、正しいデータがEEPROMに入っていかないのである。0データしか入らないのには弱った。

 今度のデータサイズは1バイトではなく、2バイトバイナリーである。多バイトのデータ蓄積は結構厄介で、EEPROMはリングバッファー的に使うので、アライメントを合わせてやらないと折り返しでおかしくなる。そんなことより4バイトのバイナリーデータから、2バイト単位にデータを入れていく過程で既に正しいデータになっていない。

 ちょうど良い機会なのでC言語のキャストをあらためて勉強する。その結果、キャストについては基本的な間違いをしていたことがわかった。キャストをアセンブラーのアドレスポインター的に考え、4バイトデータを1バイトキャストするというのは、頭の1バイトが入るものだとばかり思っていたが、そうではなかったのである。

 しかも、リトルエンディアンか、ビッグエンディアンを考える必要はないのだ。AVRはリトルエンディアンなので、完全に頭からと考えていたが、キャストはあくまでも算術的にデータをとってくるだけである。実際のデータの位置には関係ない。そのとおり(ビッグエンディアンとして)ビットシフトの演算をしてデータを入れていけばよいということがわかった。

 理屈がわかったあとは早かった。手探りで良い加減に入れていたときとは段違いにバグが取れていく。フューズビットも書き換えてデバッグの度に既存データが初期化されるのを防ぐ。ほどなく、オープンして書き込むと次々にデータを追記していき、READするとデータを最初から次々に吐き出すしかけが完成した。

Eep_output とりあえず、ダンプ機能(頭から全部吐き出す)と、EEPROMのフラッシュ(全消去)コマンドを作って動かす。本当は、シーケンシャルファイル風にデータのセッションを分けたいのだが、リアルタイマークロックがないので余り意味がない。機能の拡張は当面先送りである。

USBとバッテリーとの電源自動切り替え(7/22/2011)
 USBがつながるときは、電池からの電源は切っておかないとUSBに悪影響が出る。今は、電池とUSBの給電は単につながっていて何の対策もとっていない。USBがつながった時には、自動的に電池からの供給が切れるような回路を作れば、このことに気を遣う必要はなくなる。FETかなにかでスイッチしたいところである。

 実は、この機能はウェブの情報(掲示板で時々おみかけするgomisaiさんのサイト)を頼りに、ブレッドボードで回路を作り既にテストしていた。オリジナルはFETを2つ使っているが、USB側からの電源分離をSB(ショットキーバリア)ダイオードにしてしまえばひとつ減らせる勘定だ。

Usb_bat_fet

 ブレッドボードのテストではうまくいった。ただ実装はためらっていた。電源小基板にもうスペースがなく、他に追加したい部品があったからである。(掲載の回路図はあくまでも素人の回路です。自己責任でお使い下さい。)

 まあ、電池の電源が、USBバスに重畳しても、そう大きな障害はないと思うのだが、万が一、PCのUSBインターフェースに悪さをして壊してしまうようなことが起きると、PCのマザーボード取替えなどという大げさな事態になりかねない。ここは慎重に考えた方が良い。

 それより、今のままでもUSB給電時は、バッテリー側のレギュレーターの出力側が、5Vに曝されている。心配なので電流計を間に入れてみる。0.6mAの電流がUSBからレギュレーターに向けて流れていることがわかった。この程度では、レギュレーターは全く変化はないが、いずれにしても出力側が入力側(0V)より恒常的に高いと言うのはレギュレーターにとっては嬉しくない。

 電源を切った時、出力側のコンデンサーに残る電荷をダイオードでシャントする回路があるくらいである。がた老AVR研究所にはレギュレーターのたたりもある。FETをこのあいだに入れれば、少なくともUSBからの電圧がレギュレーターにかかることはない。早めに作りこむことにした。

 しかしこの実装は、実は結構面倒なのである。USBからの5Vを基板上で分離しなければならないからだ。基板上のUSBソケットの電源パターンは見たところ1本だけで、ここを切れば分離できそうだが、ソケット下のパターンはわからない(裏面には行っていないようだ)。

 ただ、嬉しいことにこのSparkFunのキットは、Eagleの回路図データと基板データがクリエイティブコモンで提供されている。基板データ(.brdファイル)を見て、USBコネクターから出ているパターンを切るだけで分離できることが完全に確認できた。これは助かった。

 電源小基板との接続は、既にピンとして用意されているリセットピンを流用することにする。リセットピンを外で使う可能性はもう殆どないだろう。この接続をやはりカッターナイフで切り離し、リセットピンにUSBからの電源をUEW線で接続する。出来た。ここまで出来れば、あとは小基板での配線だけに専念できる。予想より楽に出来そうだ。

 小基板では、折角つけた日圧(JST)2ピンコネクターをとりはずし(ピンヘッダーをつけたので必要性が薄れた)、その空き地にFETとダイオードを組み込む。小さい基板のハンダ付けは結構面倒くさい。それに手持ちのFET(2SJ377)がリードタイプでなく、表面実装パッケージなのでリード線をつけなければならず難儀した。

S_p7234046

 何とか組み上げる。ブレッドボードでテストしたとおり、USBの電源が入ると、バッテリーからの電流は、FETできっちり遮断された。レギュレーターにも電流は流れ込まない(テスターで確認した)。完全を期するならバッテリー出力にもダイオードを入れたいところだが、バッテリーの方の電圧降下は嬉しくないのでやめた(追記: 心配なのでこのあとダイオードを追加した。また回路図でFETの方向が誤っていたので修正した。2つの回路図とも修正済み 7/28/2011)。

あちこちで測定する(7/24/2011)
 さて、出来上がったセットを色々な場所に置いて、動かしている。USBに接続するときバッテリー電源のことを考えずにできるというのは精神的にとても楽である。USBにつなぎながら、バッテリーをONにしてUSBを外しても、何の問題もなく測定を続ける。オシロで見ると、全くスパイクもなく、0.2Vくらいの差で電源が切り替わる(PCのUSBが5.2V近く出ている)。

 EEPROMの記録機能は、予想通り大変便利である。EEPROMをクリアしてから、測定したいところに小一時間、セットを放置し、そのあとPCに持ち込んで端末を動かして結果をコンソールで見る。統計をとりたければ、何度でも結果をUARTコンソール上に出せるので、適当なデータをコピーしてExcelなどに貼り付ける。

 ダンプした後の全データの平均値を出すようにしたので、とりあえずはこの値で、全体の平均が見える。あちこち測りまくる。家屋内より、やはり屋外が若干だが値は高い。セシウム137を核種とした換算で行くと(0.0073)、室内が0.084μsV/h、これは地下のPCルームも一階も変わらなかった。屋外では門扉の50センチほど上の植木鉢で、0.091μsV/hと少し高い。

 東京都の公式の発表値は、大分前から0.057μsV/h前後と変わらないが、この測定場所は地上18mというビルの上で(都庁の屋上ではなく百人町の都健康安全センタービルでした。失礼しました)、これより高くなるのはおかしくない。

 最近は都内23区の殆どの区が独自に学校の校庭などで環境放射線量の測定値をウェブなどで発表している。当研究所に近いところでは(東京西部)、0.07~0.09μsV/h(地上1m)ということなので、あながちここで測った値はデタラメではないだろう。

Geigercounter728_2011_2

 データのログ機能が入り少し実用性が出てきたので、SparkFunガイガーカウンターの修正部分の回路図とソースコードをこの記事で公開することにする。SparkFunはソースコードと回路図をクリエイティブコモンにしているので、ライセンスはここでもこれにならう(作者名を残せば、複製、配布、改変、商用可能)ことにする。

 ただソースコードの中には、ChaNさんのコンパクトな書式付print関数、xprintfを活用させてもらっている。いつもながらお世話になっているChaNさんにあらためてお礼を申し上げる。

以下に、ソースコードをAVRStudioのプロジェクトフォルダーの形で公開します。LCDは回路図の修正を行わないと動きませんが、EEPROMの機能はオリジナルの回路でも動きます。

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

使い方の説明:
 使い方を、少し説明しておこう。USBをつないで仮想UART(9600bps 8bit 1stopbit、フロー制御なし)を立ち上げると、GM管のパルスが出る度に、LCD画面と同じ10回の移動平均値が出力されていく。このときリターンキーを押すと、プロンプトモードになり、この出力が停止する。

さらにこのあとスペースバーを押すと、EEPROMに入っているCPM値が、

レコードナンバー     CPM値
次のレコードナンバー  CPM値
    ・
    ・
Average: AA.BB CPM 0.0XY uSv/h for ZZ min

と出力される(必ずリターンキーを押してプロンプトモードにすること)。

1分単位なので、レコードナンバーは分で読み替えられる。508ポイント(分)以上蓄積すると、古いものから削除されていく。

蓄積されたデータを消去する時は、プロンプトモードで、f(小文字)キーを押下すると、

EEPROM will flushed Are you sure? enter (Y/y):

と出るので、消したい時は、Yかyを入力すると、

flushed EEPROM
>

でこれまでのデータがすべて消去される。それ以外の文字では、

No action...
>

と表示され消去されない。>は、プロンプトモードであることを表し、再度リターンキーを押すと、.(ピリオド)が表示され表示モードに戻る。画面データをコピーしたい時は、リターンキーを押して表示を止めておけば失敗しない。

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

2011年7月18日 (月)

SparkFunガイガーカウンターキットをポータブルにする

 女子サッカーワールドカップ日本代表初優勝おめでとう。決勝戦は珍しく早起きしてTV観戦したが、これほど感動、興奮したことはこれまでにない。アメリカが点を入れても入れても追いつき、PK戦では余裕の勝利。希望を捨てないことが、いかに大切かを身をもって教えてくれた。津波、原発事故、政治迷走と暗い話題ばかりの日本に大きな勇気と力を与えてくれた代表チームに心からありがとうと言いたい。

S_p7174022 それはさておき、電子工作である。今までのFreeRTOSのプロジェクトはちょっとお休みして、2ヶ月待って届いたSparkFunのガイガーカウンターキットを少し実用的な形にすることにした。みんなに自慢したい気持ちも後押ししている。「電子工作が趣味です」と言っても誰も怪訝な顔をするが、これを見せれば何をしているか理解してもらえるだろう。

面実装のCPUからI/Oピンをとりださなければならない(7/10/2011)
 このSparkFunキットは、ガイガーミュラー(GM)管がストロベリーリナックスのキットのと同じアメリカ製のLND712で、CPUチップがAVRのMega328、USBから5Vを貰い、放射線量に応じてGM管が出すパルスを、USBの仮想UART(FT232RL外付け)を通して01のASCII文字として出力する。表示装置などは何もついていない(あ、LEDが2つあるか)。

 CPUチップはMega328という結構、大きな(Arduinoでも使っている)石なので、色々なことが出来そうだが、基板には空きピンは出ておらず、ピンとして用意されているのは、UARTの送受信ピン、GM管からのパルスTTLとリセットピン、Vcc、GNDだけである。音ぐらいは外付けで出せそうだが、LCDなどの表示をしたければ、表面実装のCPUチップからピン出力を取り出さなければならない。

 別のCPU基板をつければ好きなことが出来るが、それでは折角のフラッシュが32KバイトもあるMega328は何にも使われないままになってしまう。これでは余りにも資源の無駄遣いである。地球資源に優しい(ケチとも言うが)がた老AVR研究所は当然そんなことは考えない。Mega328をとことん使ってあげなければ可哀そうである。

 品物が来る前から構想は考えてあった。当面の目標は電池駆動にして、表示装置を16文字2行のキャラクターLCDモジュールとし、持ち運びが出来るようにすることである。これを今のCPUで実現するためには、I/Oピンを少なくとも6ピン、電源、GNDの2本あわせて8ピンを引き出してLCDと接続しなければならない。

 RTC(リアルタイマークロック)や、データロガーの機能も欲しいが、これは次のバージョンとしよう。余り一度に沢山のことを企むと上手く行かないことが多い。それにCPUがクリスタルで動いていないので、このあたりも改修したいと思っているところだ。

基板のスペースにLCDと接続するソケットを固定する(7/11/2011)
 Mega328のパッケージは、自分でもこの間digikeyで手に入れたTQFP32ピンである。0.8ミリピッチなので、ここにUEW線をつけていくのはそれほど難しくはない。しかし周りにチップ抵抗や、LEDが近接しているところがあるので取れるところは限られてくる。それより引き出した線をどうまとめて外と接続するかが問題である。

 0.8ミリピッチとはいえ、通常の拡大鏡(2倍程度)では細かいハンダ付けは無理で、このあいだSTM32の0.5ミリピッチのバッテリーバックアップピンの切り離しに使ったヘッドルーペ(3.5倍以上)を取り出す。作業机の廻りを片付け、精神を集中して1本づつ引き出していく。このあたりが腕の見せどころである。

S_p7114017 ハンダ付けを終わる度に、20倍ルーペで仔細に確認する。拡大してみると綺麗についたと思っているところも結構暴れていて満足できるところは少ないが、それでも順調に線の引き出しが進み、6ピンまでとれた。調子に乗ってVccとGNDもCPUのピンから取り出す。これで8本。

 LCDモジュールで、ループウェイトかレディ待ちかで議論のあったR/W線をつけるかどうか迷ったが、何か、次ぐらいで失敗しそうな気がしてやめた。へたれである。

 次は問題の線の固定だ。色々考えた末、2ミリピッチのピンヘッダー(Xbee用)を2ミリピッチ基板(秋月で買ったもの)の小片に固定し、この基板小片をスペーサーで基板に固定することにした。

 ソケットを固定するためのスペーサーで手間取る。両方とも接着してしまえば簡単に固定できるが、これでは保守性が悪い。配線間違いなども直せない。せめて基板小片の方はネジ止めしてはずせるようにと、5ミリのスチロールパイプにドリルで穴を空け、セルフタッピングの2ミリねじで固定しようとした。 

S_p7114019

  しかし、スチロールが硬くてネジ山が切れない。丸い割り箸を切って使うと簡単だが見栄えが悪い。変なところにこだわりがある。結局、道具箱で見つけた建材の一部(家具の棚のホゾ?径5ミリ丸棒)をサーキュラーソーで5ミリに切って、そこへ錐で穴を空け、2ミリタッピングネジで止めた。意外に上手く行った。最近の瞬間接着剤(シアノクレート系)は強力になった。

LCDがスペック通りの早さで動かない(7/13/2011)
 接続ソケットとケーブルが出来たのでケースに実装する前に、テスト用のLCDをブレッドボードでつないでテストする。LCDライブラリは、ピンの位置が任意に選べる最新版。しかしこの最新版は、ループウェイトしないレディ待ちする方式なので、待ち時間を適当に入れなおして組み込む。

Ws000001 色別に線を選んで誤配線を防ぐ。ここは前に何度も誤配線したところだ。予想したとおり最初はうんとすんとも言わなかった。ははは、残っていたR/Wラインをグランドに落としていなかった。ジャンパー線でグランドに落とす。よーし、これでめでたくLCDに表示が出た。

 最初、息つくような遅さだったが、待ち時間を徐々に減らして、大体満足できる更新時間になった。しかし、データシートにあるような待ち時間ではとても動かない。40μsは全く無理で、500μs以上の待ち時間が必要である。

 まあ、チューニングは後にして、長時間LCDを出しっぱなしにして様子を見る。LCDモジュールは余り安定性が高くなく、たまにハングアップすることがあるからである。全体の消費電流は30mA。GM管は殆ど消費がないようだ(GM管への電源ON/OFFで変わらないことから)。

 とりあえず動いたがLCDの表示速度が、スペック通りではないのが気になっている。今までは手探りだったが、ロジアナがあるので、こういう外部への出力は簡単に時間やタイミングを見ることが出来るようになった。しかも正確な時間が出てくるので余計気になる。 スペック通りの待ち時間では全く反応しない。40μsどころか、その10倍以上、400μsの待ち時間にしても、コマンドのあとハングする(700μsも必要)。

 最近はLCDをレディ待ちで使うことが多かったので、こんなに待ち時間が必要だとは思ってもいなかった。大体、CPUループで作る待ち時間も良い加減なものが多い。前はカットアンドトライで動けばOKとしていたので気にならなかったのかもしれないが、知ってしまうと気になって先に進めない性分である。

 他の人のソースをいくつか見せてもらう。何い?ちゃんとスペック通り40μsで動いている。ところが、なんと、コマンドのENABLEサイクルがミリセカンドオーダーだ。こちらは、スペック通り、マイクロセカンドのオーダーで、ENABLEパルスを送っている。だから動かないのか。

 その通りにする。待ち時間をスペック通りに短くし、ENABLEをマイクロセカンドーオーダーから数百マイクロ秒(700μsも必要)で上下するようにした。これで上手く行った。そうか。こういうオチだったのか。

 LCDの全体の表示サイクルというのはミリセカンドオーダーなのだ。しかし、考えてみるとこちらの方が遅い。ENABLEの長さは、HとLで2つ変わる(つまり倍で効いてくる)が、コマンドの方は1回だけである。しかし色々いじるが結構頑固で全体でミリセカンド以下にはならなかった。

 今までのテスト用のLCD(秋月「超小型」SD1602)が一応表示されたので、次は、今度の実装に予定している少し大きいSC1602(これも秋月商品)で動かそうとした。ところが、こいつが意外に手間取ってしまった。今度は全部が工作ミスである。いやいや情けない。

 コントラストピンが0Vでは、画面がギラギラするので、コントラストを下げるため、コントラストピンに分圧した電圧をかけようと、ピンそばの抵抗の半田付けをしているうちLCDが表示されなくなり慌てた。どうも熱で隣のグランドの部分の半田付けがゆるんでしまっていたらしい。このピンをハンダ付けしなおして回復した。

 最後のミスは、10Kオームと1Kオームの誤認である。仮止めしてOKになったので、リードを切って正式につけた抵抗が、実は、隣にあった別の抵抗だったというお粗末である。出来上がったLCDはまた画面が消えて大騒ぎになった。いかん。今日は天中殺だ。

ケースの実装とちょっとした変更(7/15/2011)
 少しづつケースの工作の方も進めている。ケースは秋月電子のABS樹脂ケース112-TS(¥120)を使った。アクリルに較べ丈夫で傷つきにくい。電池ケースは4本を2本づつ横に並べるつもりだったが、これがぎりぎりで入らない。1ミリ程度の超過なので最初、両側をやすりで削って入れようとしたが、削っている最中にはたと気がついた。

 1ヶ入りのホルダーを2本連ねようとするから窮屈なので、片側を切り離して電池2本が直接ケースの中で並ぶようにすれば良い!コロンブスの卵である。サーキュラーソーで片側を切り取り電池をつけてみる。余裕でケースの中に入る。LCDの時とは打って変わって快調である。

S_p7174033 電池はエネループを予定している。しかしこの電池の電圧は微妙である。定格は1.2Vだが、満充電時は、1.4Vで1.3Vあたりが長い。Vccを5Vとすると、4本では最初は明らかに絶対定格を越え(5.6V)、長い間5.2Vというのもきつい。といって3本では、常用時は4V以下に下がってしまう。一応測定器ということなので、余り電源電圧は下げたくない。

 迷った挙句、電池は4本として、ロードロップのレギュレーターを入れることにした。これなら問題ないが、電池電圧が5Vを下回ったときにレギュレーターがどうなるか、ちょっと不安は残る。

 さらに、気になっているのがSparkFun基板に2つ付いているLEDの色である。powerが赤、GM管のパルス表示が緑だが、これはどうみても逆だろう。この赤の電源LEDはキットが届いてすぐ、CPUでブリンクするようにしたが、赤が点滅するのは非常に目立つのに、緑はよく見えない。

 暫く考えていたが、意を決してこの表面実装のLEDも交換してみることにした。例の低温ハンダを使う。しかし、ここでも、お馬鹿な失敗を2つやった。最初は、無事2つのチップLEDをはずして、意気揚々と付け直したら同じところにもう一度取り付けている。肩の力が抜ける。今度こそと、取り付け直したら、今度はLEDのひとつを逆さまに取り付けていた。やれやれ。

 電池ケースの固定は、エポキシ系の接着剤を使う。接触面積はあるが、こういう重さがあって、力がかかるところは瞬間接着剤は止めたほうが良いというのが今までのノウハウである。これは固まるのに時間がかかるので、ケースの工作は中止して1日寝かせる。無機質の部品が組み合わさって、段々、ひとつのものの形になって行くという過程は、何度やってもいつも楽しいものである。

ポータブルガイガーカウンター完成(7/17/2011)
 電池ケースの接着を待つ間に、レギュレーターの小基板の工作を始める。ポータブルということなので、電池ケーブルのソケットはちゃんとした日圧の2ピンソケットを使う。最初、主基板とはピンヘッダーでハンダ付けを考えていたが保守性を考慮して、ここもピンソケットにした。

 ケースの上蓋のヒンジをはずしてLCDの工作も始める。LCDは4つのスペーサーをつけたネジで上から固定する。化粧面なので慎重に4つの穴をまず小さいドリルで開け、やすりで調整していく。ここのスペーサーは、最近、近くのDIY店で買った5ミリのABSチューブである。スペーサーは5ミリや10ミリのものも買えば一ヶ¥5から¥10でばかにならない。ABSチューブは1メートルで¥120。サーキュラーソーがあるので切断は問題なく、地球にやさしい(これは単にケチなだけ)。

S_p7174021

 細かい調整(レギュレーターの電解コンデンサーの高さがつかえて、つけなおし)や、USBコネクターをつけるため主基板を移動(エポキシ系の接着力を確認した。元のままでは大きな穴を開けねばコネクターがつかず、泣く泣く移動)させられるなど紆余曲折はまだいくつかあったが、やっとSparkFunのガイガーカウンターキットはポータブルになった。

 持ち運べるようになったので、色々な場所に移動して測定し始めた。すぐに気が付いたことは、やはりデータログが出来ないと瞬間値をいくら測ってみてもあまり意味がないということである。バックグラウンド程度の放射線量というのは、最小と最大の幅が3倍以上あるのは普通で、現在のカウンターは10回のパルスの平均を取っているが、それでもそれくらいの差は出来る。

 すんさんの掲示板にも載せたが、アマゾンで入手した放射線源のキャンプ用のランタンの芯(マントル)では派手にパルスが上がって、このキットが間違いなく放射線を測っていることは確認できた。

Ws000000 東京も、3/15あたりはこれくらいの線量だったようで、まあ、あの程度が続けば問題になるのだろうけれど、このランタンの芯は、別に何の規制も受けていないし、だいたい30センチも離せばもう殆ど反応しない。

 ただ、ここが通常より低いところか、高いところかを判断するには、最低でも1時間程度は連続して測らないと良くわからないようだ。Mega328の内蔵のEEPROMでは1Kバイトしかないのでパルスカウントでは精々30分くらいしか記録できないが、それでもあったほうが良いようにも思える。

 ただ、I2CのフラッシュROMがこのあいだのフォトフレームのために買って沢山余っているし、これを実装してから考えるべきか思案している。これなら何時間でもログが出来る。RTCとGPSまでつければ完全だけれど、どうもこれも余り深入りしたくない気持ちもあって迷うところである。

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

2011年7月 8日 (金)

FreeRTOSマルチタスク対応UARTとガイガーカウンターキット

LCDをはずしてもFreeRTOSが動くようにする。ロジアナ大活躍(6/28/2011)
 FreeROSのセマフォーが解決して、ちょっと一息ついた。たいしたことでもないものに、自分で自分を追い込んで解決に血道を上げる。確かに、前記事で頂いたコメントの通り、自虐趣味かもしれない(少しむきになって否定したけれど)。しかし、単調な日常生活にこれほどドラマを作ってくれる趣味は、ちょっと他に見あたらない。テニスやスキーなどにもドラマはあるが、ドラマを作るためには、多大な精進と肉体を苛めるトレーニングが要求される(これは自虐とは言わない)。

 電子工作の場合は、こだわるものは目の前に無尽蔵に転がっている。盛んに研究されているプログラムライターなどもそうだ。別のライターで書いたからといってフラッシュに2倍のサイズが書き込めるわけではない。書き込みが速くなるといっても、精々数十キロのフラッシュROMにどれだけ早く書けたところでたかが知れている。しかし、みなさんのこだわりようは、尋常ではない。余程面白いに違いない。 

 それはともかく、当面解決すべき課題がなくなり、体の中にぽっかり空き地が出来たようだ。これまでのメモを取り出して、やろうとしていたことを整理し、優先順位をつけながら次のプロジェクトの準備をぼちぼち進め始めた。

P7084013 本来なら、前にも書いたようにUARTのマルチタスク対応なのだが、どうも気分が乗らない。こういうときは手を動かしているのが一番だ。ブレッドボードに臨時に設置していたFreeRTOS用のI2C LCDを次のプロジェクトに備えて外す作業を始めた。

 元のLPCMプレーヤー(テストベンチとしてブレッドボードに常駐)の方に戻し、LCDなしでARM(LPC2388)基板のFreeRTOSを動かそうとした。これが動かない。ふーむ、LPCMプレーヤーはLCDをはずしていても動いていたのに、何故、ARMでは動かない?

 ソースを見て原因はすぐわかった。I2Cの初期化で、LCDからレスポンスが返ってくるのをループで待ち続けている。これは一番確実な方法だけれど、ここはLCDがなくても事情を理解して先に行って欲しい。いわゆるソフトウエアのRobustness(堅牢さ)というやつである。

 必要とされる初期化待ち時間を仕様(300ms)の倍くらいにして、このループをはずす。あれえ、これでも動かない。どうしてだ。傍らを見ると、これまでの解析に使っていたロジックアナライザーが出たままになっているのに気づいた。そうだ、このロジアナ(ZeroPlus 16128)にはI2Cのプロトコルアナライザーがついているはずだが、まだ使ったことがない。ちょうど良い機会なのでロジアナでI2Cの波形を見てみることにした。

I2cinit うーむ、待ち時間を倍にしても、レディにならずにスタックしている。ループを使った元の状態に戻す。何ということだ。10回ほどリトライした後レディになっているが、その時間は増やした待ち時間より短いではないか。

 ちょっと待て、クロックはどうだ。おやあ、2.2μsしかない。このLCDのI2C最大クロックは400khz(2.5μs)のはずだ。これじゃあ速度違反だ。4μsまで下げる(250khz)。

 なんだなんだ。これでも10回近くリトライし続ける。待っているだけではレディにならないのは同じ。おかしいな。元のAVRのLPCMプレーヤーのI2Cをついでにロジアナで見てみる。これは全く問題なくリトライせずに一回の初期化でACKを返している。

 うーむ、どうしてだ。おかしい、ARMでは何故一回でOKにならない。同じ待ち時間なのに、と、さらに調べそうになって、先に進むのをかろうじてやめた。今自分が何をやっているかに気付いた。これはこれくらいにしておこう。セマフォーに続き、本筋に関係のないことに首をつっこみすぎだ。

 愚直に、ARMのI2Cに有限回ループ処理を加えて戦線を撤収した(20回リトライして、動かなければLCDタスクをサスペンド)。これでARM基板のFreeRTOSはLCDなしでも動くようになった。

 それにしても、大枚4万近くをはたいて導入したこのロジックアナライザー(ZeroPlus 16128)が大活躍だ。I2Cのデータの解析(スタートコンディションやデータ解析)がプロトコルアナライザーで大幅に楽になるだけでなく。宣伝にもあるデータ圧縮が素晴らしい。

 電源をトリガーにしても、LCDがオープニングメッセージを出すところまでのデータが取れる。この間2秒以上離れているが、データ圧縮のお陰でメッセージデータが記録出来ている。

Lcdopening サンプリングクロックを10Mhzとするとメモリが128KBなので、普通にデータをとっていれば、2チャンネル(I2C)だけとしても、60msの間しかデータが取れないところである。ロジアナは事象の起きているところを正確に把握することが、とても難しいのだが(膨大な期間があるので)、こういう風に長期間測定できるとその時点の特定が簡単になり解析が非常に楽になる。

FreeRTOSのキューでUARTを動かす(7/2/2011)
 道草を食っているときではない。FreeRTOSの残された課題を早く解決しておこう。まずは、UART環境の整備だ。これは、これからマルチタスクでロボットなどを動かして行く時の強力なデバッグツールになる。

 これまでの記事にあるように、FreeRTOSのUARTを含めた割り込み環境はRTCと合わせ、やっとのことで何時間動かしてもフリーズしない安定した状況になっている。しかし、UARTそのものはまだ、リエントラントになっていない。誰でも(どのタスクでも)、任意にUARTに送信リクエストを送っても正しくメッセージが出るようにはなっていない。

 マルチタスクOSであるFreeRTOSのUARTとしては、これはまずい。データが化けるくらいならともかく、下手をすると簡単にフリーズしてしまう。デバッグツールには使えない。

 OSの持っている機能、キューでデータをやりとりすれば良いということはわかっているが、このあたりはソースリストをいじって簡単に解決できるレベルではない。もう少し抽象的なレベルに上げて検討する必要がある。

 実装の対象は、ChaNさんのUARTソースである。抽象レベルではわかっていても、このFIFO、入出力バッファー付きのUARTを、どうキュー仕立てのマルチタスク対応UARTにすれば良いのか具体的な手順が見つからない。

 うまい方法が見つからず、何枚もメモシートを書き潰していて、あるとき、突然気がついた。良く考えて見たら、ひとつのUARTの受信ポートに複数のタスクが集まって、データを取り合うことは現実にあり得ない。つまり競合を心配する必要がない。

 これまでは、送受信を対称的に考え、両方を同じ仕様で作ろうとあれこれ考えていた。今度のUARTは送受信ともハードのFIFO、ユーザーのバッファーと、2段の非同期プロセスが存在する。送信は、検討の初期から別タスクを起こして処理することを考えていたが、どうしても受信プロセスがうまくいかなかった。

 受信は難しく考える必要がない。単に受信割り込みでデータをキューに送るだけで、ユーザー関数はそれを待てば良いのである。UARTの受信の速度は、CPUのキューの処理に較べれば圧倒的に遅い。バッファーも必要ないくらいだ。

 送信は、ユーザー関数をキューで受けて、別の常駐タスクを作り、ここで実際のUARTハードへの送り込みをキューイベントをトリガーとして行う。printfがリエントラントでないので、これに対しては、Mutexなどでガードしてやる必要があるが、こうしておけば複数のタスクからの送信要求は安全に処理される。

Ws000000 コンセプトが明確になったので、コーディングにとりかかる。ユーザー向けの送受信関数は、キューステートメント1行のえらい簡単な関数になった。UARTタスクからMonitorタスクを分離し(これが今後のモニターコマンド処理を担う)、UARTタスクはハードの初期化と、送信キューの送出のみに絞る。

 テストしてみる。よーし、動いた。ロジアナで動作を確認する。ふーむ、Mutexを使ってprintfをガードしたけれど、このアプリでは重なることはまずなさそうだ。Mutexもはずす。Mutexだけで、フラッシュは560バイトも使っている。

Prtfmutex さて、今のところFreeRTOSのマルチタスク対応UARTは長時間テストを続けて、順調に動作している。次は、FatFSか。まずシングルタスク用に入れてみよう。

 FreeRTOSマルチタスク対応UARTのソースは以下に置きます。やり方は、これまでの記事を見てください。

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

SparkFunのガイガーカウンターキット到着(7/4/2011)
 そうこうするうちに、4月の末に発注したSparkFunのガイガーカウンターキットが、遂に届いた。入荷は6月第二週の予定であったが、結局6月には届かず、ちょうど2ヶ月かかったことになる。

 6月第二週の情報は、SparkFunの商品ページのコメント欄で得た。このガイガーカウンターキットのコメントには100を越す色々なメッセージが飛び交っている。このコメント欄に、6月にはいってすぐ、「6/1に出荷開始!」というコメントを入れた人がいたので、心待ちにしていたのだが、一向にその気配はなかった。

 すでに代金は、5月末に、クレジットカードの支払いで引き落とされている。段々心穏やかではなくなってきた。それでもFreeRTOSのトラブルシューティングに熱中していて暫く忘れていた。

 トラブルが解決して、一息ついてネットをぶらぶらしていたら、日本のブログでSparkFunのガイガーカウンターキットの制作を報告しているところを見つけた。この人は3ヶ月待たされたらしい。

 やっと外国である日本向けの出荷が始まったのかな。久しぶりにSparkFunのページにログインして自分のOrder Historyを見てみる。おお、NewOderがin delivary に換わった!1日もしないうちに、ステイタスはshippedに換わり、めでたく品物は日本に向けて出発したようである。

S_p7043996 4日ほどで品物が届いた。初めてのSparkFunからの荷物である。記念撮影をしておく。中から小さな赤いSparkFunの箱が出てきた。おやあ、全部配線が済んでいる。何だキットというから半完成品かと思ったら、全部の配線が終わっている。ガイガー管は、配線を束ねるタイラップで基板に固定され、グランド側は、線を巻きつけているだけだ。このあたりの工作が難しいので全部組み立ててあるのだろうか(外国人は、日本人に較べると驚くほど不器用である)。

 取る物もとりあえず、USBジャックを付けて電源を入れる。赤いLEDが煌々と点いて、その隣の緑のLEDが一瞬点いた。シリアル端末を立ち上げて様子を見る。始めは何の反応もなし。暫くして、緑LEDの瞬きとともに端末に01と数字が出た。おお、動いているようだ。

Geiger

 CPUチップの横にあるのがISPピンらしい。SparkFunのサイトに行って、最新版のファームをダウンロードする。ソースの中を調べる。うーむ、このソースでは動いていない。サイトの記事を見ると、どうもV12という放射線量の数を乱数に使うプログラムが送られてきたキットには入っているようだ。その証拠に、端末の0や1が増えている。0はパルス間隔が前の時より短かったとき、1は長かったときを表すようだ。

これだけでは、全くガイガーカウンターとしては用をなさない。最新ファーム(V13)も似たようなもので、1秒間の発生したパルスの数を延々と出しているだけだ。まあ、これは覚悟していた。ISPピンが出ているのでファームの書き換えに支障はない。
 
電源LEDを点滅に換えたりファームを書き換えたり(7/6/2011)

 このガイガーカウンターキットは、USBを通したUART(FT232RLがついている)が唯一のインターフェースで、パルスが来るとLEDが一瞬点くが、音が出るわけでもない。これをポータブルにするのは、独立電源にして、何らかの表示装置をつけないといけない。素人が使うなら音もあったほうが良いかもしれない。

S_p7044002 ただ基板上にはGM管からの出力パルス(トランジスタでバッファー)しか出力が出ておらず、QFPのMega328の空きI/Oピンは全く引き出されていない。LCDをつけるには表面実装のパタンから線を引き出す必要がある。ピン配置と基板をにらめっこして、半田ごてが入りそうなピンを物色する。

 ISPピンヘッダーはパタンがあるので、これをつけるついでに、パラレルLCDをつける半田付けのための練習を兼ねて、電源を入れると点きっ放しになる基板上のLEDをMega328のピンに移して点滅するようにした。パタンを切って銅面を出し、ピンをUEW線(0.2ミリ)でつなぐ。

 順調に作業が済んだ。ソフトの方は手馴れたAVRのプログラミングである。プログラムを変えて、赤のLEDがブリンクするようになった。ただ、この基板はクリスタルをけちってCR発振のクロックなので、余り厳密なことは出来ない。出てくる数値もあくまでも目安程度だろう。

 それでも、GM管から出てくるパルスの間隔を配列に蓄積し、10ヶの移動平均をとって、直近の平均のCPMを出すプログラムの開発にとりかかった。品物が来る前から構想は練ってあったので、コーディング半日、テスト半日で、所定の4桁のCPMがUARTに並ぶプログラムが動いた。

Geiger_2 出てきた数値をPCのExcelでグラフにしてみた。地下室は一般的には、自然放射線量が多いということだが、我家では、明らかに地下の方が低い結果が出た。

 あとは、LCDにこれを移しポータブル化することと、さらにμSv/hなどに換算するロジックや、データログ機能などが待っている。まあ、もともとは、「正しく怖がらなければ」などとブログで大見得を切った手前、何らかの自衛手段を持っておかねばと、はずみで買ってしまったようなガイガーカウンターである。深入りしていけばきりがないので、適当なところで切り上げるつもりだ。

Photo ソースコードは、オリジナルソースがクリエイティブコモンズのAttributeオプションと言うことなので、ソースコードの原作者表示を残し、当ソースもこれを継承していくことにする(作者名を表示すれば、複製、改変、商用可能)。

暫定版ですが、とりあえずソースコードを、例によってAVRStudioのプロジェクトとして下に置きます。SparkFunのガイガーキットだけでなく、パルスの到着間隔を測定表示するプログラムとして他にも応用が可能です。

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

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

2011年6月25日 (土)

FreeRTOSのセマフォーの不具合がやっと解決

 雑誌付録ARM(LPC2388)基板のFreeRTOS7.0.0で、ChaNさんのバッファー付きUARTを動かすことには成功したが、セマフォーを使った受信処理はうまく動かず後味の悪い結果が残った。

 前記事にあるように、UART出力が数十分後にフリーズするという不具合がどうしても解決できない。結局この不具合究明は一時あきらめ、次の課題を、 

・ChaNさんのFatFSをFreeRTOSで動かしてSDカードが読み書きできるようにする。
・UARTをすべてOSのキューを使って入出力し、マルチタスクに対応させる。

ということに決めた。このあたりまで動けば、この基板のOSはロボットなどの多重同時制御のプラットホームとして十分な機能を持つことになり、ネットを使ったカメラ制御などのアプリケーションが簡単に開発できるようになる。

S_p6183986 ただ、FatFSを完全なマルチタスクで動くようにするのは、そう簡単ではない。コードそのものはリエントラントで書かれているが、これをいくつものタスクが同時に動いても良いようにするには、コードだけでなくディスクなどの単一リソースの排他制御を完全に行わないと、デタラメな書き込みでディスクは、あっという間に破壊される。

 しかし、検討に力が入らない。最初はシングルタスクで動くだけで良いと思っていても、頭の中で、何かがひっかかって先に進まない。そう、セマフォー不具合の問題が頭から離れないのである。

 それにしても、このしつこさは何だろう。もし、これが仕事だったら、こんな瑣末なことにこだわっていたら仕事にならない。上司から大目玉を喰らうか、プロジェクトだったら大迷走、中小企業だったら間違いなく倒産である。やっぱり、これは現役時代の反動ではないかと思う。

 人は笑うかもしれないが、不思議なことに、こういう下らないことにこだわってあれこれ悩んでいる時の方が、逆に自分が自由な気分になっていることに気づく。仕事の時はこんな悠長なことを考えている余裕はなかった。一時(いっとき)でも全体から見て効果、実効のある方向を模索することが求められ、始終あせっていた。

 その焦燥感が、現役を退くと消えた。まわりを気にせず解決を求めてさ迷っていても、誰もとがめる人はいない。いろいろ気配り心配りする方がストレスは溜まるのだ。単純に思考しているほうがむしろ幸せなときなのである。それに悩んだことが大きければ大きいほど、それが解決した時には大きなご褒美が待っている。

セマフォーを解析して不具合を追及する(6/19/2011)
 そんなことで、次の課題はぶちあげたものの、実は、あまりやる気が起こらず、暇さえあればセマフォーのトラブルシューティングをやっていた。

 まず、不具合の状況を整理する。セマフォーを導入する前は、リアルタイマークロック(RTC)からの1秒毎のUARTのメッセージを何時間出していても全くトラブルがないのに対し、受信割り込みを待つためにセマフォーを使うと、20分前後で全タスクがフリーズする。

 セマフォーが動くUART受信部を全く動かさなくても、不思議なことにフリーズする。ここが謎である。ただし、時刻を表示しなければ、セマフォーを入れていても症状は発生しない。フリーズするタイミングは時間ではない。UARTから出力するデータの数である。

 セマフォーを組み込むことで、時刻表示のUART出力に不具合が生じ、時限爆弾のように、何千回かあとで問題が顕在化する(そう見えるだけなのかもしれないが)。フリーズするまでの時間は最初10分程度だったのが、いつのころからか20~30分程度に伸びた。正確な時間をとってみると、最初は13分で、増えたときが26分。時間がちょうど倍と言うのが悩ましい。

 セマフォーの中のソースコードを解析する。セマフォーは独自のソースではなく、キューの関数を流用している。サイズが0でキューの数が1のキューをハンドリングする。mallocでメモリ(わずかだが)を取っていることがわかった。

 そういえば、時刻を表示するのに使うprintfは、mallocを使っている。printfはリエントラントではないので、受信のエコーバックと被ればおかしくなる可能性はあるが、別に被っているわけではなく(受信を一切しなくても起きる)、これがフリーズの原因とは考えにくい。しかし、念のため、printfをやめて自前の送信関数を作って時刻表示させてみる。やっぱりフリーズすることに変わりがない。

 FreeRTOSのメモリ管理は、いくつか種類があって、良く見たら、ねむいさんが公式デモソースのメモリ管理の設定をスタティック管理(heap_2.c)から、gcc標準のmallocを使ったダイナミック管理(heap_3.c)に換えていた。もしや、これかと、heap_2.cに戻してテストしてみた。

 しかし、フラッシュサイズが20%近く増えただけで、結果は全く変わらなかった。いやあ、難しいものだ。JTAGなどのデバッガーも考えたが、フリーズした地点のアドレス(恐らくBad Interruptで不正番地)がわかるだけで、このあとの解析はARMやFreeRTOSの内部環境を熟知していなければ、簡単には手をつけられない。

最初から徹底的に調べるも万策がつきる(6/20/2011)
 だいたい、最初にセマフォーが動き始めた時から動きが不審である。1回空振りをしないとセマフォーが働かなかった。何か、セマフォーに関して不具合報告はないかと、ウェブでキーワードを換えて何度も検索するが、それらしい記述は、前のSTマイクロのときのようにヒットしてくれない。お、似たようなことをしていると良く見ると、自分のブログの記事だったりして苦笑いである。

 しかも悔しいことに、このデモソースの中の別のセマフォーは何の問題なく動いている。他の例でも問題があるような話は何もない。それなのに、自分のだけがおかしいのである。不愉快なこと極まりない。

 こうなったら意地になるのがいつもの癖である。いちからセマフォーを少しづつ設定して動きを探ることにした。まず、セマフォーハンドルのメモリ上の定義だけをして、他はすべてコメントアウトしてビルドしテストする。これは問題ない(まあ、当たり前か)。

 次は、セマフォーハンドルの初期化。 これは以前、タスクでやって問題を起こしているが、もう一度、main()と、vUartTask()でそれぞれ初期化してみる。これもどちらも問題なし。

 続いて、セマフォーのTakeステートメント(待つ方)を入れる。Give(許可する方)が動いていないので、キーボード入力は出来ないが、そのまま動かしてみる。これも問題なく時刻を吐き続ける。

 今度は、セマフォーのGiveFromISRステートメントを割り込みルーチンに組み込み、テストする。キーボード入力しなければここは通らないので問題ないはずだ。ややや、違う。これだけでフリーズした。ここを一回も通っていないのは、ロジックアナライザーで確かめてある。何ということだ。通っていないルーチンの組み込みでトラブルが起きる。???である。

 これは一体どうしたことだ。セマフォーを入れたことによって、割込みルーチンの構造が変わったのか。コードを入れただけで命令を実行しなくてもトラブルが起きる。うーむ、根が深そうだ。

 フリーズの原因と見られる、RTCタスクのprintfの出力は、最終的にはUARTタスクの中の関数、uart0_putを使う。セマフォーを動かしているのはuart0_getという全く関係のない関数だ。何故それで無関係のuart0_putを使うタスクがフリーズするのか理解できない。ただ割り込みルーチンが共通なので、このあたりが臭いことは確かだ。

 セマフォーを入れることで、何かコンテキストスイッチのルーチンが組み込まれたのか。まさか、そんなわけはない。Takeなら、コンテキストスイッチが起きて、状態が変わる可能性があるが、GiveFromISRは、単にキューエリアに何か書くだけだ。状態が変わるとは思えない。しかも、その発行もしていないのだ。

キューを調べ始めて意外なものを発見(6/23/2011)
  悔しいけれどセマフォーの不具合究明はこれ以上は諦めることにする。諦めるのは2回目である。さすがにもう無理だ。調べるところがない。

 気を取り直して、前に決めた課題にとりかかる。FatFSは少し重いので、UARTのキュー化の方から始める。本来マルチタスクOSでUARTを使おうというときは、キューでメッセージを一箇所のUARTタスクに送り、ここで一手に出力するというのが正式な導入である。このデモソースでも、LCDがゲートキーパーとして、この方法で動いている。

 セマフォーで受信割り込みを監視するなどというのは、小手先のOSの利用に過ぎない。本当はキューからやるべきだったのだ。キューを勉強しながら、セマフォーを諦めた自分を一生懸命慰める。

 ただ、UARTをキューで取り扱うのは、そう簡単ではない。printfなどリエントラント化されていないサービス関数をどう取り扱うかが課題である。それでもこの方法は、幸い、ウェブにお手本ある。PICがターゲットだが、このあたりは余り変わりはない。これを少し真面目に読み込む。

 読んでいるうちに、FreeRTOS7のデモソースにも、キューで動くUARTの見本があることがわかった。そうだ、以前、ARM7_LPC2106_GCCのフォルダーでserial.cとして、UARTソースを見たけれど、それらしい。

 始め見たときは、FreeRTOS特有の長い長い変数で、あまりにも読みにくく、敬遠していたのだが、今読み返してみると、大分読めるようになっていた。FreeRTOSの理解が進んだのだろう。おおよそ何をやっているのかわかるようになってきた。

Arm そのうち、意外な部分を発見した。割り込みルーチンが違う形になっている。ありゃあ、これまでのものと大分違うぞ。ラッパーが作ってあり、コンテキストのセーブ/リストアをこのルーチンでやっていて、本来の割り込みルーチンはここから呼ばれるだけである。

 つまり、これまでは、割り込みルーチンのコンパイルモードをARMモードにし、関数の前後に、SAVE_CONTEXT();とRESTORE_CONTEXT();を挟むだけだったが、ここでは、インラインアセンブラーの、

__asm volatile ("bl 割り込みエントリ");  // 本来の割り込みエントリーにリンクする

と、この前後をSAVE_CONTEXT();とRESTORE_CONTEXT(); ではさんだラッパー(Wrapper)関数を作り、この2つの関数に対し、

void 割り込みラッパーエントリ( void ) __attribute__ ((naked));
void 割り込みエントリ( void ) __attribute__ ((noinline));

というコンパイラーオプションをつけている。割り込みラッパーエントリが実際の初期化のときに、VICテーブルに定義する割り込みエントリとなる。

 ふーむ、何か閃いたぞ。現在の割り込み処理とやっていることとあまり大きな変化があるとは思えないし、現在のデモソースの他の割り込みルーチンも、この方式は採っていなくて問題なく動いている。

 しかし、わざわざラッパーまで作って分けてあることには何か理由があるのだろう。セマフォーの不具合と関係しているのかもしれない。これは試してみる価値があるのではないか。

遂に成功。1時間経っても止まらない(6/24/2011)
 大した手間ではない。UARTとRTCの割り込みルーチンに上記のラッパーをそれぞれ組み込む。セマフォーを全部戻して、26分でフリーズする元の形にしてビルドする。フラッシュサイズの増加は、殆どなかった。

 テストする。こいつは、すぐに結果が出ない。UARTコンソールを立ち上げ、これを横目にウェブブラウザーを見ながら、時間が経つのを待つ。フリーズする26分が近づいてくる。胸の鼓動が段々高くなって、その場にいたたまれなくなる。端末は黙々と時間を刻んでいく。

 このRTCは結構精度が良く、日差数秒で数週間経つがまだ分の遅れも出ていない。いや、そんなことを言っている場合ではない。27分を越えた。まだフリーズしない。30分を過ぎた。うまく行ったのではないか。ただ、この不具合、26分のその倍、52分で止まったこともあるし、一度はフリーズせずにリセットだけして先に進んだこともある。安心はできない。

 1時間半が経った。まだ時刻表示は止まらない。歓喜がじわじわとこみあげてくる。どうも解決したようだ。他の割り込みが、この方法を使わずに何故上手く行っているのかは説明できないが、少なくとも、UART割込み、セマフォーの組み合わせでの不具合は、ラッパー関数の追加で解決した。

 いやあ、今度も長くかかった。結局、不具合がわかってから解決まで、ほぼ2週間かかっている。何度も書いているけれど、この解決した時の達成感は何物にも替えがたい。しつこく追いかけた甲斐があった。これまでの悩みが吹き飛んで、無上の喜びになる。電子工作の明らかに、変な楽しみ方のひとつである。わざわざ難問を設けて、その解決を追求するのだから。

Semaphoreuart その後、一晩、動かしっぱなしにして、フリーズしないことを確かめた。これで心置きなく、次の課題に取り組める。なぜそんなにOSにこだわるのか。ロボット制御には不可欠な機能だから、と、ちょっと偉そうに答えてみる。そろそろmbed(LPC1768)も触ってあげないといけないな。

 ソースコードの公開については迷った。こちらが付け加えたコードは少なく、ChaNさんや、ねむいさんのコードが多い。公開するのは正直言って気が引ける。まあ、でも少しは、みなさんの役に立つこともあるかと思い、アップすることにする。少なくとも、セマフォー付きUARTは完全に動く。モニターとしてはまだ未完成で、入力した文字はリターンキーで戻ってくるだけである。

 ビルドするためには、FreeRTOSの適切なディレクトリーチェーンの中におく必要がある。詳しくは当ブログのバックナンバー記事、ねむいさんの書いたreadme.txt等を参照されたい。

ここに、Eclipseのプロジェクトとしてのソースフォルダーをzipで固めたものを置きます。
解凍したフォルダーをFreeRTOSの適切なディレクトリに置き、makefileのあるディレクトリを
Eclipseのwork spaceにしてください。

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

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

2011年6月18日 (土)

FreeRTOSでバッファー付きUARTを動かす

 雑誌付録ARM基板(LPC2388)にFreeRTOS(7.0.0)をインストールし、割り込みでRTC(リアルタイマークロック)を動かすことに成功した。その勢いを駆って、本来の目的であるバッファー付きUARTの実装を目指した。

 しかし、これが難航しているのである。2週間も経つのに、まだこれで完全と言える段階に到達しない。思うようにいかないものだから、つい他のものに目移りしてしまって余計進捗が遅れる。これ以上日をあけるとわかりにくくなるので、このあたりで報告しておくことにする。

バッファー付きUARTは一文字入出力までしか動かない(6/5/2011)

 ARMでのFreeRTOS特有のコンテキスト保存のやり方を知って割り込みルーチンが無事動き(前記事)、次の割り込みを使ったバッファー付きUARTの実装は簡単に思えた。受信割り込みを何で待たせるか、セマフォーにするか、それとも全体をキューで仕立てるか、贅沢な悩みを抱えながら余裕を持ってソースコードを調べ始めた。

 このソースコードは、元祖はFreeRTOS V7の公式サンプルソースで、KEILの評価ボード(MBC2300)のイーサネットでウェブサーバーが動く。これにねむいさんがV6のとき、I2CやUARTなどを追加した。このUARTは割り込みを使わず、ポーリングで直接、送受信レジスターを叩いてデータをやりとりする方式で、これまで問題なく動いている。RTCの時刻表示メッセージや、時刻入力でも使われている。

S_p6043961 ただ、このUARTソースには、このポーリング方式以外に割り込みを使ったバッファー付きUARTのコードが入っており、#ifdefで切り替えられるようになっている。オリジナルは、Copyright(C) 2006, NXP Semiconductorとあるように、チップ製造元のフィリップスのサンプルソースのようだ。

 バッファー付きのコードの方はこれまで試してみたが全く動かなかった。一文字も出力せずいきなりハングする。RTCで割込み環境をテストしていたのは、このバッファー付きUARTをちゃんと動かすためでもある。受信はともかく、これからUARTをデバッグに使うためには、高速でデバッグメッセージが出せるように、バッファー付きの送信にしておきたいからである。

 #ifdefをバッファー付きの方に切り替え、RTCのときに得たFreeRTOS上での割り込み手順を、このソースのUART割り込みルーチンに適用していく。たいした手間ではない。期待に胸をふくらませてビルドする。受信割り込みは、用心してまだセマフォーなどは使わない。

 テストする。ふむ、最初の数文字は出力されたが、それ以上はハングアップした。ただ全く動かないのではなく、わずかだが文字が出た。道は少し開いたようだ。一旦、処理の殆どをコメントアウトし、LEDを使って少しづつ機能を調べていく。デバッグの重要な武器であるprintfはUARTの開発のときには使えない。いざとなったらロジアナでLEDのピンをプローブにして調べる。

 ARMはAVRと違ってUART割り込みは、送受信とも同じ割り込みベクターに来る。まず、受信が出来ているか調べる。LEDを割り込み部に挟んで、キーボードを打つ。ちゃんとデータを読んでいるようだ。しかし、データが来ていない。自前の関数(待ちを入れないためのラッパー)が邪魔をしていることがわかった。これをとりはずす。受信はOKになった(と思われる)。

 次は、送信である。エコーバックを戻す送信関数をコメントから本番に戻して再度ビルドする。よし、入れた文字が画面に出力された。エコーバックも問題ないようだ。これまでに直したところは、コンテキストのリカバーのあとに、割り込み終了のステートメントが入っていたケアレスミスだけである。快調なペースだ。

 1文字単位の入出力はOKとなった。残るは、連続文字出力である。オープニングメッセージを出すようにコメントをはずす。しかし、これはやはりまだ駄目だ。数文字出たところでハングアップする。今夜はもう遅いのでこのあたりで作業を終了する。

LPC2388のUARTを勉強する(6/6/2011)
 次の日は仕事だったが、帰宅して早々に地下のPCルームにこもる。割り込みを使った送信ロジックは、レジスターの送信終了を単に待つロジックに較べると、はるかに複雑である。連続送信の不具合がそう簡単に解決しないことはわかっている。

 UARTの送信割り込みは通常、送信レジスターが空の時にあがる。この割り込みを受けて割り込みルーチンは、バッファーからデータを送信レジスターに送り込み続ける。バッファーはリングバッファーになっていて、ユーザー側の送信関数は単に、バッファーにデータを置いていくだけである。これでユーザー側は、送信レジスターが空くのを気にせず効率よく送信出来る仕組みだ。

 この方式ではバッファーが空になると、割り込みを上げ続けるので、このときは割り込みを止めなければならない。リングバッファーの制御などにも気を配らないとデータは失われる。

 これまでARMのUARTではデータシートを殆ど見ずに、人の書いたソースを見よう見まねで、いじってきたが、このあたりからは無理だ。デバッグに入る前に、基本に戻ってデータシートで少しまともにLPC2388のUARTを調べ始めた。

 おお、このUARTは自動ボーレート設定機能まで持ったフル装備のUARTだ。16バイトの送受信FIFO(先入れ先出しbuffer)を持っており、受信FIFOではデータ量を指定して割り込みを発生できる。昔のPCについていて460Kbpsまでサポートしていた16550というUARTチップと同一機能ということだ。

 で、サンプルソースはどうしている。あれえ、バッファー付きといっても、送信はFIFOを使っているだけで、ユーザーバッファーを持っていない。メモリ内の移動の速度に較べれば、FIFOレジスターへのデータ送り込みはかなり遅いはずで、その証拠に送り終わるのを待つしかけがある。ここはメモリの送信バッファーが欲しいところだ。

 それに、コードを見る限り、FIFOにデータがなくなると絶えず割り込みがかかって(フラグを上げているだけだが)、わずかでもオーバーヘッドが気になる。さらに不具合の原因とみられる条件が見つかった。

 FIFOに収容した送信データがなくなると割り込みが起き、割り込みルーチンでフラグを上下しているが、送信関数でもこのフラグを動かしているので、複数のデータを送り込んだ場合、オペレーションが重なってハングする恐れがある。ここは、UART割り込みがここで起こらないよう処理の前後に割り込みをマスクする手順が必要だ。どうも、このソースの信用がおけなくなってきた。

 そのうち、このソースコードに関して大きな思い違いをしていたことに気づいた。このUARTソースはねむいさんが、どこからか持ってきたソースで、FreeRTOS用の公式サンプルソースではない。ねむいさんは、このUARTの割り込み版を使わずポーリング版を動かしただけで、恐らくこちらには何も触れていない。

つまり、このバッファー付きUARTはFreeRTOSでは全くテストされていない。要するにこれにこだわる理由は何もない。送信バッファーもないし、これを動かすことに力をかけるより、最初から作り直したほうが早そうだ。

Ws000000

ChaNさんのUARTは簡単にFreeRTOSで動いた(6/8/2011)
フルスクラッチでUARTを書こうと意気込んでは見たが、へたれである。すぐ思い直す。サンプルがこれだけあるのに何もそこまですることもない。これまでの先人の成果を利用しないのは、資源の無駄遣いである。地球にやさしくない(と勝手な理屈をつける)。

 誰のソースを選ぶかと言うと、これはもう1もなく2もなく、ChaNさんのFatFSのUARTソースである。外国人の作った長ったらしい変数に較べれば読み易く、何と言ってもコーディングのセンスが良い。(あまりにもスマートで解読に時間がかかるときもあるが)。

 このソースは、これまでのFatFSについていたUARTと殆ど同じで、大きなユーザーバッファーを送受信とも持っている。これまでのUARTをrenameして退避させ、ChaNさんのUARTをプロジェクトに持ち込む。入出力の関数名を揃える。最初はセマフォーを使わず、割り込みルーチンだけをFreeRTOSの仕様に合わせる。

 変更は僅かである。開発は順調に終わってテストに入る。うーむ、動かない。動いているコードと見比べる。コンパイルエラーは出ていないので変数名の間違いはない。ふむ、この最後のベクターインタラプトを終了させる、VICVectAddr = 0;    /* Acknowledge Interrupt */というおまじないがない。

 こんなもので、動かなくなることがあるのか、半信半疑だったが、ないことは確かなので入れてみた。ありゃあ、動いたー。一文字入出力も、多バイト出力も全く問題ない。あっけなく割り込みUARTのFreeRTOS版ができてしまった。やっぱり自前で作ったほうが良かったかな。達成感が違うもの。

セマフォーで難航する(6/10/2011)
 このままでもFreeRTOSの割り込み付きUARTなのだが、これだけではあまりにも芸がない。特に、受信はFIFOを使っているとはいえ、受信関数uart0_getcは、割り込みではなくバッファーにデータが入るのを延々と待つ方式である。OSのUARTらしくない。

 OSのセマフォーを使えば、この間はCPUがシステムに帰り、リソースの無駄遣いを減らせる。FreeRTOSの演習のつもりで、セマフォーを導入することにした。これが実現できれば、ソースを公開しても恥ずかしくないはずだ。ところがこれが難航した。功名心にかられてやるとろくなことがない。

 セマフォーが解けた(giveされたあと)、受信バッファーにデータが入ってこない。UARTのFIFOをさらに研究する。はじめ8バイトとってあった割り込みトリガーレベルを1バイト(FIFOなしと同じ)にして割り込みがすぐでるようにしたが、うまくいかない。受信バッファーにデータが入ったかチェックすればセマフォー入りでも動くが、これでは何のためにセマフォーをいれたのかわからない。ポーリングより原始的になる。

 しかも、12~20分くらいでハングアップすることも判明した。泣き面に蜂である。ロジアナを持ち出してLEDのところをプローブポイントにして調べるが、今ひとつ解明の足がかりにならない。

セマフォーが動いていないことがはっきりした(6/13/2011)
 2日間、かかりきりで調べまわったが、解決しない。たいした話(受信データをポーリングで待つか、割り込みで入るか、どっちでも大差はない)ではないのだが、どうもすっきりしない。

 LEDのプローブ点を何度か変えてテストするうち、意外なことが判明した。UARTの割り込みの不具合ではなく、セマフォーそのものが全く機能していない。つまり、セマフォーをtake(渡されるのを待つ)するステートメントでタスクが止まらないですり抜けていることがわかった。

 どうも納得できない。他のサンプルコーディングと全く同じコーディングなのに、その通りに動かないというのは、不愉快なものである。一字、一字ステートメントを確かめる。どこにも間違いはない。変数の受け渡しがおかしいのかと、main.cとuart0.cの間で変数定義をあちこち替えてみたり、volatileをつけたりはずしたりするが、変化なし(static volatile XXXではエラーになる!)。

 UARTモニターにしか使わなければ、UARTの受信はキーボードからだけで、ポーリング(人間相手なら10ms間隔で十分)で何の問題もないのだけれど、セマフォーとか、キューなどのタスク間の同期制御は、OSの重要な基本機能の一つである。

 これが動かせなければOSを使った意味がない。OSは、この基板で、モーター制御などのロボットを視野に入れているので、何としても動かしておきたい。しかし、セマフォーはがんとして言うことを聞かない。

アクリル曲げ器を作るついでに温度制御の野心(6/14/2011)
 セマフォーを使ったUARTが思うように動かないのでストレスが溜まっている。実は、kumanさんの掲示板で見た「ばんと」さんのアクリル曲げ器を、自分でも作りたくなり、大分前に秋月の調光器キットだけを買ってあった。

S_p6183980 開発が思うように進まないので、気を紛らわそうと、このキットを組み立て、ケースに作りこんだ。手を動かしていないといられない性分になったこともある。白熱電球のスタンドでテストする。ボリュームを少し動かしただけで明かりが急に変化して少しおかしいが、とりあえず調節は出来るようになった。

 東急ハンズで、アルミパイプや、耐熱ファイバーケーブル、ニクロム線などを買ってきた。ニクロム線が、みなさんが買っている値段とは違う法外な高値(0.5ミリ5mで¥500!)だったが、一箇所で間に合うので目をつぶって一緒に買う。東急ハンズですべての部品が揃った。全部で駐車料が無S_p6183966料になるぎりぎりの¥2000ちょっと。

 ニクロム線と接続ケーブルの間は、圧着端子とネジ止めでつなぐ。耐熱ファイバーをパイプから少し長めに伸ばして、接続部分が触れないように工夫する。ここにスイッチを置くアクリルカバーを作りたいが、「鶏と卵」問題で、とりあえずはバラックとする。

 調光器で試運転する。これも、こういうときのためにS_p6183963買ってあった放射温度計(通販で¥3500)で測るが、思わしいデータは出ない。温度がばらばらだ。おまけに低いと思ってうっかり触ったら、やけどまでしてしまった。適温にする調光器の調節が難しい。

 このあと、調光器キットのコンデンサーを間違えて接続したことがわかり、電圧の調整がスムーズになって、150℃前後の温度が作れるようになった。早速、アクリルの端切れを曲げてみる。うむ、正確に測って曲げれば、色々なものが作れそうだ。

S_p6183965 調整に苦労しているうちに、マイコンでこのパイプの温度制御をやりたくなった。高温のセンサーとなる熱電対を調べる。これがまた結構面白いのでついはまってしまう。調べると欲しくなり、仕事の帰り、久しぶりに秋月電子に寄って熱電対を買ってきてしまった(¥400)。

 熱電対は工作心を刺激する部品だ。このセンサーは、2極の電極の間の温度差しか出力しないので、低い方の電極の温度を知っていないと本来の温度にならない。別の温度センサー(又は氷)と組み合わせる必要がある。しかも、1℃あたりの起電力が41μVと(K型熱電対の場合)、極小なので精度の良いオペアンプで増幅する必要がある。

S_p6183981

 興味に任せて色々調べていたら、この世界にもICがあることがわかった。アナデバのAD594という、冷温側のセンサーを内蔵したオペアンプや、MAXIMのMAX6675などは、何と出力がデジタルのSPIで出てくるものなど、結線だけで簡単に測定ができるようになっている。値段はいずれも¥1000以上するので(¥1300~1500)、急には手が出せないが、いずれDigiKeyで買って見よう。こういう「ゆるい」電子工作も面白い。

やっとのことでセマフォーが動いた。しかしまだバグがとれない(6/15/2011)

S_p6183967 アクリル曲げ器の工作の合間にも、あきらめきれずにセマフォーをテストしていた。何しろ至極単純なバイナリセマフォー(一回きりの待ち)が動かないのである。他のソースコードをいくつか調べても違ったことをしているわけではない。

 このウェブサーバーのサンプルソースにも、同じような割り込みから処理を再開するのに、このセマフォーは用いられ(uIP.cでパケットが送られてくるのを待つ)、何の問題もなく動いている。何かがあるとするなら、ソースファイルを異にして、グローバル変数(セマフォーハンドル)を、extern(外部参照)で受けているくらいだ。

 まさかとは思ったが、念のため、同一ソースファイルでexternを経由せずセマフォーを動かしてみた。C言語からみれば全く同じ条件で、変るわけはないのだが、ものは試しである。

 これが、何と、驚いたことに、main.c上のセマフォーtakeが正常どおり動いたのである。これまでuart0.cに置いてあったセマフォーがどうやっても素通りしていたのに、ちゃんとgiveされるのを待つようになった。割り込みルーチンでgiveするとスペックどおり、次のステップに進む。

 一体どういうことだ。グローバル変数での受け渡しには警告すらでていない。それなのに、何故同一ファイル上でのセマフォーは動いて、別のファイルのルーチンでは動かないのだ。全く理解できない。volatileはつけてもつけなくても同じ。

 その後少しづつステートメントをずらして、一旦、main.c(セマフォーハンドルを定義したところ)で、セマフォーtakeを一回空振り(待ち時間を0にする)させておくと、別ファイルにあるセマフォーも動くことがわかった。わけはわからないが、とりあえずセマフォー付きのUARTの完成である。

 しかし、セマフォー付きのUARTは動いたとはいえ、まだ問題がある。前から気になっていた長時間時刻を表示させるとハングするトラブルが解消されない。最初は、13分、プログラムをいじっているうちに26分、RTCでUARTに時刻を表示し続けると確実にハングする。

 時刻を表示しなければ問題ない。奇妙なことにセマフォーを設定しただけ( vSemaphoreCreateBinary(セマフォーハンドル))で、ハングする。どうもこうなるとFreeRTOSのバグ臭い。RTCのprintfでのメモリー操作とぶつかっているような気がして、自前のuart0_put関数で作り直したが結果は同じだった。

 あまりこればっかりに関わっても埒が明かない。少し冷静になって周りを見てみよう。当面セマフォーからは撤退してUART受信はポーリングでデータを待つことにする。やることはまだまだ沢山ある。

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

2011年6月 4日 (土)

FreeRTOSでユーザー割り込み環境が動いた

 ここ1週間、悩んできたFreeRTOSのユーザー割り込み環境がやっとのことで通った。2年前のソースの作者にまでお助けメールを出して大騒ぎしていた一件は、何とか解決した。振り返ってみれば、何でこんなに遠回りしたのだろうと呆れるばかりだが、トラブルシューティングというのは大体こんなものだ。今度の顛末(てんまつ)も、「問題解決」という命題には恰好のケーススタディになるだろう。

LPC2388の割り込み環境を研究する(5/28/2011)
 前回の記事で、雑誌付録ARM基板(LPC2388)に入れたOS、FreeRTOSでRTC(リアルタイマークロック)が動き出したことを報告した。しかし、このRTCでは割り込みを使っていない。

 OSの元では、RTCは必ずしも割り込みを使う必要はない。それぞれのタスクが独立して動けるので、OSのタイマー(システムに戻るだけでループしていない)で1秒ごとにタスクを起して、時刻を表示させれば、自分で割り込みを使うより簡単に時刻表示が実現できる。

 割り込みにこだわるのは、実はUARTにある。現在のテストベンチのUARTは、割り込みを使ったBufferedモードが動かず、受信は10msごとにバッファーにデータが来ているかを調べるポーリング方式である。

UARTの受信はPCからのキーボード入力だけなので、このままで特に何の問題もない。それよりも、このテストベンチをこれからモーター制御や、カメラ制御などに使っていくためには、むしろUART送信の方を割り込み方式にしておく必要がある。

 割り込みを使わない現在の送信ロジックは、送信レジスターにデータを入れたら送り終わるのをただ待っているだけである。CPUの処理に較べれば、死ぬほど遅い(CPUは数十ナノセカンド、UARTは数百マイクロセカンド)UART送信が終わるまでループして待っていたら、たとえその間のCPUをOSに返すとしても、デバッグ対象のタスク環境が乱れてデバッグにならなくなる。UARTは是非割り込みで動かしておきたい。

Arm

 RTCが動き出して気持ちにゆとりが生まれた。UARTを割り込み化するのは簡単ではないので、このRTCをベンチに、少し腰をすえてARMの割り込みを基本から勉強する気になった。2年前に買ったまま放ってあった「ARM組み込みソフトウエア入門」(CQ出版社)などを取り出して読み始める。ここには1章、30ページ近くを費やして割り込みの詳しい解説がある。

 そうこうするうちに、ねむいさんから返事が返ってきた。なになに、ソースにヘッダーファイル、irq.hをインクルードして、__irqオプションを生かせば動くのではと言うメールだった。確かに、割り込みルーチンを定義している現在のUART.cや、RTC_support.cには、#include irq.hがない。これで動けばラッキーこのうえない。わざわざ割り込みを勉強する必要もない。喜び勇んで、RTC_support.cにirq.hを入れて動かしてみた。しかし、残念ながら、コンパイルエラーはなくなったが、ハングする状態に変わりはなかった。念のためUARTにも入れてみたが、動かないことは同じ。

FreeRTOSでユーザー割り込みは使えないのか(5/30/2011)

 FreeRTOSのソースは読みにくい。外国人のソースコードの特徴は変数がやたらと長いことで、英語が母国語の彼らにはこれで可読性が高まるのだろうが、日本人にはただ読みにくいだけで馴染めない。FreeRTOSも変数だけでなく、変数タイプにも長ったらしいprefixを追加したりしているのでなおさらのこと読みにくい。

 入れてみて文句を言ってみても始まらないが、FreeRTOSのtutrial(教育環境)はあまり親切とはいえない(ちょっとまともなリファレンスブックは有料になってしまう)。実践的なところの解説が不足している。移植性を謳うのなら、機種ごとに、systickタイマーを何にしているのか、どんなリソースをOSが使うのか(割り込みベクターなど)くらいの基本的なことが、書いてあれば助かるのだが、このあたりの情報は少ない。ソースコードを見れば、ということなのか。

F_rtos_eclipse

 八つ当たりしているのは、FreeRTOSで割り込みを使って、しかも動いているサンプルコードがなかなか見つからないからだ。同じ機種でないと、このあたりは参考にならない。新しく入れたRTCはともかく、既にFrerRTOSのサンプルソースに入っているUARTの割り込みが動かないのが謎である。

 割り込み環境を用意するirq.cには、ユーザーが簡単に割り込みベクターを追加して割り込み処理を加えるサービス関数install_irq()が用意されている。それなのに、それを使った割り込み環境のUARTはハングして動かない。

 スタンドアロン(ベアメタルと最近は格好良く呼ぶ)では、みんな楽々割り込みを動かしている。それはスタートアップルーチンにアセンブラーで補完した多重割り込みに備える処理が加えられているからだ。参考書や、ウェブの解説で見るとおりのことをしている。

 ところがFreeRTOSのスタートアップルーチンboot.sは殆ど裸に等しい。それに、このクラスのARMのCPUは、32ビットのARMモードと、16ビットのThumbモードの命令系統が混在しており、余計事態をややこしくしている。

 FreeRTOSで動くARMのUART、タイマーのサンプルコードくらいWebで探せばいくらでも見つかると思ったが、意外に少ない。それもいくつかあるように見えたUARTは、殆どがSTM32でもお世話になったMartin Thomas氏のUARTを元にしている。彼のベアメタルで動かしているUARTソースは割り込みを使ったBufferd UARTなのに、FreeRTOSではコメントアウトされている。これがあやしい。

 そのうち、彼のベアメタルのソースに気になるコメントを見つけた。どうもこれが犯人のような感じだ。2007年5月2日付のMartin Thomas氏のARM LPC2388用 uartサンプルでのコメントである。サービスルーチンのひとつarmVIC.cのヘッダーファイルarmVIC.hには、次のようなマクロの定義がある。そこのコメントに、
/*************************************************************
*
* MACRO Name: ISR_ENTRY()
*
* Description:
*    This MACRO is used upon entry to an ISR.  The current version of
*    the gcc compiler for ARM does not produce correct code for
*    interrupt routines to operate properly with THUMB code. 

「現在のARM用gccコンパイラーは、Thumbモードのコードでは正しい割り込みルーチンを作れない」とある。このあと、このソースコードにはこのマクロが使われている。

 どうもThumbモードでは、gccコンパイラーが適正なコードを作れないようだ。uart.cや、rtc_support.cはThumbモードのソースである。ウェブを見てみると確かに、gccコンパイラーの、バージョン3は、こういうバグがあったみたいだが、4では改善されたように見える。

 しかし、公式のARMの情報センターでは、現在のバージョンでもThumbモードでの多重割り込みは、gccコンパイラーではアセンブラーをつけないと動かないと書いてある。良くわからない。

 ということで、藁にでもすがる思いで、コンパイラーを最新のものに換えてみることにした。CodeSourceryの最新版(Sourcery G++ Lite 2011.03-42)をインストールする。gccは、2年前の、4.3.2から、4.5.2に上がった。しかし、予想したとおり結果は同じだった。コンパイルのオプションエラーになっていたno-dwarf2-cfi-asmオプションはエラーが出なくなったが、何故かファームのフラッシュサイズが20%以上増えた。このオプションのせいでもない。

デバッグ用にLEDを実装するが状況は暗い(5/31/2011)
 霧が深い。割り込みルーチンをARMモードにしてみることも考えたが、副作用が怖い。やってみようという気にならない。#ifdefで割り込みUARTをコメントアウトしてあるということは、どちらでも動くからで、もし駄目なら何らかのコメントがあるはずだ。Thumbモードで動いていたのではないか。ことさらARMモードにする理由が見つからない。

S_p6043960 仕方がないので、もう少し動かしながらデバッグしてみようと、LEDを2つ追加して実装した。このあたりのデバッグは、前にも書いたように、printfでは話にならない。UARTでメッセージを出す間もなくハングアップしてしまうからだ。LEDなら遅れない。

 LEDのI/Oピンは、WebのCGIを動かしているIOページのピンを選ぶ。こうしておけば動作確認が簡単にできる。特に問題なくウェブからLEDのON/OFFが出来るようになった。本当はそれどころでないのだが、暫くウェブでLEDを点けたり消したりして遊ぶ。

 割り込みルーチンにLEDの出力ステートメントを入れる。点灯しない。予想に反してここへ来ていないことがわかった。これまで調べていたレジスターのセーブ/リストアといった問題でない。もともとの割り込みベクターの設定がおかしい。事態は振り出しに戻ってしまった。

Freertos_led

 割り込み環境は調べれば調べるほど難しい。霧が深まるばかりで出口は見えない。あの参考書には、多重割り込み優先度つきなどという複雑な処理の方法が延々と解説されているだけで、頭の中の混乱は返って増すばかりである。

 FreeRTOSの簡単なインストールを解説したサイトを見つけた。これを見ていると割り込み環境が余りにも複雑なので、ChaNさんのFatFSプログラムをFreeRTOS化したほうが早そうな気がする妄想にとりつかれる。いやいやそんなわけはないのだけど。

頭を冷やしてもっと合理的なアプローチを考え直す(6/1/2011)
 4日近く、調べまわってやることがなくなった。少し頭を冷やすことにした。今やっていることの本当の目的は何なのか、自問してみる。FreeRTOSで沢山の仕事を同時に簡単に動かせるような環境を作るのが目的で、OSの中のロジックを理解することではない(これはこれで面白いが)。

 それなら、現在動いているソースのなかから、割り込みを使っているところを調べて、徹底的にこれを真似れば動くはずだ。要するに、大上段に振りかざして正面から問題を解決するのではなく、コバンザメのように利用できるものは何でも利用する姿勢でないと、こういう複雑な環境はいじれない。

 Thumbモードで割り込みを動かそうと四苦八苦しているが、何もそれにこだわることはない。そうなのだ現在のFreeRTOSでは、割り込みを使っているところはすべてARMモードでコンパイルしている。どうも、ここにカギがありそうだ。今動いているルーチンをそっくり真似てみよう。

 FreeRTOSのソースから、苦労して、割り込みハンドラーと、割り込みの初期設定しているコードを洗い出す。systickタイマーのTimer0のところport_ISR.cと、イーサネットのuIPの下部ルーチンEMAC_ISR.cのところだ。調べた結果、これらは2つとも自前で割り込みベクターを設定していて、例のirq.cの設定サービス関数を使っていない。うーむ、難しいな。

 さらにウェブを探していると、意外なメッセージを発見した。ねむいさんがUSBの独自ルーチンを開発する時、「FreeRTOSのやりかたを真似て割り込みルーチンを作った」とある。あ、これ、これ、これだ。ねむいさんが追加したUSB仮想COM、vcom.cは、インストールしたときハードがないので早々とコメントアウトして中味を見ていない。そういえばMakefileでもこのvcom.cはARMモードでコンパイルするようになっていた。

やっとのことで割り込みが通った(6/3/2011)
 そうか、これだ。何かつながったぞ。山が当ったような気がする。これを参考にしよう。vcom.cをあらためて詳しく調べる。それによると、

・__irqオプションは使っていない。__attribute__オプションもつけない。

・Thumbモードでなく、ARMモードでコンパイルする。

・普通のVIC設定関数install_irq()で割り込みベクターを設定する。

・FrerRTOSのコンテキストセーブ/リストアをするマクロ、portSAVE_CONTEXT()と、portRESTORE_CONTEXT()を使う。このためFreeRTOS.hをインクルードする。

・処理が終わったらVICVectAddr = 0などで、処理終了を知らせる。(6/13/2011追記)

 早速、rtc_support.cのRTC_Handler()に適用する。たいした変更ではない。ARMモードのコンパイルで副作用が出るのが心配されたが、無事何事もなくビルドは終了した。コアサイズも前と変わらない。

 今度は何か上手くいきそうな予感がする。期待が高まる。FlashMagicのファーム書き込みが終わるのがもどかしい。そろそろJTAG環境を作って書き込みを早くしたいのだが、その暇はない。

 ファーム書き込みが終わった。リセットする。おおー、動作中を示すLEDのブリンクが止まらない。割込みルーチンに入れたLEDが点灯する。やりました。やりました。UARTを立ち上げる。1秒ごとに時刻が表示される。これはまだOSのタスクウエイトで出しているメッセージだが、少なくとも割り込みルーチンはハングせずに通過している(LEDが点いている)。

 コードを割り込みのたびにフラグを上げて、メインの方でこのフラグを見て時刻を表示するロジックに換え、割り込みの中のLEDを点滅するように換えて再度テストする。

S_p6043958

 よーし、想定どおりにマシンは動いた。FreeRTOSデフォルトのLED点滅以外に、RTC割り込みルーチンに入れたLEDが1秒ごとの点滅を繰り返す。数時間放置する。問題なく動いている。嬉しい。これでUARTでもバッファー付きの送信が動かせる見通しがたった。いやあ、今度も長かったな。ねむいさんにまた助けられた。ありがとうございました。

今回の問題解決のポイントをまとめてみる。

・頭に血を昇らせずに、時々追求を休止し、現在位置を確認して、攻める方向を整理する。

・冷静に一番合理的なアプローチを決めたら、そこへ資源を集中する。

・情報は可能な限り集め、常に頭の中で情報を泳がせる。思わぬところで、つながりが見えて問題が解決する糸口になることがある。

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

2011年5月27日 (金)

雑誌付録ARM基板でSDカードとRTCを動かす

失礼しました。プライオリティが逆でした(5/20/2011)
 このOS、プリエンティティブじゃないなどと言っていたが、こちらの間違いだった。FreeRTOSでのタスクプライオリティは数字が大きいほど優先度が高いのだ。uIPは他のタスクより優先度が高いとばかり思っていたので(実際は普通より低いところで動いていた)、UARTの数字をこれより大きくして、さらに優先度を上げてしまっていた。これではUARTがループウェイトすると、uIPにはCPUが渡らない。同一プライオリティの時しかラウンドロビンでCPUは廻らない。

 設定を逆にしたら、めでたくUARTでどれだけCPUを喰っていても、Webサーバーの処理は遅れないようになった。UARTはセマフォーを使った割り込み待ちを考えていたが、その必要もなくなった。やれやれ、どうも済みませんでした。

S_p5193932

 コマンドシェルは一番低いプライオリティにしておけば、他のタスクの邪魔をしない。ただ、LCDのタスク状態表示には、何かエラーがでている。同じプライオリティのタスクがどこかにあるからだろうか、良くわからない。まだ、このあたりは手探り状態だ。

 とにかく、いつものようにPCのUART端末からモニターとして動くよう、コマンドプロンプトのロジックを作る。まずはエコーバックだ。キーボードから入れたデータをリターンキーで送り返すだけだが、これは、このあと入力データ(コマンド)を解析して各種の作業を行うコマンドシェルになる。

 この辺の開発は、AVRなどと同じなので簡単にできる。ファームを書き直してテストする。うむ、ちゃんとエコーバックされてくる。同時にLEDが点滅し、Webサーバーが順調に2秒ごとにHTTPデータを送り続ける。いやあ、だいぶコンピューターらしくなってきたな。

LPC2388の割り込み環境の設定は難しい(5/23/2011)
 プロンプトまでは快調だったが、その後のFreeRTOSのテストベンチの作業ははかどらない。本来のコマンドプロンプトは、UARTの受信割り込みで処理を開始するのが筋だ。タスクのプライオリティで誤魔化すのは邪道である。しかしUARTの割り込み関数がうまく入らない。

 LPC2388の割り込み関数の指定が良くわからない。現在のソースには、割り込みを使っているUARTが、Buffered UARTとして既にコードが用意されているが、これを動かそうとすると(#ifdefで入れ替わる)、コンパイルエラーになる。

 どうもコンパイラーによって割り込み関数の定義が違うようなのだ。環境変数の__GNUC__を定義すると、割り込みの定義のところの__irqオプションが消えるのでビルドは通るが、このファームではFreeRTOSそのものが全く動かない。他に影響がでているようだ。

 あちこち探し回るが、ソースごとに設定の方法が違っていてどうして良いのかわからない。ChaNさんの雑誌のソースもあるので、ここでの割り込みを調べるが、ここは肝腎なところはすべてアセンブラーで実装されており、残念ながら参考にならない。

 結局、割り込みを使ったUARTは断念することにした。ウェブにあったように、UART受信バッファーを10ms程度のウェイト(OSにCPUを返す)を入れて覗く方式(ポーリング方式)で妥協することにする。UART入力は端末のキーボードからだけなのでこれで何の問題もないのだけれど、何となく気に入らない。それでもこれでLCDでのOSエラーはなくなった。

 同じARMでもNXPの開発環境は、I/Oレジスターのヘッダーファイルが用意されているだけで、アセンブラーのようにせっせと設定していく方法である。STMに較べると遅れているようだ。それでmbedのクラウドIDE方式で一気に飛躍しようとしているのだろうか。そういえばまだmbedは、LEDチカチカを確認しただけで、全く先に進んでいない。こいつはPHY層も含めたイーサネットインターフェースがあるらしいので早くいじってみたいのだが、現在はおあづけである。

LPC2388でSDカードを動かす(5/24/11)
 割り込み環境が思ったように導入できず、少し手詰まりになったので、気分を換えてLAN基板の横にスペースをあけて用意してあったSDカードスロットの実装を始めることにした。アートワークは、これまでの作業の合間に少しづつ描いていて既に完成している。

S_p5273949

 思ったより早くできた。まあ、プルアップ抵抗を5本ほどつなぐだけだけだから大した作業ではない。このあたりのハンダ付けは、汎用基板、プリント基板あわせて10回以上やっている。手馴れた作業である。回路図は、雑誌(インターフェース2009年6月号)記事を使う。もっとも、定数を含めてこれまでに紹介された回路図と殆ど変更はない。MCIモジュール(SDモード4ビットバス)が動くための結線部分が違うだけだ。

 これでLPC2388のLAN&SDカード基板(雑誌付録の拡張基板とほぼ同じ仕様)のハード工作は大体予定通り終わった。SDカードの動作テストを早くやりたいのだが、現在のFreeRTOSのテストベンチに、FatFSを組み込むのは大変だ。

 ねむいさんのFreeRTOS_V6のMakeFileにはFatFSを入れようとした痕跡が残っているが、実際のリソースは入っていない。単に1タスクのファイルシステムだけなら簡単そうだが、FreeRTOSの標準ファイルシステムにするのは、結構大変なはずだ(FatFSそのものはリエントラントなので十分対応可能だが)。

 どうしようか迷ったが、FreeRTOSの1タスクとして入れるのも先に延ばし、雑誌記事のChaNさんの単独システムを先にいれて、SDカード周りの動作だけでも確認することにした(慎重と言うか臆病である)。雑誌のダウンロードサイトから、2009年6月号のソース一式を頂く。以前にご本人のページからダウンロードしてあったソースとFatFSの部分は大きく変わっていないようだ。

 コンパイラーは、WINARMのarm-elf-gccだったが、うちのWINARM環境は自信がないので、いつものようにCodeSourceryのarm-none-eabiに換える。OLED液晶の部分はついていなくても動くと言うことなので、ソースには手を入れない。

 ビルドはリンクしているライブラリもないので、あっさりNo Errorで終了した。しかし、ファーム書き込みは時間がかかる。LFN用の64KBものコードブックをフラッシュに書いているからだ。遅いはずだ。少し待って書き込みは終了した。

 早速、動かしてみる。うんともすんとも言わない。そういえばREADME.TXTにOLEDかファイルモニターの切り替えは、ESCキーを押せとあった。シリアルの速度を合わさないとキーを押してもESCの区別がつかないはずだ。230Kbpsに合わせて、ESCを押す、よーし、Monitorの開始を知らせるオープニングメッセージが出た。手近のSDカードをさしてテスト。うーむ、Disk Errorだ。

 ディスクが入っていないことを示すエラーコードである。さて、動かないとなると最初から腰をすえて調べなければならない。ファームはまず間違いがないだろう。とすると、ハードだが、昔に較べると配線技術は、格段に向上していて最近は配線ミスが殆どない。あっても事前にチェックできている。誤配線よりもっと簡単なところのミスを疑う。

 ここに入っているファームは、ソースコードを見るとSDカードの所在や、ライトプロテクトまでチェックしているフルバージョンだ。まず、これが動いているかどうか調べてみよう。このあたりはSDカードを始めて動かそうとしたとき、散々苦労したところだ。

 CD(カード検出)は負論理なので、このピンはカードを入れたときグランドに落ちていないといけない。テスターで測る。あれえ、グランドになっていない。ややや、このピンはスロット筐体とはつながってる。何だと筐体とグランドピンは浮いているのか。何と、何と、ここは明示的につながないと駄目なのだ。これまでの実装は、このあたりを無視していたことが多いので、分離しているのに気がつかなかった(スロットは秋月で買ったノーブランドの小型のもの)。

Lpc2388_fatfs

 これで動くのではという淡い期待に胸を膨らませながら、筐体とグランドピンをハンダ付けしてテストを再開する。こんなもので動けば楽なもんだけど、そうはうまくいかないだろうな。

 電源を入れる。モニターを出す。初期化コマンドdiを入れる。エラーなし。おっ、動いたか。ファイルリストを出すコマンドを入れる。やった。やりました。お馴染みのファイル名が並んだリストがUARTに並んだ。いやあ、ここも、配線間違いなし。気分が明るい。

 アクセス速度を測る。雑誌の記事によれば、データアクセスは、LPC2388のMCIモジュールを使ったSDカード4ビットバスで、ぶっちぎりの早さ(ねむいさん)だそうだ。測ってみた。すごい。どのSDカードも64KBくらいなら、4MB/sec近辺という猛烈な早さだ。これなら動画も送れそうだ。これは楽しみになってきた。

 このFatFSは、FreeRTOSで動かすという大仕事が残っているが、LPC2388のLAN&SDカード基板はこれで完成した。これまでにかかった費用を計算してみる。PHY層チップ(DP83848C)は1枚こわしたので2枚として¥1200(失敗しなければ¥600)、ピッチ変換基板(アイテムラボ)1ヶ¥180、べたアース基板(サンハヤト)¥250、モジュラージャック(秋月パルストランスLED付き)¥300、SDカードスロット¥150、50Mhzオシレーター¥260、CRは全部で¥100するかしないか、ヘッダーピンソケット¥80くらい(この辺は全て手持ち)。あれこれ合わせて¥2,520。

S_p5273941

 そもそものきっかけ、法外な価格で買うのを反発した雑誌のタイアップLAN&SDカード拡張基板は¥6800だったから、これのほぼ1/3というところか。自分の作業工賃をどう考えるか? DigiKeyのゲタに買ったmbedの¥5400はどう考えるかって? え、まあ、こういうことは聞かないお約束と言うことで。そうかmbedも動かしてやらないといけないな。

FreeRTOSにRTCを入れる(5/26/2011)
 雑誌付録ARM基板LPC2388のLAN&SDカード拡張基板が両方ともうまく動いたので意気が上がっている。矢でも鉄砲でも持ってこいくらいの状態である。調子に乗って、FatFSをFreeRTOSで動かす前に、残っていた課題を片付けることにする。LPC2388のRTC(リアルタイムクロック)機能である。

 この雑誌付録基板は、LPC2388が、バッテリーバックアップのできるRTCを持っているのに、そのバックアップ電源Vbatピンを基板上でVccにつないでしまっており、せっかくの機能が台無しになっている。

 これでは何のためのRTCかわからないと思っていたら、ChaNさんが動画サイトで器用に、0.5ミリピッチのICの足を切ってVbatを独立させている工作を見て、感嘆した。

 当研究所でも、これに刺激され、早くにバッテリーバックアップに挑戦して成功している。しかし、電池をつないだだけで、まだ動くかどうかの確認をしていない。ここは是非試しておきたいところだ。動けば、FatFSのタイムスタンプにも使える。

 今動いているFreeRTOSのソースチェーンには何故かrtc.cは入っているが、どこにもこれを動かすコードは入っていない。ねむいさんのサイトを見てみると、FreeRTOSではなく、単独で実装されているようだ。とりあえず有難くソースを頂く。

 FreeRTOS上では動かなかったのだろうか。ソースを調べていく。そうでもないらしい。ただ、このRTCのコード(rtc_support.cとmain.c)には、割り込みルーチンが入っていて、簡単には入りそうにない。FreeRTOS上の割り込み環境は、結構難しく、UARTの割り込みを使ったコードはうまくビルドできないであきらめている。

 __irqというオプションが割込みハンドラー宣言に入っていて、ここでコンパイルエラーを起こす。ウェブの情報によれば、これをはずして、__attribute__ (((interrupt("IRQ")) に換えると良いというので、そうすると今度は、このオプションはthumbモードではサポートしないとコンパイラーに怒られる。ねむいさんのコードの割り込みにも__irqオプションが入っている。ねむいさんにお助けメールを出したが、忙しいらしく返事は前のようにすぐには戻ってこない。

 出来ないとなると悔しくて余計意地になるのが性分である。色々ウェブをさまよう。解決策は見当たらない。しかし落ち着いて考えてみると、RTCの機能はハードなので、何も割り込みを使わなければ動かないというものではない。では何故割り込みを使っているかというと、1秒ごとにディスプレイに出すためだけのようである。

 ここで閃いた。1秒ごとなら何も割り込みを使う必要ない。OSの元で動いているのだ、別タスクを立ち上げて、1秒ごとにRTCを調べれば良いはずだ。そうか、割り込みを使わないでも出来そうだ。

 思い立った時の手の早さには自信がある。rtc_support.cの割り込み部分を全部とり、見よう見まねで、FreeRTOSの新しいRTCタスクを新設する。このタスクはRTCを初期化して動かした後は、1秒の待ちを入れてUARTに時間を表示する。目覚ましのようなタイマーだってこれで作ろうと思えば作れる。OSにだいぶ慣れてきた。

Lpc2388_rtc

 喜び勇んでビルド。よーし、No Errorだ。ファームを書き込む。UARTを立ち上げる。おおお、初期設定をうながすメッセージがでたぞ。年月日を入れていく。やった。動いた。RTCが時間を表示し始めた。ありゃ、止まっちまった。どうもprintfが大きすぎてスタックがあふれたような止まり方だ。ウェブも止まって暴走している。

 年月日時分秒すべてを出す表示を縮めて再トライ。ついでにタスクのスタックサイズをUARTと同じに広げる。よーし、順調に時間が表示されてきた。バックアップは大丈夫か。電源を切って暫くしてからもういちど動かす。良いぞ、バックアップされている。ほぼ2年ぶりの確認である。いやいや、これで32.767Khzの時計用クリスタルと、コイン電池の顔が立った。

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

«FreeRTOSのウェブサーバーが動いた