2017-10-19 7 views
-1

誰かがブートROMのテスト計画を書いた人はいますか?ブートカーネルテスト

このブートROMはちょうどあなたがブートROMコードを変更してください。これは、センサー

から皮質M3とデータ収集と組み込みシステムで使用されるSPI

を介してフラッシュまたはホストからデバイスをブートしますユニット/統合テストのために?

どうもありがとう

+0

関連:https://stackoverflow.com/questions/65820/unit-testing-c-code – jwdonahue

+0

優秀な回答はこちら:https://stackoverflow.com/questions/958841/unit-testing-patterns-for-microcontroller -c-code – jwdonahue

+0

または独自の検索を実行してください:https://stackoverflow.com/search?q=%5Bembedded%5D%2Bunit%2Btesting – jwdonahue

答えて

0

はい、何回もしていますが、テストのために、地上からシステムを設計する場合には最も適しています。つまり、予算や設計基準が許せば、開発やテストボックスにデジタルI/OカードとアナログI/Oカードを接続したモックボードを構築することができます。私は統合されたHPC(ASIC設計テスト)のラックを備えたラボで壁に取り付けられた8 '×4'バスパネルをカバーするFPGAおよびその他のロジックのアレイであるモックアップを見てきました。もちろん、あなたのマシンのハードウェアの限界内にとどまるためには、すべてを遅くする必要があります。

あなたのケースでは、ブートコードがテストピンに何らかの信号を提供するとき、またはチップを確認するためにいくつかのPOSTコードと組み合わされたときに、システムのパワーオン/リセットから実際のブート時間を測定するだけで十分ですおよび周辺装置の構成。ユニット/統合テストでは、POSTは、製品に同梱されているものよりも広範囲なものがあります。後者は、デバイスをプログラムし、ユニット/統合テストまたはPOSTシグナリングを監視するために、必要なプログラミングインターフェイスを備えたPC/Serverクラスマシン上で実行される自動化があることを意味します。開発用と出荷用のPOSTコードが別々の場合は、両方のビルドごとにラボ環境で実行する必要があります。

システムの初期設計フェーズでは、すべてのハードウェアおよびソフトウェア開発サイクルを通じて、シミュレーションでテストできない機能を十分に見極め、製品から完全にシミュレートできるものとは分離してください。 DevOpのテストサイクルは、コードベースのそれらの部分のすべてのテストを実行してから、提出を許可する必要があります。これには、開発が進むにつれて必要なモックを維持することも含まれます。ハードウェアを変更してDevOpsと統合するよりも、PC/Serverテストクラスのマシン上で単体テストを実行したり、いくつかのモックに対して単体テストを実行したりするのは、ほとんどの場合、高速です。

EDIT:1つ以上のCortex M3をFPGAに埋め込み、モックハードウェア全体をFPGA logicとして実装することもできます。