今度はArduinoでジョイスティックの値を読んでみました。
こんな感じでA0とA1にジョイスティックの出力を接続します。
プログラミングはさすがに超簡単です。
これだけでジョイスティックの値を読んで、シリアルコンソールに出力し、その値に応じてLEDを点滅させてくれました。
PIC10F222でジョイスティックの値を読む
PIC10F222でA/D変換した値を9600bpsで送信できるようになったので、抵抗式のアナログジョイスティックを接続してみました。
接続したところはこんな感じです。
左上に小さな変換基板が２つありますが、その下の方に10F222が載っています。上の方の変換基板には10F200が載っていますがどこにもつながっていません。そして、右半分にAkidukino（秋月Arduino）がありますが、電源供給とUSB-UART変換の部分しか使っていません。右下のTXDのジャンパのところに左上のPIC10F222の4pin（GP2）からのUART出力がつながっていて、右上のAE-UM232Rを通してPCに接続されています。
アナログジョイスティック部分の拡大です。
これでアナログジョイスティックをぐりぐり動かすと、それに応じてUARTに送信される値が変化します。中央部分は摩擦によるヒステリシスのようなものがあるようで、実際に使う場合にはそれをどうキャンセルして違和感がないように見せるかが問われそうです。
今回はブレッドボードにバラで搭載しましたが、PIC10F222は安価ですのでヒステリシスをごまかしたりした上で電源、GND、シリアル出力の３線で使えるアナログジョイスティックモジュール、なんてものも作れそうです。
ちなみにArduinoがあるなら、直接そのアナログ入力で受ければいいじゃないか、という声が聞こえてきそうですが、まさにその通りです。ただ、これはPIC10F222の実験なので、これはこれでいいということで・・・。
東京電力の記者会見で思うこと
まず、先に福島第一原子力発電所の現場で奮闘されている東京電力の関係者の方々、自衛隊や消防庁などの方々、本当にお疲れさまです。おそらくはまさに戦場ともいえる状況での皆様の奮闘を想像すると、感謝と尊敬の念を抱かずにはいられません。また、負傷された方もいらっしゃるとニュースで伝えられていますが、無事に回復されることをお祈り申し上げます。
さて、朝日新聞のサイトで、東京電力の記者会見の様子を伝える記事がありました。
その中で、最後に会見が荒れた様子が伝えられています。
『電源がすべて失われた場合を想定しなかったのは何故か？』『それに対してどのような対策を講じてきたのか？』という質問に対して、東京電力は『津波が想定外だった』という回答をしています。途中をすっ飛ばして、『津波が想定外だった』という回答を初っ端からするのもよくないけれども、そもそも外部電源が全て喪失した場合に自力で動けるように発電機を用意していたわけです。津波が想定外で、その発電機が流されてしまった、電源に関する最悪の事態に対する備えが失われた、というのが答えなのに、記者は内容を理解することなく突っ込みつづけています。これではまったく議論にならないでしょう。
例えるなら、地震で外部から食料調達ができなくなるかもしれないので、災害に対する食料備蓄をしていた。しかし、それが予想をはるかに越える津波で流されてしまった。そんな状況で『災害時に腹が減ることは想定していなかったのか？』という質問をしているようにしか見えません。なんとも滑稽な話です。
また、『現状の最悪の事態がどうのこうの』とやっていますが、そんなものは原子力に関する基礎的な知識があればおおよそ予想がつく話で、言葉尻を捉えてセンセーショナルな記事を書きたいだけにしか見えません。最悪の場合は単純に、現状維持で放射性物質の漏洩が続く、もしくは機器や配管の破損が進んで放射性物質の漏洩が増えていく、それだけのことなのではないかと思います。もちろん、そうならないように現場の方々が奮闘しているのに失礼な話だと思います。
一方で、今回の東日本大震災での津波が必ずしも想定外だったかというとそういうわけでもないようです。毎日新聞の記事によると、２００９年の６月に原発の耐震性再評価に関する中間報告書案の審議会で専門家から貞観津波の再来が近いことを警告されていたのに、「十分な情報がない」と先送りしていたようです。しかし、１１００年も前の出来事について詳細な情報があるわけがありません（自分がWebで素人なりに調べた結果は３月１４日の記事を見てください）。つまり、うやむやにしようとしていたところで今回の震災に伴う事故が起きてしまった、という状況のようです。
東京電力は民間企業ですから、経営陣からすれば余計な経費をかけたくないのも理解できます。しかし、高い公益性をもつ企業として原子力という正しく使わなければ危険な道具を託されているわけです。もっと重大な責任感をもって対応してもらわなければ困ります。
自分の勤務する会社でも経済のグローバル化に伴う国際会計基準の厳密な適用などで、経営部門の権限がどんどん強くなってきているように思います。ＣＳＲ（企業の社会的責任）とかが謳われていますが、自分の勤務する会社ではあくまで建前にしかみえません。幸い、自分の関わるものは社会インフラを支えるものや、人命に関わるようなものではないのですが、それでも技術的に危ない、人として倫理的にどうなの、と思うことがあっても、結局経済論理が最優先で判断されてしまっています。
このような風潮が日本中のもっと重要な箇所でも起きているのではないかと心配です（社内にも社会インフラや人命に関わる機器を扱う部門も存在します）。安全性に関してはもちろん規格がありますが、「規格を通りさえすれば良い」という考え方と、「規格の主旨に則って設計し、規格で確認する」という考え方では全く違います。
技術立国日本とよく言われますが、現場を知らない／理解しようとしない経営部門の前に急激に脆くなってきているのではないかと心配です。
PIC10F222でA/D変換
UART送信プログラムができたところでターゲットをPIC10F200からA/D内蔵のPIC10F222に変更して、実際にA/D変換させたものをソフトUARTで送信して、それをAE-UM232R経由でPC上のTeraTermに表示させてみました。
10F222は内部の発振周波数が8MHzも選択できるので、8MHzに設定した上で通信速度も9600bpsに変更しました。（Ｗａｉｔも現物あわせしなおしです）
A/D変換の対象は内部の0.6Vの電圧リファレンス、AN0/AN1の３つです。表示は内部リファレンス、AN0、AN1の順でスペースを開けてHEXで送信します。
こちらは機能が少ない分だけあっさり動作しました。PICKit2がつながっているとAN0/AN1は０のままなので面白みも何もないですが、PICKit2を外して、端子に指を触れると指からのノイズに応じた値を表示できました。
プログラムは一応アップロードしておきます。⇒10F222 A/D変換プログラム
使用したMPLABのバージョンは8.60、CコンパイラはHITECH-Cの9.80（評価用です。インストールしてから時間が経っているので最適化がかからなくなっています）です。
PIC10FでソフトUART
PIC10F2xxの使い道として、PIC10F222のA/DコンバータでA/D変換した値をUARTで送信する使い方を考えてみました。ターゲットはアナログジョイスティックで、実験用に値をA/D変換してPCに送りつける使い方です。で、まずその準備としてPIC10F200でソフトウェアUARTを作ってみました。（送信だけなので正確にはUARTではないですが・・・）
これで1200bpsで文字を送信してくれます。なお、真ん中あたりに７１回の無駄なループがありますが、これで送信速度（１bitの時間）を調整しています。調整はオシロスコープを見ながら現物あわせです。現物あわせですから、コンパイラのバージョンが変わると速度が合わなくなってしまう可能性もあります。TMR0を使ってきちんとタイミングを取る方法で作りかけたのですが、サイズが大きくなるのでやめました。
作成途中ではまったのは、以下の点です。
- １ビットの時間が安定しないと思ったら、ウォッチドッグタイマが動いていた。
MPLABのメニューのConfigure設定で禁止していると思ったら、禁止できていなかったです。やはりソース内に記述してしまうのが安心です。記述方法はHITECH-Cのマニュアル（PDFファイル）内に記載があります。 - OSCCALの値が破損していた。
リセット解除するたびに１ビットの時間が 大きくばらつくので、やはり使い物にならないかと思ってあきらめかけたのですが、よく考えるとクロックの周波数自体は１％の精度が保証されているので精度としては十分なはずです。何が起きているのかと思ったら、ROMの最終番地に書かれているMOVLW命令が破損していました。つまり、リセット解除時の不定なWレジスタの値がOSCCALレジスタに書かれていたわけです。ＰｉｃＫｉｔ２のToolsメニューの中に、OSCCALの値を復活させる機能があるので、それで復旧したところ綺麗に直りました。
・・・・が、これだけで10F200の256バイトのＲＯＭのうち167バイト（65%）、16バイトのＲＡＭのうち10バイトを使ってしまいます。10F222ならもう少し大きくなるとはいえ、数値を文字列に変換することなどを考えると苦しそうです。数値をバイナリで送るとかであれば何とか使えるかもしれません。
PIC10Fシリーズ
加速度計で地震がそれなりに検出できそうなので、揺れを検出したらブザーを鳴らしたいと思ったのですが、Arduinoではタイマーはすでに使われていて、500HzのPWM信号しか出力できません。そこで、ブザー自体を外部で生成することを考え、手持ちの米粒マイコンPIC10F200/222を試してみました。
SOT-23なので、変換基板を介してブレッドボードに実装してテストしました。残念ながら直接タイマーから出力できないのでタイマーを監視しながらソフトウェアでポートを制御することになります。本当にブザーだけであればまあまあですが、周期の精度が多少バラつくのか今ひとつ濁った音になります。
こちらはまだ動かしていませんが、PIC10F222です。ROM容量が倍の512バイト、RAM容量が約1.5倍の23バイト、8bit A/Dコンバータ内蔵です。
写真の編集
WordPressにアップロードする写真はあまり大きいと見る人の負担になってしまいます。なので、適切なサイズに処理してあげなければなりません。従来はIrfanViewの一括変換でまとめてリサイズ後、Ubuntuに持ってきてからjpegのヘッダを落としてアップロードしていたのですが、最近はUbuntuで閉じた作業を始めているので、Windowsを起動するのが億劫になってきました。そこで、Ubuntuでもできないか調べてみました。
結果は非常にベタで申し訳ありませんが、ImageMagickのconvert/mogrifyコマンドでOKでした。自分が使うコマンドは以下の通りです
$ convert -geometry 900×900 元ファイル名 保存ファイル名
です。geometryは900×900と指定するとその範囲に収まるように縦横比を変えずに縮小してくれます。
その後、カメラによってはＧＰＳ情報が含まれているので、ＪＰＥＧの余計なヘッダを落とします。
$ jhead -purejpg *.JPG
で完了です。ローテーション情報（縦位置、横位置の情報）がまだおかしいことがあるようですが、WordPressでも修正可能なので、そちらで修正します。
Arduinoベースの湿度計
調子に乗って、湿度計の方もまとめてみました。
基本的には同じ構成ですが、ブレッドボードで動作確認した後で気圧計も載せたいと思っているので、センサ類は暫定で載せています。あとで、LCDの下に移設しないと気圧計が入らないと思うので、まとめて0.2ミリの厚さの表面実装部品用ユニバーサルボードに載せてます。この0.2ミリ厚のボードはハサミでチョキチョキ切れるのが便利です。ちなみに、ATmega周り、レギュレータ周りなどもコンデンサ類はチップ品を使っています。1608サイズのチップは2.54ミリピッチのユニバーサル基板と相性がいいのでお勧めです。
センサ部分は奥からLM35DZ、0.22uFのフィルムコンデンサ、HS-15Pの順です。スイッチは電源スイッチで、その奥にあるのが5VのCMOSレギュレータのXC6202P502です。パスコン類は半田面側に4.7uFと10uFのチップコンデンサをつけてあります。
先に作った加速度計と並べてみました。
余震について
昨日（3/22）は比較的大きな余震が何度かありました。気象庁でも余震活動の予測を変更したようです。リンクされているPDFファイルを見ると、余震の発生が予測の範囲から外れて余震活動が活発になっている様子が見て取れます。
それはそうとして、本震後しばらくは余震が非常に多く、部屋に置いてある物（正確には吊ってある物）も頻繁にユラユラとゆれていて気持ち悪かった状況が続いていました。しかし一週間くらいたつとそれもほぼ収まっていたのですが、昨日の余震活動活発化以降は再び部屋の物はユラユラ揺れるようになりました。さらに再び揺れによる気持ち悪さ、眩暈が出てきました。なんとなく気持ち悪い、眩暈がする、と思うと、部屋の中の吊ってある物が揺れているのです。ごくわずかではありますが、なんだかいつも揺れているような感じです。
吊ってある物も揺れているので「気のせいではない」と理解できるんですが、かなりのストレスになりそうです。
Arduinoベースの加速度計
Arduinoと加速度センサの組み合わせで液晶表示ができるようにしましたが、ブレッドボードのままでは実用には程遠いので、秋月のユニバーサル基板にまとめてみました。
電源は９Ｖの角電池で写真に写っているのはだいぶ前に秋月で使用期限直前とかで箱で安売りしていたものです。この他に角電池タイプのNiMH電池も手持ちにあります。今回は配線量を減らしたいので、角電池からCMOSの三端子レギュレータ（XC６２０２P５０２）を使って５Ｖを生成してATmega328に供給しています。
肝心の地震の検出ですが、モジュールそのままでは高周波の振動ノイズを拾うのか、値のバラツキが大きく上手くいきません。データシートにもあるようにXYZの各出力端子に1uFのコンデンサをつけて、帯域を制限してやることで、上記の様に比較的に静かな環境では値が落ち着くようになりました。計算上は5Hzくらいのところで帯域制限しているはずです。（なお、表示している数値の単位は「計算上は」ガルです）。
で、実際、今回の地震の余震のゆっさゆっさした揺れだと、下の値がじっとしていると気づくものでも５程度、はっきりわかるものだと１０程度にはなります。何もない状態だと２～３には収まるようですので、とりあえず体感できる地震があったかどうかくらいは検出できそうです。
