Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Understanding debug: Intrusive and non-intrusive

Posted: 08 Jan 2016     Print Version  Bookmark and Share

Keywords:debugging  debug tools 

One crucial part of an embedded software development project is debugging. All developers have their own favourite approaches and each one has its strengths and weaknesses. A key issue is how intrusive the debug tools are—i.e. the extent to which debugging software affects the functionality of the code. This is not a black and white issue, as a number of factors and priorities need to be considered. This article outlines different approaches to debugging, from the perspective of intrusion, and also considers the implications with respect to code optimisation.

What is intrusive debug?
There are two parameters that characterise any piece of code: size and speed. In broad terms, intrusive debug may be anything that affects either of these factors.

A number common debug techniques involve the incorporation of additional code into the application, the sole function of which is to facilitate debug. This affects the overall memory footprint and may have an effect on the execution time of the application code. There may also be unexpected side-effects caused by the use of this code.

If a system has plenty of memory: over and above the needs of the application code: the inclusion of extra debug software should not be a problem. However, many embedded systems are designed to have enough memory, but only just enough, and there is no provision for adding more just during debug time. Under these circumstances, the additional memory hit would be very problematic.

An example of an intrusive debug technique, that is very widely used and exhibits this issue, is the temporary addition of printf() calls to to track the path through some code. Such instrumented code might look something like this:

av = 99;
while (av != 0)
     av = fun();
     printf("av = %d\n", av); // debug
printf("loop exit\n"); // debug

This approach works well enough, but has some drawbacks:
 • The entire application needs to be rebuilt every time you want to change the debug setup.
 • The printf() function needs to send its output somewhere. Figuring out where to send the text to and setting up the library function to do this may be challenging.
 • This function is quite large, as it has way more functionality than required for debugging. Unless the application code uses printf() (which is unlikely), inclusion of the library function will have a drastic effect on the memory footprint.
 • Many library functions are non-reentrant and their use in a multi-threaded system may be problematic.

Some of these problems may be addressed by using custom functions, written specifically for doing debug and designed to be small and simple. A possible set might be:
 • debug_print_text(): outputs a text string
 • debug_print_number(): outputs an integer in a suitable base
 • debug_print_newline(): aids display formatting

This is for C. For C++, the functions might be overloaded.

The code example might then look like this:

av = 99;
while (av != 0)
     av = fun();
    debug_print_text("av = ");
debug_print_text("loop exit");

1 • 2 • 3 Next Page Last Page

Comment on "Understanding debug: Intrusive and n..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top