心電計プロジェクト：表示系工作の道のりは遠い

　心電計プロジェクトは、オシロスコープでやっとのことで心電波形を見ることが出来たあと、例によって一気に気が抜けた。さらに、珍しく仕事の依頼が来て久しぶりに調査データの分析をしたり報告書の下書きをしたりしていた。月末には、新しく加わった家族と一緒に何年かぶりの墓参りで関西に帰省した。電子工作をやる時間がない。ブログも一か月ご無沙汰だ。

　とはいえ、このブログは備忘録も兼ねている。年ごとに短期記憶力が失われているのは確実で、こうした記録は欠かせない。時々、日記やブログを読み返しては自分の現在位置というか立ち位置を確かめている。不思議なことに読むたびに何か安心する。みなさんはどうなのだろうか。

　ということで、少し脈絡に欠けるが電子工作を含めたこの一か月の出来事を時系列でご紹介する。

表示系のプラットホームにするARM基板が多すぎて困っている(8/1/2014)
　それにしても懸案の心電波形がオシロで見えた時は本当に感激した。プロジェクトの開始は6月初めだから期間としては2ヶ月経っていない。FPGAでフォトフレームを作ったときは画像が出るまで半年以上(7か月)かかっていた。それに比べれば短いけれど感動の大きさはあまり変わらない。

　今まで、とても手が出ないと思っていた生体系の微弱電圧をアナログアンプとディジタルフィルターで捕捉して、とにかくそれらしい脈拍波形を自作機器で捉えることが出来たのだ。この先は、脳波（EEG）計測や筋電流によるロボット制御などの道につながり、アプリケーションの範囲は無限に広がる。

　プロジェクトの次のステップは第4ステップの心電波形表示部の開発である。こちらは勝手知ったデジタル系なのだが、着手する意欲はすぐには生まれない。地下の工作ルームでやることと言ったら、両腕に電極を当てて波形を出るか確かめる再現テストだけである。よーし、何度やっても同じ波形が出る。間違いない、自分の心電波形だと悦に入っている。情けないことだ。

　手がすぐに出ない理由はもうひとつある。映像を出すCPUチップを何にするか迷っている。画像表示装置は、このあいだAitendoで2.4インチTFT液晶モジュール(2P-CP2401T-C ￥1650)を用意したが、CPUチップが悩ましい。

　BeagleBoneBlackや、RaspberryPiでは少し重すぎる。手慣れたAVR(先日、秋月で買ったMega1284あたり)が楽なのだが、mbedを含めたARM系のCPUの積み基板が手元に溢れているのでこれを消化しておきたい。

　というのも、このところのARM系マシンの進化の速度が激しく特に開発環境はちょっと目を離しているすきに完全な浦島太郎状態になってしまった。この機会に何とかキャッチアップしておきたいという目論見である。

　それは良いのだが、心配なのは手持ちの評価基板は数はあるけれどみな少々時代遅れになっていることだ。果たして最新の開発環境で動くのか不安である。部品箱にある積み基板の数々を棚卸してみた。

　まず最新（ここでは）のチップのF4discovery評価ボード(STM32F407)は、とんすけさんの例のAudio　Visualボードになってしまっているので使いにくい。雑誌付録のLPC2388はFreeRTOSの実験ボードのままである。RasPiの導入でこのリアルタイムOS応用の意欲は失せているのだが、このボードには苦労して開発したLANポートが載っているので、これを無駄にしたくない。

　mbedも大分前にStar Board Orangeというマザー基板を手に入れてある(￥1400)。これにはSDカードスロットやLANのモジュラーまでついているので、心電計のようなスタンドアローンの機器にするのは勿体ない。

　F3discoveryという評価ボードもある。これも未使用だが、これには3軸加速度センサーがついており、これが無駄になる。さらにFM3、RX61などの32ビットプロセッサーも手つかずで余っているが、開発環境の整備を考えたら先が長くて手が出しにくい。

　というわけで、結局、候補として残るのは、昔、CQ-STARMと言われる基板から剥がしたSTM32F103チップだけである。これをAitendoの生基板（余分に買ってあった）につけて、これまで開発したグラフィック気圧計と同じ形にする。この石はフラッシュが128K、SRAMが20Kしかないのでちょっと不安だが、心電波形の表示くらいなら何とかなるだろう。

　それにしても、ARMの開発環境やプログラマーは、ちょっと見ないうちに大変化を遂げていて何から手を出せばよいのか見当がつかなくなっている。せっかく買ったOlimexのJTAGドングルは使えるのだろうか。ハードの工作よりこのあたりの開発環境の勉強の方が課題である。

Window7にしてAVR開発環境づくりにひと苦労(8/3/2014)
　心電図プロジェクトの合い間に、このあいだから始めていたメインPCのXPからWindow7への更新が片手間ではすまないくらい大変になってきた。このWindow7は仕事の友人からマシンごと無償で譲り受けたもので、CPUは少し古いがCore2Quad6600という4つもCPUを持っている高性能マシンである。

　いまどきWin7への更新の話をするなど笑われるだけだが、このブログをお読みの皆さんならご承知のように、所長は一旦うまく動いた環境は余程のことがない限り使い続けるのが基本方針である（問題なく動いている環境を変えるのは無駄以外の何物でもない）。いくらサポートが切れても、WinXPを止める気は全くなかった。

　それがどうして更新することになったか。理由は簡単で、使っているWinXPマシンが壊れてしまったからである。これまでのWinXPマシンは、Athlon64の自作なのだが、大分前からブート直後にマザーボードのCPU温度センサーが誤動作して警報ブザーで止まるトラブルがたまに起きていた。

　だましだまし使っていたのだが（立ち上がれば全く問題なし）、そのうちこの暑さでとうとうビープ音（ピーポーピーポーという間抜けな音）が何をやっても止まらなくなり、仕方なくWin7に切り替えた（チップの中の故障なので修理は殆ど不能と思われる）。

　最初は、XPマシンからDASD一式をこのWin7マシンに接続し、少しづつアプリケーションを移していたのだが、段々手がかかるものが出てきた。特に、AVRの開発環境は難航した。今まで何の不都合を感じなかったので、AVRStudioは4のままだったし、プログラマーも7年前にChaNさんから頂いたAVRSPだ。フラッシュが少ないので書き込み速度が少々遅くても痛痒を感じなかった。

　AVRの開発環境もARMに負けずに大きな進化を遂げ、AVRStudioもATmelStudioと名前まで変わってしまっている。せっかくなので更新することにする。インストールは特に何ごともなく成功した。Look&Feelは全く以前と異なっている。しかし、ソフトの立ち上がりが遅い。調べてみたら昔、重いことで評判だったVisualStudioがベースになっているという。遅いはずだ。

　動作テストをする。プロジェクトの作成は順調に行き、コンパイルまで行った。prog_chrがないと叱られたのはご愛嬌でこれは数年前、ばんとさんが報告されていた。その通りにして無事コンパイルも成功した。

　しかしこのあとが大変だった。何と頼みのプログラマーAVRSPが動かないのである。このAVRSPは、Mega328が動かなかった時、BorlandのBCC5.5でコンパイルし直したものだ。DLPORTIO.DLLがないのでコンパイルし直せというエラーメッセージである。もう一度作り直す気力はない。

　オリジナルを持ち込んでみる。こんどは「giveio.sys」がないと怒られる。ふーむ、ウェブ情報では、さすがにWindow7ではgiveio.sysはサポートしていない。あきらめきれず、サイトをさまよっていると、-pvオプションで動いたという報告を見つけた。オリジナルのreadmeには、このオプションはUSBでは死ぬほど遅くなるということなので試したことはない。

　しかしreadmeを読み返していると、pvオプションは、単に、ポートIOをAPI経由か、ダイレクトかを区別するだけのオプションに思える。それなら、レガシーのCOM1を通すのに-pv1とすれば、良いのかもしれない。早速試してみる（幸い、Win7マシンにはCOMポートがついていた）。

　あたったー、これだー。今までと全く変わりない速さで、AVRSPが動いた。プログラマーは純正のDragonも持っているし、そろそろAVRISPmk2を買おうかと思っていたのだが、その必要がなくなった。これはありがたい。

　AVRSPにこだわるのには理由がある。当研究所のAVRプログラムはAVRSPの機能を使ったUART、ISP-UART（と勝手に呼んでいる）を使ったシステムが多く、AVRSPが動かないのは、前のシステムを検証することが出来ないことになる。動かしておきたかった。

Window7で失ったレガシー機器(8/7/2014)
　FPGAの開発環境や、ARMの開発環境Eclipseなどは、ちょうど良い機会なので、新しいバージョンを改めてインストールしなおすことにしている。これは使うときにやれば良い。ところが、もっと重大な問題があることに気が付いた。

　これまでにもご紹介した通り、所長は年期の入った飛行機マニアで、PCのフライトシミュレーターの操縦用に、本格的な、ペダルと操舵ハンドルを所持している（最近はめったに遊ばないが）。これらの機器のインターフェースはUSBではなく、昔のサウンドカードに必ずついていたMIDIやゲーム機器とつなぐgameport（DSUB15ピンのアナログインターフェイス）である。

　MSの少し古いフライトシミュレーター（FS2004これが一番充実している）は幸いWin7でも順調にインストールが出来たのだが、このgameportのサポートが、WindowsVISTA以来、切れていることに今さらのように気づいた。フライトシミュレーターの醍醐味は、キーボードでは味わえない。

　USBで動く同じような機能を持った機器が売り出されているので、これを買えば良いのだが、前とほとんど同じ機能のハードをもういちど買い直すのはいかにも無駄で、そんなことはしたくない。

　最初、gameportとUSBとの変換アダプターがあると思って、ウェブで検索したら、日本ではもう売っていないが、アメリカのアマゾンで売っているのを発見した。喜び勇んで、アメリカAmazonの会員登録をして、これを買おうとしたら輸出禁止製品にひっかかった。

　フライトシミュレーター関係の機器は、どうも311テロ以来うるさくなっているようだ。あの時のテロリストはMSのフライトシミュレーターでジェット旅客機の操縦に熟達し、実機を簡単に操縦したと言われている。

　何かほかに手がないかウェブで探し回った結果、アメリカの好事家（日本人二世か、Daniel Kawasakiという名前）がハードのドライバーを開発して、Creative（サウンドカードの開発元）のフォーラム上で公開したらしいが、すでにリンクが切れ、現物を手に入れることはできない。

　Creativeフォーラムのメンバー登録までして、このドライバーの行方を追っかけたのだが、どうしても見つけられなかった。このほかにもサイドワインダーというMSのジョイスティックのゲームポートインターフェースをUSBに変換するマイコン基板の自作ページというのがウェブ上にあり、AVRチップ（Atmega32U4らしい）を使う。

　これにも強い魅力を感じたが、こちらの手持ちディバイスCH-Productの製品がこれで動くという保証は全くない。これもあきらめるしかない。とにかく、ここ暫くはフライトシミュレーターで遊ぶことが出来ない。残念である。

ARM基板に入れるUARTコンバーターの移設でまた道草(8/16/2014)
　心電計プロジェクトの第４ステップ、表示系の基板は、結局、一番古いSTM32F103（CQ-STARMについていた石）を、AitendoのSTM生基板（気圧計につかったものをもう一つ買ってあった）につけたものにする。これに最近買った2.4インチのTFTディスプレイを載せる。

　ぼちぼち、部品箱から基板やCPUチップなどのパーツを取り出し、制作の準備に取り掛かる。久しぶりのQFP100ピンのCPUのハンダ付けは順調にすんだ。実体顕微鏡の威力を見せ付けられる。この生基板にはシリアルインターフェースのRS232CソケットがついていてUARTドライバーのADM3202チップのパタンがある。

　部品箱には表面実装のADM3202の予備がなかった。必ず必要なインターフェースではないが空きのままにしておくのも何なので、買いなおそうと秋葉原に行ったら秋月がお盆で休みだった。千石でも売っていたが秋月の価格の2倍以上するので買わずに帰ってきた。

　こうなると意地になるのがいつもの癖である。SOPのADM3202なら以前RS232Cのブレークアウト基板を自作したときに使っている。これを強引にはずして、今度の基板に使うことにし、元のブレークアウト基板はストックのDIPのADM3202に付け替えた。相変わらずお馬鹿な工作である。

　ところが付け替えたブレークアウト基板が動かないのである。心電計のUARTでテストしたが動かない。UARTの接続はいつも送信か受信で大騒ぎするのだが（今度も間違えていた）、やっと動いたと思ったら、今度は初期メッセージだけが文字化けする。

　CP2102などのUSB経由では問題ないのに、このRS232C経由だと駄目なのである。納得できない。おかしいのはオープニングメッセージだけで、あとは大丈夫である。ほっとけばよいものを（滅多に使わない）、動かないとなると、（しかも字化けというのが気に入らない）どうにも気になって先に進めない性質（たち）である。

USI-UARTのバグを見つける(8/19/2014)
　ロジアナを持ち出して調べる。あれえ、送信の前に、TXラインに0.1μsほどのグリッチ（細いディップパルス）が出ている。これか。USBのUARTは無視するが、RS232Cではだめなのか。テストに使っている、この心電計のUARTは例の、USI-UARTである。ほっておくわけにもいかない。

　プローブ点を増やして、このグリッチがどこで発生しているのか追求する。調べた結果、おかしくなっているところは何とUSI-UARTの部分ではなくメインプログラムのポートの初期化のところだった。

　PORTレジスターを設定したあと、DDRレジスターを初期化すると、一瞬、DDRレジスターの設定で、値が0になってしまうようだ。へー、こんなことってあるんだっけ。DDRの設定のあとPORTの初期設定をするようにしてグリッチはなくなった。

　これで字化けはなくなったはずとテストする。ところが最初は治ったのだが暫くするうちまた字化けが始まった。ふーむ、これではなかったのか。さらに、しつこく調べる。

　その結果、やっと原因をつきとめた。原因は別のところだった。ロジアナの波形を詳しく調べていて、初期のデータのボーレートパルスが規定より長いことに気付いた。USI-UARTのボーレートはしっかりしたタイマー割り込みを使っているので長さが変わることはないはずなのだが。

　う、待てよ。一文字送信関数では送信バッファーにデータをセットするところは、タイマー割り込みで動くデータを取り出すルーチンとの衝突をさけるため、割り込みを禁止にしている。そうか、この期間が長すぎればタイマー割り込みは待たされてボーレートが長くなってしまう。

　ロジアナで、送信関数の割り込み禁止区間にポートを叩くテストステートメントを入れてチャートをとってみた。見事な波形が出てきた。初期のメッセージが大量にあるときは、ボーレートの1ビットの間に沢山の送信リクエストが集中し、決められたボーレートの20%以上の長さになっていることがわかった。

　原因がわかれば、対処はやさしい。割り込み禁止区間をなるべく短くなるように区間を分ける。今度の場合は2つに分割するだけで、見事にUARTは字化けしなくなった。いやあ、快感である。これだから電子工作はやめられない（このUSI-UARTのソースは公開しているので、もう少しテストをして近いうちに改善版をリリースしたい）。

帰省と久しぶりの仕事でプロジェクトが進まない(8/25/2014)
　電子工作がペースに乗りかけたところでまた邪魔が入った。何年ぶりかの仕事である。政府関係の大型汎用機システムの調査で、NDA（秘密保持契約）があるので、詳細をここで書くわけにはいかないがこれが滅法面白い。昔とった杵柄（きねづか）で心が躍る。

　数値をみては対数グラフにデータをプロットして、全体を確かめていく。仮説にもとづいて、思っていたようなデータが並ぶと、デバッグに成功したような快感を覚える。やっぱり本業（雀の涙のような報酬らしいが）の方が細かい作業をしていても充実感がある。まあ、これは仕方がないか。

　それが一段落して、月末には車で久しぶりに関西に帰省した。目的は、このところさぼっていたお墓参りである。ここ数年で娘たちが結婚し、その連れ合いも同行して4年ぶりの墓参りとなった。新幹線にしなかったのは、現地での足の便と、第二東名を走ってみたかったためである。

　第二東名は140km/hが設計速度ということで、これは実際に走ってみて実感した。実に快適である。ハコもの行政が問題になる以前の着工で、民主党政権時代には過剰投資が問題となったもののひとつだが、走っているだけならこんな快適なことはない。払った税金を取り戻しているような感じで余計気分が良い。

　関西の道路状況も何年か車で走っていなかったこともあって、ずいぶんと進んでいた。京都大阪の間の交通事情は何年か前は、高速は名神一本だけで常時渋滞だったのだが、京滋バイパスや、第二京阪バイパスなどの開通でとても楽になっている。

　墓参りは、気になっていた親戚（世話になった義兄）のところもすませて満足して帰ってきた。しかし、お盆をはずして日程を組んだのだが、帰りは事故が重なった意外な大渋滞に巻き込まれ（沼津の第二東名分岐点あたりから海老名まで連続60キロ近く）、8時間以上かかってしまった。