printfデバッグ vs デバッガ
組込み分野の本格的な開発に必須なツールとみなされているものにインサーキットエミュレータ（デバッガ）があります。
一昔前は安いものでも数十万円、ちょっと本格的なものだと一桁上の金額を用意しないと入手できないものでしたが今はマイコンにデバッグ用のハードウェアが組み込まれるようになり数千円の書き込みツールでもデバッガ機能を使えるようになりました。
このデバッガは専用のデバッガソフトで任意の位置で実行中のプログラムを止めて変数の状態やCPUの内部レジスタの値等を確認できます。
このように一見便利そうなデバッガですが開発の現場でいつも活躍しているかというと、実際にはprintfなどを使って情報をターミナルやLCDに表示するprintfデバッグの方が活躍していたりします。
マイコンカーラリーでよく使われているSDカードに走行時のセンサ情報などを記録して後から解析する手法も広義のprintfデバッグに含まれます。
私がprintfデバッグに使っているJTW32というターミナルアプリはDelphiという開発環境を使い、JTW32の開発では殆どDelphiのデバッガに頼っています。
しかし組込開発の場合はデバッガを使わずにprintfデバッグばかり使います。
ではどうして組込開発ではデバッグ専用のツールであるデバッガよりもprintfデバッグの方が活躍しているのでしょうか、
デバッガの特徴
１．ターゲットボードとデバッガソフトが走るPCを書き込みツール等で接続して使用する。
２．ブレークポイントを設定したところでプログラムを停止し、変数、CPUレジスタ、プログラムカウンタ等の詳細な情報を見ることが出来る。
printfデバッグの特徴
１．ターゲットボードとPCを通信ケーブルで接続し、プログラム中にprintf文を挿入して情報を出力する。
２．プログラム実行中の情報を連続的に観察することが出来る。
デバッグ手法の違い
デバッガはプログラムのステップ送りも出来ますがプログラムを停止してその時点の様々な情報を取り出せるのに対し、printfデバッグでは特定の情報を出力するprintf文を書くことでプログラム実行中の情報を取り出すことが出来ます。
一見、デバッガの方が便利なように見えますしPC上のアプリケーション開発ではデバッガが大活躍してくれるのですが、マイコンカーラリーなど制御プログラムの開発では初期のハードウェアデバッグ以外ではデバッガの出番は無くなってしまいます。
その理由は組込分野の制御プログラムでは、センサから入ってくるダイナミックなデータにどのように対応するかがデバッグ時の主な問題点だからです。
マイコンカーラリーなら走行時に刻々変化するラインセンサからの情報に対してどのように制御パラメータを作っていくかが課題となるためダイナミックなデータ情報こそがデバッグに必要となります。
走行時に限らずスイッチの読み込みや周辺の制御でプログラムリストをいくら眺めても問題解決の糸口が発見できない場合にもprintfデバッグは活躍します。