debugging - マイクロプロセッサのデバッグ

Question

当社のコプロセッサの 1 つは 8 ビット マイクロプロセッサです。主な役割は、フラッシュメモリを扱うハードウェアを制御することです。フラッシュ メモリの読み取り/書き込み速度が遅いことが測定されたため、実行中のコードは非常に非効率的であると思われます。問題は、メイン CPU に接続されている J-TAG ポートが 1 つしかないため、それをデバッグするオプションがないことです。私たちが持っているのは、マイクロプロセッサのプログラムカウンタを含む CPU から利用できるレジスタです。悪いニュースは、マイクロプロセッサが CPU とは異なる周波数で動作するため、外部でプログラム カウンタを監視することも難しいことです。マイクロプロセッサのレジスタは 8 ビット長しかないため、マイクロプロセッサ内の時間を測定することも非常に困難です。言うまでもなく、コードはアセンブリーであり、非常に複雑です。この問題にどのようにアプローチしますか？

Answer 1

言うまでもなく、コードはアセンブリーであり、非常に複雑です。この問題にどのようにアプローチしますか？

この部分の要件仕様から開始 (または生成) し、コードを C で再実装する (または C++ サブセットを慎重に使用する) ことをお勧めします。あなたが認識している「複雑さ」が、要件ではなく単にコードのダウンである場合は、それを設計することをお勧めします。これは、将来のメンテナンスをより複雑にし、エラーが発生しやすく、費用がかかるだけです。

アセンブラの使用に関する一般的な議論の 1 つはサイズとパフォーマンスですが、多くの場合、アセンブラ コードの大部分は最適とはほど遠いものです。生産性と保守性のレベルを維持するために、特定の状況に合わせて調整されていない「ボイラープレート」コードが使用および再利用されることがよくありますが、コンパイラはコードの変更を分析し、システム設計者が行う「マイクロ最適化」のようなものを実行します。本当に汗をかく必要はありません。アルゴリズムとデータ構造を効率化し、ターゲット命令セットの詳細をコンパイラに任せます。

ターゲット上で直接デバッグする機能がなくても、高水準言語を使用すると、たとえば PC 上でプロトタイピングとシミュレーションが可能になります。

アセンブラー コードを保持している場合でも、開発ツールに命令セット シミュレーターが含まれている場合は、ハードウェア デバッグの代わりになる可能性があります。特に、ハードウェア デバイスの動作をシミュレートするために使用できるデバッガ スクリプトをサポートしている場合。

とはいえ、これを「ブラックボックス」として見て、コードが非効率的であると結論付けることは、少し飛躍的です。たとえば、どのような種類のフラッシュ メモリが遅いように見えますか? マイクロコントローラとのインターフェースはどのようになっていますか? また、このパフォーマンスをどのように測定しましたか? フラッシュ メモリは本質的に低速です。特に、書き込みとページ消去。ソフトウェアのパフォーマンスについて結論を出す前に、フラッシュのパフォーマンス仕様を確認してください。