« 2011年6月 | トップページ | 2011年8月 »

2011年7月の3件の記事

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月 | トップページ | 2011年8月 »