プロセッサ周辺のモニター(メモリ、I/O)

プロセッサ周辺のモニター(メモリ、I/Oなど)

メモリの内容やI/Oポート他、ワンチップマイコンなどでは、多数の周辺I/O機能をワンチップにしているため、これらの状態をモニターすることができます(ワンチップでも、できないデバッガもあります状況証拠から推理小説のように類推してデバッグするしかない場合があります)。

メモリは、シンボリック・デバッガ、ソースレベル・デバッガの場合には、デバッグ情報を利用して、変数名などで参照したり、編集することが可能です。

現在は、ソースレベルのデバッガが大勢となってきましたが、以前は、シンボリック・デバッグ（名前を利用）もサポートされていないのが、専用のワンチップマイコンなどでは珍しくありませんでした。

前回は、CPUがハードウェアとして正常に動作していることの確認も必要というお話でした。

ICEというハードウェア

類似した内容ですが、組み込みCPUのソフトウェアを設計実装する場合には、メモリやI/Oなどのハードウェアのテストコードを設計してデバッグ段階で初歩的なハードウェアデバッグをしたり、製品出荷テストに組み込む場合があります。

このような場合でも、ソフトウェアのテストの信頼性を確保だけではなく、メモリやCPUのハードウェア上の性質などの知識が必要な場合があります。

例えば、ICEでのデバッグテストを行なう場合、CPUとは電気的特性が異なるためバスやI/Oなどにコンフリクトが発生してもテストが正常動作してしまう場合があります(バッファ出力が強いなど)。

実際のCPUに換装すると、コンフリクトが問題で、正常に機能しないという違いが生じます。割と原因は想定しやすいタイプの問題ですが、ICEに頼ったプログラムコードのロジカルなデバッグのみを想定している人は、全く理解できない誤動作です。

ハードウェアの理解と動作確認

ソフトウェアだけしか考えないと、ICEで正常動作しているため、プログラムには間違いがないという確認だけに終始し、そもそもの動作しているイメージができません。

DRAMのリフレッシュをソフトウェアで補助する場合なども、ギリギリの実力にすると、特定のハードウェアでは動作しても、他では記憶が消失するなどということも考えられます。ソフトウェアが主な仕事であっても、ハードウェアの基本的な知識と、動作している原理の理解は重要です。

さらに、先のコンフリクトや正常動作の確認には、オシロスコープなどで確認するのが簡単で判りやすいのですが、オシロスコープやデジタルストレージスコープを使ったことがない、使い方を知らないソフトウェア技術者も存在します。

アナログ技術となると大変ですが、デジタルのハードウェアのレベルであれば、それほど敷居は高くありませんので、ソフトウェア技術者でも、最低限のハードウェア理解やオシロスコープなどを利用することができるようにしたい所です。