つながるワイヤレス通信機器の開発手法（15）　――プロトタイプを開発する

● モニタ自体がプログラムなので負荷がかかる

　このように利点が多いモニタ機能ではあるが，ソフトウェアで実現しているので時間的な制約を受ける場合が多い．

　従来のICEやJTAGデバッグ・ツールでは，内部のモニタや制御はハードウェアで行っているため，ソフトウェアの動作に対して制限がかけられることはない．一方，モニタ・プログラムの場合，それ自体がソフトウェアであるため，モニタ処理の負荷がほかのプログラムの動作を制限する可能性がある．

　このようなことが起きないように，モニタ・プログラムは，通常，実行優先順位が低いベース・ルーチンにおかれる場合が多い．ただし，こうなるとモニタ・プログラムの優先順位が低いので，プログラムの状態遷移をリアルタイムにモニタできない可能性がある．例えば図5のように，モニタ・プログラムが含まれるベース・ルーチンよりも優先順位が高いタスクが二つあり，それぞれの中で状態の遷移が行われるとする．最初のモニタの出力は，図5のとおりF4である．次のモニタ出力までの間に，タスクBによってF4からF5へ，タスクAによってF5からF6へ遷移する．その後，再びタスクBが発生してF6からF7へ遷移することになる．次のモニタ出力を見るとF7が出力されるので，モニタ上ではF4からF5，F6をスキップしてF7に移ったように見えることになる．

　このように，ソフトウェアで実現するモニタ機能は本来の動作に必要なプログラムの動作を妨害しないように組み込まれるため，実際の動作と差が出てくる場合がある（図6）．モニタ・プログラムを使ってデバッグを行うときは，このような現象が起こることを考慮に入れておく必要がある．

図5　遷移の抜け
モニタ・プログラムが含まれるベース・ルーチンよりも優先順位が高いタスクが二つあり，それぞれの中で状態の遷移が行われると，モニタ上では状態F4からF5，F6をスキップしてF7に移ったように見えることになる．

図6　実際の動作とモニタの動作
ソフトウェアで実現するモニタ機能は本来の動作に必要なプログラムの動作を妨害しないように組み込まれる．そのため，図のように実際の動作と差が出てくる場合がある.