|Name||Modified||Size||Downloads / Week||Status|
|Totals: 22 Items||1.5 MB|
test430 is a build environment framework for simple tests and demonstrations, primarily intended for MSP430 development in a POSIX shell environment. It is used for the regression suite for the MSP430 GNU Toolchain and for other packages. It provides a board-independent framework supporting display via serial output, display via LED, and high-precision timing (where supported).
Although test430 is currently targeted at platforms using the Texas Instruments MSP430 processor, it could easily be used for other microcontrollers. For development involving more powerful processors, existing solutions such as CUnit are more appropriate. Its development was born of a violent rejection of DejaGNU, for the same sort of reasons that were elegantly and independently summarized by Ian Lance Taylor.
Guiding principles for test430 included:
test430 relies heavily on conditional directives and text processing functions provide by the GNU Make infrastructure. An example of a complete Makefile for a test is:
BUG_ID=3383737 CHECK=demo include $(TEST430_ROOT)/Makefile.common
All other code is inherited from test430. Among other capabilities, a developer can:
A brief overview of some features is below; for the reset, read the Makefile.common which drives the test build process, and review the test430 Python support module in lib/python/test430.
By default each test application will be linked to an object file test430.o which provides commonly-used functionality. The related functions and macros are declared in test430.h, which is in $(TEST430_ROOT)/support and can be included in any source file without special configuration.
The test430_initialize function should be invoked at the start of the test main routine. This will disable the watchdog time, and configure the board so that the LEDs and printf() both work. It will also emit a sequence of marker strings that are used by the capture program to synchronize with the test output.
The test430_finalize function should be invoked at the end of the test main routine. It will display the summary of results, and emit a sequence of marker strings that are used by the capture program to identify the end of the test output.
If you want to use the build infrastructure, but not the runtime infrastructure, use the following pattern in your test Makefile:
# Inhibit build/link of test430 runtime infrastructure TEST430_O=
See tests/noruntime for an example.
Python code which invokes mspdebug in a subshell is used to support capturing the complete output of the test program, by holding the MCU in reset, starting to collect serial output, and releasing the MCU. Without this sort of synchronization, the test output may begin before an external program can start to capture the data.
The capabilities in test430 python module may also be used for other applications that require programmatic interaction with a running mspdebug session. (Yes, this does repeat the same error made by DejaGNU, but was far more expedient than implementing a Python API to mspdebug.)
Copyright (c) 2011, Peter A. Bigot
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.