Embedded systems can benefit from testing on the host prior to testing on the target system for the following reasons.
Some parts of real-time applications may be ideally suited for host testing. For example, consider a real-time application that, among other things, requires a trivial in memory real-time database. The database could be coded and debugged on the host with no need for the target system.
Other parts of the real-time application may require a small bit of fudging before host testing can take place. Consider the requirement to periodically read an analog channel every 20 ms and report an error if the channel reading is out of range. There are two problems: (1) the host does not allow for multi-tasking or timing increments down to 20 ms, and (2) there are no analog channels to read. The first problem is solved if your kernel will run on the host computer. If this is not the case, then the sample rate can be ignored and the channel can be sampled in a tight loop. The second problem can be solved by writing a function called readChannel, which on the host returns a meaningful random number. When running on the target system the function would be changed to read the actual value. One may be tempted to using conditional compiles in this type of situation, but we recommend against it - it makes for messy code.
Overall testing on the host requires that the kernel/OS run on the host as well as the target, otherwise, the dynamics of multi-tasking and inter-task communication cannot be tested. If the kernel/OS does not run on the host, the best you can do is test tasks individually and integrate them together on the target for final testing.
View Entire Paper | Previous Page | White Papers Search
If you found this page useful, bookmark and share it on: