艦長日誌・私的記録 DS9

　AVRの開発環境を実現するために，MacBookProに仮想環境として，VitrualBoxを導入したことは先日書きました。このVirtualBox，実に良くできているので，簡単に紹介しておきたいと思います。

　VirtualBoxはSunMicrosystemsの製品で，無償かつオープンソースの仮想マシンソフトです。ライセンスはGPLv2に準拠していて，個人・商用を問わず利用出来ます。エンタープライズ用途向けに24時間対応のサポートが受けられるオプションもあります。

　個人的には，エンタープライズ用途向けをちゃんと目指していることを評価していて，その上きちんとアップデートを継続していることもよいと思います。現在のところ最新版はVer.3.1.0ですが，特にVer.3以降はかなりこなれてきたという印象があります。

　そもそも論ですが，昨今はやりの仮想マシンというのは，実機の上に複数のマシンを独立で構築する仕組みです。Windows上でX68000を再現するX68000エミュレータも一種の仮想マシンですし，Javaの実行環境はJavaVMといって，これも仮想マシンの一種です。

　これらは，ソフトウェアで別のマシンを実装するもので，実機のCPUが仮想マシンのCPU向けの命令をソフトウェアでいちいち翻訳しながら動作しています。だから動作が低速になることは想像が付くと思います。

　で，最近よく耳にする仮想マシンには，x86の上で，複数のx86を動作させる仮想マシンの話が多いようです。そういえば昔仮想86モードなんてのを耳にしましたね。あれは80386上で仮想8086を実現するものでしたが，言ってみれば仮想8086が仮想x86に昇格した，という感じかも知れません。

　1台の実機上で複数のマシンを稼働できると，古い機種でしか動作しないソフトウェアをそのまま動作させる事ができたり，それぞれで異なるOSを動作させることができたりしますし，またそれぞれのマシンを完全に独立させることが出来る事から，セキュリティや信頼性の向上が期待できます。

　さて，仮想マシンの実装には，元々1つしかないリソースを複数で共有し，互いに影響を与えないようにするために，仮想マシンモニタと呼ばれるソフトウェアがリソースの配分などを行う必要があります。

　ただ，この仮想マシンモニタはオーバーヘッドが大きく，処理速度の低下が深刻であったため，出来るだけオーバーヘッドが発生しないよう，機能の一部をハードウェアで支援できるような拡張が，近年のCPUには実装されつつあります。

　例えばx86（正確にはIA32プログラミングアーキテクチャ）の場合，リング0からリング3までの特権レベルがあり，OSの低レベルの部分などはハードウェアリソースのほぼすべてにアクセスが可能なリング0で実装されてきたのですが，仮想マシンを実装する上で，OSがリング0で動作していては他のOSへの影響が避けられないため，仮想マシンモニタをリング0で動作させ，OSはリング1から3で動作させることになります。まあ当然ですね。

　ところが，OSにはリング0のみ許される特権命令が含まれているため，リング1から3で動作している状態では例外が発生します。

　これを回避するため仮想マシンモニタが例外を監視し，例外が発生したら命令をエミュレートして，OSに結果を返すようにしていたのです。なんか，非常に重たそうなことをしないと，x86で仮想マシンを実現出来ないっぽいですね。

　もう1つ，x86で仮想マシンが面倒臭いというお話をしましょう。こっちはちょっと笑えます。

　popf命令などが例ですが，なんとユーザーモードと特権モードで動作の異なる命令がx86では存在しています。建て増しを繰り返してきたから，という意見もあるのですが，どっちにしても同じ命令で動きが違うなんて，ちょっとビックリです。

　これは仮想マシンモニタにすれば非常に迷惑な話で，この命令がリング1から3で動作しているOS上で見つかった場合，それは本来リング0での動作を期待されていて，リング1から3では動作させてはならないので，例外によって知らせて欲しいのに，実際にはどちらのリングにも存在する命令ゆえに，例外すら発生しないのです。

　ということは，リング1から3で動作しているOSが発行する命令を，常時監視しなければならないわけです。これはたまりません。

　VMwareなどは，こうした仕組みを実装し，もともと仮想マシンを考慮していないx86で仮想マシンを実現していました。これらの仮想マシンが高い評価を受けているのは，こうした重たい処理を必要としながらも，実用的な速度で動作する仮想マシンを実現したことにあると思います。

　ところが，こうした不細工な方法で無理矢理仮想マシンを実現するというのは，決して褒められたことではありません。そこで，x86にも仮想マシンをハードウェアで支援する機構が用意されるようになってきました。インテルではIntel VT，AMDではAMD-Vと呼ばれるものです。それぞれ異なるものではありますが，やってることは基本的には同じです。

　まず，リングプロテクションに関する支援です。リング0から3までをそれぞれ持つ，VMXrootとVMXnon-rootの2つのモードを用意しました。VMXrootでは仮想マシンモニタが動作しており，VMXnon-rootモードではOSを動作させます。

　もしOSが特権命令を発行した場合にはVMXrootモードに移行し，仮想マシンモニタに制御を移します。このように仮想マシンモニタが特権命令を監視しなくても良いので，オーベーヘッドは大幅に削減されることになります。

　また，仮想マシンごとにレジスタなどのコンテキストを保存する専用領域を用意してあり，これらの切り替えが自動化されるようになっています。このこともオーバーヘッドの削減に寄与しています。

　さらに，I/Oについても仮想マシンの実装支援が行われています。VT-dなどと呼ばれている機能です。

　仮想マシンでは，I/Oはそれぞれのデバイスのエミュレーションによって実装され，DMAを行う場合はアドレスのリマップが必要となります。

　このことは速度の低下に加えて，エミュレートされたデバイス用のデバイスドライバが必要になるため，従来のドライバをそのまま使用できなくなる場合があります。

　そこで，ハードウェアによってDMAのアドレスをリマップする機能を用意しておきます。こうすれば速度的にも有利な上，I/Oのエミュレートを行わないので従来のデバイスドライバがそのまま使えるようになります。

　こうした支援機構によって，従来に比べて2割ほど性能が向上するそうです。

　現在利用されているx86用の仮想マシンは，別にこれらの支援機構が必須になっている訳ではありません。しかし，多くがこれらの支援機構を利用出来るようにもなっており，対応したCPUを使えば，さらに速度や利便性の向上を期待できるというわけです。

　話をVirtualBoxに戻しますが，VirtualBoxも，Intel VTのうちVT-xとAMD-Vに対応しています。ただ，過去にはこれらを使うと速度が低下したケースもあったそうですし，他にもいろいろ問題が出ていたようですので，ちゃんと考えて使わないと失敗しそうです。

　さて，私のMacBookProにインストールしてみます。ホストOSはSnowLeopardで，64bitカーネルです。ここにVirtualBoxの最新版である3.1.0をインストールしますが，これはあっさりと終了。

　VirtualBoxを起動すると，最初にディスクのイメージファイルを作る事になります。仮想ドライブの容量と同じ大きさのイメージファイルを作る方法と，イメージファイルの大きさが可変するものの2つを選ぶことが出来ますが，後者はドライブの容量サイズを変更できるという意味ではなく，これは最初にしていした容量のまま変えることが出来ません。あくまで仮想ドライブにデータを書き込むと，イメージファイルの大きさも大きくなるという仕組みで，ホストOS上に無駄にでかいファイルを置かずに済むということを狙ったものです。

　ここにWindowsXPをインストールします。MacBookPro内蔵のDVDドライブもVirtualBoxの支配下にあり，ここにWindowsのCD-ROMを入れて置けば，インストーラが起動して，いつものようにWindowsXPがセットアップされます。

　なお，仮想マシンのメモリですが，あまり巨大なものを設定すると，ホストOSでスワップが発生し，パフォーマンスががた落ちになります，私の場合4GBを搭載しているので1GBくらいなら設定してもよいだろうと思いましたが，考えてみるとホストOSにとって1GBも占有するソフトが起動するというのは結構きついことで，スワップが発生すると大変なことになります。WindowsXPなら512MBもあれば十分です。

　インストールが終わればMacの画面上でWindowsが動くという見慣れない状況が起こりますが，それぞれちゃんと動いています。当たり前なのですが感動的です。

　デバイスドライバも普通のデフォルトでインストールされるので，特に問題はなく動くのですが，ここでGuestAdditionをインストールしておきます。VirtualBoxのメニューからGuestAdditionのインストールを選ぶと，Windows上でインストーラが動き出してさらに便利な仕組みが使えるようになります。

　特に便利なのが，マウスカーソルの移動です。デフォルトでは左のコマンドキーを押すごとにマウスカーソルがホストOSとゲストOSで切り替わるのですが，これが案外面倒です。ところがGuestAdditionをインストールすれば，VirtualBoxのウィンドウの上では自動的にゲストOSのものと判断され，そこから外れた領域ではホストOSのものとされます。つまり，通常のMacOSのソフトと同じようにマウスが動かせるということです。

　ネットワーク関連ですが，ここはなにも考えず，NATで設定すればOK。ホストOSとは異なるIPアドレスを割り振る必要があるだろうと思っていたのですが，NATを実装してあるので，ホストOSのネットワークを，ゲストOSが失敬するような仕組みになっているようです。

　グラフィック周りは期待しない方がよいのですが，一応2Dと3Dのアクセラレーションが有効に出来るようです。ただ，2Dのアクセラレーションはしない方がいいと警告されますし，3Dの方はチェックしても私の環境では有効にならないようでした。

　2Dのアクセラレーションが有効にならないという事はDirectXを使ったソフトは動作しないという事になるので，実は結構な数のソフトが動作しません。古いパソコンのエミュレータを動かそうと思っていましたが，ほとんどが無理でした。

　画面関係でいえば，最大解像度がXGAまでなので，これで狭いと思っても手がありません。MacBookProの画面の大きさを考えると，ホストOSの邪魔をしないようにするにはXGA位が適当だと思うので私はそれほど問題とは思っていませんが，確かに開発系の統合環境などは，窮屈な感じがします。

　USB周りは今回の目的，開発環境の動作のためには妥協できない部分です。そもそもハードウェアリソースとしてのUSBをホストOSとゲストOSで共有することになるのですから，排他使用になる事は当たり前です。

　どちらかでしか動作しないデバイスなら別にいいのですが，USBメモリのようなどちらでも使えるものはどうするか，です。

　なにも設定をしないと，まずホストOSでマウントします。この状態でゲストOSでマウントさせようとしても，グレイアウトしてマウントできません。

　そこでホストOSでアンマウントすると，ゲストOSでマウントします。しかし，いちいち面倒ですね。そこでVirtualBoxでは，USBのIDを登録しておき，どちらのOSで使用するかを設定することが出来るようになっています。

　この方法で，AVRライタやMSP430のデバッガ，USB-シリアル変換ケーブル，USBメモリを登録しておきました。それぞれ，Windows用のデバイスドライバでなんの問題もなく動作しています。これは本当に期待通りです。

　ファイル共有ですが，VirtualBoxの設定からホストOS上のフォルダを指定しておきます。例えばそのフォルダがhogehogeだったとすると，これがゲストOS上では\\vboxsvr\hogehogeとなりますので，これをネットワークドライブとしてマウントすればOKです。

　この程度の環境設定を行って実際に使ってみると，Macで動かしているという感覚を忘れてしまうほど，そのまんまWindowsです。速度も全く問題なく高速で動きますし，ホストOSに悪さをするようなこともありません。音もきちんと出ますし，光学ドライブもちゃんと共有出来るようになっています。

　VirtualBoxでWindowsを動かしつつ，iChatAVを使ってビデオチャットということも問題なく出来ていますので，メインはMacだが時々Windowsが欲しい，という程度の話であれば，それぞれに妥協をすることなく，両方のOSを同時に使用することが十分出来ると思います。

　本当に処理速度が欲しい，あるいはスタンバイや休止状態を確実に使用したい，グラフィック関係が動かないといけない，という場合にはBootcampで再起動をかけるしかありませんが，逆に言うとVirtualBoxでダメな場合にはBootcampという手があるという事ですから，MacBookを持っている人は無敵のパソコンを手に入れたに等しいと，私は感じました。

　以前からちゃんとした仮想マシンに興味があって，それは利便性だけではなく技術的な興味関心から，実際に使ってみたいと思っていたのですが，これだけ簡単に導入でき，しかも十分実用になるというのは，良くできているなあと感じました。

　私は以前PowerMac7600をPowerPCG3の500MHz程度で使っていた頃に，Connectixという会社のVirtualPCを使っていたことがありました。Windwos95を入れて，当時使っていたシャープのザウルスの母艦にしていたのですが，動作はあまりに遅く，忍耐なしで使う事は不可能でした。

　ほぼすべてのデバイスをエミュレーションするだけでななく，CPUでさえもエミュレーションしなければならなかったVirtualPCと比べるのはかわいそうですが，互換性においても速度においても，ただ動くというレベルから使えるレベルになっていることは，ユーザーにとって大きなメリットになっていると思います。

　ゲストOSが有償なら当然買う必要はありますが，VirtualBoxは無償で利用出来ますから，特にMacの人は便利だと思います。それまで一般のユーザーが使うことの出来なかった高度な技術がいとも簡単に利用出来るのが，PCの世界です。

　高速なクロック，膨大なメモリ，スーパースカラ，ベクトルプロセッサ，仮想メモリ，賢いコンパイラ，プリエンプティブカーネル，そして今回の仮想マシンと，すべて大型機のために開発された技術ばかりです。それがこうして安価に提供され，コンスーマ用に新しい活用方法が提案されて，より便利になっていきます。

　これから先，お手本とすべき大型機が不在になるなか，PCの進化はどちらを向くことになるのでしょうか。楽しみです。

　GPS時計ですが，その後も毎日のように検討を続けていました。

　GPSを使って時刻情報を得ていながら，1秒近くずれるというのはもはや言語道断といえて，何とかなるならしてみたいし，駄目な場合でも駄目な理由を理解してからあきらめたいと思ったからです。

　さて，前回，UARTのボーレートを38400ボーにするということと，使っていないセンテンスは送出させないようにしたこと，それと1秒に1回だったデータの送信周期を1秒に2回にしたことで対応を図ったが，あまり良い結果が得られなかったことを書きました。最大で1秒弱の遅れは解消されず，遅れる時間も長かったり短かったりとバラツキがみられます。

　そして，根本的にGPS本来の精度の時計を作るなら，GPSモジュールから1PPSの信号を得なければどうにもならない，ということもはっきりしました。ここまでが前回までのお話です。

　一般論としてですが，どうもGPSモジュールから出てくる時刻情報は，実際の時刻よりも少しだけ進んでいるのが普通のようです。少しだけ進んだ時刻をマイコンが取り込み，その後やってくる1PPSの信号で表示を更新することで，GPS本来の精度の時計が実現出来るというわけです。

　今回使っているGT-720Fというモジュールはこの1PPSの信号が出ていませんので，そもそもGPS時計を作るのに適していないモジュールを選んでいることになります。

　それに，これまでいじった結果として感じるのですが，少し進んだ時刻が出ているかどうかもあやしいです。

　ということで，1PPSがないと正確な時計を作る事が出来ないなら，GT-720Fから1PPSの信号を引っ張り出せないか，と考えました。

　幸いないことに，GT-720Fで使われているベースバンドチップは，Venus621LPというもので，1PPS信号の出力を持つLSIです。きっと，モジュールのどこかに1PPS信号が出ているに違いないと考えました。

　そこで背面のシールドケースをあけ，1PPS信号を探したのですが，結論からいうと見つかりませんでした。Venus621はBGAパッケージのLSIですから，端子から直接信号を取り出せません。基板上のどこかに出してくれていることを期待したのですが，スルーホールや抵抗などの部品をすべてあたっても，1PPSの出ている箇所を見つけることができませんでした。

　ならば，と衛星をつかまえたことを示すLEDはどうだろう，と考えました。GT-720Fは，衛星をつかまえていない時はLEDが点灯，つかまえると一定間隔で点滅します。

　このLEDの点滅が1PPSに同期しているなら，1PPS信号として使えるでしょう。いい所に気が付いたと思ったのですが，残念ながら全く同期しておらず，無関係でした。この段階で，GT-720Fから1PPS信号を得る事はあきらめ，外したシールドケースを元に戻しました。寂しいですね。

　ここに至って，1秒近く遅れる，という人間の感覚でもばれてしまうズレを，せめて意識しないで済む程度にする，という消極的な方法しかなくなってしまいました。

　そのためには，前回も書きましたが，何らかの理由でずれた時刻が送られて来ても，更新周期を早めて表示を頻繁に行うのが有利です。周期が短いほど，ずれた時刻の表示が正しい時刻になるまでの時間が短くなります。

　そこで，GT-720Fの設定ツールを使って，更新周期を設定可能な最大である1秒間に10回に設定しました。

　また，ボーレートを19200ボーに下げました。これは，38400ボーに上げたところで数msしか高速化されませんし，96バイトとバッファサイズを大きくしてまでこのボーレートで受け取るのは無駄で，64バイトのバッファで受信可能な19200ボーが最適という判断です。

　前回書きましたが，バッファを64バイトにすれば，リングバッファの実現が条件分岐ではなく，ANDによるマスクという処理だけで可能となります。これは処理速度にもコードサイズにも有利です。

　さらに，LCDへのデータ転送タイミングには十分すぎる時間を確保してあったのですが，これを大幅に切り詰めました。LCDへの転送クロック周期はスペックでは500nsから1000ns程度なのに，2msと2000倍も長くとってありました。動作は確実でしょうが，処理時間の大半はLCDへの転送にかかっていたことになります。

　試したところ，確かに見た目のズレはかなり軽減されています。しかし，そのズレ方は一定ではなく，1/10秒くらい遅れているときもあれば，ほとんどずれていない時もあります。

　この違いはなんだろう・・・はっきりしないと，時計として全く信用できません。

　この疑問は，GPSモジュールの吐き出すセンテンスを直接PCで見た時に氷解しました。

　実は，GPGGAにしてもGPRMCにしても，時刻情報として

133227.999

　というデータが，13時32分28秒の段階で送り出されていることがあるようなのです。

　27.999秒というのは，もうほとんど28秒なのですが，1/10秒以下を無視してしまうと，27秒と表示されてしまいます。

　もし，1秒間に1度の更新周期なら，次のデータは28.999秒となり，実際の時刻である29秒との表示のズレは，またしても1秒出てきてしまいます。こうして，GPSモジュールが何かのきっかけでxx.999ではなく，xx.000を出してくれるようになるまで，この1秒の遅れは続きます。

　もし1秒間に2回の更新を行う場合，送られて来るデータは

133227.999 133228.500 132228.999 133229.500

　という順番で出てくる事になり，ズレは0.5秒まで軽減されます。とはいえ，0.5秒のズレはばれてしまいますね。

　さらに，もしなんらかの理由で，

133228.000 133229.000

　という形で送られて来るようになると，.xxxを無視して表示すれば，ほとんどずれることなく表示が出来る事になります。

　さらに調べていくと，.xxxの部分は一定ではなくばらつくこと，バラツキの大きさによって遅れる時間が変わることも分かりました。

　これが，表示時刻が不規則に遅れる理由でした。

　少し実験をします。PCで.999というデータが出ていることを確認した上で，実機の表示を1/10秒まで表示させてみました。すると秒の桁が，

11.1 -> 11.2 -> 11.3 ... -> 11.8 -> 11.9 -> 11.9 -> 12.1 -> 12.2 ...

　という具合に変化します。1/10秒にゼロが表示されないことと，1秒の桁は11.9では変わらず12.1で変わるので，実際の時刻よりも1/10秒遅れているのがよくわかります。

　また，PCで.000で揃ったデータが出ている状態で同様に確認すると，ほとんど同時に表示も変化するようになります。これではっきりしました。

　そこで，暫定的に.999になったら秒のデータに1を加えるという簡易的な方法を試してみたところ，表示は概ねずれることなく更新されるようになったのですが，

18.8 -> 18.9 -> 19.0 -> 19.1 ... 19.8 -> 19.9 -> 1:.0 -> 20.1 ...

　という変則的な表示となり，見た目が非常に悪くなりました。キャラクタコードに1を加えただけの手抜きはダメで，やっぱり真面目にやるしかありません。

　そこで，さらに大幅な変更をします。日付はともかくとして，時刻だけはちゃんと処理する事にしましょう。日付は24時間に一度変化しますが，GPSからのデータの取得はは1秒おきですので，1秒だけ32日とか出てしまうことが考えられますが，まあいいでしょう。メモリも足りませんし。

　このため，これまで直接リングバッファの値を表示用の関数に渡していたものを，一度グローバル変数に取り込んで，文字列-から数値への変換，補正や表示を行う事にしました。

　あと，潜在的なバグとして日付の処理に問題があり，UTCで9日をJSTに変換するところでくだらないミスをしていたため，10日とならず，0:日と表示されていました。配列の宣言のミスで，暴走一歩手前だったことも白状します。お恥ずかしい。

　そうこうして出来た最終的なソースが，以下です。

続きを読む

　長く続いた「鉄道データファイル」がいよいよ最終回を迎えました。

　長かったです。辛かったです。毎週火曜日にやってくる「こなさねばならないもの」を1週間かけて読むことは習慣にこそなりましたが，できればその習慣は，一日も早く断ち切りたいと思う，忌むべきものでした。

　ならさっさとやめればいいじゃないか，と思われるでしょうが，途中で辞めてしまう事への純粋な不安，これまで頑張ってきたことが無駄になることの怖さと，希に面白い記事に巡り会う事への期待があって，もう少しだし頑張って見るかと，買い続けてきました。これが，ディアゴスティーニの本当に怖さでしょう。

　当初200号だか250号だかで終わる予定だったはずなのですが，スイッチバックをやたら詳しく説明したり，私鉄のロマンスカー（いわく，一方方向に向きを揃えたクロスシートを備えた優等列車をロマンスカーというのだそうです）を会社・時代ごとにまとめ直してみたり，ダイヤ改正を地域ごとに詳細に書いてみたりと，はっきりいって冗長な内容に気持ちよくお金が払える状態ではありませんでした。

　開いた口がふさがらないのは，ロープウェイやらケーブルカーが追加されたことです。確かに鉄道には違いないですが，問題は読者がそれらに興味を持ち，それらの情報を求めているかどうか，です。スキー客が激減してロープウェイの存在が薄くなる昨今，スキー場にぶら下がるロープウェイの写真を見せられて「知らんがな」と思った人は私だけではないでしょう。

　280号くらいからでしょうか，途中で辞められないようにするためと思われる，歯抜けにしてあったシートの補完がやっつけ仕事で急激に進められ，計画性のなさにため息が出ました。そうやって膨大な補完を行うため，ページ数が増えても内容は薄く，しかも出てくる記事があちこち飛びまくっているので，読了するのが本当に辛くなっています。

　よく言われているように，誤字脱字などの間違い以上に，著者の知識不足や誤った理解も目に付きますし，作者の趣味を反映した東南アジアの旅行記などをだらだらと作文のように読まされることも苦痛だったりしましたが，そもそもこのあたりの週刊誌に過度な期待をする方がおかしいと，私は思っています。

　悪いことばかりではありません。アメリカやヨーロッパの鉄道に興味を持たせてくれたことはきっかけとしてありがたいものですし，車輌だけ，あるいは駅だけ，というものではなく，全般を一通り取り扱っていることから，システムとしての鉄道に関心が沸いたことも事実です。

　とはいえ，さすがに300号買い支えた私は，本当にバカだと思います。あまりに恥ずかしく，一号も欠かさず買い終えた事は，死んでも黙っているべきです。

　しかし，300号までの道程をしみじみと思い返してみると，まさに私の平坦な人生において，激動期と重なっていたように思います。

　ちょうど創刊号が出た頃，ちょっとした鉄道ブームが起こっていました。理由は分かりませんが，1つには団塊世代の引退があるのではないかと思います。

　私は団塊の世代もなく，まして退職したわけでもないのですが，たまたま立ち寄った家電量販店のオモチャ売り場で，処分のワゴンに入っていたマイクロエースのED17が特価で売られており，私がNゲージで遊んでいた子供の頃とは精密度が全然違うことに驚き，買って帰ったことに端を発します。

　以後，次々と鉄道関係の本が出たり，魅力的で個性的な車輌が模型化されたり，DCCという鉄道模型に革命を起こすシステムが一般化したりと，まるで私を狙い撃ちしたかのような状況になっていきました。

　おそらく，このED17を買うことがなければ，鉄道に興味を示すことはなかっただろうと思うのですが，ひょっとすると，こんなふとしたきっかけで鉄道に回帰した人が多く，それがブームに成長したのだとしたら，私もブームに乗っただけの人だったことになるのでしょうか。

　鉄道データファイルの第1号が登場したのは，2004年2月3日でした。それから約6年，毎週毎週出続けたことになります。最終号を手にとって，この6年間の自らの境遇を，ちょっと思い出してしまいました。

　2004年は，自分の希望で慣れた職場を飛び出したはいいが，すっかり行き詰まってしまい，毎日が沈んだ日々を送っていた年でした。その職場の近所の本屋に毎号買いに出かけていました。この職場はやがて解散となってしまうのですが，ここで出会った，一生の宝となる方々には，後日随分と助けて頂くことになります。

　2005年は，結局もとの職場に戻ることになり，自分の居場所を見つけた時でした。自分が思い描いていた仕事をフルパワーでやっていた時期です。毎日が楽しく，難しい事にも果敢に挑み，充実した日々をおくっていました。仲間も出来ましたが，敵も作りました。この頃，毎週出る鉄道データファイルが楽しみで，職場から少し離れた本屋に出向くのが楽しくて仕方がありませんでした。

　2006年は，心血を注いだ仕事が水泡に帰し，その上職場を追われた時でした。別の部署に引き取られましたが，私はここで干されてしまい，ろくな仕事のない時でした。そのうち「ここにはあなたの仕事はないから」と部長に言われて職場を追われました。

　2007年は，次の職場を選んでいた私が，かつての上司に言葉巧みにだまされて，おかしな職場に引っ張り込まれた時でした。当の上司は私が異動した初日にとっとと逃げ出してしまい，私だけが置き去りとなりました。事前に聞いていた話とは全然違い，わずか1ヶ月でプロジェクトから外され，この年の夏には席まで隔離されてしまいました。そういえば「会社に残りたければ雑巾がけをやれ」と人事に言われたのもこの年でした。本当に辛い時期でした。

　2008年は，設定された期日を過ぎても異動先がなく，退職の覚悟をした後に，全く縁もゆかりもなかった職場に本当に偶然拾ってもらった年でした。ここで自分の得意な小型マイコンを使う事があったり，今も友人として親しくしている社外の方とも出会う機会があったりと，朽ちる寸前だった私の心に少しずつ血が通い始めた時でした。

　2009年は，リストラのあおりをうけてその職場も追い出され，今の職場に流れ着いた年でした。会社に対して，あるいは人間に対しての，不信感と言うよりそれらへの虚無感を抵抗なく受け入れて，まあ世の中そんなもんだと割り切って生活するようになった時期です。もっとも，一番よい仕事の出来る時期を成果も無しに過ごしてしまったことは決して取り返すことは出来ず，そのことをふと思い出した時に，ダメ人間というのはこうやって出来上がるんだなと，しみじみ思うのです。

　かくてこの6年，長かったようで短かった時間でした。いろいろあって，生きること以外のすべてを否定されても，それでも生きていかねばならないことの辛さを知った，そんな時だったように思います。

　そんな日々を送っていても，毎週火曜日には必ず鉄道データファイルの号数が1つずつ増えていきました。思い起こすと，どんなに辛いときにも，どんなにうれしいときにも，必ず枕元には鉄道データファイルがありました。無神経とさえ思うことがありました。

　鉄道データファイルが自分を支えたとは全く思いませんが，変わってゆく自分と同じ時間軸にある変わらないものに，もしかしたら，少しはもたれ掛かっていたのかも知れません。

　さてさて，これで終わったと思ったら，来年からはシリーズ第2弾「鉄道データファイル プラス」が始まるそうです。いやー，まさかの続編とは。～プラスって流行ってるんですか，もしかして。

　定期購読をお願いしているいつもの本屋さんに，いつものように火曜日の朝，最終号を取りに行くと，すっかりおなじみになったいつもの店員さんに「今日でおわりなんですよね。ありがとうございました。またきてくださいね」と，言われました。

　私も，「またきますよ」と言って，お店を後にしました。

　変わらぬ事が変わってしまった，瞬間でした。

　工作をするとゴミが出ます。切りくずや削りカスなどは掃除機がないと片付かないわけですが，私の掃除機は15年ほど前に買った何の機能もない無骨な掃除機でして，これを引っ張り出すのがいつも億劫でした。

　そもそもゴミを出さないように工作すればいいのですが，ゴミごときに気を遣って集中できないのも男としてどうかと思いますし，それが作品のクオリティを左右するなら本末転倒です。汚れないように泥遊びをしろと子供に言ってもかわいそうでしょう。

　泥遊びをする子供と同じレベルを脱せず，自分が大人であることをすっかり忘れていていた私は，大人の責任を果たすべく，手軽にゴミを片付けられる方法を模索していましたが，1つの解決策がハンディクリーナの導入です。

　・・・またおかしな理由を付けて散財か，とか思わないでやってください。

　いや，数年前からハンディクリーナを探していたのです。しかし，まだ実家にいたころの経験で，コードレスタイプは吸引力が弱く結局使い物にならない，ACタイプは吸引力は十分だが機動性に欠け，しかもケーブルが邪魔で片付けるのも面倒，ということで，どっちも次第に使わなくなってしまいました。だから非常にネガティブな印象しかないのです。

　そんなおり，なかなか良さそうなハンディクリーナを見つけたので買うことにしました。ブラック＆デッカーというメーカーの，Z-PV1000という機種です。

　PV-1000といってもカシオが1980年代初頭に出していたゲーム機ではないですよ。2006年に登場したサイクロン式のハンディクリーナです。

　ブラック＆デッカーという会社は日本では馴染みもないですが，本国アメリカでは有名なDIY関連の道具のメーカーで，日本で言うならリョービとかマキタとか，そのあたりの感じでしょうか。

　Z-PV1000は，吸込仕事率26Wとそれなりに強力であること，電動工具ではごく普通に行われている12Vという電源電圧を誇らしげに謳っていること，4時間充電で10分使用可能というスペックはハンディクリーナとして実用上なんとかOKであること，吸い込み口が回転して使いやすそう，そういえばサイクロン式って私は使ったことが一度もなかった，ということで，この機種を選びました。

　そうそう，価格もなかなか手頃で，安いお店では5000円ちょっとです。私の場合，ALESIS micronを買ったときに約1800円分のポイントがもらえたので，このポイントが使えるお店を探した結果，6300円で見つかりました。最終的にポイントを充当して4500円ほどを支払い，数日後に届きました。

　届いたZ-PV1000の印象です。

・結構大きい
　丸みを帯びたデザインなので小さく見えるかも知れませんが，床に置いて遠目に見ると結構存在感のある大きさをしています。ちょうど香箱を組んだネコくらいの大きさでしょうか。
　充電はスタンドに立てて行うのですが，立てるとこれまた結構な存在感があります。スタンド置き場所は慎重に考えた方がよいでしょう。

・結構重い
　見た目以上に結構重いです。絶対的な質量よりも，ノズルを伸ばした時の全長が長いため，手首だけで上下左右に動かすと結構力がいります。それもあってか無意識のうちに強く握りしめているようで，使用後に手に力が入らなくなるほどでした。
　ただ，重量バランスはよく考えられていますし，モータが横置きされており，回転によるモーメントの発生方向が左右ではなく前後なので，持ちにくいという印象はありませんでした。

・結構難しい
　別に操作が難しい，というわけではないのですが，先程の若干重いこと，大柄なので狭いところで苦労することもあって，ノズルが狙った所にさっといかないのがもどかしいです。
　前述のように，全長が長いことで振り回すのが大変な上，ジャイロ効果もあって，手首にぐぐっと力が入ってしまうのだと思います。

・結構うるさい
　26Wの吸込仕事率だけに，音はかなりうるさいと思います。騒音に対する配慮が全くないのではないかと思われる，遠慮のない出方です。
　が，無骨な掃除機を長年使っている私にすればこんなもんだと思います。ちなみにZ-PV1000はハンディクリーナとしては珍しく，強弱の切り替えがあります。弱ならそれほど目くじら立てるほどのものはないと思うのですが，常識として深夜には使うべきではないでしょう。

・結構電池が持たない
　約10分の使用時間ですから，それを前提にした使い方をするべきなのでしょうが，良く吸い込むハンディクリーナなので，ついつい目に付いたところをついでに掃除してしまいます。そうするとあっという間に吸引力が落ち，充電が必要になってきます。
　充電すればいいだけのこととはいえ，なにせ4時間かかりますからね，本当に必要なときに電池切れになっていないように，多少考えながら使う必要があるかも知れません。

・結構雑な作り
　今時中国製は珍しくもなんともないのですが，日本のメーカーだと中国製でも国産と同じクオリティを目指して頑張るので，最近はぱっと見ただけだと中国製かどうかわからないものですが，アメリカのメーカーはそういうわけではないようで，一瞬で中国製とわかる作りの雑さがあります。
　無用な隙間がある，成型条件が悪いのかムラがある，全体的に厚ぼったい，ビスを隠そうとしない上，そのビスがまたとても格好の悪い色や形をしていて，安っぽいのです。
　ACアダプタもトランス式で，非常に大きいです。はっきりいって邪魔な大きさです。

・結構吸い込む
　ハンディクリーナとしては十分な仕事をします。ハンディクリーナといえば，先端のゴムへらやブラシで舞い上げたホコリを吸い込むもの，という印象が私にはありましたが，Z-PV1000について言えば，ちゃんとホコリを浮かせて吸い込む力があります。
　私にとって重要な，ハンダくずの吸い込みも問題なしです。ただし，吸い込み口が小さいので，大面積のゴミを吸い込むのは，取り回しの大変さと相まって苦手です。
　強弱の切り替えがありますが，普段は弱で十分，ここ一番で強にするという使い方が私の場合はよいと思いました。

・結構ゴミが早くたまる
　ダストボックスの中心部には大きなフィルタが取り付けられていますが，このためゴミが実際にたまる空間は結構小さいです。だからちょっとゴミを吸い込むとすぐにいっぱいになります。
　ゴミがたまってくると吸い込んだゴミがノズルから出てきてしまいますので，こまめにゴミを捨てる必要がありそうです。
　
・結構ゴミ捨てが大変
　そのゴミ捨てですが，これだけが気に入りませんでした。ダストボックスの横にあるフタを開けて捨てるのですが，ふたの開く角度がちょうど90度しかなく，ゴミがフタにかかってしまいます。
　また，ゴミ箱にフタにぶつからないように注意していると，思わぬ所からゴミがこぼれてしまいます。細かいホコリもダストボックスの縁に付着しますし，ゴミ捨てがとにかく嫌になる機種だと思います。

　とまあ，GMやクライスラーが丸っこい小さい車を作ったような，そんな無理矢理な感じがなきにしもあらずなZ-PV1000ではありますが，そこはアメリカンV8の国,
ストイックな電動工具のDNAを受け継ぐだけに，実用性という点における欠点は見あたりません。

　国産品の細やかな配慮を期待するのはそもそも難しいと理解しながら，このかわいらしいデザインに惑わされないように実直に使いこなすことを前提におけば，これは優れたハンディクリーナと言えるでしょう。少なくとも私にとって，使っていて楽しい製品であることは確かです。

　普通の家電メーカーが掃除機の小型版としてハンディクリーナを作るのと，ドリルなどの充電式電動工具の派生としてハンディクリーナを作るのとでは，こんなに違うものなのかと感じた次第です。

　先日，MakeTokyoMeeting04を見学し，Maker達の熱意にずいぶん影響を受けたのですが，ともあれGPS Laboさんでわけて頂いた，GPS時計プログラムを書き込んだATtiny2313を生かさねばなりません。

　とにかく簡単に試せるという事で，MTM04の直後にGPSモジュールを秋月電子に手配を済ませてあり，翌週の土日から検討に入っています。

　LCDは昨年の今頃，大阪のデジットで入手した大型のLCDモジュールを使う事としましたが，予想通りあっさり動いてしまいました。

　元々，PICをアセンブラで使い慣れている私としては，個性の強いMSP430やPSoCならまだしも，個性の弱いAVRを今さら使うのもどうかなあ，と感じて試す気にならずにいました。

　ところが，GCCが使える（つまり無制限で優秀なCコンパイラが使える）ことと，tiny2313であれば秋月価格で1つ100円と圧倒的に安いことが私にとっては強烈な個性に見えて，軽く遊んでみることにしました。幸いライタは昨年のデジット詣の際に購入済みです。

　GCCが使えるという事から，プロセッサのアーキテクチャが無個性であることがうかがい知れるわけですが，逆にPICでは個性が強すぎてGCCをインプリ出来なかったわけですね。先日も話していたのですが，PICは「クセの強さをアセンブラで味わうマイコン」です。

　開発環境であるAVRstudioも使いやすいですし，tiny2313はちょっとメモリが少ないですが，最大20MIPSという高速処理と，レジスタと内部メモリが1クロックアクセス出来る事もあり，プログラムを作る上で速度低下に気をつけながらコードを書かずに済むため，コンパイラ任せでも精神的に随分楽です。

　わずか100円で20MIPS，豊富なI/OポートをCでグリグリ動かせますから，もうPIC18F84とはおさらばです。ということで，すっかり私はAVRのファンになってしまいました。

　AVRを使うと決めた以上，いろいろ試しておきたくなるのが人情というもので，USIという原始的なシリアルインターフェースモジュールを使ってSPIを実現する（8MHzのクロックで4MHzの転送クロックが出せます）プログラムや，LCD関連のライブラリをひと通り準備しました。

　これは，MacBookPro上にSunのVirtualBoxという仮想マシンを入れて，Windows環境が実現出来たことが随分大きいです。後日書こうと思っていますが，このVirtualBox，かなり出来がよいです。無償ですが，有償の仮想マシンを買う必要を全く感じません。

　余談ですが，x86には仮想マシンを実装するにはやや問題があり，普通に仮想マシンを実装しようとしてもパフォーマンスががた落ちになり，うまくいきません。有償の仮想マシンとして有名なVMwareはこの問題をうまく解決したソフトとして知られていますが，Core2Duoなど仮想マシンを前提とした新しいx86であれば，あまりおかしな事をしなくても仮想マシンをちゃんと実装出来ます。だから，無償の仮想マシンでもなんら問題はないというのが，私の考えだったりします。

　実際の所，VirtualBoxがどうやっているかはわかりませんが，仮想マシンを支援するハードウェアを使うかどうかのオプションがあるので，少なくともパフォーマンスへの貢献はあるのでしょう。

　話が逸れてしまいましたが，開発関連ツールはWindowsが前提なだけに，自宅にまともなWindows環境が手に入ったことはとても大きなことで，今回のAVRを楽しむことだって，その恩恵だと思います。

　それで，GPSクロックですが，どうもうまくありません。

　GPS Laboさんは，処理などに時間がかかり，表示された時刻が正確な時刻ではない，という話をされており，これをきちんと表示させるには1PPSの信号のあるGPSモジュールを使うしかない，といわれていました。

　実際，平気な顔をして1秒くらい表示が遅れています。いかにGPSが原子時計の精度を持っているといっても，表示が1秒もずれたら，正確な時計としては存在価値がありません。

　GPS Laboさんのソフトは，時刻情報の含まれているGPGGAセンテンスを割り込みで一気に80バイトのバッファに取り込み，その後文字列から時刻情報を抽出し，JSTに変換してLCDに転送する仕組みです。初期設定が終わったらひたすら空ループを回すのが，main()の中身だったりします。

　それはそれでいいのですが，割り込みは出来るだけ軽く，という考えからすると，時刻情報の抽出やJSTへの変換，LCD表示などはやはりmain()で処理したいところです。ごく普通に，UARTからの割り込みで1バイトをバッファに取り込む，という処理だけを割り込みで行うと，1センテンスの取り込み完了を待たずに続きの処理が出来る事になるので，表示のアップデートにかかる時間が短縮されて，表示の遅れが小さくなりそうです。

　そこで，UARTの練習も兼ねて，プログラムの書き直しをしてみることにしました。センテンスの処理を行って時刻情報を抽出する部分は流用させて頂きますが，それ以外は他の方のコードを参考にするか，自分で作るかします。

　UARTから受信割り込みがきたら，割り込み処理の関数で1バイトをリングバッファに取り込み，ライトポインタを進め，割り込みから復帰させます。

　main()ではループのなかで$をリングバッファからサーチし，以下に続くGPGGAが見つかったら，続けて取得した文字列をデコード，時刻情報を取り出しJSTに変換，LCDへの転送を行います。

　リングバッファは1センテンス分というより処理が間に合うだけという感じですので，当初は64バイトを確保しました。

　また，ついでにGPRMCセンテンスから日付情報も取得するようにしてみました。

　ところが，これでもやっぱり遅れます。考えてみると，UARTから80バイトを取り込むのにかかる時間は多くても100ms程度ですから，これをゼロにしても，1秒の遅れが解消されるわけではありません。なにが原因なんだろう・・・やっぱり1PPS出力がないとダメなのでしょうか。

　GPSモジュールとしては，MNEA-0183で送り出す測位情報を外部のマイコンで記録してくれることを期待しているわけですから，必要なのはその測位を行った時刻が正確であることです。リアルタイムで正確な時刻を吐き出すことはしていなくても当然です。だからGT-720Fを使う限りは，もう無理なのかなあと思ったのですが，あきらめずにもう少しだけ頑張ってみることにします。

　GT-720Fには，ボーレートを変更するためのツールがあります。9600bpsではなく，これを38400bpsにすれば1センテンスの受信にかかる時間が1/4に短縮されます。

　ということでいろいろツールをいじっていると，別の端子から専用のパルスを出すのとは違いますが，UARTへの出力を1秒で正確に出すことで1PPSが可能になったり，測位を1秒に2回とか4回といったように，測位周期を変えるたり出来ます。また，送り出すセンテンス種類を制限したり，それぞれの送信頻度を調整できたりします。

　タイムゾーンの設定が出来るとJSTへの変換もいらなくなるのでいいなと思ったのですが，設定を行っても反映されないようなのであきらめました。

　これらの設定をいろいろ試行錯誤したところ，AVR側の処理速度と受信バッファの大きさから，38400ボーでは取りこぼしが起きています。64バイトの受信バッファでは，あと数バイトたりない感じです。

　悔しいので，96バイトまで増やすことにしました。

　64バイトだと，リングバッファを実現するのに，リードポインタもライトポインタも0x3fでANDするだけでサイクリックに回せるのですが，96では真面目に96になったかどうかを判定し，真ならゼロにリセットという処理をせねばなりません。せっかくボーレートを上げても，処理が増える事で速度低下が起きるようなら本末転倒ですが，まあやるだけやってみます。

　また測位周期は1秒に1度から1秒に2度にします。これまでは1秒に1度しかGPGGAセンテンスが飛んでこず，よって1秒に1度しか表示が更新されないことになるので，表示のズレが1秒くらい出てきてしまうことは避けられないように思いました。

　しかし，1秒に2回にすれば，500msごとにGGAセンテンスが送られてきて，表示も1秒に2回更新されることになりますから，GPSモジュールが本当に1秒未満のズレで時刻を送ってこなければ，表示のズレは500ms以内に収まるはずです。

　さらに，処理を軽くするために，GPGGAとGPRMC以外のセンテンスの送信を停止し，さらに日付情報が欲しいだけのGPRMCセンテンスの送信頻度を10秒に一度にします。こうすると，GPGGAが運んでくる時刻情報が他のセンテンスに邪魔されず，1PPSを守って送られてくると考えたのです。

　また，AVRの処理速度を根本的に向上させるため，これまで内蔵クロック8MHzだったものを，外部クリスタルによる20MHz駆動としました。UARTのボーレートも正確になり，一石二鳥です。

　そんなこんなで，こんなコードになりました。

続きを読む