■

朝から、ここしばらく調査をしてきた組み込みプログラムの作者と打ち合わせ。このプログラムが組み込まれた機器を別のソフトウェアから制御するために、こちらで行う予定の変更内容を伝えて了承を取る。
具体的には装置のファームウェア（組み込みプログラム）の通信モジュールとホスト側の通信クラスを中心に必要な箇所を変更する。また、装置制御クラスにも必要なインターフェース（GetterとSetter）を追加する。

午後からは、この組み込みプログラムに本格的に手を入れ始める。まずはホストとターゲットの間の通信機能を見直す。ここをしっかり仕組みを作っておけば以降の開発で楽ができる。
現状では、ホスト側から文字列コマンドを送信してターゲット（ファームウェア）上の変数の値を変更したり、なんらかの自律動作を開始させることはできる。しかし、変数の値や動作状態を問い合わせるクエリ命令はほとんど用意されていない。
この状態ではホストから送った命令がターゲットで正しく処理されたかどうかは、装置の液晶パネルの表示を見たり、オシロスコープなどで機器の出力を観察して確認するしかない。もちろん最終的にはこういった方法で最終的な動作を確認する必要はあるが、プログラミングしながら行うにはいささか煩雑すぎる。
そこで、ホストからターゲットの状態を取得するための命令（クエリ）を追加して、「命令」→「クエリ」→「整合性チェック」のようにして動作のチェックを自動化する。一種のテスト駆動開発と言えるかも知れない。
「"AB 100"」のようなある命令があったとして、この命令に対応する「"AB ?"」というクエリを定義する。この場合、命令「"AB 100"」が送信され正常に処理されていれば、その直後の「"AB ?"」の問い合わせには「"100"」が返ってくるものとする。正しい値が返ってこなければ何らかのエラーがあるとみなす。
このような方法でほぼ全ての命令について、対応するクエリを決める。その上で全ての命令についてクエリ結果との整合性をチェックして結果を表示するテスト関数を作成する。
ファームウェア側は、クエリを受け取って結果を返す機能を作る。この時点では、クエリに対して「常に正しくない結果」を返すようにしておく。つまり整合性のチェックは全て失敗する。
ここから、それぞれのクエリについてチェックが成功するようにファームウェアを変更してゆく。

実際に上記の方法で作業を進めていったところ、一部の命令で異常な動作が見られた。液晶パネルに文字を表示させるためにIOピンを操作すると、まるで関係ないはずの変数の値が破壊される。なぜだ？メモリ破壊でも起こっているのか？
でも、遅くなってしまったので残念ながら今日はこれまで。