4

私はアジャイル開発プロセスについて良い考えを持っていますが、ハードウェアの大幅な変更を伴う組み込みプロジェクトにそれをマップする方法はありません。

現在行っていることを以下に説明します (アドホックな方法で、まだ定義されたプロセスはありません)。変更は 3 つのカテゴリに分類され、それぞれに異なるプロセスが使用されます。

  1. ハードウェアの完全な変更

    例 : 別のビデオ コーデック IP を使用する

    a) 新しい IP を検討する

    b) RTL/FPGA シミュレーション

    c) レガシー インターフェイスを実装する - b) に進む

    d) ハードウェア (テープアウト) の準備が整うまで待ちます

    f) 実際のハードウェアでのテスト

  2. ハードウェアの改善

    例 : 基礎となるアルゴリズムを改善することにより、画像の表示品質を向上させます

    a) RTL/FPGA シミュレーション

    b) ハードウェアまで待ち、ハードウェアでテストする

  3. 少しの変化

    例 : ハードウェア レジスタ マッピングのみを変更する

    a) ハードウェアまで待ち、ハードウェアでテストする

心配なのは、ハードウェアの変更に対するソフトウェアの成熟度について、私たちがあまりコントロールも自信も持っていないように見えることです。立ち上げスケジュールは常に非常にタイトであり、顧客は新しいバージョンのハードウェアに更新する際にシームレスな変更を望んでいるため、この信頼はプロジェクトの成功にとって重要です。

この種のハードウェアの変更をどのように管理しましたか? ハードウェア アブストラクション レイヤー (HAL) で解決しましたか? HAL レイヤーの自動テストはありましたか? HAL は成熟した製品では機能しますが、急速に変化する消費者向け製品ではうまく機能しない可能性があります。ハードウェア プラットフォームの準備が整っていないときに、どのようにテストしましたか? この種の変更について十分に文書化されたプロセスはありますか?

4

1 に答える 1

3

製品の存続期間中に基盤となるハードウェアが変更されることが予想される場合は、ハードウェア アブストラクション レイヤー (HAL) を追加する必要があります。正しく実行すると、HAL の両側の単体テストを作成できます。

たとえば、HAL は GUI から実際のディスプレイ ハードウェアへの単なる API です。物理デバイスを駆動しないが、さまざまな方法で応答する偽のハードウェア ドライバーを記述して、上位の API レイヤーが HAL からのすべての可能な応答コードを処理することを確認できます。おそらく、(外部 I/O を駆動する代わりに) メモリ内にビットマップを作成し、予想されるビットマップと比較して、正しくレンダリングされているかどうかを確認できます。

同様に、上位レイヤーから HAL を適切にカバーする単体テストを作成して、新しいハードウェア ドライバーが正しく応答することを確認できます。ディスプレイの例を使用して、考えられるすべての画面モード、インターフェイス要素、スクロール方法などを繰り返します。残念ながら、そのテストではディスプレイを物理的に監視する必要がありますが、古いハードウェアと並べて実行できる可能性があります。速度の向上または動作の逸脱を確認します。

ただし、例に戻ります。別のビデオ コーデックへの切り替えとの違いは? あなたはまだ上位層でバイトをプッシュしているだけです。既知のコーデックを実装している場合は、単体テストとして機能するソース ファイル (考えられるデータ形式の全範囲をカバー) を用意して、コーデックがそれらを正しく (クラッシュすることなく) デコードして表示することを確認すると便利です。メモリ内のビットマップへのデコードは、単体テストに適しています。解凍された生のフレームとメモリを比較するだけです。

それが役立つことを願っています。そうでない場合は、さらに質問してください。

于 2010-03-16T04:53:04.477 に答える