PIC AVR 工作室->TopPage->AVRの工作->ロジアナ

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

ネコロジーとは

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

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

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

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

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

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

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

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

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

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

PIC16F648を使ったロジアナですが、4チャンネルの信号を1Mspsでサンプリングできるとう代物です。 PICは1命令4クロック必要なので、20MHzのPICで1Mspsということは1サンプルを5クロックで処理しているはず。 5クロックでできることとって、結構限られますよねぇ?

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

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

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

そうなると、5MIPSのPICで1Msps出るなら、20MIPSのAVRや30MIPSのdsPICなら 単純計算でその4~6倍の速度が実現できるのでは!? dsPICやAVRのMEGAシリーズなら PIN数が多いからチャンネル数だって8入力までは簡単に増やすこともできそうだし! マイコン用工作で 使うロジアナ程度に限定すればそこそこ実用品になるかも…

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

要件抽出

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

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

(1)想定する用途について

(2)スペック的なものについて

(3)使い勝手、作りやすさ、再現性などについて

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

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

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

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

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

検討の観点となるのは(1)使用部品とおおよその配置、(2)マイコン自体に因る分解能、 (3)マイコン以外の部品に因る分解能、(4)使用するメモリとサンプル可能時間、(5)PC側ソフトの機能と通信方法、 (6)部品価格・入手容易性、(7)拡張性、(8)その他、といったところでしょうか。 以下、これらについて一つ一つ詳細に検証していきます。

(1)使用部品とおおよその配置

基本的なコンポーネント(マイコン、外部メモリ、UART通信等)は、参考としているPIC16F648使用のものが既に 必要事項を満たしているため、基本路線はこの回路で使用している部品を踏襲しつつメインとなるマイコンだけはAVRの MEGA系かdsPICを使用する方向で考えます。

AVRのMEGAシリーズを使用すれば20MIPSなので、単純に考えれば4倍の分解能。30MIPSのdsPICなら 6倍の分解能が実現可能であると予想できます。

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

次にSRAMの容量ですが、参考にした16F648用のものでも使用していた32kBのSRAMなら、 1ms毎のサンプリング(=1ksps)なら30秒以上のデータが取り込めます。そもそもこんなに長い時間は 想定していなかったのでもっと小さくてもいいのですが、大容量化が進んでいる最近では32kB品ですら入手が困難に なりつつあるらしいのと、秋月で5個300円という安価なものがあるので、32kBで良いことにします。

次にアドレス制御ですが、これも16F648用でも使われていた74HC4040を使ってマイコンの 足の少なさをカバーすると共に、SRAMの全容量サンプリングが終わったところでマイコンに外部割込みを 発生するための割り込み信号発生器としても使用します。

サンプリングしたデータは、マイコンを経由してUARTでPCに伝送し、それをPC側で加工できる ようにします。このために、MAX232(もしくは互換)のコンバーターチップを搭載することにします。

さて、メインとなるマイコンですが、16F648用のものに加えて入力が4PIN増えていることから、 ひとまず単純にMEGA48あたりを想定しておおよそのPIN配置を回路図に記し(=これがプロトタイピングの代わり)、 要件を満たすかどうか判断します。以下に、ためしにMEGA48でピン配置を行った結果を記します。

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

この図からは、アドレス設定(15ビット)、データ(8ビット)、書き込み許可信号、読み込み許可信号、 データフル割り込み、UART、ISPコネクタ(リセット端子含む)、オシレータといった要件をMEGA48でも ギリギリPIN数が足りると判断しました。よって、メインのマイコンにはMEGA48を採用します。 (動作インジケーター用のLEDなどを追加したいと考えているので、この回路図は基本設計、詳細設計の段階で 変更するという前提で扱います。コンデンサの容量、抵抗値などもその際に確定させます。)

なお、SRAM、AVR共にpinを入力状態にしたまま外部からの入力をオープン(未接続)にしてしまうとICが 発振をする恐れがあるため、AVRの入力pinは内部プルアップ設定とすることで回避したいとおもいます。

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

(2)マイコン自体による分解能

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

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

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

loop:
  out PORTD,adress  ;SRAMへのアドレスセット
  cbi PORTB,3    ;WEストローブ立ち下げ(書き込み)
  inc adress    ;アドレスを1進める
  sbi PORTB,3    ;WEストローブ立ち上げ(書き込み終了)
  rjmp loop     ;繰り返し

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

PICなら5クロックで実現できているのにMEGA48で出来ないのはなぜかと考えてみました。 PICの場合は出力ポートレジスタを直接インクリメントする命令がある一方、AVRの場合は それができません。よって、「汎用レジスタをインクリメントする処理」と「ポートに出力する処理」を 分離せざるを得ません。その結果1クロック多くなりました。20MIPSで6クロックなら、 分解能は3.33…Mspsということになります。

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

(補足)プログラム中ではアドレスのインクリメントにinc命令を使用していますが、実際はPIN配置の都合から DポートのPIN4~7をアドレス用に使用しています。よって、アドレスには1を足せばよいのではなく、 16(0x10)を加える必要があります。そのためには汎用レジスタの1つを固定値「16」として確保しておいて、 add命令でこのレジスタを加えることで実現します。

(3)マイコン以外の部品に因る分解能

マイコン以外による分解能としては、74HC4040の動作速度、SRAMの動作速度、及びそれに関わる ロジックを取り上げ、動作速度に影響があるか検討します。

74HC4040は73MHz動作。そもそもアドレスセットとWE立ち下げの間に1クロックを要するので、73MHz であれば問題なし。

SRAM(秋月製の62256互換品)のアクセス時間(WE立ち下げ~立ち上げ)までは最短55ns。 WE信号がLOW状態となっている時間は1クロックでは不足し、2クロックを要します。

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

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

(4)使用するメモリとサンプル可能時間

16F648用と同容量を採用しているため、充分と判断。

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

(5)PC側ソフトの機能と通信方法

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

(少なくともハイパーターミナルやTeraTermでデータがPC側に取り込めてしまえば、専用ソフトを急いで 用意せずとも、EXCELやVBAなどでも加工が可能だから…という判断)

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

(6)部品価格・入手容易性

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

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

補足:秋月で売られている62256互換SRAMはSOP(1.27mmピッチ)の表面実装だが、個人的には表面実装の 加工が嫌いなので、DIPサイズへの変換基板を使用することとする。

(7)拡張性

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

(1)ハード面の拡張について

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

強いて言えば2点。その1:dsPICへの移植を今後行う。その2:PCとの接続にUSBを使用する

その1のdsPICですが、今考えているのはトラ技2007年8月の付録に付いていたdsPIC30F2012。 PINの数、処理速度(30MIPS)、メモリ容量、DIP変換コネクタに搭載、というわけで、 処理能力などの点で障害が見当たらないこと。そして多くの人がお試しする環境を容易に準備できることを考慮しました。

その2のUSB接続ですが、MAX232互換ICの代わりにFT232RLなどを想定しています。PCとの接続部分 (ハード部分)だけの変更で済ませることができることと、USBから5Vの電源を取り出すことが出来るので配線の 取り回しが容易になるというメリットもあり。(電源がPCと同一のグランドを共用するので、ターゲットボードと アイソレートされなくなるデメリットもあり)

(2)ソフト面の拡張について

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

(1)(2)の結果から、ハード面、ファーム面についての拡張性はひとまず考慮しないこととして進めます。 (dsPICへの移植は別途検討を進めていくとして、その他については追々考えていくことにします)

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

(8)その他

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

32kB全データの取り込みが完了すると74HC4040の最上位ビット(Q11)信号が立ち上がります。この立ち上がり信号を トリガにして外部割込みを発生させることで32kB取り込み完了を検知します。

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

出力ポートは、出力命令完了後、約1クロック近く遅れて出力ピンに現れます。アドレス設定用の4PINのうち 最上位のビットが74HC4040のクロック入力に繋がっており、この立下り信号を以ってカウントが行われます。 32kB分のカウントが完了するとQ0~Q10がALLゼロ、Q11ピンは立ち上がり、外部割込みが生じます。 その割り込みイベントが実際に有効となるのは割り込み処理時点で実行中の命令が完了した時です。

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

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

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

以上、(1)~(8)を以って実現可能性、及びコストの点で問題はないと判断します。

要件定義

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

(1)機能要件

(2)性能要件

(3)価格要件

(4)拡張要件

基本設計

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

機能定義

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

(実現機能)

(実現しない機能)

機能分割

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

(1)全体概要(機能接続図)

ロジアナ全体の概要と、各機能間の接続を示します。 (pdfファイル:クリックすると別窓で開きます)

(2)ハードウェア実現機能

(3)ファームウェア実現機能

分解能 サンプリング時間 1サンプルの時間
3.33…Msps 9.8304ms 0.3μs
2Msps 16.384ms 0.5μs
1Msps 32.768ms 1μs
500ksps 65.536ms 2μs
200ksps 0.16384s 5μs
100ksps 0.32768s 10μs
50ksps 0.65536s 20μs
20ksps 1.6384s 50μs
10ksps 3.2768s 100μs
5ksps 6.5536s 200μs
2ksps 16.384s 500μs
1ksps 32.768s 1ms

(4)フォーマット様式

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

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

(サンプルレート)

サンプルレート名 1サンプルの時間 意味
s0 0.0000003 0.3μs
s1 0.0000005 0.5μs
s2 0.000001 1μs
s3 0.000002 2μs
s4 0.000005 5μs
s5 0.00001 10μs
s6 0.00002 20μs
s7 0.00005 50μs
s8 0.0001 100μs
s9 0.0002 200μs
sa 0.0005 500μs
sb 0.001 1ms

(トリガー条件)

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

詳細設計

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

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

回路図

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

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

サンプリング中に信号がHIGHとLOWに変動するPINで、かつ周りの回路に最も影響が無さそうなのは 62256の/WE信号に繋がるPINが最適だろうと考えました。でも、プロトタイピングで描いた回路図では /WE信号に繋いでいるPB3はISP端子と共用しています。ところがISPで使用しているPINには大きな 負荷をかけると正常な電圧がかからなくなってISPの動作が保証されなくなる恐れがあります。 (LED1個を1kΩで繋いだくらいではそれほどの影響は無いと思いますが…)

というわけで、一応PB3にLEDを繋がない為の対策をこうじます。

具体的には、PB2とPB3の接続相手(/WEと/OE)を入れ替えます。これによって、LEDはPB2に 接続することになるので、ISPへの影響はなくなります。一方、PB2の接続相手である/WEですが、 LEDを繋ぐことによって生じる電圧の上下動に対して、特にLOWレベルの信号について、MEGA48から 出力される電圧が上昇した結果が62256の入力条件(LOWと認識される電圧)に合致するかだけは きちんと検証しておく必要があります。

データシートによると、62256の入力PINがLOWと認識する電圧は最大で0.8V近辺。 一方、MEGA48のLOW出力は流入電流によって電圧が変動します。データシートによると3mAの電流が 流入した時に0.4Vが保証されています。LEDの電圧降下が2Vとして、1kΩの抵抗を繋ぐと 抵抗には3Vかかって1kΩなので3mA。よって、LOWレベルは0.4V以下であることが保証されることに なります。

0.8V>0.4Vなので、これならば、PB2にLEDを繋いでも62256側は/WE信号のLOWを正常に検知できる ことが判ります。よって、このPIN配置でokとします。この変更を加味したのが以下の回路図です。

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

使用部品、及び部品配置

*** 一旦見直し! ***

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

何が発覚したのか?

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

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

2点目ですが、74HC4040のデータシートには最速73MHzで動作とすると書いてあり、これを出力アドレスPIN すべてが73MHzで同期を取って動作できるとと理解していたんですが、これは実際は入力クロックの最大周波数のことであって、 出力PINの12本すべてが同期を取って動作するにはもっと時間がかかるというご指摘がありました。データシートをよく読み返すと 74HC4040はクロック入力~全カウンタ出力PINに反映されるまで最大で178nsを要します。これは20MHzのAVR ではクロック変化からカウンタPINが安定するまでに「4クロック分の時間を要する」ということです。

3点目ですが、使用したEPSONの55nsアクセスのSRAMは1回の書き込みサイクルは最小55nsで間違えなかったんですが、 データシートには、tAS(アドレス指定~/WE立ち下げまで)=0ns、tWR(/WE立ち上げ~次のサイクルまで)=0nsと 書いてあるため、(55-0-0=55ns)と頭の中で勝手に引き算して、tWP(書き込みパルス)=55nsと思ってしまったんですが、 データシートをよく読むとtWR=40nsで足りることなっています。データシートの読み込みが不足でした。

原因

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

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

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

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

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

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

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

影響と対応について

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

まずサンプリング分解能と動作クロックの件。当初の設計どおりにcbi,sbi命令を使ってマトモにプログラムでストローブを出力 した場合、ストローブのon、offに4クロック、アドレス加算に1クロック、アドレス出力に1クロック、ループ(rjmp)に 2クロックの計8クロックが必要(2.5Msps)となります。構想より少々遅くなってしまいます。

一方、シバ某さんからのアドバイスにあったようにPWMを使って信号の生成を行うと、74HC4040の動作速度を加味しても 5クロックで処理が可能(4Msps)となります。構想よりも速い速度が実現できることになります。

できれば4Mspsを実現したいなぁと思って、PWMの勉強がてらサンプルプログラムを作ってシミュレータでシミュレーションを 行っていたところ、AVRstudioのシミュレーターのバグが発覚して、PWMテストが充分に出来ないことが発覚しました。 タイマー1とタイマー2では高速PWMのシミュレーションが上手く動いてくれない事象です。

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

いずれにしても、作ってもきちんと動いてくれないと困るし、だからといってICD環境?ICE環境?はDIYにはちょっと高すぎる (なにしろ市販のロジアナを買わずに安く済まそうというのが当初の目的)ので、環境を買うのは当面見送って、ひとまずは 8クロック(2.5Msps)で我慢することにします。今後、シミュレーターのバグがfixされるか、ICD環境なりを 手に入れたら対応したいと思います。

次に74HC4040の動作速度の件ですが、動作速度をきちんと見直してみたところ4クロックで全出力PINが揃うと 判明したため、1サンプリング=8クロックなら特に問題ありません。さらに、今後PWMを使って5クロックで動作させる場合でも 4クロック+書き込みストローブ1クロックで足りるため、回路図レベルでの変更は行わずともすみそうです。

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

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

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

フィージビリティースタディー(見直し部分)

(2)と(3)について訂正があります。

(2)マイコン自体による分解能

loop:
  out PORTD,adress  ;SRAMへのアドレスセット
  cbi PORTB,3    ;WEストローブ立ち下げ(書き込み)
  inc adress    ;アドレスを1進める
  sbi PORTB,3    ;WEストローブ立ち上げ(書き込み終了)
  rjmp loop     ;繰り返し

6クロックになります。8クロックになります。(rjmp命令、ビットオン/オフが各2クロックなので)

分解能は3.33…Msps2.5Mspsということになります。

(補足)タイマー1の高速PWMを使って/WEのストローブを生成すれば、理論上は最速で5クロック(4Msps)が 実現可能なはずです。ただし、目下のところAVRstudioのタイマー1は高速PWMのシミュレーション機能にバグが あるため、バグfix後に改めて対応するという方向で考えます。

(3)マイコン以外の部品に因る分解能

73MHzであれば問題なし。74HC4040は1回のストローブ入力に対して12本の出力ピン全部が 安定して揃うのは178nsを要し、これは20MHzのAVRでは4クロック分に相当します。1サンプリングのサイクルを 8クロックもしくは5クロックのどちらでも、4クロックでアドレスが安定するのなら問題ないと判断します。

SRAM(秋月製の62256互換品)のアクセス時間(WE立ち下げ~立ち上げ)までは最短55ns最短40ns。 ただし、書き込み1サイクルは55ns。よって、/WE信号は立ち下げ~立ち上げに1クロックの確保を要します。

要件定義(見直し部分)

(2)について訂正があります。

(2)性能要件

基本設計(見直し部分)

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

機能定義

機能分割

(2)ハードウェア実現機能

(3)ファームウェア実現機能

分解能 サンプリング時間 1サンプルの時間
3.33…Msps2.5Msps 9.8304ms13.1072ms 0.3μs0.4μs
2Msps 16.384ms 0.5μs
1Msps 32.768ms 1μs
500ksps 65.536ms 2μs
200ksps 0.16384s 5μs
100ksps 0.32768s 10μs
50ksps 0.65536s 20μs
20ksps 1.6384s 50μs
10ksps 3.2768s 100μs
5ksps 6.5536s 200μs
2ksps 16.384s 500μs
1ksps 32.768s 1ms

(サンプルレート)

サンプルレート名 1サンプルの時間 意味
s0 0.00000030.0000004 0.3μs0.4μs
s1 0.0000005 0.5μs
s2 0.000001 1μs
s3 0.000002 2μs
s4 0.000005 5μs
s5 0.00001 10μs
s6 0.00002 20μs
s7 0.00005 50μs
s8 0.0001 100μs
s9 0.0002 200μs
sa 0.0005 500μs
sb 0.001 1ms

(5)通信速度について

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

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

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

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

また、最近のUSB-シリアル変換ケーブルでは230kbps以上の速度に対応しているものもありますが、 旧来のPCに内蔵のシリアル端子は、一般に115.2kbpsまでというのが一般的なので、通信速度はこの 115.2kbps以内とします。

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

よって、通信速度は115.2kbpsを適用することとします。なお、ロジアナからPC宛てのデータは、 ascii文字コードを用いたダンプリスト形式のフォーマットで通信するという冗長性があるため、32kB分 全部のデータを通信するには、120kB~130kB程度の通信量となります。115.2kbpsでは 10秒程度の通信速度が必要となります。もう少し短い時間で済ませたいところですが、広い環境で安定した 動作を確保するために、この速度で我慢することにします。

詳細設計

回路図

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

使用部品、及び部品配置

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

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

何点か補足を致します。

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

部品名 個数 単価/合計 補足
プリント基板 1個 399円 千石 サンハヤト10K
AT-MEGA48 1個 315円 マルツ
74HC4040 1個 110円 千石
ADM232(含むセラコン5個) 1個 200円 秋月
62256互換SRAM 1個 60円 秋月 5個300円
28PIN変換ボード 1個 130円 千石 5個650円
5Vツェナー 8個 6円/48円 秋月 100個600円
20MHzクリスタル 1個 50円 秋月 10個500円
18pセラコン 2個 10円/20円 千石
9PINシリアルメス 1個 60円 秋月
赤LED 1個 3.5円 秋月 100個350円
1kΩ抵抗 1個 1円 秋月 100個100円
4.7kΩ抵抗 8個 1円/8円 秋月 100個100円
ISP用端子(6PIN) 1個 秋月
パスコン(0.1μF) 3個 10円/30円 秋月 10個100円
電源コネクタ 1個 50円
ICクリップ 9個 73円/657円 マルツ 黒1、黄1、白7
9PINコネクタ オスメス各1 西川電子部品

以上の合計:2142円 (小数以下切り上げ)

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

処理フロー

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

製造~テスト

ボード作成

PCBEのデータにあわせて、そのまま製作してみました。

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

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

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

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

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

8入力(IC-PINが9個)は、ちょっと多かったかな?多すぎて、何がなにやら…って感じに…。

プログラム設計、作成

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

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

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

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

これを使って疎通確認をしてみました。PC側はTeraTermを使い、USB-シリアル変換ケーブル で接続し、115200bpsで通信しています。

疎通確認を行ってみた結果のスクリーンショットを貼っておきます。TeraTermを使って、キーボードから 直接「sr」とか「t2」等と打つと、AVRに送られてその実行結果がascii文字でダンプリストなどの 形式で返って来ます。

↓スクリーンショットその1 : stコマンド送信時の結果
(1行目にサンプリング条件、2行目以降に32kB分のメモリダンプが表示されます。長いので途中は省略。)

↓スクリーンショットその2 : srコマンド送信時の結果
(使用可能なサンプリングレートの照会コマンドです。)

↓スクリーンショットその3 : サンプルレート変更=s6送信時の結果
(サンプルレートをs6に変更した時の結果です)

↓(スクリーンショットその4 : tgコマンド送信時の結果
(使用可能なトリガ条件の照会コマンドです。)

↓スクリーンショットその5 : トリガ条件変更コマンド=t2送信時の結果
(トリガ条件をt2に変更した時の結果です)

↓スクリーンショットその6 : meコマンド送信時の結果
(メモリ容量の照会コマンドです)

↓スクリーンショットその7 : コマンドエラー時のメッセージ
(許可されていないコマンドを送信した場合に、そのコマンドがエラーである旨のメッセージです)

各スクリーンショットともAVRからのエコーバックが無いので、PCから送った(キーボードから打った)コマンド自体は 表示されていないことにご留意ください。

ひとまず疎通確認を行ってみて、それなりに思ったとおり動いているので、これからテストに入ります。

単体テスト

各部分を単機能毎に切り分けてテストしていきます。

本来なら、「どういう条件で動作させたら」「どの様な結果になる」のかを事細かに、モノによっては文章で、 モノによってはマトリクス形式で記述していくんですが、テストの概要だけ列挙することにします。 (テスト自体は事細かにちゃんとやりますが、このページに書くのが大変なので…)

以下、テスト概要。

ダウンロード

各データは、右クリックなどしてダウンロードしてください

ネコロジー回路図(PCBE用データ)

ネコロジーアセンブラソース

(注1)各ダウンロードデータは、テストが完了するまで修正が入る可能性があります。

PC側ソフト「ネコロジーPC」に関する記事はページを分割しました。

フロー制御に対応版

自宅のOSをWINDOWS7に入れ替えたところ、ネコロジーPC側がデータの取りこぼしをする様になってしまったので、 PCとの通信にフロー制御を行う様改造しました。

右クリックでダウンロード(zipファイル中にプロジェクトファイル一式格納)

フロー制御対応に関してはPC側ソフト「ネコロジーPC」のページに記載します。

PC側ソフトもxon/xoff対応版を使用しないとフロー制御が有効に機能しません。既に未対応版をお使いの場合は両方ともバージョンアップしてください。

評価、まとめ

… 続きます …