Chapter 99. Debug and Test
Table of Contents
If the target platform resources allow, then the first step in
debugging should be to enable
inclusion of assert checking will increase the code footprint and
lower the performance, but does allow the code to catch internal
errors from unexpected data values. e.g. when the application/client
is not able to guarantee the validity of data passed into the CCB
The CCB asserts are controlled via the standard eCos
CYGDBG_USE_ASSERTS option. If enabled then
run-time assertion checks are performed by the CCB package.
If assertions are enabled and a debugger is being used, it is normally
worthwhile setting a breakpoint at start-up on
cyg_assert_fail symbol. The debugger
will then stop prior to entering the default busy-loop assert processing.
99.1.2. Diagnostic Output
In conjuction with the
CDL configuration setting and its sub-options, the
implements the CCB I/O package specific debug control.
CYGDBG_COHERENT_CCB_DEBUG is enabled a set of
individually selectable sub-systems are available to control the
diagnostic output generated.
However, when developing or debugging the CCB implementation it may be
simpler (with less build side-effects) to control the debugging output
via direct uncommenting of the necessary manifests at the head of
src/ccb_diag.h source file,
than re-configuring the complete eCos configuration via the CDL.
This approach will limit rebuilding to just the CCB package.
When enabled, some diagnostic output may adversely affect the operation of the CCB support as seen by 3rd-party code. For example, “slow” serial diagnostic output of the packet parsing and response generation could mean that a significant amount of time passes, such that the CCB support no longer adheres to the timeout limits imposed by external code.
The configuration option
defines a set of tests that are built.
By default the package will only build the deterministic, automatic,
tests. However, the
CYGPKG_IO_CCB_TESTS_MANUAL can be
defined to build extra tests that may require manual
user-intervention, or are more realistic real-world example
The ccb_ut test application performs some
unit-testing of the CCB implementation. The test assumes specific
features of the
client-application to perform a variety of fixed tests.
ccb_ut implements a software driver which can
be used to simulate a bus, without the requirement for the
configuration to have access to a physical RS-485 bus. This is used to
test core MASTER CCB client-application functionality.
It is recommended that before executing this test that you disconnect any physical hardware.
Currently not all aspects of the CCB protocol are exercised by the test.
The ccb_master is a simple example client-application that could form the basis of an actual customer implementation. The test does not automatically exit (and hence is unsuitable for the eCosCentric automated test farm).
The application currently just waits for a slave to connect, and then issues a fixed set of queries to the slave.
|2019-06-13||eCosPro Non-Commercial Public License|