心電計プロジェクト：表示部の詳細設計とインターフェースに悩む

心電波形表示の擬似コーディングを始める(10/20/2014)
　長い間道草を食ってきたが、やっと心電計の波形表示部の詳細設計まで来た。それにしてもこのプロジェクトは遅れに遅れている。始めたのが6月だから、もうそろそろ半年近くになる。オシロで波形を見たのが7月なのに、これをARMで液晶表示をしようとしてから事が進まない。

　ARMの開発環境の整備から始まり、TFT液晶が動きだすまで、基板を買い直したりして2ヶ月もかかってしまった。どうも最近は集中力が落ちている。PCに向かってもすぐ設計に入れず、ついWindows7に入っていた無料ゲームで時間をつぶしてしまう。効率がガタ落ちである（スパイダーソリティアの中級がとても難しい。最初は20回に一回もクリアできなかった。現在は、勝率10％）。

　まあ、繰り言を言っていても始まらない。TFT液晶は何とかカラーバーまで出たので、これでやっと波形表示のソフト開発に入れる。心臓パルス波形をオシロスコープのように折れ線グラフで表示するところだ。

　オシロスコープのロジックは、難しいことを言い出せばきりがないが、基本原理は簡単だ。対象測定値の変化を時間単位に点で表示し、これを連続的に出して画面の端に来れば再び同じことを繰り返すだけである。

　単位時間が短くなり、一秒の1/1000(ミリセカンド)、1/100万（マイクロセカンド）の世界になれば、どのタイミング（トリガー）で、どれだけのデータ範囲を画面に描画するかなどとなると、とたんに難しくなるが、幸い、心臓の鼓動は1秒程度の非常に長い周期なので、そういう気遣いはいらない（はずだ）。

　こんどの液晶の描画単位は240X320ドットである。これを横に使い、300ドットの間を2秒程度でポイントを打ち終えれば、元に戻ってポイントを打ち直す。そのとき前に描いたポイントを消していく。この繰り返しで心電図の波形が表示できるはずだ（ほんとうか）。

　こういう描画で一番面倒なのが、この折れ線グラフよりむしろグラフのスケールや、数値の表示である。このあいだのグラフィック気圧計でも、プログラムの殆どの手間は、縦横の線や、日付の表示にかかっていた。

　オシロスコープのソフトは、ネットのあちこちで紹介されているようだが、見ないことにしている。困ったときは頼りにするつもりだが、初めから見てしまうのには抵抗がある。見たことでそれに縛られたくない。少し意地になって独自開発を目指している。

　印刷の裏紙にメモを書き散らし、イメージを膨らませながらプログラムの骨格を作り始めた。表示だけならどうと言うことはない。問題なのは、センサー部から送られてくるデータを取りこぼしなくいかに表示部に送るかというインターフェースの部分である。

TFT液晶基板の実装版は簡単に動いた(10/27/2014)
　その矢先、親戚に不幸があって丸々一週間の間が空いた。この間、関西を2往復した。年も年だったし(80才)、長い闘病の末だったので覚悟は出来ていたが、亡くなったのが兄弟の中で一番仲の良かった長姉だったので少し精神的に参った。

　何もしていないと次から次に思い出が湧き出してきて気持ちが沈む。それを拭っ切るために、少し無理にでも電子工作に気持ちを向けることにした。関西から帰ってきて工作机を整理していたら、TFT液晶基板の実装がまだ済んでいないことに気付いた。

　TFT液晶の接続は、このあいだ買ったスルーホール用のジャンパーによる仮接続で、このままにしておくわけにはいかない。それに、センサー部のディジタルフィルターのマイコンTiny861もブレッドボードにささったままだ。まずは、液晶基板の実装をやることする。

　実装を先延ばしにしていたのは、レイアウトに迷っていたからである。ウェブなどの作例を見ると、こうした液晶画面の実装は殆どは、基板の上に重ねていくスタック構造が主流で、この前のグラフィック気圧計もそうなっている。

　ケースのことまで考えると、コンパクトにするためには必然的にこの形になるのだが、もうちょっと面白い実装はないか色々調べていた。しかし良いヒントは得られなかった。

　結局、芸のない話だが前と同じスタック方式で、CPU基板の上に主基板を載せ、その上にTFT液晶を載せることにした。早速、両面の汎用基板を切り出す。前と同じスタイルなので作業に迷うところは少ない。

　少し工夫したところは、普通のピンヘッダーとソケットでは背が高くなりすぎるので、TFT液晶と主基板の接続を背の低いICソケットピンにすることにしたところか。ピン側は、秋月が最近売り出した「細ピンヘッダー」を使った。

　これで今までのスタック基板が何となく間が抜けた感じだったのが、少し引き締まったスタイルになった。それに、この種のピンヘッダーは高価で使いにくかったが、これは安いのでお財布にも優しい。

　3時間で15本(30個所)の配線が済んだ。ショートだけしていないことを確認して通電。あっさり動いた。まあ、ロジックも何もない、コネクターとピンの間をつなぐだけの作業なので造作がない。

詳細設計を進める。インターフェースが難しい(10/29/2014)
　問題のインターフェースの設計である。これまでのセンサー部と、表示部のインターフェースを具体的に決めなければならない。その前に電源だ。センサー部は生体に接続するので、万が一を考えて電池で駆動する。表示部はACアダプターかUSB経由で電源を供給し、センサー部とはフォトカプラーで絶縁する。

　インターフェースのプロトコルである。I2Cは既にDACで使っていて開発が不要だが、こいつは絶縁が簡単にはできないのでパスである（双方向で動く必要がある）。無線のXbeeが一番スマートなのだけれど、今のところストックがない。

　これも、あれこれ迷って、とりあえずはUARTでフォトカプラー経由でつなぐことにした。受信はいらないので、送信だけの1チャンネルで良い。

　送出データは最初、保守性を考えてキャラクターで送ることを考えていた。しかしキャラクターにすると3バイトが必要で、38400bpsの速度（当研究所のUART標準）では、センサー部の最小サンプリング単位625μsを軽くオーバーしてしまう。

　画面表示は早くても数十msのオーダーなので、平均化などして送出単位を延ばせばよいのだが、このあたりの調整は表示部でやりたい。ということになると2バイトバイナリで送るのが順当なところだろう。

　読み込みのロジックは結構面倒だ。受信は、UART受信割り込みでデータを取る予定なので、2バイトづつで1ブロックのデータを識別する必要がある。姑息な方法だが、フラグを立てて、最初のバイトと、2番目のバイトを区別する方法に決める（最初のデータを落とすとおしまいだが）。

　画面表示のタイミングは独立したタイマーの割り込み（正確な時間表示のため）とし、センサー部からの数値データの受信とは非同期にする。こういうところの設計はなるべく独立して動くようにしておくのがコツといえばコツである。

　こうしておくと、プログラムの開発が別々に出来るし、いわゆる丈夫な（Robust）なプログラムになる（バグや変更に強い）。プログラムの構造は決して簡単にはならないし、ステップ数も多くなるが、独立して動くようにしておく方が、保守性は高い。オブジェクト指向と同じである。

　描画のタイミングを確かめておく。画面には2周期くらいの心電波形が出るようにして、一画面300ドットが2秒、1周期なら1秒。1ドットの描画タイミングは、33～66msと極めて長い。これに対して、センサーからは、最速で0.625ms単位にデータが送られてくる。

　たまたま読んだ1つだけのデータをそのタイミングの値にするのでなく、平均値を計算しておいて、それを使うべきだろう。タイミングがずれた時や、バッファーの書き込みと読み出しはどちらを優先するかなど、決めておくことが多い。なかなか具体的なコーディングには入ることが出来ない。

フォトカプラーの道草。TLP552はぶっちぎりに早い(11/2/2014)
  そんななか、また本題とは関係ないところで脱線してしまった。今度はフォトカプラーである。センサー部と、表示部の間の絶縁をする、UARTのフォトカプラーの選定で道草を食ってしまった。

　まず、実際の38400bpsのUARTに試しに手持ちの汎用カプラーPS2501を入れてみた。全く動かない。オシロで波形を見る。細いパルスは出ているが、UARTの波形の形を成していない。出力側の負荷抵抗や、入力LEDの制限抵抗を少しいじるが全く効果なし。やっぱりだめか。

　このまえのウェブカメラの駆動部ではRaspiの間でフォトカプラーを使ったが、これは単なるスイッチ入力なので速度は関係ない。そういえばフォトカプラーでUARTをつなぐのは始めてだ。どの程度のUART速度が良いのか。汎用カプラーでも、立下りは25μsなので、40Kbpsくらいまで行くはずなのだが何故通らないのだろう。

　急に、このあたりを調べたくなってきた。高周波パルスなら、自作したシグナルジェネレーターが20Mhzまでの矩形波が出せる。こいつでフォトカプラーを通してみれば一目瞭然だ。でもそのうち、シグナルジェネレーターの出力ではフォトカプラーを駆動できないことに気づいた。

　今までだったら、ここで諦めているところだが、電子工作歴も7年となると色々な手を思いつく。よせば良いのに、ついこれまでの経験を生かしたくなる。オペアンプで増幅し（AC 1VをP-P　5VのDCにする）、ボルテージフォロワーで受ければ、LEDぐらいは動くはずだ。

　思い立つと、矢も楯もたまらなくなってしまう気質だ。早速、試してみる。2倍程度の反転ACアンプとボルテージフォロワーの組み合わせをブレッドボードにでっちあげる。意気揚々とテストに入った。うむ、LEDを点灯させても波形が出ている。良いぞ。

ところが周波数を上げていくと波形が崩れてきた。矩形波が三角波になり最後は消えてしまう（DCになる）。何い、常用のオペアンプLM358ではそもそも10Khz以上を増幅できないのだ。ええー、オペアンプってこんなに遅いの？

　そうか、音声周波程度までしか動かしたことがなかったか。しかし、オペアンプなら手持ちは他にも沢山ある（計装アンプまである）。ただヘッドアンプ用が多いので高周波に使えるかどうか。それに、両電源でないと性能を発揮しないオペアンプもあったはずだ。

　自信はなかったが、とりあえずは、レールtoレールのLM6428で試してみることにする。これは確か高周波にも強く、単電源でも動く。ブレッドボードなので交換はいとも簡単で差替えるだけである。

　おーし、LM6428ならMHzレベルも余裕でOKだ。これでMhzオーダーの対LEDパルスを出す装置が完成した。喜び勇んで、手持ちのフォトカプラーを片っ端から動かしてみた。

　結果、PC817, PS2501、TLP521のような汎用カプラーは、9600bpsがやっとである。10khzを越えると、長いturn off時間で次のパルスと一緒になってしまい、元の波形とは似ても似つかない形になる。

　では、かねて用意の高速フォトカプラーTLP552(￥200)ではどうだろうか。このフォトカプラーは、以前FETスイッチを作るためにサトー電気まで行ってフォトボル（TLP590B）を買いに行ったとき、何かの時にと買ってあったものである。DIP8ピンだが、一回路しか入っていない。データシートを見ながら通常のフォトカプラーと違う結線をする。

　動かしてみた。何と、こいつはすごい。オペアンプもMHz近くなると矩形波がなまってくるが、これを見事にカバーして楽勝でパルスを伝達する。10Mbit/sの性能は伊達ではない。この急ごしらえのパルス発生装置では上限を測れなかった（オペアンプの方が降参する）。ただし、パスコン(0.1μF)を入れないと確実に発振する。

別のフォトカプラーTLP512を調達(11/5/2014)
　しかし、このTLP552は１個￥200（千石では￥242）と汎用カプラーに比べれば、5倍近いコストである。それに10メガビットオーダーまで動くというのに、この程度のものに使うのにはちょっともったいない。どうしようかと迷っていたら、サトー電気のウェブサイトで、TLP512という高速カプラーが￥140で出ているのを発見した。

　こいつは1Mbitまで動くとあるので、38400bps程度のUARTの接続にはぴったりだ。値段も半分とは言わないが大分安い。脱線につぐ脱線だが、こうなるとどうにも止まらなくなる性質で、手に入れたくなった。

　次の日、車で環七を南下して久しぶりにサトー電気の川崎店まで足を延ばす。片道20キロ。ガソリン代を考えたら通販の方が安いと思うが、ま、ドライブのつもりなら腹も立たないと自己正当化する。せっかくなので10個手に入れた（このあたりは生産停止が多いので買い置き）。

　ついでに欲しかったシングルチャネルのインバーターTC7S04Fも10個買う(10ケで￥500　これも生産停止品)。高速で正負論理を切り替えたりするときに、トランジスターでは遅すぎ、インバーターICを1回路だけ使うのも大げさな時に便利である。それに、今度の高速カプラーは論理反転してしまうので、必要になるかもしれない。これはSOT23-5の小さなチップだが、変換基板があるので怖くない。

　帰って、早速、TLP512のテストをした。うん、38400bps程度では全く問題ない。115200bpsあたりになると少々怪しくなるが、ほぼ、問題なくパルスを通した。DIP6ピンなので、TLP552より小さくできる。これでUARTを絶縁するフォトカプラーの準備が出来た。

モニター用のISP-UARTが動かない！Tiny861のバグか？(11/8/2014)
　フォトカプラーの実験はそろそろ切り上げて本来の工程に戻ろう。ブレッドボードにささったままだったセンサー部のディジタルフィルターのTiny861の実装である。

　アナログアンプの基板には既にスペースは確保してある。つけるパーツは殆どない。単にISPピンを立てて、それぞれの入出力（アナログ入力、UART出力）をつなぐだけである。フォトカプラーのスペースも空けておく、今後の改造(Xbeeを追加したい)にそなえて、Xbeeチップの場所も考えながらレイアウトする。これも特記することもなく順調に終了した。

　このあとの地獄が待っているとも知らず、鼻歌混じりでソフトの開発に移る。インターフェース部の通信インターフェースの開発である。これまでは、モニター用のUARTと、I2Cだったが、今度は、UART２つになる。

　Tiny861はハードのUARTを持っていない。2つのソフトUARTを用意しないといけない。当然のように、モニターには、ISPケーブルだけで動くISP-UARTをテスト用に入れ、これまでコンソールに使っていたバッファー付きUSI-UARTをデータ転送用に移すことにする。

　まずは、AVRSPのプログラマー経由で動くISP－UARTの組み込みである。AVRを始めて以来、何十回も繰り返した手順だ。ソースコードの最初の開発日付は、7年も前の2007年から始まっている。ChaNさんオリジナルのUARTモニターにピンチェンジ割り込みの受信ルーチンが追加されたものだ。

　バージョンも、ChaNさんのアセンブラーが残っているソースから、最近のCのライブラリで統一したバージョンまで沢山ある。最新のバージョンを選んでライブラリを取り換え、テストする。

　これがウンともスンとも動かないのだ。おかしい、何も変わったことはしていない。とりあえずオシロで送受信波形を調べる。なにー、PB1(ISPではMISO)から何も波形が出ていない。PB0はPCコンソールからの入力なので波形が見えるの当然で、ピンチェンジの割り込みは入っているようだ。

　ISP-UARTは、リセットピンがenableのときに動く特殊なUARTで、PB1はプログラムをロードするときは派手に動いているのでハード的には問題ない。しかしUARTとしてPB1を使おうとすると最初に一回パルスがでるだけで動かない。UART関数の送信ピンをPB1ではなく、PB2やPB3にすると問題なく送信波形が出力される。？？？である。

　以前、リセットピンとグランドの結線を間違えて同じような現象で悩んだことがあったことを思い出し、何度も配線チェックをするが、間違っていない。プログラムのバージョンを取り換えたり、最初のChaNさんのソースまで戻ったが、動かない。

　念のためにCPUチップを取り換えたが、もちろん同じ状況である。もう調べるところがなくなった。途方に暮れる。ISP-UARTが動かなくても大勢には影響しない。ただでさえ遅れているのにこれ以上遅らせるわけにはいかない。結局、諦めた。

　普通のGPIOのUARTに切り替える。何という事もなく動いた。モニター用のUARTピンを追加しなければならなくなったが、それだけのことだ。しかも、このUARTは本番時には使わない、やれやれ。Tiny861のバグは、まあ考えられないだろう。どこかで勘違いをしている可能性が大きいが、とりあえずは、このあたりでブログの記事を上げることにする。