各種ファイルのロード、セーブ

各種ファイルのロード、セーブ

基本的に、デバッガですから、実行ファイルやシンボル、マップファイルなどデバッグ情報のファイルのロードが可能なのは言うまでもありませんが（といっても、シンボリックデバッグ不能なICEだってありますし、ロードファイルもHEXなどの限られた形式のファイルのみという場合だってあります）、ファイルのセーブが可能とは限りません。

現在のは、ICEも、端末にパソコンやワークステーションと汎用OSを利用するものが主流ですから、パソコンのファイルを扱うことができるのは一般的ですが、実行用バイナリファイルや、特定の形式のファイルを専用の開発ツール（リンカも含めて）で作成したファイルが読み込めるだけの場合もあります。

また、専用の開発ツールのオプションになっているものが、実は、大変重要で、しかも高価だったりする場合がありますので、ファイルの入出力については、開発環境を選択評価するときに気をつけたい所です。

機能スペック表記の罠

もう古い話になりますが、以前に２種類のICEから１つを選択する時、シンボリックデバッグが可能という点に利点があったため、選択したICEがあったのですが、実際に利用してみると、シンボル上限300個、シンボルの読み込みは独自形式のシンボルファイルというものでした。

ファイルは、テキスト形式でしたので、記述方法をメーカーに教えてもらってシンボルファイルを作成するツールを作って対処したのですが、シンボル上限300個（スコープを管理しても3000超の規模に対して）というのは、少しだけ開発手法に影響しました（ツール側で有用なシンボル300への絞り込みを対処しました）。

読み込み方法も、実は、コマンドラインの命令をファイルから行なうバッチファイルの機能で、コマンドラインでシンボル定義を行なうのをファイルで自動化しただけのものでした（このようなバッチやスクリプトファイルの実行は便利で、重要な機能の一つと言えますが）。

その上、ICEとパソコン端末の間は、通信速度が遅いので、３００個のシンボル定義の命令に何分間もかかります(TT)。

シンボルファイルの読み込みというスペックだけで、詳細を評価することをなおざりにしたために起こった出来事ですが、バッチファイルでシンボルをコマンドライン定義することが可能ということを独自の形式のシンボルファイルと記載しているとは想像できませんでした。

メモリイメージのロード、セーブ

ファイルをメモリイメージのままロード、セーブする機能は、バックアップメモリにユーザーデータやプリセットデータを持つ機器の開発などをしていると良く利用する機能です。電池バックアップされるCMOS系のSRAMや、ROM領域などですとイメージをそのままメモリにロードしたり、デバッグ中のメモリイメージをそのままバイナリでファイルにセーブしたりするのが容易ですが、シリアル経由によってアクセスするタイプのメモリ・カードや、プログラム方法の決まったEEP-ROM、フラッシュ・メモリ、バンク切替メモリなどの場合には、ローダーなどのデバッグ用コードが必要になります。

開発のために環境を整える作業の中に、実機で動作するメモリローダーなど、ICEでデバッグ環境でのみ実効することが前提の機能コードを設計、実装する作業も含まれます。

このあたりは、大きなプロジェクトでは、最初から検討されますが開発者の提案や工夫によって効率化されている場合もめずらしくありません。現在は、EEP-ROM、フラッシュメモリなどの書き換え可能なROMやメモリカードスロットを搭載している機器が多いので、このメモリとパソコン上のファイルのロード、セーブのツール、コードは、組み込み系の機器開発の上でのノウハウの１つと言えるかも知れません。

　　▼ASII24 アスキーデジタル用語辞典
　　　　EEPROM
　　　　http://yougo.ascii24.com/gh/01/000117.html
　　　　フラッシュメモリ
　　　　http://yougo.ascii24.com/gh/01/000118.html

地味ながら必要なスキル

書籍などでは、あまり出現しないのですが、この手のコードや、前回ご紹介したようなICEを使う上でのツールを作るなどという作業も開発過程では必要になります。メモリに限らず、ハードデバッグのためのコードというのが必要で、開発者の工夫や実力によって差が生じやすい部分だと思います。

音響機器などでも、アナログの場合には、ハードウェアの試作が出来ると通電した時点で動作確認できるのですが、デジタルの場合には、ソフトウェアが走らないと、全くなにも起こらないことが多いため、基準音の発信プログラムや、各種ハードウェアスキャンなど、スタートアップコドと一緒にデバッグのタイミングで利用できるように設計、実装しておく必要があります。

また、正常動作しなかった場合の原因究明は、大変なので（何も起こらないだけに陥りやすい）、カスタムチップ、CPU、DSPなど、部分的な動作検証ができるよう工夫したデバッグコードを設計する能力も要求される場合があります。