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

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

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

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

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

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

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

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

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

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

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

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

　基板の配線図をショップのウェブから入手し、部品リストを作る。そろそろ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をつけるチャンスである。

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

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

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

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

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

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

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

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

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

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

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

突然動かなくなる(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の価格（一時、品切れだったが、最近戻ったようだ）で、効果は変わらない。

　しまってあった雑誌付録のオリジナル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日間は完全にこれにふりまわされた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　それが、何故買う気になったのか。フューズビットを書き損なった石が増えてきたこともある。それならパラレルライターを自作すればよい。制作例はいたるところにころがっている。実はブレッドボードで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とのあいだをフラットケーブルのジャンパーでつなぐことにする。

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

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

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

　しかも、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のテストが待っている。

見事に２つとも生還(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％の元はとったことになる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いまいちよくわからないが、自己流の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のパラメーターをあれこれいじって、ヒーターの熱制御をスムーズにしようと頑張ったが、結局、目の覚めるような改善は出来なかった。しかし、まあ、こんなものかという程度までは制御が出来るようになった。グラフがその苦労のあとである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

しゃれた二次曲線の比例制御ではうまくいかない(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の全電力がかかる）。比例制御は最初からやるべきか。

　おやあ、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でなく倍にしてみてはどうだろうか。

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

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

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

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

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

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

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

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

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

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

　いつものようにアートワークを始める。下の主基板の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つのはないので今度の工作には使えない。ただ黙々とつないでいくしかない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

熱電対温度計に決める(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を含めたレイアウトが悩ましい。

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

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

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

　するとまたこれも作りたくなり、以前買ってあった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もある。これは助かった。

　しかし、入力オフセット電圧の測定でつまづく。ボルテージフォロワーでそれぞれのオフセット電圧（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がデタラメながら点滅しはじめた。ここまで来たらあともう少しだ。

　このあと、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が点って、それぞれ動くところまで来た。

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

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

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

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

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

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

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

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

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

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

　しかし、日を替えてテストしてみると同じ管でも、一定にはならず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時間づつ動かして、驚くべき事実が明らかになった。

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

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

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

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

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

例のマントルを近づけると、ケースの中に入れた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に電圧不足のメッセージを出すことも出来る。今までの方法だと、何の挨拶もなく落ちるので、故障なのか、電池不足なのか判断ができないので困っていたのだ。これは一石二鳥だ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　この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がリセットしてしまうようになった。こうなったらリセットの原因を徹底的に究明しないと解決しない。（今度の回路はリチウム電池の過放電防止回路がついているが、これをバイパスさせても起きるので、これが原因ではない）。

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

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

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

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

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

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

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

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

CHANEYガイガーカウンターはソフトパワースイッチにする(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だ。トランジスターとは大違いである。

　今度の電源制御は、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ほど流れている。

　ありゃあ、電圧計は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になって安心である。

　ところが、ありあわせの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より明らかに多い。しかも、時間がたつに連れて増えてくる。

　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の光も強く、パルスも見たところ一番少なくなったように見えた。

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

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

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

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

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

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

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

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

K型熱電対と遊ぶための準備(9/2/2011)
　SparkFunのキットの後始末が一段落しブログにその顛末をアップしてから、高揚した気分が一気に落ち着いた。モチベーションが下がり暫くは何もしたくない気分である。ところが不思議なことに、頭は休養を要求していても、手は何か動かしていないと落ち着かない性分になってしまった。本当に困ったものである。

　というわけでもないが、これまでちょっとづつ準備し、部品を集めてきた熱電対の温度測定の回路をブレッドボードで作り上げる。このページに触発されたアナログ回路である。少しアナログづいているのかもしれない。アナログが楽しい。最初は、温度測定だけだが、最終的には、SSR（ソリッドステートリレー）を使った温度制御をやる。強電工作第二段である。

　そもそもは、このあいだ作ったアクリル曲げ器の温度制御がやりたくて、秋月でK型熱電対を衝動買いしたことが始まりである。昔から炎など普通の温度計では測れない高温を測定したいと思っていた。偶然、同じ動機を持った人がサイトにわかりやすい熱電対の使い方を解説していて、チェックしてあった。

　熱電対による温度測定には専用のICが用意されており、これを使えばこれから作る回路は全く必要ない（以前の記事参照）。しかし、そこは凝り性の性格である。この面倒な補正をやってみたというこのページを見逃すわけには行かない。

　アクリル曲げ器の方は、このあいだ実際にオッシロの高圧測定の分圧器の端子盤を作るのに使ってみた。うすっぺらいアクリル板（CDケース）を使ったやっつけの簡単な加工だが、結構それらしく出来た。まともなケースを作るところまでになるにはまだ先が長いが、こういう簡易なしかけをつくるくらいは簡単だ。回数を重ねればもっと上手くなるだろう。このアクリル曲げ器にもう少し資本投下してみることにしよう。

　温度センサーと熱電対を組み合わせた温度計のアナログ回路そのものは、記事にあるように至極簡単である。多回転ボリューム2つで倍率を調整する。温度センサーと熱電対の熱勾配を一緒にしておけば、温度センサーと熱電対の検出電圧の和が、実際の温度になるという理屈である（熱電対は2電極の温度差しか出さないので、冷極の温度が必要）。合算された電圧をオペアンプで増幅してADコンバータにかける。

　結構、これが面白い。反転増幅器の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まで上昇する。これは少し高すぎる。

　もうひとつの指摘は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スクリーンの窓を開ける必要がある。

　LCDの固定は少し工夫してみた。これまで、LCDの固定は、基板からポストで固定して化粧板には窓だけ開ける方法か、化粧板にネジで固定して基板とコードでつなぐかの、どちらかの方式だった。今度の基板は、CHANEYのキットが入って2段になり基板からポストを立てるのは難しい。とすると、化粧板に固定する方式だが、ネジが表から見えてしまうのは、みっともないなと前々から思っていた。

　裏からネジを当てれば良いが、のりしろが少ない（基板1.6ミリ、ケース厚2ミリ）ので小さいネジでは不安だし、少し大きくすればネジが突き抜ける心配がある。そこで、2ミリのアクリル小片を3枚使い、中にLCD基板をはさむ方式を考えた。

　こうするとLCDパネルが化粧板から大きくはみ出るのも防げる。サーキュラーソーがあるので、アクリルの小片は簡単に正確なものがいくらでも作れる。接着剤も、接着面が広いので滅法強い固定ができる。ちょっとのことでははがれない。

　出来上がりは予想以上にうまくいった。片側は枠を作るだけでネジを使わない。はさむだけである。もう一方も同じような枠を作り、上蓋を2.6ミリのタッピングネジで止める。簡単に出来て、しかも確実にLCDが固定できた。嬉しくて何度もつけたりはずしたりして出来上がりを喜ぶ。他愛ないものである。

　主基板の工作も進める。CHANEYのキットは高さ10ミリのポストで主基板上につけ、パルス検出LEDが化粧板になるべく近くなるようにする。主基板には、電池と、CPU基板などが入る。最初、ケースの上蓋をうっかり逆にして、蓋を閉めようとしてLCDがガイガー管にあたり、管をわずかだがへこましてしまう。一瞬、肝が冷えたが、問題なく動いて胸をなでおろす。

　電池は、例の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をつけて遊ぶくらいにしか使われていない。

　そうだ、これなら、リチウムバッテリー(4.2V)からなので5Vに高効率で昇圧できる。200mAまでとれるので全く余裕だ（LCDはバックライト無しなので全部で10mAも流れない）。シリーズレギュレーターよりはるかに地球に優しい（おおげさな）。これで、電源ICを2つに出来る。

　しかし今度は、リチウム電池の過放電が心配である。これまでは、シリーズレギュレーターなので電圧が下がればLCDが薄くなったり、音が割れてきたりして電圧低下がすぐわかったが、DC-DCコンバーターは、ギリギリまで電圧を維持し電源から電気をしぼりとる。こいつは何らかの予防手段をとらないと危ない。

　そこで、あらたに電源電圧が一定以下になれば供給をストップする過放電防止回路を検討した。最初は、AVRのADコンバータかなにかで調べてなどと大層なことを考えていたが、ウェブですごく簡単なものを見つけた。リセットICを使う方法である。リセットICは電圧が規定以下になると、論理0を出力する。こいつは簡単だ。

　でも、このページ何か前に見たようなページだなあと、良く見たら、何と何とAVRを始めたころお世話になったkumanさんのサイトだった。ローサイドでnMOS-FETをリセットICの出力でスイッチし、リチウム電池の過放電を防止する方法である。部品はたったそれだけ。

　ただリセットICは閾値が2.6V（3.3V用）なので、リチウム電池の下限まで上げてやる必要がある。kumanさんは、ダイオードを使っておられたが、ここは半固定か何かの抵抗で分圧した方が良いかもしれない。いずれにしても、以前、電子リモコンボリュームの電源を切る時に1ヶ使ったきりで遊んでいたリセットICが役に立つことは有難い。kumanさん、ありがとう。

Windowsのプログラム開発に手を出す。AVRSPの再ビルド(9/10/2011)
　可能な限り敬遠していたPC上のプログラム開発をどうしてもやらなければならなくなり、久しぶりにコマンドラインでChaNさんのAVRSPをソースからビルドした。

　そのきっかけは、DigiKeyから買ったTQFPのMega328である。CHANEYのキットのCPUにするべく、鼻歌まじりで、秋月で買った変換基板に取り付け、クリスタルやパスコンなどを基板上に表面実装し、機嫌よくブレッドボードで動作テストを開始した。

　ところが、愛用のプログラムライター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変数宣言）、恐る恐るコンパイルしてみる。

　いやあ、沢山コンパイルエラーが出る。念のため修正前のオリジナルでコンパイル。なーんだ、最初からエラーが出ている。ふむふむ、_outpとか、_inpというダイレクトにポートを叩く関数がライブラリーにないようだ。GiVEIO用のライブラリが見つからない。

　おや、このページは、本来はAVRSPをユーザーモードで動かす方法(GIVEIOを使わない)の紹介で、別のフリーのライブラリをリンクすれば、これが出来るようなことが書いてある。店をこれ以上広げたくはないけれど、この際これに乗っかってみよう。言われるとおりのライブラリをダウンロードしてリンクしてみる。

　よーし、コンパイルは警告だけになった。うむ、EXEファイルが出来たようである。だめもとで、こいつを動かしてみた。おおー良いぞ。無印のMega328を認識した。フューズビットは変えられるか。よしよし、これも大丈夫だ。オシロには勢い良く8MHzのクリスタルの発振波形が確認できた。勢いに乗ってSparkFunで動かしているファームを焼いてみる。問題なく焼けた。LEDなどがブリンクし、UARTからメッセージが出る。これで万全だ。

　いやいや、こういう抜け道のようなコンパイルでAVRSPが作り直せた。こんなに簡単にWindows（まあ限りなくDOSですが）のプログラムがコンパイルできるとは正直、思っていなかった。それにしても、ソースコードがあるというのはありがたいことである。　このページの作者、木村 真也さん、それにChaNさん、ありがとう。

SparkFunのガイガーカウンターを正しく動かす

　前回の記事の反響は大きかった。次の日、研究所開設以来の最大アクセス(一日866)を記録したかと思ったら、週明けの月曜はその記録もあっさり抜いて一日のアクセスが1200を越えた（1244)。いつもの3倍である。

　「ゆきの研究室」という著名なサイト（ここの作品は見事と言うしかない）や、所長もお世話になっているsimさんあたりが話題にしてくれてアクセスに拍車がかかった。有難いことだと思うと同時に何か責任の重さを感じる（あまり好き勝手なことが出来なくなってくる）。

　ただ、SparkFunのキットの問題は、前回ですべてが解決したわけではない。もう少しこのキットにこだわってみることにした。それにしても、つっこみどころ満載のキットである。

時々動かなくなる原因を見つけたか(8/26/2011)
　ブログの初日のアクセス急増はツイッターによるところが大きい。アクセスログに見慣れないリンク先が出てくるのでアクセスすると、自分のブログが出てくる。Googleで検索しても見つからない。おかしいなあと思って、このあたりに詳しい娘に聞くとツィッターの短縮URLというものらしい。ツィッターのページからは検索できる。所長もあわててツィッター登録し、震源地を調査した。これが不慣れで、どなたが最初にtwittしたのか見極められない。とりあえず、この場を借りて御礼申し上げておきたい。

　それはともかく、過大電圧でガイガー管を壊してしまう危険は回避した。しかし、そもそもはそれが問題ではなかった。最初のトラブルは時々動かなくなることだった。この原因は解明されていない。　このトラブルシューティングのために部品を次々にはずし、結果としてブレッドボード上に別の部品で配線図どおり組み立てて動かすところまで行った（トランスだけは、基板から取り出した同じもの）。この状態では高圧が出なくなることは一度も起きていない。

　時々動かなくなるのは、基板上の発振回路のパターンに、接着剤でスペーサーをつけたためと結論付けたが、どうも納得できていない。接着剤そのものは絶縁物だし、基板の上にはかなり厚いレジストが塗られており、これが原因とは考えにくい。トランジスターは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に下がった。しかし、今度は、パルスを拾えなくなってしまった。今まで効果のあった出力回路にあるコンデンサーの値をいくら小さくしても駄目である。

　試しに、このコンデンサーをはずしてみた。さすがにこれでパルスを拾うようになったが、オシロで見てみると、このパルスは、反応パルスが起きた後の電源の変動のピークも拾っている。多数のパルスが起きる。電圧が下がったせいで本来のパルスが小さくなり区別がつかなくなっている。

　どうもおかしい。トランジスターのベースに入る入力パルスが負電圧なのだ。GM管の反応パルスは、高電圧から一気に0Vに落ちるパルスなので、コンデンサーを通すと逆方向に電流が流れ、ベースが負電圧になるのは納得できる。ところが、どういうわけか今までの検出は、このパルスのオーバーシュートの部分でベース電圧がプラスになるところで、コレクター電流が流れてパルスが落ちる。結果として、正論理のままの出力になる

　これは明らかにおかしい。オーバーシュートの部分をトリガーにしている。考えてみれば、GM管の反応が負論理なのに、トランジスターの出力も負論理のままである。本来のトランジスターバッファーは反転しなければならない。

　これまでの過大電圧（1500V近く）のときは、GM管は10ms以上の間、立て続けにパルスが発生し、派手なオーバーシュートが出ていたので、コンデンサーでなまらせて1パルスにしていたが、定格のパルスでは、このままでは正規のパルスと電源変動のパルスの区別がつかない。

　パルスが負電圧なので、いわばプルアップしてやれば良い筈だと、ベースに交流増幅のように分圧抵抗で持ち上げるが駄目。パルスが消えてしまう。ウェブで「負電圧　ベース入力　プルアップ」などのキーワードで調べるが埒（らち）は明かない。トランジスター回路の応用なのだが、アナログの素人の悲しさ、どうしてこれを解決すれば良いのか方策が見当たらない。

先人の回路を真似る。見事なパルス（8/29/2011)
　そのうち気がついた。自分で回路を開発しようというのが無謀なのだ。他の人がどうやっているか調べてみるべきだ。これまでの集めてきた自作ガイガーカウンターのサイトをしらみつぶしに検出回路について調べてみた。

　すると、ここのサイトの説明で、謎がすっかり解けた。ここには簡潔に書いてある。「アノード検出回路は、負パルスなのでPNPトランジスターを使います。」なるほど、そういうことなのか。NPNで一生懸命プルアップしても、ベースとエミッターの間の電圧は一定なので動作点が変わってしまい、負電圧は拾えないのだ（少し勉強した）。

　SparkFunの検出回路はGM管のアノードからなのに、NPNを使っている。そもそも根本的なところから間違っている。これではまともなパルスは検出できないわけだ。しかし、市販のキットでもこんなことがあるのかとちょっとあきれ気味である。しかも、クリエイティブコモンで、回路図もボード図もEagleで公開している。暇があったら英訳して送ってあげたいところだ。

　検出回路をブレッドボードに移して、このサイトの回路図や、別のサイト（ここや、ここ）でも見つけた回路図を参考に、回路を組んでみた。ブレッドボードなので簡単に組みあがる。オシロで波形を見る。おおお、何と言う美しさだ。見事な検出パルスが出た。サイドのノイズは、回路図にある100pFのコンデンサーで綺麗に消えた。素晴らしい。教科書にでてくるようなパルスだ。マイコンは立下りでとっているはずで、ソフトは全くいじらないで、この正パルスで動くはずだ。

キットの実装に熱中する(8/31/2011)
　ブレッドボードの検出回路は見事に動いた。次はキットの基板への実装である。頭を捻る。検出TRのパッケージはチップでなくお馴染みのTO-62（MPSA18）だ。NPNからPNPに換える必要がある。PNPは手持ちの2SA1015で、キットの石のピンアサインは、CHANEYのときと同じ、EBCである。注意しないと前の二の舞になる。

　こういう改良は、なぜか心が躍る。いかにこれまでのパターンを活用して簡潔に回路を完成させるか。メモ用紙に実体図を描いて検討する。ほどなく空中配線にならず、一番合理的な方法を考え付いた(おおげさな)。

　まず、カッターでTRのエミッターの接地部分を切り離す。ここは感心にもスルーホールになっていた。そうか、トランスのところも最初はスルーホールだったが、トランスのピンが大きすぎて広げた結果、そうでなくなってしまったのかもしれないと勝手な推理をする。

　当初のエミッターのピンはご丁寧に両面ともベタアースにつながっており、ここはPNPになるとVccにつながるので余裕を見てカットしておかないといけない。切り離しに時間がかかる。ルーペで何度も確認する。

　次は、部品面にある1KΩのダンピング抵抗を47Kに変更し、プルアップ抵抗(1M)とノイズ防止コンデンサー(100pF)をハンダ面に固定する。Vccラインを遠方から引っ張ってトランジスター(エミッター）のところへ配線する。最後は、当初のVccからのプルアップ抵抗(1K)を除去し、4.7μFの載っていた大きなランドにコレクターの負荷抵抗（100K）をつければ完了である。

　何度も配線をなぞって間違いがないか確かめる。よーし、問題ない。これで動くはずだ。念を入れて電源をONする。暫くたって赤いLEDが消え、LCDに「ケンチシマシタ！」のメッセージが出た。いやあ、SparkFunのガイガーカウンターは、これでやっと本来の機能を取り戻した。GM管の高圧は、400～450V。問題ない値だ。

　回路図はいくつかのサイトを参考にさせてもらったが、著作権の問題を避けるために、そのまま掲載することはやめることにする。リンク先の回路図をご覧になっていただきたい。回路図がなくてもこれまでの説明と画像で変更はできる。ただし、トランジスターのピンアサインにはくれぐれもご注意（前々回記事参照）。

　ついでに、ソースコードの修正をしておく。正規のパルスにしたせいでタイマーの1tick 128μs以内に複数回起きるパルスを拾うようになった。LND712のデッドタイムは、90μsなので、128/2=64μsは、独立したパルスとみなさないほうが良い。これを無視するように修正してある。

ここに、AVRStudioのプロジェクトになったソース一式を置きます。

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

遂にSparkFunガイガーカウンターの不具合を解決した

　とうとう、SparkFunのガイガーカウンターキットの不具合（と言って良いだろう）の原因を解明した。もし、同じこのキットをお持ちの方は、この記事の最後に出てくる改修を出来る限り早く実施された方が良いだろう。さもないと、虎の子のガイガーミュラー管LND712を失う可能性が高い。

なぜ高電圧のまま出荷されていたのか理由がわかった(8/22/2011)
　SparkFunのガイガーカウンターキットの高圧部は、高入力抵抗の電圧計でも1500V近く、分圧器（1GΩ）を使ったオシロでも同じくらいの電圧がかかっていることが確認された。2種類の測定で同じ値だ。この電圧に間違いないだろう。このキットのガイガー管（以下GM管）はLND712で定格は500V、この電圧は余りにも高すぎる。

　Sparkfunのフォーラムには、以前の記事でも紹介したように、900V以上電圧が出ているよというユーザーの投書があり、Sparkfunから調べておくという返事があってそのままになっている。

　しかし、発振回路を調整して500Vに下げると、こんどは放射線パルスを感知しない。ガイガーカウンターとしての機能を果たさない。仕方がないので、元へ戻すと、高圧部から、異音が発生して電圧が断続的に低下し、正常な観測が出来なくなる。このブログにも同じような悩みを持っている人からのコメントがある。

　こちらで最初、高圧がでなくなったのは、当方の原因（配線パターンに接着剤をつけた）のようだが、電圧が高すぎることについては全く思い当たる節はない。フライバックトランスの出力は、オシロで見た限りでは、p-pで160～180V、3倍圧整流回路を通って、500V近辺になるはずだが、ウェブ情報などによると、フライバックトランスによる発振は安定でなく共振すると突然上がったり下がったりすると言う。

　そのため、Sparkfunがお手本にしたらしい回路には、ツェナーダイオードを直列にした電圧制限回路が入っており、一定の電圧以上では、ドライバーに制限がかかって出力が下がるようになっている。ところがSparkFunの回路は、なぜかこの部分が省かれている。

　いずれにしても、定格にすると機能しない。高圧に戻すと検知はするものの、異音が出て電圧が下がる。進退窮まって、もうSparkfunのキットは諦めようと思っていた（前記事にはそう書いた）ときのことである。

　GM管からの波形をオシロで見るともなしに見ながら、ふと、このGM管の放射線検知によるパルス波形が、これまでのウェブで見たお馴染みのパルス波形でなく、えらく派手なのに気がついた。

　ふーむ、ウェブで見るパルスは一回限りで、こんなに20ms近い連続したパルスではない。500Vではこのキットでは検知しないが、もしかしたら、このGM管はパルスを出していても回路が認知していないだけなのではないかという感じがしてきた。

　500Vに電圧を下げる。前のようなパルスは発生しない。つまり検知しない。オシロのスキャンの時間を一旦長くしておいてから、様子を見る。おっ、何か非常に短いがパルスが出ている感じがする。少しづつスキャン時間を短くしていく。そうだ、1現象ではなく、GM管から引き出されている信号出力にもオシロをかけてみよう。さらにトリガーをAutoでなく、検知したらそこで止まるNormalモードにしてみた。

　ビンゴ！である。トランジスターのベースには綺麗なパルスが入っているのが確認できた。間隔は、環境放射線の線量に近い間隔だ。なーんだ。ちゃんと検知しているではないか。それなのに何故マイコンの方には伝えられないのだ？

　回路図を見る。おおお、検知トランジスターのコレクターに4.7μFのコンデンサーが入っている。今まで気がつかなかったけれど、こんなに大きな時定数では、GM管の短いパルスは吸収されてしまうはずだ。

　わかったぞ、わかったぞ。このコンデンサーを使っていると言うことは、さきほどの派手なパルスを1パルスにするための定数だったのだ。今までの事実の断片が、次々につながって確かなストーリーが出来上がっていく。全部の謎がずるずると解けていくのがわかる。このコンデンサーの定数が動かぬ証拠だ。

　Sparkfunの開発者は、何らかの理由で電圧制限回路を省略し、電圧が1500V近くに上がっていることに気づかず、そのときのGM管の高圧でのパルス挙動を通常のパルスと勘違いし、このパルスで1カウントになるように、このコンデンサーを調整したのだ。

恐らく内部抵抗の低い計測器で高圧を測ったのだろう。高圧部の測定値が実際よりかなり低く、フライバック発振の電圧を見ているので3倍圧整流回路を通っても500V以下と確信していたに違いない。

　1500V近辺のLND712の放射線感知の波形は、多数のパルスが長時間でる(20ms以上）。設計者はこれに合わせて、信号検知の時定数を大きくし、結果として、通常のGM管の反応の時はパルスを拾わなくなってしまった。本来のGM管の反応パルスは、非常に短く（100μｓ程度）、この定数では隠れてしまう。

　アメリカでは余り問題にならず、日本のユーザーで「動かなくなった」という声があるのは、アメリカが日本に較べれば、圧倒的に湿度が低いため、数倍の電圧でもおかしくならなかったのだろう。

　日本の湿度はアメリカでは想像できないほど高い。これによって、LND712の絶縁が限度を越えてしまった可能性が高い。カンッカンッと音がしていたのは、定格の3倍近い電圧を喰らってリークしているGM管の悲鳴だったのだ。危ない、危ない。

　謎が解ければ、対処の方法は簡単だ。基板上の4.7μFのコンデンサーをはずし、少し極端だが、0.1μFに減らしてみる。よーし、良いぞ、500Vでも、しっかり反応をするようになった。オシロでみると少し少なすぎてパルスを余分に集めてしまいそうだが、これはあとで調整できる。

　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の正規パルスを拾うようになる。ただし、この定数は調整する
　　必要があるだろう。余り小さいと主パルスに付随する弱いパルスを独立した
　　パルスとして拾ってしまう可能性がある。

　(1)は1μFより、0.5μFにした方が良いかもしれない。（ 1μでも定格の500Vを超える）。一番良いのは、前回記事の海外サイトのオリジナル回路のように、ツェナー（またはバリスター）で高圧電圧を測りフィードバックして制御するのが一番確実だ。ブロッキング発振は、調整が難しい。原作者はそれを知っていて電圧制限回路を加えていた。これならツェナーダイオードで設定した以上の電圧はかからない。

　面実装の部品を取り外すのは通常では難しい。10μFのチップコンデンサーは2012クラスで、この程度なら、半田ごて一本で辛うじてはずせると思うが、4.7μFのコンデンサーは大きくてパタンが離れているので、はずすのは苦労するだろう。半田ごて2本あればとれると思うが、簡単にとるには、所長の愛用しているサンハヤトの低温特殊ハンダをお勧めする。少し高い(千石電商で￥4200)が、こういう表面実装部品のとりはずしはうそのように簡単になる。

ガイガーカウンター制作は迷走が続く

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)自作しようと思っていた。買ったのは大分前で、なかなか実装する機会がなかったがちょうど良いチャンスが巡ってきた。ブレッドボードではうまく動かないという話を聞いていたので(発振回路が微妙なのだそうだ）、直接、基板を切り出して作りこんだ。

　誤配線もなく、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)も手に入れた。高圧用のコンデンサーもここで買う。この店は目が離せない。千石、秋月にない商品が揃っている。

　部品を持ち帰って、まずは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を越えた。

　トランジスターが原因ではなかった。しかし、それなら何故、交換で動いた？　やったことは、面実装のTRを取り外したことと、LCDへつなぐソケット基板を、固定するスペーサーから浮かしただけである。スペーサーの片側はまだはずしていない。鉄（ステンレス）ネジが基板に近づいたから？まさか。　謎は深まるばかりである。

　ただ、このスペーサーをなくすことは出来ない。ソケット基板の固定が出来なくなってしまう。もう、何がなにやらさっぱり見当がつかなくなって呆然自失の状態である。

SparkFunの回路のモデルを発見。ブレッドボードで作り直し(8/21/2011)
　そうは言っても、ころんでもただでは起きない性分の所長である。しつこいことには自信がある（自慢にならないか）。完全に手段が目的化しているが、このまま黙ってSparkFunのキットを見捨てるわけには行かなくなった。ここまで来れば、何とか原因を解明しないことには気がすまない。

　来週、旧友に会ってガイガーカウンターを持ち込んで自慢しようと思っていたが、それどころではなくなった。事態を冷静に見直して、やはりプリント基板の上に、気楽にスペーサーを接着したのが原因ではないかと感じ始めた。基板は、かなり厚いレジストが表面に塗られているが、発振回路なので微妙だ。

　それを確認するのは、もういちど回路を別のところで作り直すしかない、と思っていたときに、偶然、SparkFunの高圧回路のオリジナルとおぼしい回路を海外のサイトで見つけた。これ、これ。間違いない。全く同じように音響トランスをフライバックトランスに使った回路だ。

　あれ、この回路には、高圧からツェナーダイオード2ヶを使った回路がついていてTR一個でドライバーTRの出力を制御する電圧制限回路がついている。しかし、SparkFunではこれが省略されている。

　ふーむ、謎が解けてきたぞ。やっぱりこの回路はほっておくと500Vでは納まらないのだ。だから、制限回路がついている。1500Vを観測しているが、やっぱりこれだけの電圧が出ていた可能性が高い。とすると、GM管は、過電圧を長時間かけられたために、正規の500Vでは動かなくなったのか(800Vでは動かなかった）。

　このあたりは、あとで調べることとして、今は、接着剤で回路がおかしくなったという仮説を証明するのが先だ。ブレッドボードで同じ回路を組んでみることにした。こういうこともあろうかとこのあいだ行った秋葉原で小さなブレッドボードを入手してある。SparkFunのキットから音響トランスもとりはずす。

　ブレッドボードはやはり便利だ。あっというまに音響トランスを使った高圧ドライバーが完成した。こんどは、オシロで観測もしやすい。このドライバーだけで動かしてみる。波形を観測した。すごいパルスだ。P-Pで140V、3倍圧の整流回路にかければ、500V近くが取り出せるしかけのようだ。

　元のチップTRをブレッドボードに差し込んで実験してみる。何のことはない。これでも全く同じ電圧、波形が観測された。TRが原因でないことは明らかになった。やれやれ。

　いよいよ、本体に接続。少し賢くなって、オシロで高圧が測れるように、もうひとつの1Gオームで分圧器を作った。このあいだのアクリル曲げ器で、CDケースの切れ端で簡易な端子盤を作る。

　オシロで1.3Vの直流がでた。1000Xなので、1300Vが軽々でている。ほう、フライバックトランスのときは派手な脈流だったが、コンデンサーでこんなに平坦になるのか。

　SparkFunのガイガーカウンターは、また動き始めた。ところが、そのうち、カンッ、カンッという例の音がし始めた。電圧がその度に急激に下がる。この音、初めはトランスかと思ったが、場所が離れたので、そうではないことがわかる。

　すると音の発生元はGM管しか考えられない。これがプラトー電圧を超えた上限での連続放電の音かもしれない。電圧は、オシロでもDVMでも同じ電圧だった。この電圧で間違いないだろう。500Vでは反応しないが、現在の電圧はGM管を壊す可能性がある（もう壊れているかも）。心配になってきたので、とりあえず実験は中止する。

　さて、このあとである。残念ながらSparkFunは、これ以上の実験は無駄のような気がする。GM管の替えはないのである。これが悪いのなら、もう先には進めない。これまでの経過では、電圧がでなくなったのは、ドライバー回路のプリントパターンの上に接着剤でスペーサーをつけたことが原因であることは、ほぼ間違いないようだ。ただ、1500Vの高圧が何故かかっていたのかという最も根本的な原因は解明されないままである。

ガイガーカウンター制作で思わぬ道草

　高入力インピーダンスのDVM（デジタル電圧計）を作ったり、別のガイガーカウンターのキットを組み立てたり、このところすっかりアナログの世界にはまっている。ガイガーカウンターの高圧発生回路は、所長の最も不得手なアナログのハードウエアの世界である。調べれば調べるほど知らないことが出てきて、これがまた面白くて横道に入る。つい調べる目的をそっちのけにして、ウェブサーフィンに時間が経つのを忘れてしまう。まあ、これが楽しいのだから仕方がない。いつになったら本題（ってなんだっけ）に戻れるやら。

SparkFunガイガーカウンターキットの不具合(8/7/2011)
　そもそもの原因は、SparkFunのガイガーカウンターキットの不調である。突然、パルスが出なくなるかと思うと、暫くすると何事もなかったように復旧する。これが電圧計の完成直前、とうとう動かなくなった。これまでは数分か数十分放置しておくと自然に戻っていたのだが、今度は1時間以上経過しても回復しない。

　折角、ボタンをつけて完成！と思っていたのにこれである。ウェブを見ると、SparkFunのキットが動かなくなったという記事を散見する。何か販売元でも交換に応じているようなのだが、こちらのキットは、既に14本も線を追加しており、いくら高圧部は触っていないと主張しても交換や修理に応じてもらえる可能性は低い。

　と暗い気持ちになっていたら、また復活した。ガイガー管そのものが壊れていることは考えにくい（希望的観測）。恐らく高圧発生部だと思う。その理由として、ガイガー管がパルスを出す度に、トランス近くから「ジイッ」という小さい音が段々大きくなり、最近は、パルスに関係なく1秒程度の間隔で、小さな「カンッ」「カンッ」という音まで出始めた。どこかで回路が放電して電圧が出ていない感じだ。

　入力インピーダンスの高い電圧計（秋月のDVMキット)はまだ完成していない。本体が正常に動いているあいだに動作電圧を測っておこうと、あわててDVMキットを組み立て始める。組み立てている最中に気がついた。1Gオームの抵抗があるのだから、その分圧部(ローサイド）では普通のテスターで測れるのではないか（内部抵抗の低いテスターを分圧部に入れても入力インピーダンスは1Gで変わらない）。

　早速、試してみる。1Gオームを慎重に袋から取り出し、1MΩと空中配線し、恐る恐る、ガイガー管のアノードにリードを差し込む。１Mの低圧部も安心できない。グランド側が万が一外れれば、一気にここも高圧（まあ、極小電流の500V程度だが）がかかる。テスターに接続して、電源をONにする。

　ありゃあ、テスターで1.28V。1Gと1Mだから1280V以上かかっていることになる。これはどうしたことだ。念のため、1Mを2Mに換えると、0.58V。ほんとだ。倍にすれば1160V、これでも1KV以上の高圧だ。SparkFunのガイガー管はLND712で適正電圧は、460～500Vとある。

　以前、SparkFunのガイガーカウンターの掲示板で、「電圧が900V以上出てるぜ。コンデンサーを変えたら500Vに戻ったけど」という書き込みがあったのを思い出した。このとき、SparkFun側は、「そんなことあり得ないが、調べるから詳しい状況を教えて」ということでそのままになっている。

　ところが皮肉なことに、１Gオームの回路をつけて測っている間に、音が出るのが直ってしまったのである。何の音も出ることなく高圧は順調にでている（測定値は1200V近辺）。やれやれ、おかしくなった時の電圧を確かめて修理しようと思っていたが、現象が起きないので、おあずけである。

デジタル電圧計(DVM)の組み立て(8/7/2011)
　秋月キットのベストセラー商品のようである。相当古い歴史を持っているようだ。色々なキットに応用されている。ユニバーサル基板に配線したパターンをそのまま基板に起こしたような、ちょっと変わったプリント基板である。1テラオームに近いという内部抵抗が自慢で、今度の1GΩの分圧抵抗100Kに並列にするには十分な性能を持っている（つけたことを殆ど無視できる）。

　組み立ては造作がない。数時間で半田付けは終わった。ただ、キットのICとLCDは２つとも40ピンの大きなDIPパッケージで、ソケットにつけるのは慣れないと緊張する。少し力を入れると歪んでLCDの画面が一瞬黒くなったりして慌てる。

　最初、LCDを逆さまにつけてLCDにデタラメな文字が表示され頭を抱えた。冷や汗をかきながらやっとのことではずし、正しい位置に付け直してめでたく数値が出た。いやいやお恥ずかしい。わきの下にたっぷり汗をかいた。

　さて、バラックでは電圧が測れるようになった。次はケースへの組み込みである。前からどうするか、あれこれ悩んでいる。仕事の帰り、秋葉原を巡回して高圧用の端子（テフロン製）を探す。ウェブではマックエイトなどのブランドで色々あるが、単品で売っているところを見つけられない。

　ネジで有名な西川で、やっとみつけたが、テスターのプローブジャックになるような大きめの端子は売っておらず、小さいのはあっても、10ヶ￥2300とかの値段で手が出ない。

　ロータリースイッチは、はなから高圧用はあきらめている。ロータリースイッチは200V以下の測定レンジと高圧のローサイド側に使うことにする。高圧用に独立の端子を設ける。考えてみればケースは金属ではなく、プラスティックなので、普通の端子でも1000V以上に耐えられると判断した。

　ロータリースイッチに、電圧計キットについている1％の抵抗を直付けし、小さな基板を足して、ここに残りの抵抗や、高電圧分圧の半固定抵抗をつける。この小基板には、さらにLCDの数字のドット表示用の回路が乗る予定だ。

別のガイガーカウンターキット到着(8/9/2011)
　SparkFunのガイガーカウンターがおかしな動きを始めたので心配になり、前から目をつけていた別のキットを発注してしまった。現在使っているものが危うくなると、あわてて代替品を衝動買いする癖がある。今度もそうである。

　ウェブ上で試しにお買い物籠に入れている間に、思わず「買う」ボタンをポチってしまった。これもアメリカの電子キット会社CHANEYのものである。GM管は、日本のウェブでも高性能と定評のあるロシア製のSBM-20。今度のキットはスピーカーとLEDがついているだけでマイコンは付属していない。多数の応用例があり、日本でも売り出されている(値段は￥12,000程度）。

　直接買えば、価格が94ドル。30ドルの送料をつけても、超円高の時代、1万円を切る。ここは会員登録も要求しない。メールアドレスと住所を知らせると素直に注文を受け付けてくれた。今度は、何のメールの問い合わせも来ない。問題のSparkFunのキットが回復し、うーむ、はやまったかと思う間もなく品物が届いた。何と発注から4日しか経っていない。

　今度も記念撮影しておく。エアバックのような包装ラップから部品セットがビニル袋に入って登場した。おや、今度は組み上がっていない部品がアイロンで分割した袋にまとめて入ったキットだ。GM管だけはさらにエアマットにくるまれている。基板の作りは雑である。基板の切断面は手を切りそうな荒っぽい切り方だ。SparkFunに較べると、素人のプリント配線と余り変わらない。これで本当に動くのかちょっと心配だ。

DVM(電圧計)ケース完成。LCDドット表示回路にはまる(8/13/2011)
　CHANEYのガイガーカウンター組み立ては、すこしお預けにしてDVM（電圧計）キットのケースの工作を続ける。秋葉原からさらに部品を調達し、実装に色々工夫する。これはこれで結構夢中になる。

　仮組み立てをして、待ちきれずに端子経由で高圧を測ってみる。端子の絶縁を確認する目的もある。えー、1495Vもある。嘘だろー。いや、間違いなさそうだ。コッククロフト・ウォルトン回路になっているところを測ると、忠実に半分づつ電圧が低下していく。間違いないだろう。しかし、何故こんなに高いのか。

　DVMのケースの実装が完成した。キットについていたケースは、偶然にも現在のSparkFunのガイガーカウンターと全く同じケースである。これに入れるのも芸のない話なので、もう少し小さいケースに入れようと探したが、なかなか適当なものが見つからない。電池(006P)とロータリースイッチが意外とかさばり、小さくまとめられない。結局、最初のケースよりほんの少し小さい、タカチの透明ケース（PB2 110×80×33）でがまんする。

　ロータリースイッチで、電圧のスケールが換えられることを確かめる。うまく動いた。ここまできたら、やっぱり数字の下にドットを表示させたい。説明書には、このドットの点け方が載っている。これが微妙な書き方である。この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の逆相が得られた（あたりまえか）。

　これを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枚の実体配線図つきの説明書があるので、組み立ては至極簡単である。

　とりかかって小一時間で半田付けを終える。早速通電。よし、スピーカーからクリック音、青い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しないから気が楽である。やることが色々増えてきた。

SparkFunガイガーカウンターに操作ボタンをつける

USBと電池切り替え回路の改良(7/28/2011)

 ブログに記事を上げてから、ずっと気になっていたことがある。SparkFunのガイガーカウンターキットに手を加え、電池駆動で動くようにしたのだが、USBをつないだとき、USBバスに電池の5Vが入りこまないよう、FETで電池からの供給を止めるのは良いとしても、逆に電池の電源をレギュレーターの前のスイッチで切るとレギュレーターの入力側が0になるのに、レギュレーターの出力側はFETのソースにつながっていて、ドレインはUSBの5Vがつながったままになる（ゲートは0Vだが）。

　最初、回路が出来たときドレインからソースへ電流が流れていなかったので（誤測定だった）安心していたのだが、ウェブの記事を見ると、FETは内部的にドレインからソースに順方向の寄生ダイオード（Body　Diode）が入っている。それなら、ドレインの電圧はそのままソースに反映されてしまうはずだ。電池ならさほど問題ないが、レギュレーターはまずい。本来ならもうひとつFETがいるところをさぼっている。

　ぐだぐだ言っているより、試してみたほうが早い。出来上がっているのをテストするのは、GM管の高圧が近くにあって怖いので、ブレッドボードに新しく2SJ377をブレッドボード用にハンダ付けして、テストしてみた。

　おお、やっぱり心配していた通りだ。ソースに何もつながないで、ドレインに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つの回路図は、この修正が反映されています）

やっぱり屋外で平均値が見たい(7/30/2011)
　今日は久しぶりにテニスをやってきた。雨を覚悟していたのだが、結局、降らず。真夏にしては快適にテニスが出来た。雨模様で参加者が少なかったので、順番が早く廻り、ほとんどプレイしっぱなし。さすがに疲れた。ガイガーカウンターをテニスコートに持っていくのを忘れていた。自慢できなかったのは残念だったが、このところ、ことあるごとに持ち出しては測定の機会を増やしている。

　週2回出かける事務所は日本橋にある。ここでの平均は、ビルの3階のせいか自宅よりやや少ない放射線量である。ある政党の調査結果によると、東京都内は東部にかけてかなり高くなるという。確かに事務所近辺の地面近くでは一気に線量は増える(0.1μSv/hを常に超える）。といっても、まあ、海外旅行を1回した程度の線量だ。大騒ぎする量には程遠い。

　ある場所を測定したあとは、最寄のPCにつなぎ、蓄積値（平均値）を出しているが、やっぱり蓄積データをリセットして個別の平均値をだす操作が出先で自由に出来ないと、使い勝手が悪いことがわかる。頭で考えるより、こういうフィールドテストが操作仕様を決める最善の方法だ。ということでやはり、タクトスイッチをつけてガイガーカウンターをボタンで制御できるように改良することにした。

　そのためには、スイッチだけでなく、CPUチップからさらにI/Oピンを引き出す必要がある。引き出した線の固定やスイッチの実装も考えなければいけない。最初は今までの工作と同じスタイルで、パネルにあけたLCD固定用ねじを使って付属追加基板を固定し、そこにスイッチを実装しようとした。しかしフロントパネルにスイッチの穴を開けると、ちょっとした雨でもケース内に水が入ってしまう。

　すでにUSBのコネクターの穴が横に空いているので、防滴仕様にもなっていないが正面に穴があくのはやっぱり避けたい。ということになるとタクトスイッチはパネルにネジで固定しなければならない。あいにく部品箱にはネジで止めるタクトスイッチの在庫がないので、部品の調達が出来るまでハードの工作は一休みである。

ATMega328の全部のピンを引き出す(8/1/2011)
　仕事の帰り、久しぶりに秋葉原に出る。秋月、千石界隈は、相変わらずメイド喫茶の客引きが煩わしい。目立ったところでは、定点観測しているSDカード2GBの値段が遂に￥300を切った(￥250)ことと、安売りショップにやたらとガイガーカウンター売出しのポップが増えたことである。大抵のショップには１つや2つの案内がある。値段はウェブ上と同程度だが、一時に較べると安くなった。この分で行くと秋には、完成品でも1万を切るかもしれない。

　今日の買い物の中心は、やっぱりガイガーカウンター関係である。パネルに直付けするタクトスイッチをまず探す。タクトスイッチは、ねじでパネルに固定し、しかも小型のものというと意外に種類が少ない。下の電池や基板に干渉しない、低背（ローハイト）のものを探すが、見つけられなかった（結局、千石で前と同じようなものを買う）。

　次は、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チップからの引き出しは大分慣れてきて、ほどなく全部引き出し終えたが、問題はこの小基板への接続である。

　これまでのLCDの8本（Vcc、GNDを含む）に加えて6本、あわせて14本のソケットへのハンダ付けは、欲張ってこの小基板にタクトスイッチ用のプルアップ抵抗までつけたものだから、ちょっとした手品のしかけを作るような気分である。2段になったピンソケットへのハンダ付けの手順をあらかじめ確認し、ピンセットで慎重に0.2ミリのUEW線を、2段になったソケットピンの位置に合わせて切りそろえ、先端をハンダあげする。　

　始める前は、本当にこれで全部ハンダ付けできるか自信がなかったが、やってみると意外にうまく行った。こういうときのハンダは、みんなが推奨する日本アルミットのKR-19ではハンダの流動性が高すぎて、むしろ以前まで使っていたGootの普通の糸ハンダの方が仕上げが綺麗に出来る気がする（これに慣れているだけかもしれないが）。

　全部の配線を終わった。恐る恐るソケットを定位置に戻し、テストする。良かった。LCDがちゃんと動いた。新たにつないだ線も、チップのピンとソケットの導通テストでちゃんとつながっていることが確認できた。全部出来たとなるとすっかり気が抜けて次のステップに進む気力を失う。

タクトスイッチをつけてハードは完成。残りはソフトの開発(8/2/2011）
　自分は左利きだが、タクトスイッチは右利き用にLCDの右側につける。5ミリの穴2つである。念のため養生テープをつけたので、気楽に3.3ミリのバイトで大きなドリルを使って開けたら、しっかりずれてしまった（キリで下穴をあけていたのに）。気を抜くとろくなことがない。リーマーで何とか揃える。

　スイッチのプルアップ抵抗はソケット基板に既につけてあるので、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コンパイラーのソースを全部記憶していて、何かエラーが起きるとたちどころに修正点を指摘できたそうである。ここまでいかなくても、いわゆるハッカーと呼ばれる人たちは大抵常人を超えた能力を持っている人たちである。この人たちを真似ようと思ってはいけない。

　こうした名人達に、我々凡人が対抗できる数少ない手段が擬似コーディングだと思っている。プログラムの動きを普通の自然語（我々なら日本語）で徹底的に記述し、矛盾点を洗い出す。

　矛盾するところがなくなったら、これを少しづつコンピューター言語に移していく。この手順を踏むことで、プログラムがどれだけ複雑になってもメンテナンスが可能になる。もちろんプログラム開発には、言語に特有の文法や、モジュール構成とか、構造化するとか専門的なテクニックを多々求められるが、これは必要に応じて身に着けていけばよい話だ。

　肝腎なところは、バグのない（論理矛盾のない）プログラムをいかに作るかで、それは自然語である日本語でも、プログラム言語でも基本的には変りはない。このあたりをおろそかにして開発をコーディングから始めると、大抵の人はバグを取りきれずに挫折してしまう。

　擬似コーディングの例は、これまでにいくつか（ここや、ここに）お示ししているが、ただ形や決まりにこだわることは無意味である。自分が納得するまで紙の上で何度も書き直して（アートワークと同じで、ボールペンより鉛筆、消しゴムがおすすめ）、ロジックを整理することである。

　開発したソフトウエアが思ったとおりの動きをするのを見ることは、もの言わぬ小さな部品を集めて特定のハードウエアを作り上げるのと全く同じ喜びである。電子工作の醍醐味のひとつだ。これを読んだ方々が、擬似コーディングの手法でソフトウエア開発のレベルを少しでも上げられることを願っている。

操作ボタンをつけたガイガーカウンター完成(8/5/2011)
　てなことを書きつつ操作ボタンの開発である。擬似コーディング数枚を費やして、ガイガーカウンターの操作ボタンのソフト開発は終わった。タクトスイッチの制御は、ピンチェンジ割込みをトリガーとして、ボタン処理ルーチンで一手に行う。ここではチャタリングの待ち時間を入れたあと、スイッチの押下でディスプレイモードを切り替え、そのあとの表示ルーチンで、モードに応じたLCDの画面を用意する。

　表示タイミングは1秒ごとか、状態が変わったときなのだが、今度は、スイッチで表示モードが変わるというタイミングでも表示しなければならない。最初の擬似コーディングでは、このことを考慮していなかったので、1秒ごとにLCDがチラチラし見にくい。

　本来はもっと前に戻るべきなのだろうが、ずるをしてフラグ（表示モード変更フラグ）を追加し誤魔化す。ちょっとフラグが多すぎるなあ。UARTも残してあるので7ヶもある。余り褒められたコードではない。

　それに誤算がもうひとつあった。AVRのピンチェンジ割込みは、立下りや立ち上がり、レベルなどの割込みのモードが指定できない。ロジアナで見ると、このタクトスイッチは押すときも離す時も派手なチャタリングが出るので普通のロジックではまともに動かない。

　仕方がないので、チャタリングを待つ時間は割込み禁止にして割込みフラグをクリアしてから割込み許可にする苦肉の策をとった（main.cの239行付近）。やっとこれでボタン操作が落ち着く。それまでは、いきなり確認ボタンを2つ連続して押すようなときがあって使い物にならなかった。

　まあ、それはともかく、SparkFunのガイガーカウンターは、ほぼこれで完成形に近づいた。ピンは余っているし、フラッシュはまだ10KB以下なので、RTCでも何でもつけられるが、こればっかりやっているわけにもいかない。それより、このガイガーカウンター時々、高圧が出なくなるのかGM管そのものなのか、時々計測不能になる。デジタル電圧計（DVM)の開発を急ごう。

ここにボタンで制御するSparkFunガイガーカウンターのソース一式を置きます。回路図は前回のものに、PD4、PD5にタクトスイッチを追加しただけなので省略しました。
8/5/2011に公開したソースにバグがあったので修正した版を以下に掲載します（EEPROMをボタンで消去するとデータが蓄積されない）  8/7/2011

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

ログ機能を持ったSparkFunガイガーカウンターのソース公開

内蔵EEPROMでも実用的な量のデータ保存ができる(7/18/2011)
　SparkFunのガイガーカウンターキットは、データを残すのに内蔵EEPROMでは小さすぎて現実的でないと思っていたがフラッシュROMを外付けしなくても、結構実用レベルまでログを溜められることがわかった。

　勘違いをしていた。最初はGM管のパルス間隔時間を記録することしか考えていなかったので、Mega328の1KバイトのEEPROMでは、僅かの時間（30分くらい）しか記録できないと思っていたが、パルス幅でなく１分ごとのパルス数（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）で見ることにした。

　このロジアナは標準プローブでも0.8ミリピッチを挟めるそうだが、ここは販売元のお店（ストロベリーリナックス）が、少し高い製品以上に(LAP-C16128)におまけにつけている、0.5ミリピッチでも挟めるという極小プローブを使う良い機会だ。

　これだけでも買えば一万円以上するという触れ込みのプローブである。ケースから、プローブをとりだす。買った当座、ケーブルをつけておいたが、あらためて見てみるとこれは本当に小さい。ピンに挟み込むには拡大鏡なしでは無理である。ヘッドルーペをつけて送受信ピンに取り付ける。

　測定の結果は予想通りだった。受信ピンにPCからのデータが来ていない。これまでのピンの引き出し工作で不具合が起きたのだろうか。いや、ハンダ付けしたところはUARTピンから遠く離れている。この基板はFT232RLでUSBとつないでいる。ここがおかしくなったのだろうか。いや問題ない。

　あれこれ悩んでいたが、動かない原因は意外なところだった。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するとデータを最初から次々に吐き出すしかけが完成した。

　とりあえず、ダンプ機能（頭から全部吐き出す）と、EEPROMのフラッシュ（全消去）コマンドを作って動かす。本当は、シーケンシャルファイル風にデータのセッションを分けたいのだが、リアルタイマークロックがないので余り意味がない。機能の拡張は当面先送りである。

USBとバッテリーとの電源自動切り替え(7/22/2011)
　USBがつながるときは、電池からの電源は切っておかないとUSBに悪影響が出る。今は、電池とUSBの給電は単につながっていて何の対策もとっていない。USBがつながった時には、自動的に電池からの供給が切れるような回路を作れば、このことに気を遣う必要はなくなる。FETかなにかでスイッチしたいところである。

　実は、この機能はウェブの情報(掲示板で時々おみかけするgomisaiさんのサイト）を頼りに、ブレッドボードで回路を作り既にテストしていた。オリジナルはFETを2つ使っているが、USB側からの電源分離をSB(ショットキーバリア)ダイオードにしてしまえばひとつ減らせる勘定だ。

　ブレッドボードのテストではうまくいった。ただ実装はためらっていた。電源小基板にもうスペースがなく、他に追加したい部品があったからである。（掲載の回路図はあくまでも素人の回路です。自己責任でお使い下さい。）

　まあ、電池の電源が、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)がリードタイプでなく、表面実装パッケージなのでリード線をつけなければならず難儀した。

　何とか組み上げる。ブレッドボードでテストしたとおり、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（地上1ｍ）ということなので、あながちここで測った値はデタラメではないだろう。

　データのログ機能が入り少し実用性が出てきたので、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...
>

と表示され消去されない。>は、プロンプトモードであることを表し、再度リターンキーを押すと、．（ピリオド）が表示され表示モードに戻る。画面データをコピーしたい時は、リターンキーを押して表示を止めておけば失敗しない。

SparkFunガイガーカウンターキットをポータブルにする

　女子サッカーワールドカップ日本代表初優勝おめでとう。決勝戦は珍しく早起きしてTV観戦したが、これほど感動、興奮したことはこれまでにない。アメリカが点を入れても入れても追いつき、PK戦では余裕の勝利。希望を捨てないことが、いかに大切かを身をもって教えてくれた。津波、原発事故、政治迷走と暗い話題ばかりの日本に大きな勇気と力を与えてくれた代表チームに心からありがとうと言いたい。

　それはさておき、電子工作である。今までの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本づつ引き出していく。このあたりが腕の見せどころである。

　ハンダ付けを終わる度に、20倍ルーペで仔細に確認する。拡大してみると綺麗についたと思っているところも結構暴れていて満足できるところは少ないが、それでも順調に線の引き出しが進み、6ピンまでとれた。調子に乗ってVccとGNDもCPUのピンから取り出す。これで8本。

　LCDモジュールで、ループウェイトかレディ待ちかで議論のあったR/W線をつけるかどうか迷ったが、何か、次ぐらいで失敗しそうな気がしてやめた。へたれである。

　次は問題の線の固定だ。色々考えた末、2ミリピッチのピンヘッダー(Xbee用）を2ミリピッチ基板（秋月で買ったもの）の小片に固定し、この基板小片をスペーサーで基板に固定することにした。

　ソケットを固定するためのスペーサーで手間取る。両方とも接着してしまえば簡単に固定できるが、これでは保守性が悪い。配線間違いなども直せない。せめて基板小片の方はネジ止めしてはずせるようにと、5ミリのスチロールパイプにドリルで穴を空け、セルフタッピングの2ミリねじで固定しようとした。　

  しかし、スチロールが硬くてネジ山が切れない。丸い割り箸を切って使うと簡単だが見栄えが悪い。変なところにこだわりがある。結局、道具箱で見つけた建材の一部（家具の棚のホゾ？径5ミリ丸棒）をサーキュラーソーで5ミリに切って、そこへ錐で穴を空け、2ミリタッピングネジで止めた。意外に上手く行った。最近の瞬間接着剤（シアノクレート系）は強力になった。

LCDがスペック通りの早さで動かない(7/13/2011)
　接続ソケットとケーブルが出来たのでケースに実装する前に、テスト用のLCDをブレッドボードでつないでテストする。LCDライブラリは、ピンの位置が任意に選べる最新版。しかしこの最新版は、ループウェイトしないレディ待ちする方式なので、待ち時間を適当に入れなおして組み込む。

　色別に線を選んで誤配線を防ぐ。ここは前に何度も誤配線したところだ。予想したとおり最初はうんとすんとも言わなかった。ははは、残っていた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ミリ程度の超過なので最初、両側をやすりで削って入れようとしたが、削っている最中にはたと気がついた。

　１ヶ入りのホルダーを2本連ねようとするから窮屈なので、片側を切り離して電池2本が直接ケースの中で並ぶようにすれば良い！コロンブスの卵である。サーキュラーソーで片側を切り取り電池をつけてみる。余裕でケースの中に入る。LCDの時とは打って変わって快調である。

　電池はエネループを予定している。しかしこの電池の電圧は微妙である。定格は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つのチップLEDをはずして、意気揚々と付け直したら同じところにもう一度取り付けている。肩の力が抜ける。今度こそと、取り付け直したら、今度はLEDのひとつを逆さまに取り付けていた。やれやれ。

　電池ケースの固定は、エポキシ系の接着剤を使う。接触面積はあるが、こういう重さがあって、力がかかるところは瞬間接着剤は止めたほうが良いというのが今までのノウハウである。これは固まるのに時間がかかるので、ケースの工作は中止して1日寝かせる。無機質の部品が組み合わさって、段々、ひとつのものの形になって行くという過程は、何度やってもいつも楽しいものである。

ポータブルガイガーカウンター完成(7/17/2011)
　電池ケースの接着を待つ間に、レギュレーターの小基板の工作を始める。ポータブルということなので、電池ケーブルのソケットはちゃんとした日圧の2ピンソケットを使う。最初、主基板とはピンヘッダーでハンダ付けを考えていたが保守性を考慮して、ここもピンソケットにした。

　ケースの上蓋のヒンジをはずしてLCDの工作も始める。LCDは4つのスペーサーをつけたネジで上から固定する。化粧面なので慎重に4つの穴をまず小さいドリルで開け、やすりで調整していく。ここのスペーサーは、最近、近くのDIY店で買った5ミリのABSチューブである。スペーサーは5ミリや10ミリのものも買えば一ヶ￥5から￥10でばかにならない。ABSチューブは1メートルで￥120。サーキュラーソーがあるので切断は問題なく、地球にやさしい（これは単にケチなだけ）。

　細かい調整（レギュレーターの電解コンデンサーの高さがつかえて、つけなおし）や、USBコネクターをつけるため主基板を移動（エポキシ系の接着力を確認した。元のままでは大きな穴を開けねばコネクターがつかず、泣く泣く移動）させられるなど紆余曲折はまだいくつかあったが、やっとSparkFunのガイガーカウンターキットはポータブルになった。

　持ち運べるようになったので、色々な場所に移動して測定し始めた。すぐに気が付いたことは、やはりデータログが出来ないと瞬間値をいくら測ってみてもあまり意味がないということである。バックグラウンド程度の放射線量というのは、最小と最大の幅が3倍以上あるのは普通で、現在のカウンターは10回のパルスの平均を取っているが、それでもそれくらいの差は出来る。

　すんさんの掲示板にも載せたが、アマゾンで入手した放射線源のキャンプ用のランタンの芯（マントル）では派手にパルスが上がって、このキットが間違いなく放射線を測っていることは確認できた。

　東京も、3/15あたりはこれくらいの線量だったようで、まあ、あの程度が続けば問題になるのだろうけれど、このランタンの芯は、別に何の規制も受けていないし、だいたい30センチも離せばもう殆ど反応しない。

　ただ、ここが通常より低いところか、高いところかを判断するには、最低でも1時間程度は連続して測らないと良くわからないようだ。Mega328の内蔵のEEPROMでは1Kバイトしかないのでパルスカウントでは精々30分くらいしか記録できないが、それでもあったほうが良いようにも思える。

　ただ、I2CのフラッシュROMがこのあいだのフォトフレームのために買って沢山余っているし、これを実装してから考えるべきか思案している。これなら何時間でもログが出来る。RTCとGPSまでつければ完全だけれど、どうもこれも余り深入りしたくない気持ちもあって迷うところである。

FreeRTOSマルチタスク対応UARTとガイガーカウンターキット

LCDをはずしてもFreeRTOSが動くようにする。ロジアナ大活躍(6/28/2011)
　FreeROSのセマフォーが解決して、ちょっと一息ついた。たいしたことでもないものに、自分で自分を追い込んで解決に血道を上げる。確かに、前記事で頂いたコメントの通り、自虐趣味かもしれない（少しむきになって否定したけれど）。しかし、単調な日常生活にこれほどドラマを作ってくれる趣味は、ちょっと他に見あたらない。テニスやスキーなどにもドラマはあるが、ドラマを作るためには、多大な精進と肉体を苛めるトレーニングが要求される（これは自虐とは言わない）。

　電子工作の場合は、こだわるものは目の前に無尽蔵に転がっている。盛んに研究されているプログラムライターなどもそうだ。別のライターで書いたからといってフラッシュに2倍のサイズが書き込めるわけではない。書き込みが速くなるといっても、精々数十キロのフラッシュROMにどれだけ早く書けたところでたかが知れている。しかし、みなさんのこだわりようは、尋常ではない。余程面白いに違いない。　

　それはともかく、当面解決すべき課題がなくなり、体の中にぽっかり空き地が出来たようだ。これまでのメモを取り出して、やろうとしていたことを整理し、優先順位をつけながら次のプロジェクトの準備をぼちぼち進め始めた。

　本来なら、前にも書いたようにUARTのマルチタスク対応なのだが、どうも気分が乗らない。こういうときは手を動かしているのが一番だ。ブレッドボードに臨時に設置していたFreeRTOS用のI2C LCDを次のプロジェクトに備えて外す作業を始めた。

　元のLPCMプレーヤー(テストベンチとしてブレッドボードに常駐）の方に戻し、LCDなしでARM(LPC2388)基板のFreeRTOSを動かそうとした。これが動かない。ふーむ、LPCMプレーヤーはLCDをはずしていても動いていたのに、何故、ARMでは動かない？

　ソースを見て原因はすぐわかった。I2Cの初期化で、LCDからレスポンスが返ってくるのをループで待ち続けている。これは一番確実な方法だけれど、ここはLCDがなくても事情を理解して先に行って欲しい。いわゆるソフトウエアのRobustness(堅牢さ）というやつである。

　必要とされる初期化待ち時間を仕様(300ms)の倍くらいにして、このループをはずす。あれえ、これでも動かない。どうしてだ。傍らを見ると、これまでの解析に使っていたロジックアナライザーが出たままになっているのに気づいた。そうだ、このロジアナ（ZeroPlus 16128)にはI2Cのプロトコルアナライザーがついているはずだが、まだ使ったことがない。ちょうど良い機会なのでロジアナでI2Cの波形を見てみることにした。

　うーむ、待ち時間を倍にしても、レディにならずにスタックしている。ループを使った元の状態に戻す。何ということだ。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秒以上離れているが、データ圧縮のお陰でメッセージデータが記録出来ている。

　サンプリングクロックを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などでガードしてやる必要があるが、こうしておけば複数のタスクからの送信要求は安全に処理される。

　コンセプトが明確になったので、コーディングにとりかかる。ユーザー向けの送受信関数は、キューステートメント1行のえらい簡単な関数になった。UARTタスクからMonitorタスクを分離し（これが今後のモニターコマンド処理を担う）、UARTタスクはハードの初期化と、送信キューの送出のみに絞る。

　テストしてみる。よーし、動いた。ロジアナで動作を確認する。ふーむ、Mutexを使ってprintfをガードしたけれど、このアプリでは重なることはまずなさそうだ。Mutexもはずす。Mutexだけで、フラッシュは560バイトも使っている。

　さて、今のところ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に換わり、めでたく品物は日本に向けて出発したようである。

　4日ほどで品物が届いた。初めてのSparkFunからの荷物である。記念撮影をしておく。中から小さな赤いSparkFunの箱が出てきた。おやあ、全部配線が済んでいる。何だキットというから半完成品かと思ったら、全部の配線が終わっている。ガイガー管は、配線を束ねるタイラップで基板に固定され、グランド側は、線を巻きつけているだけだ。このあたりの工作が難しいので全部組み立ててあるのだろうか（外国人は、日本人に較べると驚くほど不器用である）。

　取る物もとりあえず、USBジャックを付けて電源を入れる。赤いLEDが煌々と点いて、その隣の緑のLEDが一瞬点いた。シリアル端末を立ち上げて様子を見る。始めは何の反応もなし。暫くして、緑LEDの瞬きとともに端末に01と数字が出た。おお、動いているようだ。

　CPUチップの横にあるのがISPピンらしい。SparkFunのサイトに行って、最新版のファームをダウンロードする。ソースの中を調べる。うーむ、このソースでは動いていない。サイトの記事を見ると、どうもV12という放射線量の数を乱数に使うプログラムが送られてきたキットには入っているようだ。その証拠に、端末の0や1が増えている。0はパルス間隔が前の時より短かったとき、1は長かったときを表すようだ。

これだけでは、全くガイガーカウンターとしては用をなさない。最新ファーム（V13)も似たようなもので、1秒間の発生したパルスの数を延々と出しているだけだ。まあ、これは覚悟していた。ISPピンが出ているのでファームの書き換えに支障はない。
　
電源LEDを点滅に換えたりファームを書き換えたり(7/6/2011)
　このガイガーカウンターキットは、USBを通したUART（FT232RLがついている)が唯一のインターフェースで、パルスが来るとLEDが一瞬点くが、音が出るわけでもない。これをポータブルにするのは、独立電源にして、何らかの表示装置をつけないといけない。素人が使うなら音もあったほうが良いかもしれない。

　ただ基板上にはGM管からの出力パルス（トランジスタでバッファー）しか出力が出ておらず、QFPのMega328の空きI/Oピンは全く引き出されていない。LCDをつけるには表面実装のパタンから線を引き出す必要がある。ピン配置と基板をにらめっこして、半田ごてが入りそうなピンを物色する。

　ISPピンヘッダーはパタンがあるので、これをつけるついでに、パラレルLCDをつける半田付けのための練習を兼ねて、電源を入れると点きっ放しになる基板上のLEDをMega328のピンに移して点滅するようにした。パタンを切って銅面を出し、ピンをUEW線（0.2ミリ）でつなぐ。

　順調に作業が済んだ。ソフトの方は手馴れたAVRのプログラミングである。プログラムを変えて、赤のLEDがブリンクするようになった。ただ、この基板はクリスタルをけちってCR発振のクロックなので、余り厳密なことは出来ない。出てくる数値もあくまでも目安程度だろう。

　それでも、GM管から出てくるパルスの間隔を配列に蓄積し、10ヶの移動平均をとって、直近の平均のCPMを出すプログラムの開発にとりかかった。品物が来る前から構想は練ってあったので、コーディング半日、テスト半日で、所定の4桁のCPMがUARTに並ぶプログラムが動いた。

　出てきた数値をPCのExcelでグラフにしてみた。地下室は一般的には、自然放射線量が多いということだが、我家では、明らかに地下の方が低い結果が出た。

　あとは、LCDにこれを移しポータブル化することと、さらにμSv/hなどに換算するロジックや、データログ機能などが待っている。まあ、もともとは、「正しく怖がらなければ」などとブログで大見得を切った手前、何らかの自衛手段を持っておかねばと、はずみで買ってしまったようなガイガーカウンターである。深入りしていけばきりがないので、適当なところで切り上げるつもりだ。

　ソースコードは、オリジナルソースがクリエイティブコモンズのAttributeオプションと言うことなので、ソースコードの原作者表示を残し、当ソースもこれを継承していくことにする（作者名を表示すれば、複製、改変、商用可能）。

暫定版ですが、とりあえずソースコードを、例によってAVRStudioのプロジェクトとして下に置きます。SparkFunのガイガーキットだけでなく、パルスの到着間隔を測定表示するプログラムとして他にも応用が可能です。

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

FreeRTOSのセマフォーの不具合がやっと解決

　雑誌付録ARM(LPC2388)基板のFreeRTOS7.0.0で、ChaNさんのバッファー付きUARTを動かすことには成功したが、セマフォーを使った受信処理はうまく動かず後味の悪い結果が残った。

　前記事にあるように、UART出力が数十分後にフリーズするという不具合がどうしても解決できない。結局この不具合究明は一時あきらめ、次の課題を、　

・ChaNさんのFatFSをFreeRTOSで動かしてSDカードが読み書きできるようにする。
・UARTをすべてOSのキューを使って入出力し、マルチタスクに対応させる。

ということに決めた。このあたりまで動けば、この基板のOSはロボットなどの多重同時制御のプラットホームとして十分な機能を持つことになり、ネットを使ったカメラ制御などのアプリケーションが簡単に開発できるようになる。

　ただ、FatFSを完全なマルチタスクで動くようにするのは、そう簡単ではない。コードそのものはリエントラントで書かれているが、これをいくつものタスクが同時に動いても良いようにするには、コードだけでなくディスクなどの単一リソースの排他制御を完全に行わないと、デタラメな書き込みでディスクは、あっという間に破壊される。

　しかし、検討に力が入らない。最初はシングルタスクで動くだけで良いと思っていても、頭の中で、何かがひっかかって先に進まない。そう、セマフォー不具合の問題が頭から離れないのである。

　それにしても、このしつこさは何だろう。もし、これが仕事だったら、こんな瑣末なことにこだわっていたら仕事にならない。上司から大目玉を喰らうか、プロジェクトだったら大迷走、中小企業だったら間違いなく倒産である。やっぱり、これは現役時代の反動ではないかと思う。

　人は笑うかもしれないが、不思議なことに、こういう下らないことにこだわってあれこれ悩んでいる時の方が、逆に自分が自由な気分になっていることに気づく。仕事の時はこんな悠長なことを考えている余裕はなかった。一時（いっとき）でも全体から見て効果、実効のある方向を模索することが求められ、始終あせっていた。

　その焦燥感が、現役を退くと消えた。まわりを気にせず解決を求めてさ迷っていても、誰もとがめる人はいない。いろいろ気配り心配りする方がストレスは溜まるのだ。単純に思考しているほうがむしろ幸せなときなのである。それに悩んだことが大きければ大きいほど、それが解決した時には大きなご褒美が待っている。

セマフォーを解析して不具合を追及する（6/19/2011）
　そんなことで、次の課題はぶちあげたものの、実は、あまりやる気が起こらず、暇さえあればセマフォーのトラブルシューティングをやっていた。

　まず、不具合の状況を整理する。セマフォーを導入する前は、リアルタイマークロック（RTC)からの1秒毎のUARTのメッセージを何時間出していても全くトラブルがないのに対し、受信割り込みを待つためにセマフォーを使うと、20分前後で全タスクがフリーズする。

　セマフォーが動くUART受信部を全く動かさなくても、不思議なことにフリーズする。ここが謎である。ただし、時刻を表示しなければ、セマフォーを入れていても症状は発生しない。フリーズするタイミングは時間ではない。UARTから出力するデータの数である。

　セマフォーを組み込むことで、時刻表示のUART出力に不具合が生じ、時限爆弾のように、何千回かあとで問題が顕在化する（そう見えるだけなのかもしれないが）。フリーズするまでの時間は最初10分程度だったのが、いつのころからか20～30分程度に伸びた。正確な時間をとってみると、最初は13分で、増えたときが26分。時間がちょうど倍と言うのが悩ましい。

　セマフォーの中のソースコードを解析する。セマフォーは独自のソースではなく、キューの関数を流用している。サイズが0でキューの数が１のキューをハンドリングする。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モードにし、関数の前後に、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週間かかっている。何度も書いているけれど、この解決した時の達成感は何物にも替えがたい。しつこく追いかけた甲斐があった。これまでの悩みが吹き飛んで、無上の喜びになる。電子工作の明らかに、変な楽しみ方のひとつである。わざわざ難問を設けて、その解決を追求するのだから。

　その後、一晩、動かしっぱなしにして、フリーズしないことを確かめた。これで心置きなく、次の課題に取り組める。なぜそんなにOSにこだわるのか。ロボット制御には不可欠な機能だから、と、ちょっと偉そうに答えてみる。そろそろmbed(LPC1768)も触ってあげないといけないな。

　ソースコードの公開については迷った。こちらが付け加えたコードは少なく、ChaNさんや、ねむいさんのコードが多い。公開するのは正直言って気が引ける。まあ、でも少しは、みなさんの役に立つこともあるかと思い、アップすることにする。少なくとも、セマフォー付きUARTは完全に動く。モニターとしてはまだ未完成で、入力した文字はリターンキーで戻ってくるだけである。

　ビルドするためには、FreeRTOSの適切なディレクトリーチェーンの中におく必要がある。詳しくは当ブログのバックナンバー記事、ねむいさんの書いたreadme.txt等を参照されたい。

ここに、Eclipseのプロジェクトとしてのソースフォルダーをzipで固めたものを置きます。
解凍したフォルダーをFreeRTOSの適切なディレクトリに置き、makefileのあるディレクトリを
Eclipseのwork spaceにしてください。

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

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の時刻表示メッセージや、時刻入力でも使われている。

　ただ、この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では全くテストされていない。要するにこれにこだわる理由は何もない。送信バッファーもないし、これを動かすことに力をかけるより、最初から作り直したほうが早そうだ。

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さんの掲示板で見た「ばんと」さんのアクリル曲げ器を、自分でも作りたくなり、大分前に秋月の調光器キットだけを買ってあった。

　開発が思うように進まないので、気を紛らわそうと、このキットを組み立て、ケースに作りこんだ。手を動かしていないといられない性分になったこともある。白熱電球のスタンドでテストする。ボリュームを少し動かしただけで明かりが急に変化して少しおかしいが、とりあえず調節は出来るようになった。

　東急ハンズで、アルミパイプや、耐熱ファイバーケーブル、ニクロム線などを買ってきた。ニクロム線が、みなさんが買っている値段とは違う法外な高値（0.5ミリ5mで￥500！）だったが、一箇所で間に合うので目をつぶって一緒に買う。東急ハンズですべての部品が揃った。全部で駐車料が無料になるぎりぎりの￥2000ちょっと。

　ニクロム線と接続ケーブルの間は、圧着端子とネジ止めでつなぐ。耐熱ファイバーをパイプから少し長めに伸ばして、接続部分が触れないように工夫する。ここにスイッチを置くアクリルカバーを作りたいが、「鶏と卵」問題で、とりあえずはバラックとする。

　調光器で試運転する。これも、こういうときのために買ってあった放射温度計(通販で￥3500)で測るが、思わしいデータは出ない。温度がばらばらだ。おまけに低いと思ってうっかり触ったら、やけどまでしてしまった。適温にする調光器の調節が難しい。

　このあと、調光器キットのコンデンサーを間違えて接続したことがわかり、電圧の調整がスムーズになって、150℃前後の温度が作れるようになった。早速、アクリルの端切れを曲げてみる。うむ、正確に測って曲げれば、色々なものが作れそうだ。

　調整に苦労しているうちに、マイコンでこのパイプの温度制御をやりたくなった。高温のセンサーとなる熱電対を調べる。これがまた結構面白いのでついはまってしまう。調べると欲しくなり、仕事の帰り、久しぶりに秋月電子に寄って熱電対を買ってきてしまった(￥400)。

　熱電対は工作心を刺激する部品だ。このセンサーは、2極の電極の間の温度差しか出力しないので、低い方の電極の温度を知っていないと本来の温度にならない。別の温度センサー（又は氷）と組み合わせる必要がある。しかも、1℃あたりの起電力が41μVと（K型熱電対の場合）、極小なので精度の良いオペアンプで増幅する必要がある。

　興味に任せて色々調べていたら、この世界にもICがあることがわかった。アナデバのAD594という、冷温側のセンサーを内蔵したオペアンプや、MAXIMのMAX6675などは、何と出力がデジタルのSPIで出てくるものなど、結線だけで簡単に測定ができるようになっている。値段はいずれも￥1000以上するので（￥1300～1500)、急には手が出せないが、いずれDigiKeyで買って見よう。こういう「ゆるい」電子工作も面白い。

やっとのことでセマフォーが動いた。しかしまだバグがとれない(6/15/2011)

　アクリル曲げ器の工作の合間にも、あきらめきれずにセマフォーをテストしていた。何しろ至極単純なバイナリセマフォー（一回きりの待ち）が動かないのである。他のソースコードをいくつか調べても違ったことをしているわけではない。

　このウェブサーバーのサンプルソースにも、同じような割り込みから処理を再開するのに、このセマフォーは用いられ（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受信はポーリングでデータを待つことにする。やることはまだまだ沢山ある。

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は是非割り込みで動かしておきたい。

　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が使うのか（割り込みベクターなど）くらいの基本的なことが、書いてあれば助かるのだが、このあたりの情報は少ない。ソースコードを見れば、ということなのか。

　八つ当たりしているのは、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モードにする理由が見つからない。

　仕方がないので、もう少し動かしながらデバッグしてみようと、LEDを2つ追加して実装した。このあたりのデバッグは、前にも書いたように、printfでは話にならない。UARTでメッセージを出す間もなくハングアップしてしまうからだ。LEDなら遅れない。

　LEDのI/Oピンは、WebのCGIを動かしているIOページのピンを選ぶ。こうしておけば動作確認が簡単にできる。特に問題なくウェブからLEDのON/OFFが出来るようになった。本当はそれどころでないのだが、暫くウェブでLEDを点けたり消したりして遊ぶ。

　割り込みルーチンにLEDの出力ステートメントを入れる。点灯しない。予想に反してここへ来ていないことがわかった。これまで調べていたレジスターのセーブ/リストアといった問題でない。もともとの割り込みベクターの設定がおかしい。事態は振り出しに戻ってしまった。

　割り込み環境は調べれば調べるほど難しい。霧が深まるばかりで出口は見えない。あの参考書には、多重割り込み優先度つきなどという複雑な処理の方法が延々と解説されているだけで、頭の中の混乱は返って増すばかりである。

　FreeRTOSの簡単なインストールを解説したサイトを見つけた。これを見ていると割り込み環境が余りにも複雑なので、ChaNさんのFatFSプログラムをFreeRTOS化したほうが早そうな気がする妄想にとりつかれる。いやいやそんなわけはないのだけど。

頭を冷やしてもっと合理的なアプローチを考え直す(6/1/2011)
　4日近く、調べまわってやることがなくなった。少し頭を冷やすことにした。今やっていることの本当の目的は何なのか、自問してみる。FreeRTOSで沢山の仕事を同時に簡単に動かせるような環境を作るのが目的で、OSの中のロジックを理解することではない（これはこれで面白いが）。

　それなら、現在動いているソースのなかから、割り込みを使っているところを調べて、徹底的にこれを真似れば動くはずだ。要するに、大上段に振りかざして正面から問題を解決するのではなく、コバンザメのように利用できるものは何でも利用する姿勢でないと、こういう複雑な環境はいじれない。

　Thumbモードで割り込みを動かそうと四苦八苦しているが、何もそれにこだわることはない。そうなのだ現在のFreeRTOSでは、割り込みを使っているところはすべてARMモードでコンパイルしている。どうも、ここにカギがありそうだ。今動いているルーチンをそっくり真似てみよう。

　FreeRTOSのソースから、苦労して、割り込みハンドラーと、割り込みの初期設定しているコードを洗い出す。systickタイマーのTimer0のところport_ISR.cと、イーサネットのuIPの下部ルーチンEMAC_ISR.ｃのところだ。調べた結果、これらは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を点滅するように換えて再度テストする。

　よーし、想定どおりにマシンは動いた。FreeRTOSデフォルトのLED点滅以外に、RTC割り込みルーチンに入れたLEDが1秒ごとの点滅を繰り返す。数時間放置する。問題なく動いている。嬉しい。これでUARTでもバッファー付きの送信が動かせる見通しがたった。いやあ、今度も長かったな。ねむいさんにまた助けられた。ありがとうございました。

今回の問題解決のポイントをまとめてみる。

・頭に血を昇らせずに、時々追求を休止し、現在位置を確認して、攻める方向を整理する。

・冷静に一番合理的なアプローチを決めたら、そこへ資源を集中する。

・情報は可能な限り集め、常に頭の中で情報を泳がせる。思わぬところで、つながりが見えて問題が解決する糸口になることがある。

雑誌付録ARM基板でSDカードとRTCを動かす

失礼しました。プライオリティが逆でした(5/20/2011)
　このOS、プリエンティティブじゃないなどと言っていたが、こちらの間違いだった。FreeRTOSでのタスクプライオリティは数字が大きいほど優先度が高いのだ。uIPは他のタスクより優先度が高いとばかり思っていたので（実際は普通より低いところで動いていた）、UARTの数字をこれより大きくして、さらに優先度を上げてしまっていた。これではUARTがループウェイトすると、uIPにはCPUが渡らない。同一プライオリティの時しかラウンドロビンでCPUは廻らない。

　設定を逆にしたら、めでたくUARTでどれだけCPUを喰っていても、Webサーバーの処理は遅れないようになった。UARTはセマフォーを使った割り込み待ちを考えていたが、その必要もなくなった。やれやれ、どうも済みませんでした。

　コマンドシェルは一番低いプライオリティにしておけば、他のタスクの邪魔をしない。ただ、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カードスロットの実装を始めることにした。アートワークは、これまでの作業の合間に少しづつ描いていて既に完成している。

　思ったより早くできた。まあ、プルアップ抵抗を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（カード検出）は負論理なので、このピンはカードを入れたときグランドに落ちていないといけない。テスターで測る。あれえ、グランドになっていない。ややや、このピンはスロット筐体とはつながってる。何だと筐体とグランドピンは浮いているのか。何と、何と、ここは明示的につながないと駄目なのだ。これまでの実装は、このあたりを無視していたことが多いので、分離しているのに気がつかなかった（スロットは秋月で買ったノーブランドの小型のもの）。

　これで動くのではという淡い期待に胸を膨らませながら、筐体とグランドピンをハンダ付けしてテストを再開する。こんなもので動けば楽なもんだけど、そうはうまくいかないだろうな。

　電源を入れる。モニターを出す。初期化コマンド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。

　そもそものきっかけ、法外な価格で買うのを反発した雑誌のタイアップ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にだいぶ慣れてきた。

　喜び勇んでビルド。よーし、No Errorだ。ファームを書き込む。UARTを立ち上げる。おおお、初期設定をうながすメッセージがでたぞ。年月日を入れていく。やった。動いた。RTCが時間を表示し始めた。ありゃ、止まっちまった。どうもprintfが大きすぎてスタックがあふれたような止まり方だ。ウェブも止まって暴走している。

　年月日時分秒すべてを出す表示を縮めて再トライ。ついでにタスクのスタックサイズをUARTと同じに広げる。よーし、順調に時間が表示されてきた。バックアップは大丈夫か。電源を切って暫くしてからもういちど動かす。良いぞ、バックアップされている。ほぼ2年ぶりの確認である。いやいや、これで32.767Khzの時計用クリスタルと、コイン電池の顔が立った。

FreeRTOSのウェブサーバーが動いた

　連休前から始めた、2年前の雑誌付録ARM(LPC2388)基板につけるLAN基板は、チップ(DP83848C)ひとつを誤操作で失いながら、何とか完成した。電源を入れるとモジュラージャックのリンクやアクセスLEDが点滅しているので、電気物理（PHY)層は動いているようだが、ソフトを何も用意していないので、正常に動いているかどうかはまだ確かめられない。

Eclipseを思い出すのに大変(5/13/2011)
　前々記事にもあるように、手当たり次第にWebからソースを沢山集めすぎて何にするか迷ってしまった。このLAN基板(PHY層がDP83848）を動かすものだけでも5つ、OSなしのもの2つと、FreeRTOSというOSの元で動くソース3つである。

　LAN基板の動作確認のために未経験のOSも入れるというのは、不確定要素が増えて嬉しくないのだけれど、この基板をカメラ制御のホストにするなど、先の開発のためには、OSが動いていて欲しい。面倒かもしれないが、あえてOSのついている方法を選ぶことにする。

　「ねむい」さんが親切にインストール手順を残しておいてくれているのだが、情けないことにその意味がよくわからない。このソースをうまく入れられる見通しがない。迷ったあげく、結局、正規のサイトが公開している一番新しいV7のデモソースを入れることにした。FreeRTOSも勉強しなくてはならない。

　FreeRTOSは軽い実装で、殆どの組み込みマイコンで動く移植性が評判のようだ。AVRならMega328クラスでも動くらしい。しかし、まだあまり詳しく調べていない。これからの開発にはUARTなどを使ったモニターコンソールのようなものが欲しいのだが見当たらない。これは自作するしかなさそうだ。

　久しぶりにEclipseを立ち上げて、ソフト開発に着手する。こちらの案内が具体的だったので、これを参考に、FreeRTOS V7のLPC2368のデモソースをプロジェクトにしようとするが(LPC2368と2388はピン数が違うだけで殆ど同じ）、これがうまくいかない。

　情けないことにEclipseの操作法をみんな忘れている。出来合いのソースを使ってEclipseで新しいプロジェクトを作るという作業が出来ない。ウェブに助けを求めるが、Eclipseの情報はあまりにも膨大で的確な回答を得るのは至難の業だ。情報の海に溺れそうになる。

　「import」を使って、所定のディレクトリの上でワークスペースを指定するということを理解するまで大分時間がかかった。 Makefileがあるところをカレントディレクトリにすることで、ソースの中の「unresolved」な変数は殆どなくなった。試しにビルドをしてみる。だめだ。あっという間にエラーで戻ってきた。

　MakeFileの内容とディレクトリーチェーンを何度も確認する。間違っていない。Eclipseには未定義変数を示すエラーは出ていないが、Makeが一瞬に終わってしまう。いろいろなサイト(ここや、ここ）を調べるうち、どうもコンパイラーが、こちらで使っているCodeSourceryと違うことに気がついた。

　MakeFileのコンパイラーの指定を、arm-elf-gccからarm-none-eabi-gccにかえる。よし、少し動いたが、またストップ。今度は何だ。前とエラーメッセージが違う。

error Please uncomment one of the two configPINSEL2_VALUE definitions above, depending on the revision of the LPC2000 device being used.

う、これは、どこかで見たぞ。何だ、何だ、さっき参考にしていたこのページのエラーと同じだ。ディバイスの識別番号を選ばせている。良くわからないが新しい方にして次へ。

no memory region specified for loadable section '.ARM.exidx'
あー、また同じエラーだ。対処法が書いてある。これは楽だ。「ねむい」さんがオリジナルのようだ。

次は？_sbrk,_write,_close,_fstat,_isatty,_lseek,_readのundefinedエラー
これは、今度のソースにはsycalls.cが入っているので出ないはずだ。

　よーし、ビルドが出来た。いやあ、このページのとおりでビルドが通ってしまった。「枯れ井戸Scope」さん、ねむいさんありがとう。　

ねむいさんのバイナリでLAN基板動く！(5/17/2011)
　ビルドは通ったが、このソースにはUARTがついておらずLCDもKeilの評価用ボードについているLCD用ルーチンで、動作確認する術がない。これではもしLAN部分が動かなかった時、手がかりが全くない状態になる。

　迷った挙句、ねむいさんのソースもビルドしてみることにした。ディレクトリーチェーンの様子がわかってきてインストールできそうだ。このソースにはUARTがついているのでこちらを基本にしたい。ただRTOSのバージョンは6で、これがRTOS7.0.0で動くかどうかの不安要素はあるが、ストロベリーリナックスのI2C LCDも動くようになっているので心強い。

　たまたま、OSなしでも動くLPC2388の単独のUARTのバイナリコードが見つかったので、LPC系のシリアルライター、FlashMagicのテストを兼ねて、これを試しに書き込んでみた。よーし、USBを通したUARTが動いた。

　そうか、ねむいさんのところにはソースだけでなく、バイナリも入っていた。MakeFileが整備されていないのでビルドは通らないが、これをロードすれば、とりあえずLAN基板の動作確認が出来るのではないか。用心のため、このソースについているI2C LCDの実装までしてしまう。これでハードは全く同じになった。

　動かなくて元々である。HEXファイルをFlash Magicで書き込む。200KB以上あるので時間がかかる。何とかエラーなしで書き込めた。いよいよ通電テストである。IPアドレスは何だっけ。ソースリストを確かめる（あとで、ねむいさんのブログの画面写真を拡大するとちゃんと出ていた。さすが、ぬかりがない）。

　このソースはLCDもUARTも別のUSBからのUARTも盛りだくさんの出力が出る。まずは、USBにつながっているUART0から。USBコネクターを差し、TeraTERMを立ち上げる。おおお、字化けはしているが何かメッセージが出始めた。速度を調整して、Tickの回数を示す出力が出た。よし、FreeRTOSそのものはうまく動いているようだ。

　さあ、本題のイーサネットだ。アクセスランプがついたりしてPHY層の部分は何か動いているようだが、上位プロトコルはまだ未検証である。緊張が走る。PCでDOS画面を出し、pingを打つ。

　やりました。やりました。1msでレスポンスが返ってきた。ICMPパケットは通った。さあ、次は、HTMLだ。はやる心を抑えてブラウザーにIPアドレスを打ち込む。おおおー、FreeRTOSのウェブ画面が出た！ひゃっほー、やったぞ。誤配線もなく完全試合だ。2秒ごとにタスクの統計を打ち出してくる。TCP/IPの画面も異常なし。

　いやあ、嬉しい。ねむいさんが折角作ってくれたストロベリーリナックスのI2C LCDは何故か全面LCD点灯（真っ黒）になってしまい調子が悪いが、それを除けばあとは問題ない。

　FreeRTOSの仕組みはまだ殆どわかっていない。まだ何をして良いのかわからない。しかし、とにかくDP83848を使ったLAN基板の100Mbpsのイーサネット・ハードは、これで完全に動いていることが確認された。

　I2C LCDが動かなかったのは別の原因だった。何と雑誌のピンアサインが間違っていたのだ。CN2の38ピンは3.3V、39ピンは5Vとの記載があるが（インターフェース2009年5月号ページ41)、実際はちょうど逆である。3.3Vのはずが、5Vもかかっている。電圧計で確認した。

　サイトには訂正記事が出ているが、こんなところまで調べきれない。電源の間違いは致命的だ。I2C LCDが始め全面点灯するのは過大電圧がかかっていたからだ。もう少しで壊すところだった。プンプン。　隣のピンに移して、I2C LCDも問題なく表示した。サーバーの入力ページから文字を入れてみたが、残念ながらこちらには反映されていないようだ。

ソースビルドに挑戦(5/18/2011)
　仕事から帰って、すぐ工作室にこもる。まだビルドがOKになっていない。動いたのはバイナリーファイルだ。これからこれをいじるのにソースから動かなければ意味がない。V7のソースはビルドできているが、こちらのソースはUARTなどがついておらず不便だ。

　バイナリで動いたねむいさんのソースをベースに開発を進めたいが、このソースはFreeRTOSのV6ベースのようで、V7で動くかどうかは定かではない。最初、試しにビルドしてみたが、makeで殆ど先に行かず門前払いだった。

　しかし、何故上手く行かないのか大分わかってきている。ねむいさんが注釈でFreeRTOSのデモディレクトリに入れるという意味が理解できて来た。要するに、FreeRTOSのソースのディレクトリの構成が、共通部分と機種依存に別れているので、MakeFileを環境に合わせれば良いのだ。バージョンの違いはなさそうだ。

　MakeFileを仔細に調べて、各所で参照しているディレクトリパスを修正していく。すこしづつディレクトリチェーンが合ってきてMakeの時間が増えてきた。おお、最後まで通ったようだ。HEXのファイルサイズを確かめる。少し大きいがほぼ同じサイズだ。これで動くかもしれない。

　ファームの書き込みも順調に済んだ。電源を入れる。よーし、ソースリストに自分が加えた変更どおりのメッセージがI2C LCDに出た。思わずガッツポーズが出る。すべて人さまのソースを借りてのビルドだけれど、これで一山越した。

　　ついでにSpeedを示すLEDが点かない不具合を検証する。LEDの方向を間違えていた。これを訂正し、100Mbpsを示す赤のLEDがついた状態を記念撮影する。写真でぼやけたように映っているのは、ハンダ面が表になる基板なのでアクリルの保護カバーをつけたものである。

　次の課題は、ChaNさんのFatFSの導入とWebからのI/O制御である。ただ、ちょっとみただけでは、FreeRTOSにコードを加える見当は全くつかない。WebServerのソースもファイルシステムを内部的に実現していて難しそうだ。RTCを動かしたいのだが、これもソースリストが余りにも簡単すぎて良くわからない。

　まだまだわからないことだらけだが、これでこのマイコンは、当研究所の4つめのネット対応のマイコンとなった。H8と違ってpingも1msで返って来るし、SDカードのファイルシステムが入れば、今度こそ本格的なWebサーバーに出来る。楽しみである。

FreeRTOSのUARTはいくつもあって(5/19/2011)
　興奮が納まって反省した。人のソースを頂いてそのままビルドし、動いた動いたと喜んでいるだけでは情けない（動くのは当たり前だ）。自分で喜んでいるだけならともかく、ブログで自慢するのも芸のない話だ。少しは創意工夫をした結果を載せるべきだろう。

　と、言うことで、UARTコンソールのための開発を始めることにした。ねむいさんのUARTはprintfを使っているが、入力はない。printfは、syscalls.cにUARTに出す自前の関数を入れて、あとはgccの標準入出力を使っているようだが、このあたりは一番わからないところで、scanfなどは敬遠したいところだ。

　他のサイトの情報によると、FreeRTOSにはUARTの実装にはいくつもの種類があるようで、難しそうだ。NXP社のサンプルソースにはUART関係だけでもserial.c　と　uart.c　がある。バッファーが付いているUARTや、直にデータをとるUARTもある。OSのメッセージキューを使っている方法もある。良くわからない。後閑さんのFreeRTOSのガイドはとてもわかりやすいが、まだFreeRTOSの仕組みが理解できていないので、先に進めない。

　それでも、よくわからないまま、見よう見まねでサンプルソースのuart.cの中のUARTGetchを使って、コマンドプロンプトを出してみる。よーし、データの読み込みのためUARTが止まった。キーボードから一文字入れる。うむ、エコーバックされた。おやあ、ウェブの更新が止まったぞ。おかしい。何のためのOSだ。FreeRTOSはプリエンティティブなOSのはずだ。UARTタスクのループウエイトで他が止まったら困る。

　タスクの優先度が同じなのかもしれない。順位をuIPとUARTで大きく変えてみる（最初から同じではなかった）。しかし、状況は同じだ。OSがプリエンティティブに動いていないのかもしれない。でも調べ方がまだわからない。軽いOSとはいえ、設定するところは山ほどある。

　仕方がないので、これまでAVRでやっていたと同様に、バッファーにデータがあるかどうか調べる自前のUARTGetchar関数をでっち上げ、UARTでは止まらないようにした。

　これで、Webサーバーも動き、LEDも点滅し、UARTもデータを受け取るマルチタスク状態に戻った。しかし、これはUARTが必ず一定時間、vTaskDelay()というCPUを返す待ち時間があるためで、本来のUARTの動きではない。本当は、UARTの受信バッファーにデータの入ることをトリガーに待ち時間が解ける割り込み処理が必要なのだが、FreeRTOSではこれをどうやって実現するかはまだわからない。

　まあ、わからないことは沢山あるが、気ばかりあせっても仕方がない。少しづつ調べていくことにしよう。調べることが沢山あるということは幸せなことなのだ。

雑誌付録ARM基板のLANアダプター作成にはまる

アートワークを始める(4/29/2011)
　どういうはずみか、雑誌付録(2009年5月インターフェース誌）のLPC2388基板のLANアダプター基板を作ることになった。先にぶちあげたプロジェクトのテーマ、モーター制御、ロボット制御からみれば全く関係ない開発なのだが、こういう行き当たりばったりはアマチュアの特権である。現役時代の所長の仕事が目的に対して厳密だったので、その反動なのかもしれない。前にも書いたが、運命の赤い糸に結ばれて何かが決まっていくというのが好きである。

　まあ、しいてこじつければウェブサーバーのライブカメラのマシンになり、モーターでカメラの制御をするかもしれないというところか。ソフトの目処はだいたい見通しがついたので、イーサネットPHY層チップDP83848（正規名はDP83848C）のLAN基板の具体的な構成を考える。

　親基板のこのLPC2388基板は、以前、ChaNさんのビデオに刺激され0.5ミリピッチのVbatピンを切って、RTCバックアップバッテリーの実装がしてある。このとき電池CR2032はマザー基板にフォルダーをつけて、コネクターでつないだ。

　LAN基板をつけるのにはこの縦型の電池フォルダーが邪魔になる。まずこれをはずし、STM32でやったように、CPUチップの上にカプトンテープで絶縁した表面実装用のコイン電池のフォルダーをつける。いけない。Vbatピンのハンダ付けがとれた。また例の照明付きのヘッドルーペを持ち出して再度ハンダ付けやり直し。何かとても無駄なことをやっているようで、ひとりで苦笑いする。

　やっと元に戻った。テスターでVbatに3Vがかかっていることを確認し、胸をなでおろす。これだけ手間をかけたのだから、このLAN基板にSDカードまでつけようと欲張ってみた。雑誌の拡張基板と同じ構成である。ChaNさんがLPC2388用のFatFSを作ってくれている。これを利用しない手はない。このためにLAN関係のレイアウトが片隅に寄り余計窮屈になる。べたアース汎用基板は片面基板になるので、親基板とのコネクターを付けるためハンダ面が表側になってしまうが、これは仕方がない。まあSDカードが上に来るのでこれで良しとしよう。

　久しぶりのアートワークを念入りに始める。これが結構はまる。紙を真っ黒にして何回も配線をやりなおす。狭くなっているので大変だ。でも、自分にはこういう工作が何と言っても一番面白い。根がケチなこともあるのだろうが、ありあわせの汎用基板に、あれこれ部品の配置を考えて、きれいな配線を考えることは、キットや出来上がりの基板に部品をハンダ付けしていくより何倍もわくわくする。創意工夫で事態が一気に解決した時の快感がたまらない。部品の配置を換えてみて、配線が少しでも楽になると暫く機嫌が良い。

　アートワークの途中で、モジュラー用のLEDを基板につける余裕はとてもないことがわかった。用意しているモジュラージャックは、例の付録のフリースケールのイーサネットマイコンボード(MCF52233)のため、DigiKeyで買ってあったものである（結局、つけないままになっている）。

　こいつはパルストランスはついているが、LEDが入っていない。LEDは、リンクとアクティブ、それに10/100Mbps識別の3つも使うことになっている。パルストランスとLED付きのモジュラーを秋月で買いなおすことにする。

SparkFunにガイガーカウンターキットを発注(4/30/2011)
　すんさんの掲示板にも報告したが、あれこれ迷っていたガイガーカウンターをとうとう発注してしまった。前回のブログ記事に「正しく怖がって欲しいものだ」などと偉そうに書いたが、電子工作をやっているのに身の回りの放射線量も測れないようでは、「安全神話」を信じているだけの、ただの能天気になってしまう。

　「正しく怖がる」ためには、自分なりの判断基準を持っていなければならない。実は、大分昔にもガイガーカウンターを作る寸前まで調べたことがある。秋月のキットも、ストロベリーリナックスのキットも知っていた。ただ値段が、気楽に買って実験してみようという値段ではなかったので、買うところまで行かなかった。

　それで今度の騒ぎである。全世界的にガイガーミュラー管（GM管）が不足しているそうだ。どうせなら、真空管にあたるGM管ではなく、半導体（PINフォトダイオード）のセンサーがあると聞いていたので、自作するなら、このキットがないかと調べてみた。さすがにこれは見つからず、あっても10万以上する完成品しかないことがわかる。

　ウェブを調べると、雨後の竹の子のように、キットや完成品が売り出されている。いずれも5万円以上という結構な値段だ。こういう人の弱みにつけこむ商売は、所長の最も嫌うところである。

　絶対に乗ってやるものかと、心に決めていたのだが、ストロベリーリナックスが再び、以前の価格と同じでガイガーカウンターキットの予約受付を始めた。この良心的な価格設定に好感を持って、思わず申し込んでみた。しかし、申し込んだのが遅すぎたのだろう一回目の入荷数に入れず、見事はずれた（うわさでは、申し込みが3000件以上あったとか）。こうなると意地になるのが性分である。

　検索してみたら、SparkFunでもキットを売り出していることがわかった。今は在庫切れだが、バックオーダーを受け付けている。GM管はストロベリーのものと同じ、LND社のチューブLND712を使っている(価格は$149.95 プラス送料　$30.82　$180.77 　円高なので￥14,570）。

　日本代理店のスイッチサイエンスにはラインナップされていない。だめもとで、本体のサイトの会員になり試してみたら、外国からも受付をしてくれそうである。勇んで申し込みをすませる。

　次の日、メールが届いた。やっぱりだめかと読んでみたら、「輸出規制国（北朝鮮、イラン、スーダンなど）に売ったり送ったりしないか申告せよ」とのメールだった。

Hello,
On your recent order, you ordered 1 x SEN-09848: Geiger Counter. This item
is export controlled by the United States government. Do you intend to sell
or send this item to anyone in any of the following countries: Cuba, Iran,
North Korea, Sudan, or Syria? Please let me know at your earliest
convenience.

「ご存知のように日本では、大地震で原発が重大事故を起こしているので、自分のところで監視するために使い、外国に売るなどと言うことは絶対無い」とメールを返す。

As you know, we, Japanese have experienced a serious accident of nuclear
plant with a large earthquake. I want to use this item only for myself
in order to watch environmental radiation. So I absolutely do not intend
to sell or send it to those countries.

ほどなく、「注文を受け付けるので手続きせよ」というメールが来た。FAXでクレジット番号を送る。これはOlimexで経験済みだ。自宅のFAXから国際電話をかける。順調に送られた。これでめでたく注文は受理された。いつ商品が来るかはわからないが、まあ安心を買ったような気がして心が軽い。

LAN基板の工作開始(5/4/2011)
　そうこうするうちに、すんさんの掲示板で、千石でGM管を販売しているということを知った。価格は￥3700。少し小さいようだがレーセオン社だから信頼はおけそうである。ただ、もう売り切れているだろうな。　仕事の帰り、秋葉原に立ち寄り、秋月でLED付きのモジュラーを買うついでに、千石でGM管があるかどうか調査した。やはりどの階にも品物はなかった。店員に今さら聞くのもしゃくなので何も聞かずに帰る。

　LAN基板の方である。アートワークがひとわたり完成したので、基板の工作を始める。やっぱり、モジュラージャックの穴あけが一番大変だ。前回はモジュラーの固定用のボスの部分に大穴を空けてみっともない形になった。今度はドリルスタンドもある。モジュラーの接続ピンは2列目がmil規格の丁度半分ずれた形に並んでいるので、ランドとランドの間に1ミリの穴が開けていく。ドリルスタンドのおかげで正確に開けることが出来た。試してみる。よーし、ピンがぴったり入る。ショートしないようにランドを削ってハンダ付けに備える。うーむ、大分うまくなったぞ。

　しかし、固定用のボスの穴あけはやっぱり綺麗には空かなかった。汎用基板は既に穴が開いているので、この上にぴったり入る孔を開けることはドリルでは難しい。それでも、何とかLEDのピンも含めてかなり正確に穴があいた。モジュラーはピッタリ基板に取り付けられた。これがつけば工作の山は越える。あとはアートワーク通り、配線をしていくだけである。

　DP83848のクリスタルはまだ謎が残る。オシレーター（発振器）は50MhzがRMII時に指定されているが、水晶発振子（xtal resonater)の場合は、25Mhzしかない。しかし、50Mhzのオシレーターをつけようにも、何故か行きつけの千石、秋月では売っていないのだ（48Mhzとか66Mhzはあるのだが）。まあ、とにかく25Mhzの水晶で組んでみよう。水晶なら手持ちの在庫がある。

黙々とハンダ付けにいそしむ(5/7/2011)
　この連休は、ひたすらDP83848のLAN（PHY層)の基板を作っていた。このまえのENC28J60のLAN基板はオプティマイズのお手本があったが、今度はねむいさんの写真だけが頼りだ。こういう配線は一種のパズルである。幾何学のように補助線一本で一挙解決というのは中々ないが、パーツの位置を90度回転させただけで、嘘のように配線が楽になる時があるので気が抜けない。

　アートワークはひととおり終わってはいるが、ハンダ付けの途中でも部分的なアートワークを何度もやりなおし、あれこれ考える。欲を出してLANだけでなくSDカードソケットも付けてやろうと考えているから場所が狭い。思ったより部品が多く、最後は大苦労だった。全部の抵抗を部品面にどうしても置けず、ひとつだけがハンダ面に移動した。

　そのかわり、10/100Mbpsの識別をするチップLEDをつけて（最初は付けない予定）、ちょっと自己満足する。チップLEDを使うのは始めてである。チップLEDのハンダ付けの練習に、チップLEDを基板小片につけて遊ぶ。

　制限抵抗は、ジャンク基板（以前、MACアドレスを貰ったNIC基板、こわしたRTC基板など）から、例の低温ハンダで取得する。チップ部品は意外に普通の半田だけではしぶとく残るが、このハンダだと面白いように簡単にとれる。

　久しぶりのハンダ付けを堪能して、ようやくLANのPHY層基板は完成した。お馬鹿なことに親基板のLPC2388基板はまだ何もやっていない。親基板に電源を入れると、LEDが点滅した。ははは、LEDチカチカから一歩も進んでいなかったのだ。

　ソフトが全く準備されていないので、親基板につけても何も動かない。早く動くのを見たいが、しばらくお預けである。何でLPC2388を開発していたのかも忘れている。そうだ、JTAG経由だった。こういうときにこのブログは大変役に立つ。

DP83848のLAN基板完成後に思わぬ落とし穴(5/7/2011)
　やはり、間違えていた。データシートにはっきり明記されていた。LPC2388とつなぐには、50Mhzのオシレーター（発振器）がいるのだ。遠慮せずに「ねむい」さんに聞くべきだった。自分の都合の良い解釈で25Mhzの発振子で組み上げて、ウェブを見ていたら、「LPC2388はRMIIモードでうごくので50Mhzの発振器が必要」という記事を見つけた。

　ええー、そんなことどこに書いてある。いーえ、しっかりデータシートに出ておりました。「50Mhzの発振子では動かない。RMIIのときは必ず発振器にすること」（p21）。やれやれ。

　動かす前からこれである。腹立ちまぎれにすぐ低温ハンダをとりだして、25Mhzのクリスタルとコンデンサーを一気にとりはずす。さて、50Mhzの発振器である。これが秋月や千石などの定番の店にないのだ。マルツにはあるが12ミリ四方の大きなやつで、とてもこの基板のスペースには入らない。しかも￥1000近くする。

　ウェブでカタログはいくらでも手に入るが、みんな卸しやプロ相手の店ばかりで、小売してくれそうな店は見つからない。やっと京セラの表面実装の50Mhz発振器をばら売りするところを秋葉でみつけたが、￥750。「店頭販売はしない」ということで通販なら送料がかかって￥1000以上だ。話にならない。

　思いあぐねていたら、猫が遊んでボロボロになった分厚いDigiKeyのカタログが目に止まった。ああそうだ。ここにあるかもしれない。調べてみる。あった、あった。CTS社という知らないメーカーだが、表面実装の京セラのにそっくりの石が見つかった（OEMかも）。値段はなんと￥265。

　よーし、これでMbedを買うチャンスが生まれた。前から欲しかったMbedである。DigiKeyでは、日本より￥500ほど安い（￥5405)。何かのときの送料無料のゲタがわりにしようと、買うのを我慢していたのだ。

　Mbedと、このオシレーター、それにDC-DCコンバーターLM2735（ストロベリーリナックスの昇圧モジュールに使われているもの、12V500mAまでとれる。￥322)2ヶ、HブリッジドライバーIR2011(内部に昇圧回路を持ち、NMOS-FETだけでHブリッジを作れる。￥311）3ヶ、あわせて￥7515。送料無料ラインを超え、消費税のかからない(￥10000以下）、最も経済的な価格帯である。上機嫌で発注のボタンを押す。

DigiKeyからオシレーター到着。しかしまたまた大変なことに(5/11/2011)
　DigiKeyから早くも品物が届いた。喜び勇んで表面実装の発振器をとりだす。うーむ、横に出ているパッドが小さくて半田付けに苦労しそうだ。mbedはケースから出してみただけ。少しお預けである。

　ハンダ付けを慎重に行う。ベタアース基板なので、固定は当然、ハンダ面である。DP83848の位置を50Mhz出力に考慮せずに決めてしまったので、LPC2388へのコネクターまでの距離が長い。気休めに、オシレーターをチップとコネクターの中間位置に置いて少しでも距離を稼ぐ。

　パッドが小さくて、本当にハンダ付けが出来たのか心もとないが、とりあえずは全体の配線は終わった。念のため、VccとGNDの導通テストをする。ありゃりゃ、ショートしている。このテストは、クリスタルの時にやって50KΩ以上だったことを確認している。今度のオシレータ化が原因だ。

　あちこち調べ始める。ところが、これが何と、オシレータにしたところを全部外してもショートしている。おかしい。次々にはずして行って、チップ（DP83848)のいくつかあるVcc(48ピン）とGND（47ピン）が残った。こいつがショートしている。えー、ハンダボールでも基板に乗ったのか、拡大ルーペで変換基板上を丹念にチェックする。いや、きれいなものだ。

　遂に、チップをはずす。やっぱりチップでショートしていた。ええー、これはどうしたことだ。思い当たる節がない。まだ電源も入れていない。あっ、そういえば、チップLEDをつけたときに点灯するかどうか、チップLEDの間に3Vの電圧をかけた。チップLEDの一方はI/Oピンに接続され、Vccピンとはプルアップ抵抗を介してつながっている。

　うーむ、これだろうか。この程度でICが壊れてしまうのだろうか。しかし、現実にはチップがショートしている。今のところ、この操作くらいしか原因は考えられない。DP83848は幸い、予備が買ってある。泣く泣く、新しいものに交換する。

100MbpsでHUBが認識した（5/12/2011）
　えらいめにあったが、何とかオシレーター版が完成した。当然のように、VccとGNDのショートはなくなった。それにしても何で壊れたのだろう。まだ狐につままれたような信じられない気持ちだ。配線は完了したが、これで動くのかはまだ全くわからない。簡単に確認する術がない。下手に単独で電源を入れて、こわれたらさっきの二の舞だ。

　親基板のLPC2388はまだソフトが何も入っていないのだ。しかしショックが強くて、すぐ作業を開始する気にならない。色々考えたが、やはりソフトを動かして確かめていくしかない。出来上がった基板を横目にして、LPC2388のソフト開発の手順をゆるゆるとウェブで調べ始める。

　先は長そうだ。気が散ってなかなか先に進まない。意を決して、本体のLPC2388に基板を差し込み、LANケーブルをつないで電源を入れてみた。いずれこれはやらなければならないことである（また大げさな）。ソフトは何も入っていないのでDP83848には電源が入るだけだ。何が起こるかわからないが、もう我慢しきれない。

　おお、薄くモジュラーのリンクLEDが点いた。やった、やった。つながった。接続先のHUBには100Mbpsのディバイスがつながったことを表す緑のLEDが点灯した。時々、アクティブを示すLEDも点滅している。よーし、PHY層の一番下のレベルは動いたようだ。

　オシロを取り出して、オシレーターの出力を測定する。お、良いぞ。きれいな正弦波の50Mhzが出ている。やれやれ、ハードの基本部分は凡そ動いているようだ。今までの苦労が報われた感じで、肩の荷がおりた。とりあえず一段落である。

先が長くなりそうなので、このあたりでブログに報告しておくことにする。

モーター制御が先に進まない

　メカトロニクスだ、ロボットだと意気込んで始めたモーター制御だが、早くも挫折気味である。Xbeeラジコンが一通り動いたので、次はステッピングモーターを動かしてみた。これはすんなり動いたのだが、その先の課題、センシング技術でぱったり歩みが止まってしまった。

その顛末はあとでゆっくり説明するとして、とりあえずこの3週間の活動報告から。

ステッピングモーターで遊ぶ(4/12/11)
　モーター制御の次のお題。ステッピングモーターである。マイコンの作ったパルスだけでモーターを回す一種のブラシレスモーターで、こういうしかけは工作心（ごころ）をとても刺激する。今度のプロジェクト（ライントレーサーが一応の目標）の買い物をしたときに、用もないのに面白がって秋月で一番小型で手頃なステッピングモーターを買ってあった（SPG20-1362　￥250)。

　先達（ここや、ここなど）のページを読んでやりかたを勉強する。5V近辺では、普通のステッピングモーターでは余り高回転にはできないようだ。kumanさんあたりによると120rpm(1秒に2回転）くらいが限度だと言う。実験なので、ありあわせの5V電源に、LEDマトリックスのとき使ったトランジスタアレイTD62083をドライバーにして早速ブレッドボードに組んでみる。

　マイコンは、お馴染みのAVR　Tiny2313。フラッシュは少ないが、ポートが連続して取れるし、何しろ安い(￥100)のが強みである。　プログラムは順当にタイマー割り込みで制御タイミングを作り、例のISP-UARTでモーターのスタート・ストップ、速度制御が出来るようにする。

　コンペアマッチで起きるタイマー割り込みの間隔をUARTのコマンドで調整できるようにして、4bitのポートピンを順次パターンどおり入れて動かしていく。ポートの下半分（上半分にはISP-UARTが入っている）だけをいじりたいので、一旦、ポートごと、ピンを読み出してセーブし、必要なところだけデータを入れ替えてから元へ戻す。いわゆるread/modify/writeでコードを組む。

配列phase[4]に二相駆動のパターンをconstで定義し、

const phase[4] = {0b00001001, 0b00001100, 0b00000110, 0b00000011};

それで、以下のステートメントを割り込みの度に実行させれば、動くはずだ。

pin_save = PINB & 0xF0;    // save upper nibble of PINB
    pin_save |= phase[i++];    // take next pattern
    if(i == 4) i = 0;          // repeat it evry 4 times
    PORTB = pin_save;          // set new PORTB pattern

　モーターはすんなり動き始めた。おやあ、ジージー音がして、余り良く廻らないぞ。これが脱調と言われるやつか。タイマーの時間を増やしていく。うむ、少しづつ振動が減って回転がスムーズになってきた。遂に全く音も振動もなく静かにモーターが廻り続ける。おやおや60ｒpm（回転数/分）以下だ。このステッピングモーターは5Vでは、55rpmを越すと細かい脱調が始まる。

　スタートストップや、逆回転（逆にしたパターンの配列に換えるだけ）のコマンドを入れて、UARTから自由にモーターが制御できるようにする。こんな簡単な実験でも、やっぱり動きモノは理屈ぬきに面白い。しばらく遊ぶ。

「Tiny2313でステッピングモーターをまわす 」

　ただ、ステッピングモーターは残念ながら実験だけで手近な応用例が見当たらない。この程度の速さなら、時計の針くらいしか用途が思い浮かばない。カメラのパンくらいには使えそうな気もするが、今のモーターでは非力すぎて無理だろう。マイクロマウスにはもっと強力なモーターが必要だ。 

ステッピングモーターを回すだけのソースですが、とりあえずここに置いておきます。例によってAVRStudioのフォルダーになっています。回路図はつけませんが、ソースのコメントを参照してください。

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

大阪造幣局の「通り抜け」に行ってきた(4/14/2011)
　久しぶりに関西に家の用事で戻ったとき、丁度、遅咲きの桜で有名な大阪造幣局の「通り抜け」の公開初日にあたったので見に行ってきた。ここは、見事な八重桜の並木が川沿いに1キロ近く続くところで、所長は関西出身だが、これまでTV、新聞で見るだけで実際にここを「通り抜ける」のは今回が始めてである。

　平日の初日なので思ったほど人は居なかった。花の時期としてはまだ少し早く、こぼれるような八重桜というわけには行かなかったが、沢山の種類の八重桜を鑑賞できた。ただ、たいして混んでも居ないのに係員が「立ち止まるな。足を止めるな」とうるさく拡声器でせかすのは興ざめだった。

　関西は地震の影響は少ないと聞いていたが、このとき乗ったタクシーの運転手の話に驚いた。国外に避難した外国人だけでなく、関東の日本人もたくさん関西に逃げてきたそうである。　明治維新の頃、写真をとられると魂が抜かれると怖がり、明治になってからでも、送電線の下をくぐるとコレラにかかるという迷信が流行ったことがあるそうだ。人間と言うのは、理解できない、目に見えないものに対しては特別な恐怖心を覚えるものらしい。

　原発の是非をここで議論するつもりはない。ただ冷静に判断して、4月に入ってからの福島原発の状況は、関西まで逃げなければならない状態ではない。事故発生直後の1週間は確かに心配だった（ひそかに風向きとか天候を調べていた）が、今はその危機を脱していることは確実だ。日本は最近まで、放射線照射などによる遺伝子組み換え大豆を輸入していなかった数少ない国の一つだそうであるが、どうも怖がり方のピントがずれている。

　女優と離婚騒ぎを起こしたネットの有名人が、西表島から「原発から一番遠い南の島より」というメッセージをブログに載せてみんなの顰蹙（ひんしゅく）を買ったが、西表島の西200キロ（東京福島間くらい）には放射能漏れで反対運動の起きている台湾の原子力発電所が3つ以上稼動しており、しかも偏西風で間違いなく風は沖縄にやってくる。怖がるのも良いが、正しい怖がり方をして欲しいものだ。明治の人を笑ってはいられない。

FETならもっと早くなると思ったが(4/16/2011)
　それはともかく電子工作である。旅行から帰った後、工作室に戻っても、やることがなくなってしまった。ステッピングモーターは動いたが、目的がないので、まわってしまえばそれだけの話である。それでは身も蓋もないので、モータードライバーをトランジスタアレイでなく、MOS-FETに換えてみた。

　秋月で買ったNMOSのFETアレイMP4401である。5つも買ってしまってある。ネットの回路図には、ゲートとマイコンのポートの間に抵抗が入っている（2KΩ程度）のと入っていない直結のものがあるが、実験なので直接つないでしまう。

　ピンを少しやすりで削り（1mm近くあってブレッドボードにささらない）、トランジスタアレイへの配線からFETアレイの方にジャンパーを飛ばす。造作のない話である。このFETアレイには、モーターの逆起電圧をバイパスする、フライバックダイオードも内蔵されているので配線は簡単に済んだ。

　回してみる。うむ、トランジスタより快調のようだ。脱調が起きずにスムーズに廻る限界は、トランジスタでは55rpmだったが、FETにすると70rpmくらいまで楽に安定して廻った。ただ、オシロで見ると、モーターにかかる電圧はP-Pではどちらも5.2Vで全く変わらない。変わったところは、RMS（実効電圧）で、FETで3.6Vとトランジスタより、0.1Vほど高くなった。

　モーターは暫く連続して回すと（80～90mA)、ほんのり暖かくなるが、FETの方は全く熱らしいものは持たない。そりゃそうだ。連続3Aをドライブできる石に1/30もかけていない。牛刀で鶏を解体しているようなものだ。トランジスタの場合は、この前のXbeeラジコンカーのTA7291Pでは小さなモーターひとつに結構、熱を持っていたが。

　FETで動かして、ステッピングモーターでは、やることがなくなった。もう少し大きいものを動かさないと大電流の制御をマスターしたことにはならない。この先のマイクロマウスなどは、ステッピングモーターで駆動しているようで、このまま先に行くのはちょっと不安だが、ウェブで見る限りマイクロマウスに使っているモーターは結構高価でそう簡単に試すわけには行かない。

　計画しているウェブカメラの雲台などの制御はステッピングモーターになると思うが、これは機械工作の方が大変だ。急には始められない。となると、当面の目標はライントレーサーということになる。2モーターの制御はラジコンで確かめてあるので、地面の書かれた線をなぞって車を制御するセンシング技術が次の課題である。センサーのハードそのものは、このまえ既に秋月で、大きめのフォトインタラプタ（LBR127HLD　￥60）を調達し、これでやるつもりだ。

ライン制御のノウハウがわからない(4/18/2011)
　センサーのロジックを調べ始めた。しかし参考になる情報が極めて少ない。ライントレーサーを話題にしているサイトは山ほどあるのだが、実際にフォトインタラプターの数はどれくらいが良いのか、折れ曲がったライン（直角のラインなどが難しそう）をうまくトレースして2つのモーターの制御を具体的にどうするべきかなどの実践的な情報がないのである。

　モーター制御の特集をした雑誌（インターフェース誌　2010年1月号）には簡単な制御ロジックがでているが(P60～65)、こんな簡単な制御（3つのインタラプター出力をコンパレーターにかけ0,1だけで判断）では、少し速度を上げればすぐ破綻するのは目に見えている。

　一番頼りになったのは、結局はやはりChaNさんのチョロQのモーターをつかった手のひらサイズのライントレーサーのページである。こいつはコイン電池2つを載せてA3 の用紙の上に描かれた8の字コースを器用にクルクル廻る。素晴らしい。

　しかし、ここでも制御アルゴリズムとなると途端にPID制御の話が出てきて理解不能に陥る。こちらは昔、なまじ自動制御技術をラプラス変換か何かで勉強させられたのでその復習を、良い機会なのでやりたいのだが、このPID制御理論との整合性がどうにもとれない。

　他のサイトも、このあたりは極端に省いているか、極端に難しく説明しているかどちらかで、こちらが考えているような具体的な技術（しかけ）に応用できそうなロジックが見つからない。最近、良くコメントを寄せてくれるeNastyさんが紹介してくれたサイトも、全体的な話だけで肝腎のセンシングのアルゴリズムまでは出ていない。

　秋月で入手した大きめのフォトインタラプターLBR127HLDは、ちょっと試してみたところ、かなり感度は高そうなので性能的には問題なさそうだが、これをいくつ並べて、どの位置から値をとれば良いのかがわからない。どうもラインセンサーのこの部分はかなり高いノウハウのようで、そう簡単にはウェブでは教えてくれないようだ。意図的に省いているのではないかと勘ぐりたくなるくらいである。

　やれやれ、これは相当な下準備をして、実験を重ねながら、自分なりのアルゴリズムを考えて実装していく必要がありそうだ。一筋縄では行かない。道は遠そうである。

雑誌付録基板LPC2388のLANポートを作り始めた(4/20/2011)
　そんなことを思い悩んでいるうち、このブログに、2年近くも前のXbee電力ロガーの記事を目当てに来るお客さんが急に増えた。調べてみると、震災後の話題のひとつ節電にからんだ交流電力の測定の話である。こちらのURLがいくつかのサイトで紹介されているようだ。そこでも話題になっているのが、正確な交流電力の測定のための専用のチップADE7753である。2年前に買ってそのままになっている。

　そう言えばあのとき一緒に買った、EtherNetの物理層（PHY層）のIC、DP83848も、変換基板に載せたままそのままになっている。久しぶりに、このチップ2つを取り出して眺めているうち、どういうはずみか、急にネットワークチップDP83848の実装がやりたくなった。

　この石は、もともとCPU基板の雑誌付録(インターフェース誌2009年5月)とタイアップした部品販売店のLAN&SDカード拡張基板が法外に高価なのに反発して、自分で作ってやろうと手に入れたのだが、ぐずぐずしているうちに、STM32でお世話になっている「ねむい」さんに先にあっさり実装されてしまい、変換基板に半田付けした時点で、すっかりやる気をなくして放置してある。

　このLANチップの親のCPU基板は、LPC2388である。この基板も、ChaNさんが雑誌に詳しく制作記事を掲載されたのを契機に制作意欲を失い、開発環境を試しただけでそのままになっている。へそ曲がりで天邪鬼（あまのじゃく）な性格なのは困ったものだ。結局ARMはSTM32の方に走った。

　今となっては少し古い設計だが規模から言えば、この石（LPC2388)なら静止画くらいのウェブサーバーを作れそうである。ここにステッピングモーターを使ったカメラの移動装置を作りこめば面白いかもしれない。イーサネットPHY層のチップ、DP83848の実装が無駄にならないですみそうだ。

　寄り道をする癖がついてしまって、DP83848を載せた変換基板に、かねてより準備していた回路図でハードの実装を始めた。この回路図は、「ねむい」さんが、実装するのに利用したKeilのLPC23XX用の評価ボードMBC2300の回路図である。こちらも同じ頃、独自に発見して残してあった。　

　実装も彼のやりかたをそっくり真似て、千石でサンハヤトの片面べたアースの汎用基板を手に入れた。このまえのマイクロチップのLANチップENC28J60は普通の基板で問題なく動いたが、今度は100BASE/Tでも動くNICチップである。彼の言うように用心するに越したことはない。価格も￥250とサンハヤトにしてはそう高くない。

　まず、変換基板上につけられるだけのパスコンをチップコンデンサーでハンダ付けする。べたアース基板は気をつけないと簡単にショートしてしまいそうで実装には気を遣いそうだ。久しぶりの細かいハンダ付けである。モジュラージャックの固定が問題だ。

ソフトをたくさんダウンロードしすぎた(4/25/11)
　配線そのものは予想したとおり、そう難しいところはない。「ねむい」さんが50Mhzの配線に気を遣っておられるが、データシートでは25Mhzのクリスタルを外付けすることになっている。良くわからない。RMIIモードでは50Mhzを出力するピンがあるが、Keilの回路図ではここはどこともつながっていない。まあ、組むだけ組んでみよう。それよりソフトを用意しなければならない。

　LPC2388にDP83848を付けてウェブサーバーにしているサンプルソースは、いくつかウェブ上に見つかっている。ただ、OSを使うか使わないかの判断が難しい。CPUお膝元のNXPのサイトには、この評価ボード用のデモソースがあるが、これはOSを使っていない（AN10799)。　uIPのサイトからもLPC23XX用のOSを使わないDP83848を使ったWebServerのデモソースを落とす。これもOSなしだ。

　ウェブカメラのようなアプリケーションを制御するならOSなしより、OSが入っていたほうが圧倒的に開発が楽になるので、FreeRTOS6.0とlwIP1.3を使ってWebServerをこの評価ボードで作った個人のサイトからも、ソースを頂く。当然、「ねむい」さんのところからも。ChaNさんのFatFSが、FreeRTOSのもとで動くか心配だが。

　TOPPERS/JSPもLPC2388で動くようだ。TOPPERS/JSPは、参考書も買って一時、H8に入れようとしたが、開発環境がLinuxだったりして敷居が高く、先に進まなかった。ChaNさんのFaｔFSはTOPPERSの標準ファイルシステムだ。TOPPERSにしたい気持ちもある。今まで外国製品ばかり使っている。H8もNECの78K0も、ルネサスのSH2もろくに使っていない。

　ここでOSまでもFreeRTOSにすると非国民と言われそうなので、TOPPERSを無理にでも入れたいのだが、初めての評価ボードにいきなり実装するのは余りにも冒険過ぎるだろう。OSにこだわるのは、一旦、入れてしまうと別の環境に移りにくく、いわゆるロックインされてしまうからだ。

　あれやこれやと迷路の迷路に入り込んで、ウェブをさまよう。まあ、これが面白くて電子工作しているようなものだけどね。

　結局、ウェブからソースコードが5セットも集まった。OS付きが3つ、OSなしが2つ。色々迷った結果、正規のFreeRTOS7.0のデモソースが、この評価ボードをターゲットにしていることを確認し、これが一番新しそうなので、これをインストールして動かすことに決めた。さて始めてのOSである。うまく動くかどうか。

Xbee APIモードのラジコン制御成功

　モーター制御をするはずだったのが、XbeeのAPIモードに寄り道し、XbeeのAPI汎用モニターをでっちあげてしまった。そのついでに、これまで気になっていたUARTの改善にはまりこんでしまう。完全な「寄り道の寄り道」である。

ソフトUARTをC言語化する(4/1/2011)
　Xbee自体が道草だったのだが、さらに迷路である。このISP-UARTは、最初ChaNさんが作られたもので、ISPシリアルライター（AVRSP)でプログラムを書き込んだ後ケーブルをつなぎかえる必要もなく、そのままの状態でUARTに使えるというのがウリである。

　AVRに取り組んですぐ、ChaNさんのオリジナルUARTソース（アセンブラー）に、受信が割り込みで動くようにC言語でロジックを追加した。この改修で、UARTは入力待ちで止まらないので（入力があるとフラグを返す関数を使う）、モニター代わりに当研究所では殆どのシステムに入れてある。

　デバッグが済めばUARTを使わないシステムでは完成後はずせばよい（フラッシュに余裕のある時は結線をはずすだけ）。中の変数を簡単に出力でき、プログラムをLEDなどでデバッグするより格段に効率が良いので、大変重宝している。

　ただ、前から不満が残っていた。それは、ソースコードに、ChaNさんのアセンブラールーチンが残っていて、使うたびに、アセンブラーのファイル（.S)とUART本体のファイル(.C)の2つをインクルードしなければならないことである。それと以前、アセンブラーの部分をすべてCに換えようとして、うまくいかずあきらめて残した経緯がある。それ以来、何となくわだかまりが残っている。

　ISPのラインを使わず（MOSI/MISO/SCK)、通常のGPIOで、このUARTが使えるようにしたことはあるが、このASMルーチンは残したままであった。ISP-UARTは、通常のUARTと違い、ISPのプログラム書き込みの関係か、UARTのデータラインが正論理（スタートビットがHigh)になっており、このときはこれを負論理に置き換えただけである。

　アセンブラーで書いた部分をC言語に出来なかったのは、時間遅れを正確に把握できず、受信がどうしても安定しなかったためと記憶している。しかし、あのころに較べたらオシロもロジアナもあるし、開発環境は格段に進歩している。丁度良い機会なので、XbeeのAPI汎用モニターをより汎用化するため、GPIOのC言語だけのUARTを作ってしまおうと決意した。

　意気込みは良かったが、やっぱり今度も、四苦八苦した。送信は何とか動くようになって、マイコンからのオープニングメッセージが出るようになったが、PCからのデータ受信が難しい。キーボードからの1文字だけの入力なのだが、どうしても正しい文字を受け取れない。

  やっぱり、ロジックアナライザーの出番が必要になった。GPIOでボーレートに従ってピンの入力を調べるところへ、ロジアナに信号を送るプローブピン（ピンをトグルするステートメント）を入れ、時間を測った。UARTはどんなに早くても1ビット数十から数百μsの世界だが、AVRのクロックは4Mhzでも1/4μsで少々プローブを入れても影響は殆どない。コンパイルし直してロジックアナライザーを動かす。

　これでGPIOの動きが一目瞭然になる。これが一番強力なデバッグ法だ。これができなくて前は挫折したのだ。画面を注意深く検討する。うーむ、想定どおりのタイミングでデータを読み込んでいるぞ。正しくデータをとっているようだな。ビットを数える。ちゃんとスタートビット、ストップビットをカウントしている。チャートで見る限りは正しい文字を得ているはずだ。それなのに出力がおかしい。

　わかってしまえば、馬鹿馬鹿しくなるほど簡単な間違いなのだが、この段階でも原因はつかめなかった。デバッグというのはこういうものだ。一生懸命、タイミングを調べていたが、ロジアナで見る限り、データを採取するタイミングは間違っていない。最初、割り込み直後の待ち時間が長すぎて、全体が後ろにずれていたが、これを補正してコンパイルしなおしても正しいデータはとれない。とすると原因はここではない。

　採集した1バイトデータがこのあとおかしくなっていることになる。1バイトデータはシフトレジスター的に1ビットづつ移動しながらデータを取る。ふーむ、前もこんなことがあったような....もしかして出来上がったデータを最後にさらに回してはいないかい。あ、あ、あ、やっぱりここでもやっていた。

　いやあ、時間がかかった。これはdo whileのように終了条件を後にしても解決しない。8ビットのデータを得ながら、8回シフトすれば、データは1ビットずれる。出力する側をシフトするのでなく、マスクする側をシフトするようにロジックを変更する。

　よーし、受信も問題なく動くようになった。C言語での割り込みのオーバーヘッドはやはり思った以上にASMよりかなり大きかった。ASMではビットレートの半分くらいをスタートビットから待っていたが、この部分はCでは殆ど必要がないくらいだった。クロック4Mhzで14μsもかかっている（38.4kbpsで1ビット26μs)。一旦読み込みが始まれば割り込みを経由しないので、ほぼ想定どおりの待ち時間でまわっている。

　CPUクロックが4Mhzとかなり低い（たまたまこの水晶しかなかっただけだが）のでクロックを上げたときには、もう少し補正する必要があるかもしれない。

　それにしてもChaNさんのコーディングは何時見ても実に素晴らしい。このUARTの送信の部分のアセンブラーコードなどは惚れ惚れする。UARTのスタートビットとストップビットの追加は、普通なら別のステップを用意するところを、10回のループをまわしているだけで実現している。

　スタートビットは、まずCOMという命令でデータを反転させ（このUARTは正論理なのでこれが必要）、ついでにこのときできたキャリービットをスタートビットに使う。そして最後のストップビットは、シフトの空振りで出来るゼロビットで実現だ。送受信とも命令数は10あるかないか。

　皮肉なことにフラッシュサイズは、全部Cにしたら数十バイト増えてしまった。要するにこれだけ苦労して必要なファイル数をひとつ減らしたに過ぎない。まあ、これで全部自前のコードになったというつまらないプライドは満足させることができた。

タクトスイッチを使ったXbeeのデジタル出力が実現した(4/5/2011)
　それはともかく、Xbeeのラジコン制御である。ラジコンだけなら、面倒な汎用モニターの大部分（キーボード入力文字をデコードする部分）のコードは不要である。どうしようか迷ったが、ラジコン制御のロジックも今のAPI汎用モニターに組み込んでしまうことにする。

　汎用モニターもまだ修正するところがあるだろうし、ソースをひとまとめに管理していた方が楽だ。すべての処理はイベントドリブンで動いているので、どちらもオーバーヘッドになることはない（ifのところだけ）。フラッシュにも余裕がある。

　モーターにひとつづつタクトスイッチを割り当て、スイッチの押下でモーター起動、離すと停止するコマンドを送ることにする。前進、後進の切り替えは、スナップスイッチで別のピンを設定する。

　このピンを見ながら、それぞれのモータードライバーの2本の制御線のどちらかをONにすればラジコン側は、4本の出力ピンだけで前後進、左右転回ができる理屈である。

　まず手始めに、一方のモーターの前進部分だけを実装する。モータードライバーへの供給電圧と、XbeeのVccが違うのに気がついて、最初はLEDを使う。

　タクトスイッチのチャタリングは、これまでのインタバルタイマーの時間を20msから5msに短縮（プリスケールを1024から256に）し、ピンチェンジ割り込みをスイッチポートに設定し、割り込みが起きてから5ms待つことで防止する。

　大した作業量ではない。ほどなくスイッチを押すとLEDが点灯し、離すと消えるという機能が実現した。心配していたが、応答速度は、想定していた通り、100ms内外に納まる。　最初は通信が確立していないので、1秒位待つ時があるが、その後は、殆ど変わらない。　UARTからメッセージが滝のように流れるが、これはXbeeからのレスポンスデータなので、タクトスイッチのレスポンスには影響がない。子供のように子機を遠くに離してLEDが点いたり消えたりするのを楽しむ。

遂に、XbeeのAPIモードを使ったラジコンの操縦に成功（4/7/2011)
　LEDで成功したので、いよいよモータードライバーへの接続である。子機のXbeeの電源はレギュレーターで3.3Vにしているが、モーターは大きなレギュレーターがないのでリチウム電池そのままで、この間にはレベルシフターが必要になってきた。XbeeからいきなりモータードライバーTA7291Pにつなぐのも心配だったので丁度良い。手持ちの2SC1213などのトランジスタでバッファーをブレッドボードに組んだ。とりあえず前進のみの2つ。

　Xbeeを載せたブレッドボードは落ちないようにモーターの上にマジックテープで仮止めし、電池フォルダーもモータードライバーのサブ基板のすきまに放り込んだ。急回転するとどちらも落ちそうだが、早く動くところを見たいので激しい手抜きである。

　試運転に入る。胸が高まる。スイッチを入れるとき少し暴れてモーターが動くがすぐに納まる。Xbeeは最初の通信が確立するまで秒単位待たされる。

　タクトスイッチ2つを同時に押すと直進、どちらかを止めると回転。おおー、操縦できる。快調快調。コマンドの遅れも殆ど感じない。機械は、電池と制御ボードを背中に載せた不細工な自走車だし、ラジコンで動くことなどいまどき驚く話でも何でもないが、すべて手作りでここまで動かしているという感動で胸が一杯になる。

　この感激を分かってもらうのは、これはやはり動画でないと面白くない。携帯で動画を撮ることを思い立つ。苦心して携帯を固定し、何シーンか撮ったが、やはり操縦と撮影を一人でやるのは大変だ。何とか出来たムービーを、ブログのビデオ共有サイトに送ってはみたもののもう少し良い画を撮りたい。

Xbeeラジコン試走

　それに、今は前進だけで、後進できないので一旦障害物に当たると戻れない。リモコンはPC横の大きなブレッドボードに作ってあるので移動できない。やらなければならないことが急に増えた。

少しまともな動画を撮る(4/08/2011)

　携帯電話で撮った動画は、まあ、動いていることをみなさんにわかってもらうだけのレベルで満足できる結果ではなかった。負け惜しみになるが、もともとはライントレーサーにしてみようと思っていた車体をXbeeを見て浮気してしまっただけのことである。　この程度で止めれば良いものを、やりだしたら止まらない性格である。後進機能と、リモコン機のポータブル化につきすすむ。PC横の大きなブレッドボードに設置した親機を、ミニブレッドボード2つに移し、リモコンとして持ち運べるようにする。

　ラジコン車の方は、4つのトランジスタをミニブレッドボードに詰め込んで、後進もできるように実装した。後進のロジックは大分前にもう作ってある。リモコン機が出来た。電源は単3二つのバッテリーケースを持ちながら移動する。後進も想定どおりスナップスイッチの切り替えで順調に動いた。家族にビデオをとってもらうため居間に持ち込む。猫2匹が早速重大な関心を寄せる。

　家族に撮影を頼んで、居間で動かす。猫がいても面白いので、猫を入れて撮影する。始めは恐る恐る見て いた猫も次第に慣れて来て、容赦のない猫パンチを浴びせ、ジャンパーが飛んで操縦不能になるところまでの画がとれた。少しは笑っていただけるかもしれない。

　ひと時の興奮から醒めて冷静になって考えた。ラジコンだけでは今さら何も珍しくも何ともない。XbeeZBのAPIモードでマイコン使わないで制御していることなど、わかる人でもなければ、誰も感心してくれない。やっぱりライントレーサーにいくしかないか。

以下に、ISPピンでなく普通のI/Oピン（PC5,PC4)でUARTを動かすバージョンのXbeeAPIモード汎用モニターのソースと回路図ファイルをAVRStudioのフォルダーに入れたものを置きます。ChaNさんのASMソースを使ったものも入っています。コンパイルのときに選んでください。ISPピンで動くソースは、save_org_uartフォルダーにあります。

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

「XbeeZBラジコンと猫の襲撃 」

Xbee ZB APIモード汎用モニターのソース公開

　遂にXbeeのAPIモードを使ったリモートATコマンドが動いた。親機から送ったコマンドがリモートの子機に伝えられて子機のLEDが点いたり消えたりする。これでラジコンのための機能は実現した。いやあ今度も最後の一歩が長かった。ローカルのATコマンドが動いてから、リモートを動かすまでに3日もかかっている。

やっとのことでリモートATコマンド稼動(3/24/2011)
　リモートATコマンドが動かなかった原因は、今度もわかってしまえば何でもないところだった。親機（マイコンにつけたコーディネーター側のXbee)ではAPIフレームに入れたコマンドが動き、続いてパラメーターの入力の開発にとりかかったころ、戯れにX-CTUでリモートコンフィギュレーションの画面を出してみたら、何と子機のアドレスが画面に現れ、パラメーターの読み書きが出来るようになっているではないか。

　これはXbeeのAPIモードでのリモート環境が正常に動いていることを示している。リモートATコマンドが動かないのは、みなこちらのせいだ。原因究明に力が入る。しかしAPIフレームのフォーマットをいくら調べてみても間違っていない。アドレスは何度見ても正しい。無線なので、中のデータを覗くわけにも行かない。これ以上調べるところがない。

　ただ、気になっていることがひとつある。親子に同一の2バイトのPAN（Personal Area Network）ネットワークアドレスを指定しても、返ってくるレスポンスデータには、必ず0xFFFEというブロードキャストアドレスが所定のエリアに載っている。

　無印のXbeeとXbeeZBでは、このあたりのアドレスの取り扱いが大きく変わっており、マニュアルを読み込んでいないので自信はないが、どうもこの2バイトアドレスは、ネットワークがつながる度にダイナミックに決まっているような感じである。ただしX-CTUでは任意に初期設定ができる。

　だめもとで、送信APIフレームのネットワークアドレスの欄を、返ってきた値と同じ、0xFFFEにして動かしてみた。やったー、ビンゴ！である。リモートにコマンドが届き、レスポンスがNo　Errorで戻ってきた。

　やっぱり、おかしい、おかしいと思っていたこの2バイトアドレスが張本人だった。もういちど丁寧にマニュアルを読み込む。ZBでのこのアドレスは、無印Xbeeのときのような所定のPANアドレス（PANID)ではなく、ネットワークが確立する度に、コーディネーター（親）がエンドディバイス（子）に対して振り直すようだ。

　それを無視して一定のPANIDでアクセスしても子供は見つからないと言うことか。そう言えば、ログを調べているうち、一回だけ動いていたのを見つけたことがある。これは最初の通信だったからだろうか？　それならどうして指定することが出来る。わけがわからない。

　それはとにかく、今のところ本気でXbeeのネットワークを組む気はないので、とりあえず親機でネットワークアドレスを0xFFFEにしておけば、万事解決である。動けばそれで良い。いやいや、久しぶりに解決したときの爽快感を味わう。体の動きが軽い。

リモートのI/Oピンを動かすのに成功！(3/25/2011)
　興奮が納まって次の課題に取り組む。実は、まだ当面の目的に達していない。動いたのはコマンド問い合わせ（query）だけで、コマンドのあとにパラメーターを指定してデジタルピンなどを動かす設定(modify)機能が動いていない。パラメーター指定はUARTからなのでキャラクターを、APIフレームのためにバイナリに換えなければいけない。

　さらにソフト開発を続ける。これが結構難しい。APIフレームのデータレイアウトはアライメントが無視されているので、4バイトバイナリーなどはうっかり使えない。1バイトづつの処理が必要だ。アスキー文字の16進表示を実際のバイナリデータにするのは、1対2でデータをずらしていかなければならない。簡単には行かない（1バイトのデータを得るのに、2バイト分のキャラクターが必要）。

　これで良いと思ってテストしても想定したバイナリが入らず、Invalid　Parameterのエラーメッセージではねられる。意地になって、久しぶりのコーディングに夢中になる。手当たり次第にprintfで途中経過を表示させながら、何とかATコマンドの後についた16進数キャラクターをパラメーターのバイナリーにするロジックが完成した（出力側のAPIフレームのパラメーターエリアを固定にして最後からデータを入れていくのがミソだった）。

　パラメーター入力はコーディネーター(親機)の方では正常に動いた。次はいよいよリモートだ。あせる手でエンドディバイス(子機)のXbeeのブレッドボードにLEDをデジタルピンD1につけ、PCに戻って親機の方から子機にデジタルピンを上下するコマンド、ATD14（D1ピンをOFF(4)にする）を入れる。点いた！（LEDをVccにつないでいるので負論理）　やった、やった。今度は、ATD13(ON)。消えた。けなげに点いたり消えたりするLEDがいとおしい。撫でてやりたい。よしよし、これでXbeeだけでラジコンを動かす機能は実現した。完成まであともう少しである。

100ミリ秒で制御できれば何とか使えるか(3/26/2011)
　ただ喜んでいるわけにはいかない。LEDの点灯や、消灯は、コマンドを入れて一瞬とは行かず、ほんの少しだが一呼吸おいて動作する。どれくらい遅れているのだろう。ラジコンが動かせるくらいの早さでON/OFFが出来ているのだろうか。　

　オシロで時間を測ってみることにする。2現象でPCからマイコンに行くUARTと、マイコンからコーディネーターXbeeに行くUARTの2箇所と、実際のエンドディバイスのXbeeのLEDのON/OFFの間を比較する。PCを起点とするUARTからでは200ms、マイコンからXbeeへのUARTからなら50～100msでピンの制御ができることがわかった。思ったより早い。

　ラジコンのコントロールはタクトスイッチでやるとするなら、PCからのUARTの早さでなく、マイコンからXbeeへのUARTの早さでコントロールできるだろう。100ms以内で動きそうだ。車程度ならそう遅れを感じずに制御できるだろう。

　それにしてもAPIモードは難しい。分からない単語が頻発する。もともと省電力化した複雑なネットワークを意識しているので、盛りだくさんの機能がついている。エンドディバイスもデフォルトで、スリープモードに入るようになっている（制御が始まれば暫く動いているが）。今のところラジコンだけが目的なので、当面このあたりは関係ない。

　マニュアルを読んでいると、あまり詳しく設定しなくても、エンドディバイスを兼ねたルーターをいくつも介して、遠方にいるXbeeとメッセージ交換ができるようで興味をそそられるが、暫くはお預けにする。

　こういう性格なので、いちどのめりこむと元へ戻るのに時間がかかる。だいたいXbeeだってモーター制御をやろうとして、ラジコン制御に気が移り、寄り道した完全な道草だ。それよりAPIモードのモニターの完成度をもう少し高めようと思う。今のままではとても人さまに使ってもらえる状態ではない。

汎用的なAPIモニターの制作へ(3/27/2011)
　汎用的なとは言ったものの、現在のプログラムは、PCにつなぐUARTは、ChaNさんのシリアルISPプログラムライターのケーブルを利用した特殊なUARTだし、子機のアドレスはプログラム決めうちでコンパイルしなければ変更できない。とても汎用的とは言えない。

　しかし、ウェブを見ているとXbeeのAPIモードでの取り扱いはみな苦労している。頼りのユーティリティX-CTUはAPIモードになってしまうとコマンドはいちいちフレームを作らないと動かせないからだ。

　X-CTUでは、パラメーターの設定はリモートまで出来るが、ファームに全部の設定をバッチジョブ的に書きこむだけで、ATモードのときのように適当なコマンドを入れて確かめたり、設定を臨時に変えたりすることは出来ない。

　これに対して、今のプログラムは、少なくともコーディネーター配下につながる全てのAPIモードのXbeeに対し、任意のコマンドとメッセージを送ることができる。アドレスをプログラムで換えられるようにするなど、あともう少し機能を追加すれば、みんなの役に立つツールになるのではないかと考えた。道草ついでに少し時間をかけてみることにする。

　そこで、まずAPIモードのもうひとつの方法、Escapeモード(ATAP=2)も実装することにする。今度のラジコンには関係ないが、アナログセンサーなどにXbeeをAPIモードで使うときは、普通のAPIモードでは実用的ではない。フレームのヘッダー文字0x7Eがデータの中に現れたら、そのフレームは目茶目茶になる。　

まあ、APIフレームにはデータレングスがあるので、すべてのソフトが注意深く作られていれば問題ないはずだが、ちゃんと守らない奴が中継する経路のどこかに居るとデータの保全は保証されない。エスケープしておくことに越したことはない。

　この実装は、思ったより簡単に出来た。1バイト送受信の一番フロントにロジックを入れてやれば良い。あとは変更する必要がない。エスケープする文字は、ヘッダーの0x7Eだけでなく、エスケープ文字そのもの0x7Dと、シリアルのフロー制御文字XON(0x11)、XOFF（0x13)まで必要とマニュアルにはある。いまどき、XON、XOFFでフロー制御しているところもなさそうだが、言われるまま全部エスケープする。勢いに乗って、APIモードも動作中に切り替えられるようにする。

　ソフトが出来たのでテストである。まずXbeeの双方をX-CTUでAPIのEscape付きモードに変更する。ビクビクしてX-CTUを動かしたのだが、2ヶともファーム復活をさせられることもなく、writeだけで問題なくEscapeモードになった。だいぶX-CTUの動かし方にも慣れてきたようだ。Escapeモードでも問題なく動いた。よーし、これで一歩、完成に近づいた。すべてキャラクターベースのインターフェース（CUI）だが、あとは64ビットアドレスの入力だ。

汎用モニターひととおり完成(3/28/2011)
　EEPROMにリモートの64ビットアドレスを収容し、プログラムをコンパイルし直さないで、コマンドからの入力でアドレスを設定するルーチンがやっとのことで動いた。8バイトの16進アドレスをキーボードから入力させるロジックは結構面倒である。

　ATOIなどの標準ライブラリには、16進数のキャラクターをバイナリに変換する関数もあるようだが、使い方が難しく、今愛用させて貰っているChaNさんのxatoiにはその機能がない（あることはあるのだが、0xというプリフィックスをつける必要がある）。全部自作するしかない。

　フラッシュに余裕があるとはいえ（まだ5KB少々）、同じようなロジックの繰り返しは避けたい。8バイトをすべて入れさせるのは、キャラクターベースでは間違いやすいので、4バイトづつ分けて2回に入力をさせるようにしたため、これをまとめるのに苦労した。

　Windowsのような画面からの入力に慣れていると、多バイトの入力は気にならないが、CUIでは難しい。昔を思い出しながら、せっせとコーディングする。繰り返される入力の部分は関数に切り出した。このあたりは力仕事に近い。

夜半、ついに完成した。出来たソフトを動かして、一人で満足する。デバッグのための送受信のテストメッセージが延々と出てくるが、むしろこれは残しておいた方が便利かもしれない。現在のAPIフレームモニターの機能は以下の通りである。

・コーディネーター及び、リモートのXbeeにAPIモードで任意のコマンドが送れる。
リターン　キーでコマンドを確定すると、それぞれ、所定のフォーマットで結果が
戻されてくる。

tABnnn　コーディネーター（親機）にABというコマンドを送る。nnnは設定するときの
             パラメーター。コマンドABとnnnの間にブランクを入れない。nnnは、
             8文字(4バイト）までの16進数。右詰めで左の0は省略可能。

rABnnn　リモートにあるエンドディバイス(子機）へのATコマンド。仕様は上と同じ。

・リモートにはメッセージが送れる。

;ABCDEF    リモートディバイスに;以下のテキストを送る（1パケット40文字まで）。
                  リターンキーがテキスト終了を示す文字なので、リターンキー(0x0D)は
                  送れない。

・いくつかの設定用コマンド

d0 d1 Xbeeからの受信APIフレームを、16進表示だけの文字列(d0)にするか、
         一定のレスポンス(5種類）については、アドレスやパラメーターを
         フォーマットして出力する(d1)かを決める。デフォルトはd1。

a1 a2  APIモードにおける、通常APIモード(a1)か、エスケープ付き(a2)かを
　　　　　選択する。デフォルトはa2(エスケープ付き）。
　　　　　ATモードにはならない（そもそも意味がない）。　

ad    エンドディバイス(子機)の64ビットアドレスを設定する。adだけ入れて
　　　リターンキーを押すと、現在設定中のアドレスが表示されるので、それを
　　　参考に1バイトづつブランクを空けて入力する。

　　　00は0でも良く、上位0は省略できる。上位(Higher)の4バイトと、下位(lower)の
　　　4バイトを分けて入力する。リターンキーだけのときは変更しない。

       最後に64ビットすべてが表示され確認を求められる。Yかyを入れると
　　　EEPROMに書かれ、以後はそのアドレスが使われる。

　　　プログラムの最初にはこの設定が必ず必要である（EEPROMには
　　　ダミーアドレスが入っている）。なおフューズビットはEEPROMを保存する
　　　ようにしておくと便利である。　

h       以上のコマンドの簡単な紹介。

　Xbeeからの受信メッセージはdコマンドに従って、画面に表示される。d1を選んでもコマンドレスポンスなど良く出てくるメッセージ以外は、すべて16進コードで表示される。

　なお、このプログラムは、ChaNさんのシリアルISPライターがないとUARTが動作しない。同じ仕様の市販のライターもあるようなので、とりあえずはこのままにすることにした。ソースコードを公開するので、普通のUARTに換えるときは、soft_uart.cを変更してほしい。

　ただ、このISP-UARTはChaNさんのオリジナルUARTソースを大幅に変更して、受信待ちをせず、データをバッファーに蓄える改良が施され、ピンチェンジ割り込みで動くようになっているので、簡単には移植できないかもしれない。そのときはブログにコメントを頂ければ、改良版を作りたいと思っている。

ここに例によってAVRStudioのフォルダーを固めたソース一式を置きます。無印Xbeeも動きますが、色々なところでAPIフレームのフォーマットが異なるので注意が必要です。

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

Xbee ZB APIモードにはまる

　モーター制御のついでに、以前試したことのあるXbeeを使って簡単なラジコンを作ろうとXbeeを新しく買ってきたのは良かったが、ラジコンそっちのけで、Xbeeにはまってしまった。

　そもそもは、Xbeeの遠方の子機にコマンドを送る機能（リモートATコマンド）を使って子機のデジタルI/Oを動かしそれでラジコンカーのモーター制御をするつもりだった。Xbeeはシリアルの無線通信の替わりに使うだけなら至極簡単で楽なのだが、少しネットワークっぽくやろうとか、センサー機能をAPIモードで使ってやろうなどと考えると、途端にとんでもなく難しくなる。このAPIモードというのが曲者（くせもの）である。今度も気楽に始めたが、泥沼に足をとられて収拾がつかなくなってしまった。

大きな勘違いをしていた(3/10/2011)
　秋月から買ってきた新しいXbee（ZB)2つをあやうくお釈迦にしてしまうところを、何とかDigi　Internationalさんの支援で元へ戻し、不勉強を反省してXbeeをあらためてウェブで真剣に調べ始めた。2年前に較べるとウェブ上にもたくさんXbeeの話題が載っている。読んでいくうち自分が大きな勘違いをしていたことに気がつく。

　最初に買った無印のXbeeはいわゆるOEM仕様といわれるハードウエア規格だけのIEEE802.15.4仕様というチップで、Zigbee規格というのは、ライセンスを支払ってこの上に載せるソフトウエアプロダクトだと思っていた。ところが、今度買ってきたXbeeは、そのZigbee規格を既にファームで持っているシリーズ2だという（このあたりは、次のブログが詳しい。http://todotani.cocolog-nifty.com/blog/2010/12/xbee-f604.html　PS3とLinux、電子工作も）

　これまでの理解とは大分違う。今度買ってきたシリーズ2のZBはあのZigBeeそのものなのだ。無印のXbeeは、ソフトで、Zigbeeになれるが（正確にはZnet2.5という独自規格らしい）、シリーズ2のXbee　ZBは始めからそうなのだ。

　道理で、XbeeユーティリティのX-CTUで、MyAddressが設定できないわけだ。そもそもZBではコーディネーターと、ルーターと、エンドディバイスのファームが違うので、動作中に役割を変えることが出来ない。しかもATモード（透過モード）とAPIモードとでは、ファームウエアからして違うので、ATコマンドで簡単にAPIモードになれない。アドレスも自由に設定できないし、この前設定した16ビットアドレスも存在しない。これは前（無印Xbee）のチップと、同じような形、同一無線規格で、同じユーティリティ(X-CTU)を使っていても全く違うディバイスのようだ。

　つまりシリーズ2のZBは、これまでソフトで実現していたネットワーク的な機能、自律的（ソフトの助けなしに）にネットワークを作り、勝手に省電力する機能がファームウエアに実装されている。要するに賢くなっているのだ。

　しかし、こちらとしてはあまり嬉しくない事態である。単純なラジコンにするには返って面倒になった。でも、調べているうち、親機をCoordinator、子機をEnd deviceにし、送信相手アドレス(64ビットで始めから決まっている）を決めうちしてしまえば、前と同じようなユニキャストの1対1の関係で通信が出来そうだ。ほっと胸をなでおろす。

もうひとつの変換基板(3/12/2011)
　先に2ミリピッチの変換基板に汎用基板をくっつけてXbee基板を作ったが、別のやり方でもうひとつ作った。素直に市販のピッチ変換基板を使えばよいものを、私と同じようなことを考える人は他にもいるとみえて、秋月で売っている2ミリ汎用基板を利用して、Xbeeの変換基板を作った人がいた。（ ここはXbeeそのものについても詳しい)

　以前、Xbeeのような2ミリピッチのパーツを2.54ミリピッチの汎用基板にそのまま固定することを考えたことがある。汎用基板のピッチと2ミリのピン配列をつらつら眺めていて、10ピンを固定するのは、1ミリのドリル穴を余分に2つ開けるだけで、他はすべて穴を少し広げるだけで固定できそうなことに気づいた（汎用ピッチの4つめは、10.16ミリ、2ミリピッチの5つめ10ミリと0.16ミリずれているだけ）。　実際に図面まで引いて、工作を始める直前、もう一方のXbeeのピン列の間隔が、22ミリと、mil規格と大きくずれることに気がつき、作るのを諦めた。

　今度の方法はこれのバリエーションだ。2.54ミリピッチのL型ヘッダーピンをうまく利用して2ミリピッチ基板にハンダ付けしている。ただ、もう少し綺麗に出来るような気がしてきた。ウェブの工作法では隣接したランドにまずL型ヘッダーピンを固定してから所定のピンに配線しているが、空いたランドは全く利用せず、L型ヘッダーピンをペンチで細かく曲げて直接2ミリピッチに合せれば、もっとすっきり出来そうだ。早速試してみることにする。

　意外にうまくいった。小さなブレッドボードにとりつけてみる。半田付けの部分は少ないが、10箇所で固定されたハンダ付けというものは意外に丈夫で、少し動かしたくらいではびくともしない。これをミニブレッドボードに差して子機とし、一方の変換基板は大き目のブレッドボードに使い、Xbee　ZBのテスト基盤は整った。これでループバックテストが開始できる。

ループバック成功(3/13/2011)
　ブロードキャストでのループバックテストはとても遅いと聞いていたので、決めうちアドレスの設定をX-CTUでした。前に書いたように、X-CTUで送り先のXbeeのアドレス64ビットをDH(Destination High Address)とDL(Destination Low Address)で設定する。

　ファームウエアタイプは、一方をCoordinator AT、もう一方をEnd device AT（テストなのでATコマンドモードのまま）に設定すれば、一対一になる。

　ループバックテストの開始。よーし、アドレスを指定しないブロードキャストでテストしたときは飛び飛びだった受信が完全にきれいに返ってくる。2階の踊り場まで持っていく。ふむ、急にエラーが起きる。

　今度はエラーが出ると立て続けにエラーになり、また突然復帰する。無印（IEEE802.15.2)のときのようなポチポチエラーが出るのと大分様子が違う。スペック上は、無印Xbeeより、XbeeZBの方が少し到達範囲が広いはずなのだが（30m->40m）、送信範囲は前と同じくらいなようだ。

　とりあえずは、これでループバックもOKとなった。透過（ATコマンド）モードでは、前の状態と同じになった。いよいよこれからAPIフレームの送信である。これまでAPIフレームの受信はセンサーデータの受信で経験済みだが、送信、特にコマンド送出は始めてである。ブレッドボードを片付けて、マイコンのスペースを作る。

APIフレームの送信モニターの制作(3/18/2011)
　やりたいことは、APIモード上のリモートATコマンドの送出だけなのだが、丁度良い機会なので、任意のローカルATコマンドや、メッセージなども送れるXbeeのAPIモニターみたいなものを作ろうと思っている。ウェブ上にはArduinoシールドの商用製品があるようだが、自作例が見当たらない。これを完成させてソースでも公開すれば喜ばれるかもしれない。

　ターゲットは、AVR　Mega168を選ぶ。このまえのXbeeロガーはSDカードアクセスがあったのでMega128にしたが、今度はこれほどのチップは要らないだろう。それにMega128は旧製品だ（最近はMega1284が後継らしい。秋月でも売っている）。2年前に作ったXbee電力ロガーのソースを引っ張り出して思い出しながらソースを作っていく。

　開発の途中で思い出した。この前はAPIフレームを最初のうち構造体で定義して開発したがどうしてもうまく動かず、あきらめて配列の番号でデータをアクセスした経緯がある。受信データフレームは一種類なので、これでも余り問題はなかったが、今度の送信フレームはローカルとリモートで違うし、コマンド送出と、データ送出でも違う。構造体を使わないと複雑になって後が大変だ。

　この前の構造体での不具合はその後原因がわかっている。APIフレームがアラインメントを無視している（奇数バイトオフセットに2バイトバイナリのデータが定義されているなど）ので、まともに構造体を定義すると、実際のメモリ上の位置と構造体の定義がずれてしまうためである。

　所長はアセンブラー育ちなのでDSECT（ダミーセクション、物差しのようなもの）を使ったアセンブラーの構造体的プログラミングはいやというほどやった（というより、OSはそれの固まり）が、Cの構造体には、余り慣れていない。しかし少し規模の大きいソフトを開発する時は、この考え方は必須である。是非Cでもマスターしておきたい。しかも今度は複数のフォーマットを持つ構造体だ。腕が鳴る。

　前回の失敗を踏まえて構造体の中の変数はすべて1バイト変数にして定義する。リモートとローカルで大きさの違うところは、久しぶりに教則本を勉強して、共用体（union)をstructにいれて定義する。

　さらに、このフレームはチェックサムが必要なので、あらかじめ大きめの配列を定義しておいて、構造体のポインターをこの配列アドレスに指定しようとした。これでこの構造体は、配列番号でもアクセスが出来るはずだ。しかしこれがどうしてもうまくいかない。2重に定義しているとコンパイラーに怒られる。アセンブラー育ちには、このCのポインターのキャストが今ひとつ理解できていない。

　結局、ウェブを調べまわった結果、staticでは、2重に定義することは不可能とわかる。考えてみたら確かに同じ実体メモリに重複した変数を定義されることをコンパイラーが許すわけがない。mallocを使っても良いがそこまでやることもない。強引にunionで、同じstructの上に配列を定義すれば良いが、これも大げさすぎる。というのでポインターの加減算でやることにした。

　これが、最後までたたった。所定のデータが出来てから計算するチェックサムがどうしても正しく入らない。考えあぐねたあげく、アドレスから中味まですべての変数をprintfして始めて原因がわかった。

uint8_t *adr;   //1バイトづつ動かすポインターの定義
APID    api_d;  //構造体の定義

adr = &api_d + 3;    //3バイト先に進んだつもりだが

これは、構造体api_d の長さ分を3つ加えたことになる！！　&が付くので、構造体ではなく、単なるアドレスデータになると考えるのが普通だが、Cでは、&がついても構造体の性格がなくならない。正しくは、

adr = (uint8_t *) &api_d;
adr = adr + 3;

でないといけないと書いて、このあと気がついた。これはC言語の仕様で、&演算子と＋の演算子の優先順位の勘違いに過ぎないだけのことだ。＋の方が、&より優先順位が高いので、

adr = &api_d + 3;　は、adr = &(api_d + 3);　になるのだ（前も同じことをやったか）。

さっきのように2行にしなくても

adr = (uint8_t *) &(api_d) + 3;

で、警告も出ずに何事もなく動いた。いくらブランクで空けていても思いはコンパイラーには通じない。やれやれC言語も難しいものだ。

気難しいX－CTUをあやしてAPIモードの設定(3/18/2011)　
　ソフトが出来た。次はXbeeをATモード（透過モード）からAPIモードにする手順だ。ところが、X-CTUが気難しくて、簡単にAPIモードのファームが書けない。色々なところでエラーが出て先に進まない。ウェブにも、「根性で」とか「活入れしながら」という言葉が出るほど、動作が不安定である。当研究所のPCのOSは今となっては古いXPだが一番安定していると考えられるOSでもこんな状況である。

　リセットボタンを長めに何回か押すとうまくいったり、そうかと思うと画面上のエラーアイテムをクリックするだけでX-CTUが異常終了したりする。下手をするとOSを再起動しないとX-CTUも動かなくなる。しかも、異常終了したときに設定していたXbeeは大抵動かなくなるので、例のファーム復活の手順を繰り返す羽目におちいる。

　根気良く、何度もXbeeのファームの復活手順をやらされながら、だましだましX-CTUを動かして、何とか2枚のXbeeの設定を終えた。余り自信はないが、ポイントらしいものが見つかったので、以下にまとめておく。

(0)成功を祈って斎戒沐浴する（冗談である）。

(1)設定の終わったXbeeを違うファームウエアにそのまま書き直すのは止めたほうが良い。大抵エラーが起きて先に進めなくなる。なるべくファームウエア復活の手順から始める。このとき、DTR、RTS、CTSはUARTと接続し、垂れ流しのUARTにはしない（無印はそれでも動くがZBは駄目）

(2)復活のときはModem　Configurationタブ で、Always update firmwareのチェックを必ず入れること。しかし、復活手順後は必ずはずしておくこと（ここがポイントか）

(3)また、その前のPC Settingsタブで、Enable APIのチェックも外しておくことを忘れずに。なおPCチェックの通信テストで、XbeeZBがXbee24-Bと出るのはバグである。

(4)さらに回線速度は、9600bpsが一番エラーが少ない、というよりこのあとの手順はこの速度でないとエラーが起きる確率が格段に高い。

(5)Modemの欄に「XB24-ZB」（秋月で買ったXBeeなら）を選び、Function SetからXXXXXX　APIなどを選んでWriteを押す。このときXbeeの電源は入れてはいけない。

(6)リセットしろという画面が出るが無視して、Xbeeの電源を入れる。するとリセット要求画面は自然に消えて、勝手にファームを書き込み始める。

(7)No Errorで各設定が出てきたら、必ず、Always　update firmwareのチェックをはずし、必要なパラメーターを設定し、Writeボタンを押して書き込む。リセットしろという画面が何度か出るので、今度はリセットボタンを押して先に進む。

(8)これでNo Errorで帰って来て、パラメータが表示されたら、おめでとう。Xbeeは成功裡に設定された。そうでないときは難儀である。エラーを修正してwriteし直しても、うまく行くときもあるが、改善されないことが多い。また、エラーが出ていても読んでみると直っているときもある。最初の(2)に戻ってファームを書き直したほうが精神衛生上安心である。

(9)一旦、XbeeがAPIモードになったら、PCセッティングタブで、APIをenableにしないとエラーになる。Modem　Configurationタブでのパラメーター読み書きもこれが必要（ただし、ファーム復活の時は入れてはならない。このあたりも注意）。

(10)パラメーターの書き込み(Write)の前に、一度リセットしてから書き込むとエラーが少ない。いずれにしても、PC　SettingタブのCOMテストも何回か押して突然動いたり、エラーが出ても繰り返すとOKになるときがあるので、それこそ「根気」と「根性」を要求される。

なんとかAPIフレームでコマンドが送れたが(3/22/2011)
　両方のXbeeをAPIモードのCoordinatorとEnd deviceにして、出来上がったソースでテストを開始する。ISPケーブルを使ったChaNさんのUARTはISPアダプターを有効にしたまま（書き込みモード）でないと動かないことを忘れていて、最初あせった（気持ち良く忘れていた）が、無事、オープニングメッセージが出た。おおお、Xbeeからデータが送られてきたぞ。うーむ、ヘルスチェックのフレームのようだ。受信側はOKなようだ。いよいよコマンドから送信のテストだ。

　まず、ローカルコマンドを打つ。よーし、レスポンスが返ってきた。ふむふむ、ちゃんとしたデータが返っている。良いぞ。まだ16進コードの羅列にすぎないが、間違いなくさっき送ったATコマンドのレスポンスだ。

　次はいよいよ問題のリモートコマンドだ。簡単なATコマンドを送る。返事がない。やった、暫くしてコマンドが返ってきた。残念。「送ったが受け取っていない」という親側のメッセージだった。

　アソシエーションLEDの点滅に変化があるので、親から子へコマンドを送っていることは間違いなさそうだが、まだデータフォーマットなどがおかしいのかもしれない。ただ、APIモードでのループバックテストが動かないのが気になっている。

　このあと、X-CTUでリモートコンフィギュレーションが可能になった。Xbeeのハードやファームは問題なく動いているようだ。ローカルのATコマンドの方は、APIモードで殆ど確実に送れるようになった。しかし、リモートコマンドはがんとして送信失敗のエラーコードで先に進まない。メッセージ送信も出来ない。先が長そうなので、とりあえずはこのあたりでブログに報告することにする。

メカトロニクスの第一歩、モーター制御に踏み出す

　東北地方に大地震と大津波が襲い、大勢の方が亡くなられた。東京も震度5で、経験したことのない長い揺れに驚いたが、テレビの画面で町を次々に飲み込んでいく黒い津波を見て背筋が凍えた。自然の力の前にいかに人間が無力か思い知らされる。亡くなられた方々のご冥福を心から祈りたい。

　それはそうと、このブログの更新が20日以上滞っている。2月末から3月にかけてのこの時期は、例年、行事や仕事が集中し、電子工作どころではないのだが、このブログは自分の備忘録を兼ねている。あまり日を空けてしまうと、あとから何をやっていたのかわからなくなってしまう。たいしたこともやっていないが、とにかく作業記録だけは残しておくことにする。

次のプロジェクトはモーター制御と決める(2/16/2011)
　FPGAのフォトフレームプロジェクトは一段落した。　I2CフラッシュROMを使ったレジューム機能など、部品を買ったまま、残している課題はまだ山ほどあるが、ここらで少し一休みしよう。次のプロジェクトは、いよいよ年初の挨拶でも触れたモーター制御をやってみたい。これまで電子工作と言われるものは手当たり次第、幅広くやってきたが、モーター制御だけは最後まで残っている。

　前から興味は持っていて、モーター制御特集の雑誌を買ったりしていたのだが、この世界も奥が深い。そう簡単に手をつけられるところではない。というのも、どうせやるならモーター制御だけではなく、自動制御、ロボットの世界まで行きたいからである。いずれにしろ大電流の制御や、距離センサーなどの技術は、慣れ親しんだソフト開発の世界とは全く違う、所長にとっては一大フロンティアである。

このフロンティアの奥の院には、電子工作の最高峰、メカトロニクス、ロボットが聳えている。これまでFPGAやBealeBoardでは、進めば進むほど、パソコンやiPhoneの世界に近づき、苦心の末、出来上がったものを見せても、「で、それがどうしたの？」と聞かれる危険性を常にはらんでいるが、ここはまだ手付かずの世界が残っている。夢は広がる。

　しかし、現実はそう甘くない。ときどき、これらロボット界の現状をウェブで垣間見るが、見る度に想像を絶する発展がアマチュアの世界でも繰り広げられ、新たにやってみようかという意欲を失わせるのに十分だ。

　信じられない速度でマイクロマウスが迷路の中を駆け巡り、相撲ロボットは、圧倒的な迫力で、相手を土俵の外へはじき飛ばす。ロボットが色の違うボールを器用につかんで、色別に整理し、GPSを搭載して実際の町の中を障害物を避けながら通行する。ここも、素人が気楽に遊べるところが急速に失われつつある。

　まあ、上を見ていたらきりがない。そこまで行かなくても面白いことはたくさんある。しかも、実用をモットーとするがた老AVR研究所としては、実用的な目的は既に考えてある。最初の応用例は、ウェブカメラのアングル制御である。BeagleBoardあたりにウェブカメラを載せ、遠隔地からカメラを自由に操作できるようにすれば、ウェブカメラの能力を飛躍的に広げることが出来る。カメラのアングル、ズームなどがサーボモーターによって制御出来れば、とりあえずの実用性は十分だ。

　次のアプリケーションは、お掃除ロボットだ。小型掃除機を改良し、床の障害物を判別して、それを避けながら定期的に歩き回り、電池が減れば、自分でコンセントにつながりに行って充電する。すでに市販品もあるようだが、これが完成できれば、家族の中でも大威張りだ。夢（妄想）は大きい方が楽しい。

行き当たりばったりに部品を買ってくる(2/18/2011)
　夢はどこまでも膨らむが、ただ考えているだけでは何も始まらない。千里の道も一歩からという。仕事の帰り、久しぶりに秋葉原に寄り、ウェブの情報を頼りに、千石3号館で、タミヤのツインモーターギヤ（ライントレーサー用 ￥710）とタイヤ(￥310)、秋月では、評判の良い在庫限りのFETアレイ（MP4401 ￥200)、ステップモーター（￥350)などを買い込んだ。何でも良いから、とりあえずは何か動くものを作ろうという方針である。

　帰ってきてすぐ間違ったものを買ったことに気づく。買って来たFETアレイMP4401は、ステップモーター用のNMOS-FETだけのアレイで、一般のモーター用のドライバーではない。このままではタミヤのモーターは制御できない。モーターの正逆転をするにはHブリッジといってトランジスタで言えば、コンプリメンタリなFETアレイが必要なのだ。

　それに、初心者がいきなりFETドライバーで動かすのは、どうもやめたほうが良さそうだ。FETのON抵抗は、0.1オーム台で、下手な制御をすると、一瞬に大電流が流れ機器を壊してしまう。やはり最初は、バイポーラの定番のトランジスタのモータードライバーを使うのが無難なようだ。

　始めは何故、みんな電圧降下の大きい、こんな非効率なバイポーラのモータードライバーを使うのか理解できなかったが、調べるうちに理由がわかった。こちらの方が少々無理な制御をしても簡単には壊れないから安心なのだ。それに、タミヤのツインギヤセットについているモーターの定格の推奨は、1.5Vなので、3.7Vのリチウムバッテリーを使うのなら電圧降下の具合がちょうど良い。なにも損失の少ないFETドライバーを考える必要がない。

　次の日、家族が日本橋に行きたいと言うので、また秋葉原に寄る。秋月で、定番のモータードライバーTA7291P(2つ入り￥300)と、過電流防止のポリスイッチ（1.5A近辺で3種ほど一ヶ￥30）、千石でHブリッジ用のFETモジュールMP4212（これも在庫限りらしいので今のうち ￥340）を仕入れた。

　ライントレーサーなら、モーターを逆転させる必要ないが、まだアプリケーションを何にするか決めていない。とりあえずは気の付いた部品は揃えて置こうというぐらいの気持ちだ。当初は、ARM基板がついたライントレーサーキットを買おう（￥6000以上する）と思っていたくらいだから、少々余剰部品を沢山買ってもおつりがくる。

　回路を真剣に検討し始める。良く調べてみれば、余り難しく考える必要はなかった。Hブリッジとか言っているが、要するに2極双投のスイッチをFETか、トランジスタが替わりをしているだけと考えれば理解が早い。モーターという誘導負荷を動かすので、逆起電電圧とか、両方の素子が導通しないためのデッドタイムとかに気をつければ、そうびびることはない。でも最初はバイポーラで始めることにする（臆病である）。

FETは、やっぱり1.5Vでは動かない(2/20/2011)
　まずは、ブレッドボードで買ってきたパーツの動作確認テストをする。最初は、間違えて5ヶも買ってしまったMP4401である。生産終了なのに人気が高いと言うので、ついわけもわからず大目に買ってしまっている。一ヶ￥200で、モジュールひとつにN-MOSのパワーFETが4ヶも入っている(ステップモーターも買ってあるので無駄にはなるまい)。オペアンプのように最小動作電圧はデータシートにないが、想定している3V近辺でこのFETは動くのだろうか。

　だめもとで、1.5Vの乾電池ひとつでFETをドライブしてみる。さすがに動く気配はない。3VのDCアダプターで実験する。おおー、動いた動いた。3V近く（2.7V)かかっているので、やたらモーターの勢いが良い。ライントレーサーにするには苦労しそうな速さだ。

　結局、安全のため買ってあったバイポーラトランジスタのモータードライバーTA7291Pが思った通りちょうど良い早さになった。（1.4V。1.6Vも電圧降下があることになる非能率）。電池を積んで動かすことを考えれば、慣れてきた時はFETに換えるべきだろう。

　TA7291Pは、単なるトランジスタアレイではなく、ロジックが内蔵されており、。アナログ電圧(Vref)でモーターの出力電圧を変えられる。半固定抵抗でやってみる。ブレッドボードで組んで、モーターを動かしてみた。電源は車に積めるよう、プレーヤーに使った3.7Vのリチウムバッテリーである。

　うむ、面白い。ちゃんと微速から全速に無段階で変えられる。ここにPWMでチョッパーした出力をLPFでならせばアクセルが出来るはずだ。石はとりあえず、2313で十分だろう。ライントレーサーの前に、Xbeeか何かでラジコンのテストもしてみたくなってきた。秋月でもXbeeを売り出したことだし。

自走車の制作(2/22/2011)

　車（自走車）のシャーシーを適当な汎用基板で作り出したら止まらなくなった。あちこちのウェブを参考に、それらしい形を作る。モーター制御の部分は、このシャーシーには作りこまず、FETとバイポーラの2つにわけてテストできるようにモーター制御のサブ基板を作る。

　これを組み立ててみたらなんとなく自動車らしくなり昔を思い出してはまる。ただ工作の進捗が遅い。これは、この車体をラジコンカーにするのか、ライントレーサーにするのか、それともマイクロマウスのような自走ロボットにするのか方針が決まっていないからだ。

　本来は、何を作るか最初に決めて、まず設計図を引き、次に部品を揃え、それから作らないと、良いものは出来ないのだが、こういう気ままな作り方も、「ゆるくて」面白い。まあ、モーター制御の最初の練習車だ。気楽に考えよう。

　モーター2つで自由に方向を変えるため、もう一つの車輪は、カートのキャスターみたいのもので良いと思って調べてみたら、おあつらえのように、同じタミヤから「ボールキャスター」というのが売られていた（最初は自作しようと意気込んでいた）。ウェブを良く見たら、この部品を使っているサイトはやたらに多いことに気づいた。

　このキャスターは￥400しない。しかしこれだけを買いに都心に出かけるのも何だかなあと思っていたら、最近のアマゾンは、自社直接の注文では、どんな安い商品でも送料を無料にしているのを発見した。早速、ネットで注文した。2日で届いた。

　ライントレーサーにするか、ラジコン車にするか、まだ方針が決まらない。マイクロマウスは、その場で回転（両側の車輪を逆にまわす）できるように、大輪の車輪にステップモーターで駆動するのが定番のようで、この形のマイクロマウスはあきらめる。

　とりあえずは、ライントレーサーにしようと、フォトセンサーのひとつ、フォトリフレクター(TPR-105F ￥50)を久しぶりに動かしてみた。このセンサーはライントレーサーを考えていて、たまたま、これを脈拍計にしようとしているサイトを見つけ、面白そうなので衝動買いしたセンサーである。実験をした後ブレッドボードにささったままになっている。

　この実験をブログに載せたら、意外なことにいくつかのサイトで紹介され、ブログのアクセス急増に寄与したことがあるが、脈拍計としては、指の置く位置が微妙で、思うように脈拍がとれず、ちょっとテストしたままそれきりになっている。

　本来のライントレーサーのテストのため、紙にマジックで黒線を入れリフレクターの上をずらせて変化を見る。しかし、どういうわけか思ったように動かない。かなり紙を密着させないと白黒の判定が明確に出ない。ウェブの記事を見ているとライントレーサーは、このセンサーでなく、秋月でのもうひとつの種類、LBR127HLD(TPR-105より少し大きく、フォトTRとLEDが外せる ￥60）を使っていることが多い。

　うーむ、ライントレーサーも今のところ手持ちの部品では実験が進められない（折角あれから3つも買ったのに）。というと残るは、無線操縦くらいか。そういえば、このあいだhamayanさんのブログで、受信側をXbeeモジュールだけで動かすリモコンの実験が載っていた。これはまさしく当所長があたためてきたアイデアである。

　久しぶりに、Xbeeをもう一度調べ始めた。当ブログの最近のアクセスのトップはXbee関連である。何かの縁を感じる。Xbeeは、UARTの通信機能やネットワーク機能以外に、チップにデジタルI/Oピンを8ヶ内蔵している。しかし、これまでこれをラジコンに使っている例はない。みんな慣れたUARTを通してコマンド受信し、受信側にマイコンを置いてモーターを制御している。XbeeモジュールのI/Oピンだけでモーターを制御できればマイコンなしで動かせる。これは少し面白くなってきた。

APIモードのXbeeだけでラジコンにする？(2/27/2011)
　確定申告や、恒例の年度末の全国大会の準備など、そろそろ行事が集中してきて、電子工作に時間をかけられない時期がきた。それでも、暇を見ては、自走車（今はこう呼ぶしかない）の工作を続けている。

　とりあえずはバイポーラのモータードライバーTA7291Pで、自走するところまで作ってみた。速度制御は、このドライバーはアナログでできるが、正逆進の切り替えは、2本の制御線の操作がそれぞれ必要である。とりあえず組み立て、少し長いコードをつけて動作テストする。小さなブレッドボードとリチウム電池フォルダー（Xbeeワイヤレス電力センサー子機から流用）を載せた車がビービー動く。下らないけれど楽しい。

　勢いに乗って、モーター2つから出てくる4本の制御線を統合して、前進と後進が一挙動で出来るように、トランジスター1ヶをインバーターにして、1本のHLで動くようにする。ブレッドボードで、回路を組む。オシロを使って、2本の制御線が同時にプラスにならないよう、100pFのコンデンサーをかまして遅延させる。

　よし、立ち上がりは、遅延回路のおかげでトランジスタがONになるまで持ちこたえ、OFFのときは、トランジスタの立ち上がりの遅さが効いて、制御線が両方プラスになることが避けられる。モーターは思ったように、正転と逆転を繰り返す。こんな簡単な回路だけれど、思うように動いた時の快感は、複雑なものを完成させたときと同じだ。

　Xbeeのほうである。ラジコンにすると言っても、XbeeのPWMは、出力だけで入力は出来ない。細かい速度調整などには、PWM制御できるマイコンが必要だが、正進、逆進、停止、左右転回程度のラジコン操作ならXbeeのデジタルピンだけで動くはずだ。

　hamayanさんのブログをもういちど仔細に調べてみた。Arduinoを使って、APIフレームを飛ばして、子機側のI/Oを操作している。APIフレームでリモートATコマンドを出せば、子機側のXbeeのI/Oを直接動かせるので、ラジコンが出来る理屈だ。ただ、PWMのような早い切り替えは出来ないだろう。

買ってきたXbeeが二つとも動かなくなる(3/6/2011)
　秋月でもXbeeを売り出している。シリーズ2のXbee ZBが￥2400、Xbee ZB Proが￥3800とやはりどこよりも安い。ちょうど良い機会だ。仕事の出張が終わって一段落したので、帰りにラジコン用に2つ買ってきた。

　ついでに2ミリメッシュの汎用基板を買って、Xbee基板を作り始める。Xbee用の変換基板はいくつかのショップで売っているが、この汎用基板はたったの￥80。変換基板は安いのでも￥315(ストロベリーリナックス）、￥500（スイッチサイエンス）する。根がケチというのか、へそ曲がりというのか、素直に変換基板を買ってくれば良いものを、何か違うことをやりたがる。2ミリピッチの基板を2つに切り、汎用ピッチのピンヘッダーをつけた基板の小片をネジ止めして自前のブレッドボード用の変換基板を作る。簡単に出来た。

　例によって、XbeeのユーティリティX-CTUでパラメーターの設定に入った。あれえ、Xbee ZBは、前の無印Xbeeと違って、MY ADDRESSが設定できない。どうしてだろう。と、色々いじっているうち、X-CTUがおかしくなってファームアップデートが終わらなくなった。仕方なく強制終了させたところ、Xbeeそのものが動かなくなってしまった。例の、ファームウエアリカバリーでも駄目。何度やっても元へ戻らない。

　そのうち、動いていたもうひとつのXbeeチップも、X-CTUの異常終了（こいつときどきこける）とともに同じような状態になる。買って間もないチップ2つが全部動かなくなった。大事件である。Xbeeラジコンどころではない。

DigiからのメールでXbee生き返る(3/9/2011)
　思い余って、販売元の日本のDigi Internationalにメールする。余り期待していなかったが、一日もしないうちに返事が来た。しかし、教えてくれたのは、前にやって動かなかった手順である。さらにしつこく情報提供を要請する。無視されると思ったが誠実に回答が来た。好感が持てる。

　なになに、DTRとRTSをつなげとある。DTRはつないであったが、RTSはCTSとジャンパーしてさぼっている。今までのXbeeはこれでも、問題なくリカバリーできていた。しかしhamayanさんのブログでも、ファームの書き込みは、DTRなどの制御線が必要とある。

　そういえば、RTSはUARTのところでジャンパーさせてXbeeには届いていない。XbeeがRTSを聞いているのならつなぐ必要がある。制御線を追加する。

　念のため、CTSとRTSのジャンパーもはずしてCTSをXbeeから送るようにする。あきるほどやったリカバリー手順を、また最初からやりなおし。おおお、何か違うぞ。オシロに受信のパルスが流れる。やった、やった。メッセージがOKになった。2つとも生きかえった。

　いやあ、人の言うことは聞くものだ。こんなにきめ細かく制御していたとは。Xbeeシリーズ2はやはり、大分、無印Xbeeとは様子が違う。

　何とか、Xbee2つを救ったところで一段落し、このあたりでブログに報告することにする。実は、このあと思ってもいない展開になったのだが、それは次回と言うことで。