ＰＩＣ　ＡＶＲ　工作室－＞ＴｏｐＰａｇｅ－＞ＡＶＲの工作－＞ロジアナ

簡易ロジックアナライザー「ネコロジー」

ネコロジーとは

ネコ好きな管理人nekosanが作るロジアナ、略してネコロジーです。最近とあるサイトでＰＩＣを使った簡易ロジアナを見つけ、それに触発されて作ろうと思ったのがこのネコロジー。ロジアナを買うお金がもったいないので、マイコンを使ってそこそこ実用的なものを作ってしまおうという無謀な挑戦です。

普通、ロジアナ作るとしたらやっぱＣＰＬＤなんか使って、考えられる範囲で最大限の速度を追うものだと思いますが、そこを敢えてマイコンで安く仕上げることに挑戦してみるところが私らしいところ。はたしてどうなることやら…

作ろうと思ったきっかけと進め方

何年か前、ＰＩＣというマイコンに出会って、それ以来幾つかのモノを作ってきました。本やネットで開示されているモノも作りましたが、大部分は「アレが欲しい、こんなの作ってみたい」ということからオリジナル品をゼロから設計、製造してきました。

始めたばかりの頃手元にあった工具は半田ごてとニッパー、ミニドリル程度。計測器類はテスターしか持ってませんでした。その後、秋月で小さいオシロ（osziFOXというもの）を買いました。分解能が５０ｎｓ（２０Ｍｓｐｓ）と値段の割には細かいものまで見える代物です。が、内蔵メモリが小さすぎて、ビデオ信号などを見ようと思うと分解能を１０μｓ（０．１Ｍｓｐｓ）程度に落とさないと走査線１本が入りきらないという程度のもの。

テキスト画面表示器を作った際、出力信号が想定どおりに映らなかった時のデバッグに使いましたが、osziFOXではずいぶん苦労しました。まぁ、無いよりはずっとマシなんですが…。

というわけで、以前からロジアナが欲しかったんですが、市販のロジアナはオシロ同様に結構なお値段。私のように趣味でちょっと何か作ろうという人間には無用の長物という気もしてしまいます。

２０ＭＩＰＳのマイコン使えば、２０Ｍｓｐｓとまでは行かないまでもそこそこのものが自作でるんじゃないかなぁ… って思って、処理方式を想像してみたことがあるんですが、私の頭の中で考えていたマイコン使用のロジアナは、「マイコンでデータを入力」→「それを外部のＳＲＡＭに書き込み」→「ある程度データを蓄積するまで繰り返し」、という感じです。処理クロック数をザッと数えると、少なくとも２０クロック程度にはなりそう。場合によってはそれ以上。これじゃぁせっかく作っても、とても実用には程遠いなぁと諦めていました。

ですが広い世の中、簡易的なロジアナくらい作っちゃう人もいるのでは？と思って探してみると、やはりいくつか見つかりました。ただ大部分は「作ることに意義がある」的なもので、動作速度などの実用性という観点では少々難があるものが多いです。

その中で、シンプルなのに極めて秀逸な作りをしたものを最近見つけました。これです。

PICを始めよう「PIC16F648A で作る４CH 簡易ロジックアナライザ」

ＰＩＣ１６Ｆ６４８を使ったロジアナですが、４チャンネルの信号を１Ｍｓｐｓでサンプリングできるとう代物です。ＰＩＣは１命令４クロック必要なので、２０ＭＨｚのＰＩＣで１Ｍｓｐｓということは１サンプルを５クロックで処理しているはず。５クロックでできることとって、結構限られますよねぇ？

今回見つけたこのロジアナ、どこが秀逸なのかというと、マイコン自体が行っている処理が極めて限定されていること。マイコンが行っているのは、ＳＲＡＭに指示するアドレスのセットとＷＥ信号（書き込み可能信号）の操作だけ。データの入力はＳＲＡＭの足に直接繋ぎ、終了条件は外部割込み信号をマイコンに引き込むという仕組み。

なるほどねぇーーーーーー！　この仕掛け、目からウロコだーーーー！　（ソースが公開されていないので想像ですが、回路図と動作内容から考慮するとそうなっているはずです…。）

私は何でもソフトで処理したい人間なので、ついソフトウェアとしてどう処理すればいいのかを考えてしまっていたのですが、そうかぁ、ソフトウェアで何でも処理せずに、こういうふうに外部ＩＣに処理を任せてしまうこともアリなんだなぁ…。世の中広いなぁ。（私が無知なだけ？）

そうなると、５ＭＩＰＳのＰＩＣで１Ｍｓｐｓ出るなら、２０ＭＩＰＳのＡＶＲや３０ＭＩＰＳのｄｓＰＩＣなら単純計算でその４～６倍の速度が実現できるのでは！？　ｄｓＰＩＣやＡＶＲのＭＥＧＡシリーズならＰＩＮ数が多いからチャンネル数だって８入力までは簡単に増やすこともできそうだし！　マイコン用工作で使うロジアナ程度に限定すればそこそこ実用品になるかも…

とういわけで、自分でもこれに習ってＡＶＲを使ったロジアナを作ってみようと思います。「作ることに意義がある」とはならない様にある程度実用性を持たせたいと思います。一般的な開発プロジェクトで使われているような開発の各ステップをちょこっと真似ることで、仕様や品質について後々まで実用に耐えるような代物にしようと考えました（あくまで、真似事レベルの範囲ですが）。で、どの程度のスペックが実現できるのかを算出し、もし作ったら永いこと実用になるのか？それとも役に立たないなら既製品を買っちゃった方がいいのか？情報を整理しながら、そういった判断も踏まえてすすめていきたいと思います。

要件抽出

まずは実現可否に関わらず、少ーし欲張って思いつくまま要件を挙げていきたいと思います。今だけは、言いたい放題のお客さんの立場に成れます（＾_＾）。

といっても、あまり言いたい放題の仕様を挙げると後々の自分の首を締めるので、工作するのが大変だったり、再現性が低くなりそうだったり、実用上支障が出そうなデメリットなどはあらかじめ避け、それなりに実現可能性が見込めるものを仕様に挙げたいと思います。さらに実現困難な要件は後段のステップで削るなりスペックダウンするなりしていきます。

（１）想定する用途について

マイコンで生成できるビデオ映像信号程度の分解能をサンプリングして可視化
Ｉ２Ｃ、ＵＳＩ、ＵＳＡＲＴなどのシリアル通信データの内容をサンプリングして可視化
ステッピングモーターなどの励磁信号を全チャンネルサンプル
ＤＣモーターコントロール用のＰＷＭ信号をサンプル
　…などなど

（２）スペック的なものについて

マイコンで生成するビデオ信号（の元となるマイコンの出力ＰＩＮ）を読み取れる分解能
その上、１回のサンプリングで走査線がたくさん、できれば１画面２６２本の走査線がすべて取り込めるサンプル時間
ＰＷＭ信号やステッピングモーター励磁の信号をある程度長い時間に渡って取り込み可能なサンプル時間
osziFOXよりはるかに長い時間連続してサンプル
サンプルレートは幾つかのレートから選択することができる（分解能優先／サンプル時間優先の選択が可能）
外部ＳＲＡＭが許容するデータ幅（８ビット）がｆｕｌｌで取り込める
サンプルしたデータはＰＣに転送し、ＰＣ側のソフトで可視化したり加工できるようにする
サンプル開始のトリガは、任意のタイミング／立ち上がりエッヂ／立下りエッジ等いくつかから選択できる
作りやすさを考慮し、シリアルＩ／Ｆのフロー制御は行わない。ＵＳＢ－シリアル変換器での使用なども考慮し、ＰＣとの接続速度はデータの読み飛ばしが起こらない程度の遅さで、かつ実用上不便とならない程度の速さを実現する

（３）使い勝手、作りやすさ、再現性などについて

参考サイトで実現済みの１６Ｆ６４８用の仕組みは既に実績があり、これ以上改良出来そうもないので基本構成を踏襲する
筐体があまり大きいと使い勝手が下がるので、ある程度小型の基板に納める
各入力端子は取替え可能とし、時と場合によって接続端子を変更できるようにする
オーバークロックなどを行うと再現性が低くなるので、各ＩＣのスペック内で作る
手に入り難い部品を使うと再現性が低くなるので、汎用品を使うか、代替品が容易に手に入るものを用いる
あまり高くなると既製品買ったほうが安上がりで高スペックになるので、極力安い汎用品で仕上げる
ハードウェア、ソフトウェアとも極力シンプルな構造とし、誰でも応用、改造が可能とする
気を抜いて使っていても事故が起きないよう、ある程度のフールセーフを盛り込む（過電圧入力など）

といったところでしょうか。

以上を踏まえて、各要件が実現可能かどうか、そして実現する意味があるのかどうかを検討、判断したいと思います。

フィージビリティースタディー

上記で挙げた要件を元に、実現可能性を検討し、現実的なスペックを決めていきます。

検討に際しある程度実感を持って考えられるように、今回はプロトタイプ的なものを用意してそれをたたき台として検討を進めていくことにします。ただし、プロトタイプ的といってもブレッドボードでミニシステムを組んでしまおうと言うようなレベルではなく、ある程度回路図に落として可視化すると共に、コアロジックのアセンブリ言語イメージを突き合わせて、処理内容を細かいレベルまでイメージできれば良しとします。

検討の観点となるのは（１）使用部品とおおよその配置、（２）マイコン自体に因る分解能、（３）マイコン以外の部品に因る分解能、（４）使用するメモリとサンプル可能時間、（５）ＰＣ側ソフトの機能と通信方法、（６）部品価格・入手容易性、（７）拡張性、（８）その他、といったところでしょうか。以下、これらについて一つ一つ詳細に検証していきます。

（１）使用部品とおおよその配置

基本的なコンポーネント（マイコン、外部メモリ、ＵＡＲＴ通信等）は、参考としているＰＩＣ１６Ｆ６４８使用のものが既に必要事項を満たしているため、基本路線はこの回路で使用している部品を踏襲しつつメインとなるマイコンだけはＡＶＲのＭＥＧＡ系かｄｓＰＩＣを使用する方向で考えます。

ＡＶＲのＭＥＧＡシリーズを使用すれば２０ＭＩＰＳなので、単純に考えれば４倍の分解能。３０ＭＩＰＳのｄｓＰＩＣなら６倍の分解能が実現可能であると予想できます。

どちらにしても最高速（最高の分解能）を引き出すにはアセンブラの使用が必須。ＰＩＣは１４ビットコアのアセンブラはこれまでに使ったことはありますが、現状はｄｓＰＩＣはアセンブラも開発環境も未知の状態なので、ここから手をつけるには少々障壁が大きいと判断。ひとまずＡＶＲのＭＥＧＡシリーズで作成し、今後ｄｓＰＩＣに移植するという方向で考えたいと思います。（それにしても、サイトの主旨に反して相変わらずＰＩＣの成果物がありませんねぇ…）

次にＳＲＡＭの容量ですが、参考にした１６Ｆ６４８用のものでも使用していた３２ｋＢのＳＲＡＭなら、１ｍｓ毎のサンプリング（＝１ｋｓｐｓ）なら３０秒以上のデータが取り込めます。そもそもこんなに長い時間は想定していなかったのでもっと小さくてもいいのですが、大容量化が進んでいる最近では３２ｋＢ品ですら入手が困難になりつつあるらしいのと、秋月で５個３００円という安価なものがあるので、３２ｋＢで良いことにします。

次にアドレス制御ですが、これも１６Ｆ６４８用でも使われていた７４ＨＣ４０４０を使ってマイコンの足の少なさをカバーすると共に、ＳＲＡＭの全容量サンプリングが終わったところでマイコンに外部割込みを発生するための割り込み信号発生器としても使用します。

サンプリングしたデータは、マイコンを経由してＵＡＲＴでＰＣに伝送し、それをＰＣ側で加工できるようにします。このために、ＭＡＸ２３２（もしくは互換）のコンバーターチップを搭載することにします。

さて、メインとなるマイコンですが、１６Ｆ６４８用のものに加えて入力が４ＰＩＮ増えていることから、ひとまず単純にＭＥＧＡ４８あたりを想定しておおよそのＰＩＮ配置を回路図に記し（＝これがプロトタイピングの代わり）、要件を満たすかどうか判断します。以下に、ためしにＭＥＧＡ４８でピン配置を行った結果を記します。

縮小表示してありるので、別窓で開いて拡大表示するとか、ハードディスクに保存してグラフィックツール等で原寸大でご覧ください。

この図からは、アドレス設定（１５ビット）、データ（８ビット）、書き込み許可信号、読み込み許可信号、データフル割り込み、ＵＡＲＴ、ＩＳＰコネクタ（リセット端子含む）、オシレータといった要件をＭＥＧＡ４８でもギリギリＰＩＮ数が足りると判断しました。よって、メインのマイコンにはＭＥＧＡ４８を採用します。（動作インジケーター用のＬＥＤなどを追加したいと考えているので、この回路図は基本設計、詳細設計の段階で変更するという前提で扱います。コンデンサの容量、抵抗値などもその際に確定させます。）

なお、ＳＲＡＭ、ＡＶＲ共にｐｉｎを入力状態にしたまま外部からの入力をオープン（未接続）にしてしまうとＩＣが発振をする恐れがあるため、ＡＶＲの入力ｐｉｎは内部プルアップ設定とすることで回避したいとおもいます。

以上を以って、使用部品とその接続配置はＯＫとします。

（２）マイコン自体による分解能

マイコンの処理能力、及びプログラムのロジックによってどの程度の分解能が実現できるのかを詳細に詰めていきます。

ＰＣとの送受信やＳＲＡＭのアクセスの方法については一般論的なコーディングで特に問題ないと思うのですが、データ取り込みの分解能を最小にするには、コアロジックだけは厳密に考えておく必要があります。

ＳＲＡＭに入力データを書き込むためには、「アドレスセット」「書き込み許可信号立ち下げ」「書き込み許可信号立ち上げ」「アドレスのインクリメント」を無限ループで繰り返しておいて、外部割込みで強制的にストップするという流れになります。ＭＥＧＡ４８用のアセンブリ言語を使って最小のクロック数で実現するロジックを考えて見ます。（プロトタイピングその２といったところです。）

loop:
　　out PORTD,adress　　;ＳＲＡＭへのアドレスセット
　　cbi PORTB,3　　　　;ＷＥストローブ立ち下げ（書き込み）
　　inc adress　　　　;アドレスを１進める
　　sbi PORTB,3　　　　;ＷＥストローブ立ち上げ（書き込み終了）
　　rjmp loop　　　　　;繰り返し

色々なやみましたが、これ以上は短く出来ませんでした。６クロックになります。（rjmp命令が２クロックなので）

ＰＩＣなら５クロックで実現できているのにＭＥＧＡ４８で出来ないのはなぜかと考えてみました。ＰＩＣの場合は出力ポートレジスタを直接インクリメントする命令がある一方、ＡＶＲの場合はそれができません。よって、「汎用レジスタをインクリメントする処理」と「ポートに出力する処理」を分離せざるを得ません。その結果１クロック多くなりました。２０ＭＩＰＳで６クロックなら、分解能は３．３３…Ｍｓｐｓということになります。

当初想定していた４Ｍｓｐｓよりスペックダウンということになりますが、要件に挙げた「マイコンで生成したビデオ信号を取り込める分解能」という観点で考えると、スプライト表示器で出力するビデオ信号は３．３３…ＭＨｚの信号幅なので、ビデオ信号の幅と分解能が一緒ということになってしまうのですが、まぁ、所詮汎用マイコンではこの辺が限界だし、そうとはいえ実用ギリギリのスペックは実現できたと判断し、ＯＫとします。

（補足）プログラム中ではアドレスのインクリメントにinc命令を使用していますが、実際はＰＩＮ配置の都合からＤポートのＰＩＮ４～７をアドレス用に使用しています。よって、アドレスには１を足せばよいのではなく、１６（０ｘ１０）を加える必要があります。そのためには汎用レジスタの１つを固定値「１６」として確保しておいて、 add命令でこのレジスタを加えることで実現します。

（３）マイコン以外の部品に因る分解能

マイコン以外による分解能としては、７４ＨＣ４０４０の動作速度、ＳＲＡＭの動作速度、及びそれに関わるロジックを取り上げ、動作速度に影響があるか検討します。

７４ＨＣ４０４０は７３ＭＨｚ動作。そもそもアドレスセットとＷＥ立ち下げの間に１クロックを要するので、７３ＭＨｚであれば問題なし。

ＳＲＡＭ（秋月製の６２２５６互換品）のアクセス時間（ＷＥ立ち下げ～立ち上げ）までは最短５５ｎｓ。ＷＥ信号がＬＯＷ状態となっている時間は１クロックでは不足し、２クロックを要します。

上記（２）で示したアセンブリ言語サンプルではそれを考慮し、立ち下げ～立ち上げの間にアドレスインクリメントの処理を持ってくることによってＷＥ信号のＬＯＷ状態２クロック分を確保。動作速度の点では問題なし。

以上、マイコンとその周辺機の間の信号やりとりについて、分解能に関する問題はないと判断。

（４）使用するメモリとサンプル可能時間

１６Ｆ６４８用と同容量を採用しているため、充分と判断。

なお、最も細かい分解能でビデオ信号をキャプチャーした場合、単純計算では走査線約１５５本のキャプチャーが可能です。１画面分（２５２本）には足りませんが、分解能を半分にすると１画面すべてがキャプチャー可能となるのでヨシとします。

（５）ＰＣ側ソフトの機能と通信方法

ハード、ファームと同時にＰＣ側ソフトも完成させて品質も確保するとなると少々敷居が高くなるため、送受信データともにひとまずＡＳＣＩＩ文字だけで通信できるようにし、ハイパーターミナルや TeraTermなどでテストが行えるように考えます。ＰＣ側の専用アプリは、ハードウェアやファームウェアの品質が確保できてから別途考えることにします。

（少なくともハイパーターミナルやTeraTermでデータがＰＣ側に取り込めてしまえば、専用ソフトを急いで用意せずとも、ＥＸＣＥＬやＶＢＡなどでも加工が可能だから…という判断）

ただし、今後ＣＰＬＤなどでもっと高性能なものを作るかもしれないので、ＰＣとの通信フォーマットは拡張性に富んだ形にしておき、今後ともＰＣ側ソフトが流用可能になるよう配慮しておくこと。

（６）部品価格・入手容易性

使用する（主だった）部品はと値段は以下のとおり。

ＡＴＭＥＬ　ＡＴ－ＭＥＧＡ４８（マルツ）　＠３１５円
ＴＣ７４ＨＣ４０４０ＡＰ（千石）　＠１１０円
６２２５６互換ＳＲＡＭ（秋月）　＠６０円（５個３００円）
ＭＡＸ２３２互換ＩＣ（秋月）　＠２００円
その他、コネクタやプリント基板、抵抗、コンデンサ、クリスタルなど…

各部品とも入手性はとくに問題なし。プリント基板を自作すると仮定しても、専用機と比べて価格的にも破格の安さと判断。６２２５６互換ＳＲＡＭが入手困難の場合は、これより大きい容量のＳＲＡＭで代替可能と考えることにします。よって問題なし。

補足：秋月で売られている６２２５６互換ＳＲＡＭはＳＯＰ（１．２７ｍｍピッチ）の表面実装だが、個人的には表面実装の加工が嫌いなので、ＤＩＰサイズへの変換基板を使用することとする。

（７）拡張性

まず直近の拡張として、拡張性を想定してみます。ハード的な限界を拡張する観点と、使い勝手（ソフト面）の向上の観点と、大きくは２つに分けられると思われます。

（１）ハード面の拡張について

基本的には、一度作りこみを行ったらハード面、ファームウェア面での拡張は行わない方針（bug fixを除く）。

強いて言えば２点。その１：ｄｓＰＩＣへの移植を今後行う。その２：ＰＣとの接続にＵＳＢを使用する

その１のｄｓＰＩＣですが、今考えているのはトラ技２００７年８月の付録に付いていたｄｓＰＩＣ３０Ｆ２０１２。ＰＩＮの数、処理速度（３０ＭＩＰＳ）、メモリ容量、ＤＩＰ変換コネクタに搭載、というわけで、処理能力などの点で障害が見当たらないこと。そして多くの人がお試しする環境を容易に準備できることを考慮しました。

その２のＵＳＢ接続ですが、ＭＡＸ２３２互換ＩＣの代わりにＦＴ２３２ＲＬなどを想定しています。ＰＣとの接続部分（ハード部分）だけの変更で済ませることができることと、ＵＳＢから５Ｖの電源を取り出すことが出来るので配線の取り回しが容易になるというメリットもあり。（電源がＰＣと同一のグランドを共用するので、ターゲットボードとアイソレートされなくなるデメリットもあり）

（２）ソフト面の拡張について

ファーストリリース時点では、ＰＣ側ソフトは既存のターミナルソフト（ハイパーターミナル、TeraTerm等）とのデータ送受信のみに対応することとし、今後専用ソフトを作成する際には、ロジアナ本体の作成とは切り離して仕様の検討を行うこととします。

（１）（２）の結果から、ハード面、ファーム面についての拡張性はひとまず考慮しないこととして進めます。（ｄｓＰＩＣへの移植は別途検討を進めていくとして、その他については追々考えていくことにします）

ただし、今後はＣＰＬＤなどでもっと高速なロジアナを作ることを想定し、その際にＰＣ側のソフトを変更することなく流用できるように、ハードウェアとＰＣの間の通信フォーマットについてはあらかじめ汎用性を持たせておくこととします。

（８）その他

電源立ち上げからＰＣへのデータの取り込みまでの動作を一通り通しで眺めてみると、（１）～（５）の中で検討が充分でないところが１点あり。　→　全データ取り込み完了時の中断処理について。

３２ｋＢ全データの取り込みが完了すると７４ＨＣ４０４０の最上位ビット（Ｑ１１）信号が立ち上がります。この立ち上がり信号をトリガにして外部割込みを発生させることで３２ｋＢ取り込み完了を検知します。

この考え方自体はよいのですが、（２）で挙げたアセンブリ言語のロジックと突き合わせてよーく考えると、実用上１点問題が生じます。外部割込みの発生タイミングです。

出力ポートは、出力命令完了後、約１クロック近く遅れて出力ピンに現れます。アドレス設定用の４ＰＩＮのうち最上位のビットが７４ＨＣ４０４０のクロック入力に繋がっており、この立下り信号を以ってカウントが行われます。３２ｋＢ分のカウントが完了するとＱ０～Ｑ１０がＡＬＬゼロ、Ｑ１１ピンは立ち上がり、外部割込みが生じます。その割り込みイベントが実際に有効となるのは割り込み処理時点で実行中の命令が完了した時です。

以上を踏まえて割り込みが行われるタイミングを考えてみると、（２）のサンプルプログラムにおいては inc命令とsbi命令の間で割り込みが発生すると考えられます。（もしかしたら、cbi命令とinc命令の間になるかもしれません）

何が問題かというと、割り込みイベントが発生した時点では既にＷＥ信号を立ち下げてしまっていること。つまり、アドレスがＡＬＬゼロの状態でＳＲＡＭに対して書き込み許可を行っているわけです。よって、ＳＲＡＭの０番地にはデータが上書きされることになります。

ファームウェアやＰＣ側ソフトはこのことを考慮した上で設計を行わないと、最初の８ビット分のデータを誤って処理することとなります。ただし、本質的な問題ではなく、ロジックでいかようにでも調整出来る（ＳＲＡＭへの書き込みは１番地からスタートして、０番地で終了するなどによって対応可能）ので、設計の内容としてはこれでＯＫとします。

以上、（１）～（８）を以って実現可能性、及びコストの点で問題はないと判断します。

要件定義

ＡＶＲロジアナの要件を以下に整理します。

（１）機能要件

ＡＴ－ＭＥＧＡ４８を用いて、考えられる最高速でデータをサンプリングするロジアナを実現
外付けのＳＲＡＭを使用し、ＰＩＣ１６Ｆ６４８用と同程度のサンプリング時間を確保
入力ｐｉｎにはフールセーフとして、過電流制限用抵抗と過電圧対策用ツェナーダイオードを備える
ＰＣとの接続用にシリアルＩ／Ｆを備える
ＰＣとの通信にはＡＳＣＩＩ文字だけを使用し、汎用の通信ソフトからでも操作可能とする

（２）性能要件

最小分解能＝３．３３…Ｍｓｐｓ　（１サンプル０．３μ秒…２０ＭＨｚのＡＶＲで６クロックに相当）
分解能は幾つかの段階から選択可能とし、トータルのサンプル時間を変えられるようにする
３２ｋＢの容量を持ち、最も細かい分解能でサンプリングしても約１０ミリ秒間。最長では、１ミリ秒でサンプリングすると約３０秒間。
８ｐｉｎの入力と１ｐｉｎのグランド端子の、計９ｐｉｎの入力端子を備える

（３）価格要件

部品、ＰＣＢ、配線等を合計して２～３０００円程度に抑える

（４）拡張要件

ＵＳＢを介したシリアル通信も考慮する
ＰＣとロジアナの間の通信データは、今後ＣＰＬＤなどを使用して高性能版を作る際にも応用が効くように拡張性を配慮

基本設計

要件定義で挙げられた要件の実現に向け、搭載する機能と搭載しない機能を切り分けを行い、搭載する機能について詳説します。

機能定義

要件定義で挙げた要件を元に、実現すべき機能の洗い出しを行います。また、搭載しない機能について補記します。要件定義で明示されていない事項については、機能性や安定性などを考慮して、実用性を確保できるように機能を定義します。

（実現機能）

メインＣＰＵはＡＴ－ＭＥＧＡ４８を２０ＭＨｚで動作させ、最小分解能＝３．３３…Ｍｓｐｓを実現
ＡＶＲプログラマとの接続はＩＳＰ端子を介して行う
信号の入力用に８ＰＩＮパラレルの入力端子＋グランド端子の計９個のＩＣクリップを装備する
ＩＣクリップは取り外し可能な９ＰＩＮのソケットで接続し、必要に応じてワニ口などに取替え可能とする
最小分解能を含め、幾つかの分解能から選択してサンプリング可能とする
サンプリング開始のトリガは、幾つかの条件から選んで行えるようにする
３２ｋＢのＳＲＡＭを搭載し、サンプリングデータをストックする
ＳＲＡＭにストックしたサンプリングデータは、９ＰＩＮシリアル端子でＰＣ宛てに安定的かつ実用的な速度で転送する
ＳＲＡＭに対するアドレス指定に不足するＰＩＮは、７４ＨＣ４０４０を用いて補う
ＰＣ宛にはＡＳＣＩＩ文字のみを使用したフォーマットでデータの送信を行う
フォーマット及びプロトコルは今後の拡張性を考慮し、接続中のロジアナが適用可能なサンプルレートやトリガ条件をＰＣ宛てに通知する機能を持たせる
サンプルレートを下げてサンプル時間が長くなった場合を想定し、サンプリング中を示すＬＥＤを装備
５Ｖ単一電源を入力とする
信号入力には、過電圧、過電流に対する保護回路を装備する

（実現しない機能）

ＰＣ側のコントロールソフトは別途作成することとし、今回の実現機能からは除外する（ＰＣ側はひとまず一般的なターミナルソフトを利用）
ＵＳＢ接続機能は搭載しない（シリアルＩ／Ｆを搭載しないＰＣにはＵＳＢ－シリアル変換器を介して接続）

機能分割

実現する機能を分割し、その各機能の詳細と、機能間の接続を記します。

（１）全体概要（機能接続図）

ロジアナ全体の概要と、各機能間の接続を示します。（ｐｄｆファイル：クリックすると別窓で開きます）

（２）ハードウェア実現機能

メモリにはＳＯＰタイプの３２ｋＢ、５５ｎｓの６２２５６互換ＳＲＡＭを使用（工作の容易さを考慮し、ＳＯＰ→ＤＩＰへの変換ボードを利用）
ＣＰＵにはＡＴ－ＭＥＧＡ４８を２０ＭＨｚで動作させ、最小分解能＝３．３３…Ｍｓｐｓを実現
ＭＥＧＡ４８のＩ／ＯＰＩＮのうち、８ＰＩＮをＳＲＡＭからのデータ入力に割り当て
ＳＲＡＭへのアドレス指定には、４ビット分をＣＰＵから取り、残りの１１ビット分を７４ＨＣ４０４０で補う
７４ＨＣ４０４０やＳＲＡＭへの各種ストローブ信号には、ＣＰＵから必要量のＰＩＮを割り当てする
ＰＣとの接続用にはＭＡＸ２３２（もしくは互換）を利用し、９ＰＩＮシリアル端子を介して接続する
外部からの信号入力は８チャンネルとし、それにグランド端子を加えた９ＰＩＮでの接続とする
９ＰＩＮの各端子はＩＣクリップを使用し、基板からはソケットで接続することで脱着可能とする（必要に応じて交換可能とする）
グランドを除く８本の入力端子は過電圧、過電流保護のため、ツェナーダイオードと電流制限用抵抗を備える
ＳＲＡＭのデータ入出力ＰＩＮに繋がるＣＰＵの８本のＰＩＮについては、ＩＣクリップ未接続時に”オープン入力”とならないように内部プルアップを設定する（外部のプルアップ／プルダウンの抵抗は用いない）
各ＩＣにはパスコンを備え、安定動作に配慮する
電源はＤＣ５Ｖを直接入力する（ボード側では３端子レギュレーターなどは搭載しない）
サンプル時間が長い場合にサンプリング処理中であると判るよう、動作中を示すＬＥＤを搭載する
ＩＳＰ端子を搭載し、ＭＥＧＡ４８へのプログラミング時に使用する
ＣＰＵの入出力端子とＩＳＰ端子は、必要に応じて重畳させる

（３）ファームウェア実現機能

今後の拡張性を考慮し、ＰＣ側からは接続したロジアナが提供できるサンプリングレート（下表の１２種）、トリガ条件（下記の３つ）、及び搭載しているＲＡＭサイズ（＝３２ｋＢ）をＰＣ側に通知できる機能を搭載する
サンプリングのトリガは、「無条件」「立ち上がりエッヂ」「立下りエッジ」の３つを搭載する
ＰＣ側からサンプリングレートとサンプリング開始条件（トリガ）を受信してサンプリングを開始する
トリガの検知は８個のうち１番目のＩＣクリップだけを対象とする（複数入力からの複合条件は対応しない）
サンプリングが完了したら、ＰＣ宛てに３２ｋＢ分のデータ全部を送信する（一部分のみの転送には対応しない）
サンプリングの分解能とサンプリング時間の組合せは以下のとおりとする（１２種類）

分解能	サンプリング時間	１サンプルの時間
３．３３…Ｍｓｐｓ	9.8304ｍｓ	０．３μｓ
２Ｍｓｐｓ	16.384ｍｓ	０．５μｓ
１Ｍｓｐｓ	32.768ｍｓ	１μｓ
５００ｋｓｐｓ	65.536ｍｓ	２μｓ
２００ｋｓｐｓ	0.16384ｓ	５μｓ
１００ｋｓｐｓ	0.32768ｓ	１０μｓ
５０ｋｓｐｓ	0.65536ｓ	２０μｓ
２０ｋｓｐｓ	1.6384ｓ	５０μｓ
１０ｋｓｐｓ	3.2768ｓ	１００μｓ
５ｋｓｐｓ	6.5536ｓ	２００μｓ
２ｋｓｐｓ	16.384ｓ	５００μｓ
１ｋｓｐｓ	32.768ｓ	１ｍｓ

（４）フォーマット様式

ＰＣとロジアナの間で取り交わされる信号のフォーマットをｐｄｆファイルに纏めておきます。クリックして開いてください。

なお、今回ＡＶＲで作成するバージョンにおいては、サンプリング時間とトリガ条件を以下のとおりに設定します。

（サンプルレート）

サンプルレート名	１サンプルの時間	意味
s0	0.0000003	０．３μｓ
s1	0.0000005	０．５μｓ
s2	0.000001	１μｓ
s3	0.000002	２μｓ
s4	0.000005	５μｓ
s5	0.00001	１０μｓ
s6	0.00002	２０μｓ
s7	0.00005	５０μｓ
s8	0.0001	１００μｓ
s9	0.0002	２００μｓ
sa	0.0005	５００μｓ
sb	0.001	１ｍｓ

（トリガー条件）

トリガー名	トリガー文言	意味
t0	free run	フリーラン
t1	fall edge	立ち下がりエッヂをトリガに
t2	rise edge	立ち上がりエッヂをトリガに

詳細設計

基本設計で挙げた実現すべき各機能について、具体的な処理方法や部品構成を明確にします。

といっても、基本設計段階で設計内容のかなり細かいところまで既に明確になっていることと、バカ正直に１から１０まで書くほど複雑な機能でもないので、処理フローについてはソースプログラムを以って代替とし、端折りたいと思います。

回路図

プロトタイピングで用意した回路図に対し、抵抗値やコンデンサーの容量などを明示すると共に、要件定義、基本設計の内容を反映して１点だけ修正を行いました。動作中（サンプリング中）を明示するためのＬＥＤを追加したことです。これにより、回路の配線の一部分を見直ししました。

とはいえ、新たにＬＥＤを点けるための専用ＰＩＮを割り当てる余裕はありません。よって、「動作中と同義の信号ＰＩＮを流用」して、しかも「ＬＥＤを繋いでも元々の機能に影響が出ない」ようなＰＩＮを選ぶ必要がありました。

サンプリング中に信号がＨＩＧＨとＬＯＷに変動するＰＩＮで、かつ周りの回路に最も影響が無さそうなのは６２２５６の/WE信号に繋がるＰＩＮが最適だろうと考えました。でも、プロトタイピングで描いた回路図では /WE信号に繋いでいるＰＢ３はＩＳＰ端子と共用しています。ところがＩＳＰで使用しているＰＩＮには大きな負荷をかけると正常な電圧がかからなくなってＩＳＰの動作が保証されなくなる恐れがあります。（ＬＥＤ１個を１ｋΩで繋いだくらいではそれほどの影響は無いと思いますが…）

というわけで、一応ＰＢ３にＬＥＤを繋がない為の対策をこうじます。

具体的には、ＰＢ２とＰＢ３の接続相手（/WEと/OE）を入れ替えます。これによって、ＬＥＤはＰＢ２に接続することになるので、ＩＳＰへの影響はなくなります。一方、ＰＢ２の接続相手である/WEですが、ＬＥＤを繋ぐことによって生じる電圧の上下動に対して、特にＬＯＷレベルの信号について、ＭＥＧＡ４８から出力される電圧が上昇した結果が６２２５６の入力条件（ＬＯＷと認識される電圧）に合致するかだけはきちんと検証しておく必要があります。

データシートによると、６２２５６の入力ＰＩＮがＬＯＷと認識する電圧は最大で０．８Ｖ近辺。一方、ＭＥＧＡ４８のＬＯＷ出力は流入電流によって電圧が変動します。データシートによると３ｍＡの電流が流入した時に０．４Ｖが保証されています。ＬＥＤの電圧降下が２Ｖとして、１ｋΩの抵抗を繋ぐと抵抗には３Ｖかかって１ｋΩなので３ｍＡ。よって、ＬＯＷレベルは０．４Ｖ以下であることが保証されることになります。

０．８Ｖ＞０．４Ｖなので、これならば、ＰＢ２にＬＥＤを繋いでも６２２５６側は/WE信号のＬＯＷを正常に検知できることが判ります。よって、このＰＩＮ配置でｏｋとします。この変更を加味したのが以下の回路図です。

別窓で開いて拡大するか、保存してから等倍でご覧ください。

使用部品、及び部品配置

＊＊＊　一旦見直し！　＊＊＊

先日発覚した不具合について状況を整理し、今後の進め方などを再検討します。まず、何があったのかを挙げ、それぞれについて原因と影響を整理し、それらに対してどういう対応を行うかについて纏めます。

何が発覚したのか？

サンプリング分解能に関わる動作クロックの見積もりに考慮不足があった。
７４ＨＣ４０４０の動作速度について理解不足があった。
６２２５６互換ＳＲＡＭの／ＷＥ信号のＬＯＷ状態をキープする必要のある時間に誤解があった。

これら３点について考慮不足が発覚しました。前２件は”シバ某さん”からのご指摘により発覚。それを受けて全体的に見直しを行ったところもう１件について発覚しました。

まず１点目について。１サンプリングは６クロックで動作可能と思っていたんですが、実際はcbiとsbiはそれぞれ２クロックを要するため、１サンプリング８クロックが必要というご指摘を頂きました。実は、この点については当初クロック数を数えてみた際に頭にはあったのですが、その直後にさらに「ＡＶＲでは出力ポートをダイレクトにインクリメントする命令がない」と判り、この点でもＰＩＣよりも更にクロック数を要すると判明しました。で、この後者ばかりが気になってしまい、前者のことがすっかり頭から抜け落ちてました。

２点目ですが、７４ＨＣ４０４０のデータシートには最速７３ＭＨｚで動作とすると書いてあり、これを出力アドレスＰＩＮすべてが７３ＭＨｚで同期を取って動作できるとと理解していたんですが、これは実際は入力クロックの最大周波数のことであって、出力ＰＩＮの１２本すべてが同期を取って動作するにはもっと時間がかかるというご指摘がありました。データシートをよく読み返すと７４ＨＣ４０４０はクロック入力～全カウンタ出力ＰＩＮに反映されるまで最大で１７８ｎｓを要します。これは２０ＭＨｚのＡＶＲではクロック変化からカウンタＰＩＮが安定するまでに「４クロック分の時間を要する」ということです。

３点目ですが、使用したＥＰＳＯＮの５５ｎｓアクセスのＳＲＡＭは１回の書き込みサイクルは最小５５ｎｓで間違えなかったんですが、データシートには、ｔＡＳ（アドレス指定～／ＷＥ立ち下げまで）＝０ｎｓ、ｔＷＲ（／ＷＥ立ち上げ～次のサイクルまで）＝０ｎｓと書いてあるため、（５５－０－０＝５５ｎｓ）と頭の中で勝手に引き算して、ｔＷＰ（書き込みパルス）＝５５ｎｓと思ってしまったんですが、データシートをよく読むとｔＷＲ＝４０ｎｓで足りることなっています。データシートの読み込みが不足でした。

原因

原因ですが、１点目に関することと、２，３点目に関することの大きく２つに分けられるかと思います。１点目については認識済みの問題が未対応のまま残ったという問題。２および３点目は、データシートを理解する理解力不足ということでしょうか。

前者については、その根本的な原因は実は承知済み。仕事で開発を行う場合には通常複数人でチームを組み、逐次発生する問題をそのメンバー間で共有し合うとともに、その担当者を繁忙度にあわせて動的に割り当てたり出来るように「問題点管理台帳」的なものを利用します。そして”問題の内容”、”対応期限”、”担当者”、”対応内容”などを管理していくものですが、ＤＩＹということなのでこの台帳は最初から端折りました。

そのため、何か抜け落ちが生じるであろう事は実は予想の範疇でした。この手のバグはテストを行えばいずれ発覚するわけですし、仕事と違ってＤＩＹなので、開発の工数削減などを削ろうとかいうことは考慮にありません。今回は、最終的に品質が確保できればＯＫ。なので今後もこれでいい事にします。

後者については、直接の原因は知識不足、理解不足ですが、実際の開発現場では１次的な原因だけでなく、もっとその奥深くにある原因を追求し、根っこの原因を追求するまで掘り下げたうえで、その対応としてどうすべきかということを考え、開発ルールなどに盛り込んでいくなどの対応を行うのですが、所詮ＤＩＹなのでそこまではやらないつもりでやってきました。なので、きっと何か手落ちが起きるだろうと思っていたんですが…　まぁＤＩＹなので、そんなことまでやってしまうと仕事っぽくていやだなぁってことで、本格的な手当てはしないことにします。こういうつまづきもＤＩＹの楽しみって感じで…。

そもそも１次的な原因、つまり知識不足、理解不足ですが、まぁ、ＤＩＹだからなんでもかんでも知っている状態にはいつまでたっても至らないでしょう。きっと。事前に１００％バグを除いておくことはそもそも不可能でしょう。なので、テストで発覚すればそれで良しとします。

いずれにしても、「できあがり」って言った瞬間にバグがなくなっていればＯＫということです。逆に、「できあがり」って言った後にバグが発覚したら、設計の方法、製造の方法、テストの方法などなどに間違えがあるというわけで、色々新たな課題を掘り起こしてしまうのですが…。まぁ、あまり堅苦しく考えるとＤＩＹじゃなくなっちゃうので程々でいいでしょう。

後者についてご興味があれば、ＦＴＡ分析（クリックするとwikipediaを開きます）などをご覧ください。サイトの主旨とズレるので詳説は致しませんが。

影響と対応について

上記の各問題についての影響と対応方針を纏めます。

まずサンプリング分解能と動作クロックの件。当初の設計どおりにcbi,sbi命令を使ってマトモにプログラムでストローブを出力した場合、ストローブのｏｎ、ｏｆｆに４クロック、アドレス加算に１クロック、アドレス出力に１クロック、ループ（rjmp）に２クロックの計８クロックが必要（２．５Ｍｓｐｓ）となります。構想より少々遅くなってしまいます。

一方、シバ某さんからのアドバイスにあったようにＰＷＭを使って信号の生成を行うと、７４ＨＣ４０４０の動作速度を加味しても５クロックで処理が可能（４Ｍｓｐｓ）となります。構想よりも速い速度が実現できることになります。

できれば４Ｍｓｐｓを実現したいなぁと思って、ＰＷＭの勉強がてらサンプルプログラムを作ってシミュレータでシミュレーションを行っていたところ、ＡＶＲｓｔｕｄｉｏのシミュレーターのバグが発覚して、ＰＷＭテストが充分に出来ないことが発覚しました。タイマー１とタイマー２では高速ＰＷＭのシミュレーションが上手く動いてくれない事象です。

時間が空いたら、ＰＷＭの使い方やシミュレーターのバグについて纏めておきます。

いずれにしても、作ってもきちんと動いてくれないと困るし、だからといってＩＣＤ環境？ＩＣＥ環境？はＤＩＹにはちょっと高すぎる（なにしろ市販のロジアナを買わずに安く済まそうというのが当初の目的）ので、環境を買うのは当面見送って、ひとまずは８クロック（２．５Ｍｓｐｓ）で我慢することにします。今後、シミュレーターのバグがｆｉｘされるか、ＩＣＤ環境なりを手に入れたら対応したいと思います。

次に７４ＨＣ４０４０の動作速度の件ですが、動作速度をきちんと見直してみたところ４クロックで全出力ＰＩＮが揃うと判明したため、１サンプリング＝８クロックなら特に問題ありません。さらに、今後ＰＷＭを使って５クロックで動作させる場合でも４クロック＋書き込みストローブ１クロックで足りるため、回路図レベルでの変更は行わずともすみそうです。

３点目については動作速度が当初の想定より若干速まっているので、特に対応せずともｏｋとします。

それから、「問題管理台帳」とか「ＦＴＡ分析」とかはＤＩＹの楽しみから逸れてしまうので、今後も対応しないこととします。

これらを踏まえて、フィージビリティースタディー、基本設計あたりから若干手直しが必要になるので、見直し点の洗い出しを行ってから詳細設計に戻ろうと思います。

フィージビリティースタディー（見直し部分）

（２）と（３）について訂正があります。

（２）マイコン自体による分解能

~~６クロックになります。~~８クロックになります。（rjmp命令、ビットオン／オフが各２クロックなので）

分解能は~~３．３３…Ｍｓｐｓ~~２.５Mｓｐｓということになります。

（補足）タイマー１の高速ＰＷＭを使って／ＷＥのストローブを生成すれば、理論上は最速で５クロック（４Ｍｓｐｓ）が実現可能なはずです。ただし、目下のところＡＶＲｓｔｕｄｉｏのタイマー１は高速ＰＷＭのシミュレーション機能にバグがあるため、バグｆｉｘ後に改めて対応するという方向で考えます。

（３）マイコン以外の部品に因る分解能

~~７３ＭＨｚであれば問題なし。~~７４ＨＣ４０４０は１回のストローブ入力に対して１２本の出力ピン全部が安定して揃うのは１７８ｎｓを要し、これは２０ＭＨｚのＡＶＲでは４クロック分に相当します。１サンプリングのサイクルを８クロックもしくは５クロックのどちらでも、４クロックでアドレスが安定するのなら問題ないと判断します。

ＳＲＡＭ（秋月製の６２２５６互換品）のアクセス時間（ＷＥ立ち下げ～立ち上げ）までは~~最短５５ｎｓ~~最短４０ｎｓ。ただし、書き込み１サイクルは５５ｎｓ。よって、／ＷＥ信号は立ち下げ～立ち上げに１クロックの確保を要します。

要件定義（見直し部分）

（２）について訂正があります。

（２）性能要件

最小分解能＝~~３．３３…Ｍｓｐｓ　（１サンプル０．３μ秒…２０ＭＨｚのＡＶＲで６クロックに相当）~~ ２．５Ｍｓｐｓ　（１サンプル０．４μ秒…２０ＭＨｚのＡＶＲで８クロックに相当）

基本設計（見直し部分）

機能定義、機能分割の以下の部分について訂正があります。加えて、ロジアナ－ＰＣ間のシリアル通信速度について未決定だったため、これを明らかにします。

機能定義

メインＣＰＵはＡＴ－ＭＥＧＡ４８を２０ＭＨｚで動作させ、最小分解能＝~~３．３３…Ｍｓｐｓ~~２．５Ｍｓｐｓを実現

機能分割

（２）ハードウェア実現機能

ＣＰＵにはＡＴ－ＭＥＧＡ４８を２０ＭＨｚで動作させ、最小分解能＝~~３．３３…Ｍｓｐｓ~~２．５Ｍｓｐｓを実現

（３）ファームウェア実現機能

サンプリングの分解能とサンプリング時間の組合せは以下のとおりとする（１２種類）

分解能	サンプリング時間	１サンプルの時間
~~３．３３…Ｍｓｐｓ~~２．５Ｍｓｐｓ	~~9.8304ｍｓ~~13.1072ｍｓ	~~０．３μｓ~~０．４μｓ
２Ｍｓｐｓ	16.384ｍｓ	０．５μｓ
１Ｍｓｐｓ	32.768ｍｓ	１μｓ
５００ｋｓｐｓ	65.536ｍｓ	２μｓ
２００ｋｓｐｓ	0.16384ｓ	５μｓ
１００ｋｓｐｓ	0.32768ｓ	１０μｓ
５０ｋｓｐｓ	0.65536ｓ	２０μｓ
２０ｋｓｐｓ	1.6384ｓ	５０μｓ
１０ｋｓｐｓ	3.2768ｓ	１００μｓ
５ｋｓｐｓ	6.5536ｓ	２００μｓ
２ｋｓｐｓ	16.384ｓ	５００μｓ
１ｋｓｐｓ	32.768ｓ	１ｍｓ

（サンプルレート）

サンプルレート名	１サンプルの時間	意味
s0	~~0.0000003~~0.0000004	~~０．３μｓ~~０．４μｓ
s1	0.0000005	０．５μｓ
s2	0.000001	１μｓ
s3	0.000002	２μｓ
s4	0.000005	５μｓ
s5	0.00001	１０μｓ
s6	0.00002	２０μｓ
s7	0.00005	５０μｓ
s8	0.0001	１００μｓ
s9	0.0002	２００μｓ
sa	0.0005	５００μｓ
sb	0.001	１ｍｓ

（５）通信速度について

ロジアナとＰＣの間で行う通信速度については、極力高速かつ安定動作が出来る範囲内とする必要があります。

この通信にあたっては、連続して数十ｋＢのデータを安全に送り出す必要がありますが、回路の簡略化を目的としてフロー制御を採用していません。最近のＰＣであればさすがにＰＣ側の処理速度が追いつかないということはないかと思いますが、一方、最近のＰＣにはシリアル端子を要していないものもあり、ＵＳＢ－シリアル変換ケーブルを利用することが多いかと思います。

ＵＳＢシリアル変換ケーブルはその名前の通り「バス」の一種なので、他のデバイスとバスをシェアリングしながら使っています。もし他のデバイスにある程度以上バスを占有されてしまうと、ＵＳＢ－シリアル変換ケーブル内に内蔵されたバッファ（百バイト程度）がオーバーフローしてしまい、データの欠落が発生する恐れがあります。

これを考慮し、幾つかの通信速度で数十～百ｋＢ程度のダミーデータをＡＶＲからＰＣ宛てに送信するテストプログラムを作り、何種類かの通信速度で安定して動作する範囲の調査を実施します。

また、最近のＵＳＢ－シリアル変換ケーブルでは２３０ｋｂｐｓ以上の速度に対応しているものもありますが、旧来のＰＣに内蔵のシリアル端子は、一般に１１５．２ｋｂｐｓまでというのが一般的なので、通信速度はこの１１５．２ｋｂｐｓ以内とします。

テストの詳細は省きますが、結果だけ記します。１１５．２ｋｂｐｓ以内であれば特に問題なく通信を行うことが可能でした。ただ、その際はＵＳＢ端子に長時間バスを占有するような機器を接続すると、データの欠落を生じることがあるようです。例えば、ＡＶＲ－ＩＳＰｍｋⅡも時々何か通信をしているみたいなのですが、その際に欠落をしてしまうことが時々ありました。これは速度を落としても同様なので、ＡＶＲ－ＩＳＰｍｋⅡはかなりの長時間バスを占有しているような気がします。ＵＳＢマウスやキーボード程度なら問題はありません。多分、転送の真っ最中にＵＳＢメモリーを挿してＰＣ間とデータの授受でも行わなければそれほど影響が出ることはないでしょう。

よって、通信速度は１１５．２ｋｂｐｓを適用することとします。なお、ロジアナからＰＣ宛てのデータは、ａｓｃｉｉ文字コードを用いたダンプリスト形式のフォーマットで通信するという冗長性があるため、３２ｋＢ分全部のデータを通信するには、１２０ｋＢ～１３０ｋＢ程度の通信量となります。１１５．２ｋｂｐｓでは１０秒程度の通信速度が必要となります。もう少し短い時間で済ませたいところですが、広い環境で安定した動作を確保するために、この速度で我慢することにします。

詳細設計

回路図

回路図については、既に記載した通りの内容で変更はありません。

使用部品、及び部品配置

回路図を元に、実際の部品配置に落としていきます。

縮小図ですので、別窓で等倍表示するなりしてください。ＰＣＢＥ用データを下記ダウンロードに貼り付けておきます。

何点か補足を致します。

画面中央付近や画面右側にある８個のダイオードは、すべて５Ｖのツェナーダイオードです。
画面右側にある９ＰＩＮの部品は、ＩＣクリップなどを介して計測対象と接続するためのコネクタです。

使用部品について以下に纏めます。

部品名	個数	単価／合計	補足
プリント基板	１個	399円	千石　サンハヤト１０Ｋ
ＡＴ－ＭＥＧＡ４８	１個	315円	マルツ
７４ＨＣ４０４０	１個	110円	千石
ＡＤＭ２３２（含むセラコン５個）	１個	200円	秋月
６２２５６互換ＳＲＡＭ	１個	60円	秋月　5個300円
２８ＰＩＮ変換ボード	１個	130円	千石　5個650円
５Ｖツェナー	８個	6円／48円	秋月　100個600円
２０ＭＨｚクリスタル	１個	50円	秋月　10個500円
１８ｐセラコン	２個	10円／20円	千石
９ＰＩＮシリアルメス	１個	60円	秋月
赤ＬＥＤ	１個	3．5円	秋月　100個350円
１ｋΩ抵抗	１個	1円	秋月　100個100円
４．７ｋΩ抵抗	８個	1円／8円	秋月　100個100円
ＩＳＰ用端子（６ＰＩＮ）	１個	－	秋月
パスコン（０．１μＦ）	３個	10円／30円	秋月　10個100円
電源コネクタ	１個	50円
ＩＣクリップ	９個	73円／657円	マルツ　黒1、黄1、白7
９ＰＩＮコネクタ	オスメス各１	－	西川電子部品

以上の合計：2142円　（小数以下切り上げ）

その他、半田、配線、現像液、エッチング液、ＯＨＰシート等適宜使用します。

処理フロー

処理内容は既に明確になっており、また規模も小さいので、ソースプログラムを以って処理フローに代替と致します。ソースプログラムは製造フェーズで明示します。

製造～テスト

ボード作成

ＰＣＢＥのデータにあわせて、そのまま製作してみました。

サイズもピッタリ。穴あけ、はんだ付けもまぁまぁな仕上がりになりました。ただ、フラックスをティッシュで塗ったら少々汚くなってしまいました。

いままでＰＫ－ＣＬＡＭＰを持ってなかったので、ＯＨＰシートをカメレオンレジストにセロテープで固定していたんですが、今回、何枚も連続して露光に失敗して「プチッ」と切れてしまい、ＰＫ－ＣＬＡＭＰを買ってしまいました。…超簡単・綺麗に仕上がりました。なんで最初から買わなかったんだろう？実売２０００円もしないのなら、今回失敗で無駄にしたカメレオンレジストの値段より安かった…

単機能確認の為に幾つかのテストプログラムを作成しました。ＵＡＲＴでのＰＣ接続、ＳＲＡＭアクセス、入力ＰＩＮの接触不良有無などを確認してみました。ワンオフなので、設計不良だけでなく製造不良についてもちゃんと確認しておかないとこの後のテストに意味がなくなっちゃうので、一応しっかりとやっときます。

ひとまず上手く動きましたよ。ハードウェア面では設計不良、製造不良はないみたい。（さすがにこんなところで躓いている場合じゃありません。）

外部ＳＲＡＭは今回初めてだし、接続方法も特殊なので、単に入出力ＰＩＮからの入力→ ＳＲＡＭ書き込み→ＳＲＡＭからＡＶＲに読み込みという流れだけでなく、もう少し凝った確認をしてみました。具体的には、ＡＶＲから適当なデータを順に書き込んでいって、それをＡＶＲから読み出すというテストプログラムを作ってみました。ちゃんと読み書きできました。めでたし、めでたし。

８入力（ＩＣ－ＰＩＮが９個）は、ちょっと多かったかな？多すぎて、何がなにやら…って感じに…。

プログラム設計、作成

本来ならプログラムの詳細設計書的なもの（入出力やフローチャートもしくはＰＡＤ図、変数表などを含む）を書くべきなのでしょうが、基本設計段階で作るべきものについてほとんど明確になっているし、面倒臭いので省略します。 →プログラムソースを以ってソフトウェア部分の詳細設計に代替します。

ソースプログラムを、下記のダウンロードに貼り付けておきます。（目下、暫定版です）

３２ｋＢの取り込み終了を外部割込みで検知するとか、サンプリング開始のジャンプ先アドレスをＺレジスタに保存してあったりと、色々特殊なことをしているために、構造化プログラミング的なことすら実現できない状態です。よって、今までに見たこと無いくらいにスパゲッティ－プログラムになっているはずです。

ｔｉｎｙ２３１３のわずか２ｋＢのメモリにスプライト表示を詰め込んだ時よりも込み入ったプログラムになっているのが困ったものです。ただし、入力した文字列を解釈して振り分けたり、サンプリング時にｎｏｐ命令で時間稼ぎしたりといった「似通った処理」がだらだら並んでいるだけで、ロジック自体は結構単純なので、ひとまずいいことにします。

これを使って疎通確認をしてみました。ＰＣ側はＴｅｒａＴｅｒｍを使い、ＵＳＢ－シリアル変換ケーブルで接続し、１１５２００ｂｐｓで通信しています。

疎通確認を行ってみた結果のスクリーンショットを貼っておきます。ＴｅｒａＴｅｒｍを使って、キーボードから直接「ｓｒ」とか「ｔ２」等と打つと、ＡＶＲに送られてその実行結果がａｓｃｉｉ文字でダンプリストなどの形式で返って来ます。

↓スクリーンショットその１　：　ｓｔコマンド送信時の結果
（１行目にサンプリング条件、２行目以降に３２ｋＢ分のメモリダンプが表示されます。長いので途中は省略。）