Difference between revisions of "Off-Target Environment"

From STRIDE Wiki
Jump to: navigation, search
(Evaluation Steps)
(Overview)
Line 1: Line 1:
 
== Overview ==
 
== Overview ==
[[image:STRIDE_Sandbox_Configuration.jpg|right|The sandbox configuration puts both host and target code on the host PC]]
+
[[image:STRIDE_Desktop.jpg|right|The Off-Target configuration puts both host and target code on the desktop]]
Two of the largest barriers to embedded developer productivity are long build/test cycles and scarce target hardware. Fortunately, STRIDE's cross-platform capabilities make it possible to run STRIDE in a host-only ''sandbox'' that emulates your target system for purposes of evaluation and training. All of the supplied samples and test code run identically under either the sandbox environment or your actual target. In addition, any test code you write will also run in either environment.
+
Two of the largest barriers to embedded developer productivity are long build/test cycles and scarce target hardware. Fortunately, STRIDE's cross-platform capabilities make it possible to run STRIDE in a host-only ''Off-Target Configuration'' that emulates your target system for purposes of evaluation and training. All of the supplied samples and test code run identically under either the Off-Target environment or your actual target. In addition, any test code you write will also run in either environment. This enables the user to create their own '''sandbox''' for evaluation, training, and unit testing.  
  
The sandbox utilizes a "target" application that is built and runs on the host system. The test runner application runs on the same system and communicates with the "target" process over a TCP/IP connection. This set up frees you from external hardware dependencies and provides for rapid build/run cycles.
+
The Off-target utilizes the Framework's "SDK" that can be built and executed on the host system. The test runner application runs on the same system and communicates with the "target" process over a TCP/IP connection. This set up frees you from external hardware dependencies and provides for a rapid "edit/build/test" cycle.
  
 
== Evaluation Steps ==
 
== Evaluation Steps ==

Revision as of 15:48, 17 May 2010

Overview

The Off-Target configuration puts both host and target code on the desktop

Two of the largest barriers to embedded developer productivity are long build/test cycles and scarce target hardware. Fortunately, STRIDE's cross-platform capabilities make it possible to run STRIDE in a host-only Off-Target Configuration that emulates your target system for purposes of evaluation and training. All of the supplied samples and test code run identically under either the Off-Target environment or your actual target. In addition, any test code you write will also run in either environment. This enables the user to create their own sandbox for evaluation, training, and unit testing.

The Off-target utilizes the Framework's "SDK" that can be built and executed on the host system. The test runner application runs on the same system and communicates with the "target" process over a TCP/IP connection. This set up frees you from external hardware dependencies and provides for a rapid "edit/build/test" cycle.

Evaluation Steps

To simplify the evaluation, we recommend using a single Windows or Linux (x86) computer for both the target and host systems. Host and target code will run in separate processes and communicate via TCP/IP, thus simulating an embedded target with host computer configuration. All code and techniques used in the sandbox evaluation and training are directly transferable to a production environment.

The recommended evaluation steps are as follows:

  1. Review the STRIDE Overview
  2. Install required Framework
  3. Configure STRIDE Test Space for publishing results
  4. Build the basic TestApp with built-in S2 diagnostic tests
  5. Build and test the TestApp with the Expectations sample, publishing results to Test Space
  6. If you are interested in learning about tests in native C/C++, you can also build and test the TestApp with the TestIntro sample.
  7. Explore other sample tests