Any ideas on technique?

[Douglas Kennedy]

The issue is about a way to easily remove debug statements from the code when versioning
...I have been wrapping each debug trace in #IFDEF DEBUG_ENABLED
#ENDIF
I can also use a text editor and remove all debugging statements but it has the small disadvantage of keeping to source code versions one with debug statements the other without

Is there a better way to make the debug trace statement mute in a release version and still keep it embedded in the code?

Example code

[Ttelmah]

Leave them in!.....
Use this approach instead:

[Douglas Kennedy]

Thanks
It makes so much sense I missed it.

[Douglas Kennedy]

It gets a bit more tricky.
What if fprintf(MONITOR, has several variables which vary between fprintf statements
Ex

[ckielstra]

On a PC I would use a generic debug function like:

[Douglas Kennedy]

[asmboy]

In over 30 projects, some of of considerable complexity - involving as many as 3 pics interacting - I have NEVER used "debug", as other hardware/software analysis has always done the trick.

Perhaps someone could tell me the attraction /benefit pf debug insertion??

[SherpaDoug]

I often have a "sync" pin that I will pulse to trigger a scope or logic analyzer at certain times. I may give it a single, double, tripple, or even quadruple pulse to mark up to 4 different points in the code. Printing out ASCII messages usually takes too much time.

Many years ago I bought a bondout ICE from Microchip. It cost a lot of money but found I rarely used it. It doesn't support any of the newer chips now.

I don't use MPLAB anymore either.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[asmboy]

Sherpadoug 's methods of debug find a lot of resonance with me...
my favorite tools for debug are external instruments ( of which I have great choices, in depth - in any area I need ).

When I think about it - my debug tools are

* pin toggles -
* rs-232 messages
* canned routines that I use to do postmortem AND activity updates.

The overhead and code alteration ( time domain especially ) introduced by MPLAB - and especially dreadful pic circuit SIMULATION ala Proteus make no sense to me at all.

I just assume if my overall design, code included, is not working - and the LST file looks right -- then there is a circuit or conceptual problem - && it MUST be my problem - and I just dig in and experiment with the code till I suss it out.

That approach and the odd tip on this forum - has never failed yet
You could say I never go the debug habit

[Douglas Kennedy]

This project involves radio communications between several transceivers in a mesh network.
Each transceiver has a FSM . Some states are forced by asynchronous interrupts. When the mesh network has issues it often is a function of one or more transceivers being in the wrong state with respect to its FSM or in the right state just at the wrong time. I find it useful to debug this via a logging aka tracing of the FSM states. The CCS debugger programmer has the capability thru a single pin and without any additional hardware being required on the target boards to display data on a monitor. That's why the compiler has the debugger parameters in the #use RS232 statement. Further the printf to the monitor can be used via the CCS ICD and also at run time via CCS load. If the code holds up in real testing the debugging code is removed. Anyway the reason I do this isn't that relevant since my request was for ideas on technique.

[PCM programmer]

[Ttelmah]

My own technique is to start by putting all the actual debug defines, into a file 'debug.h'.
The has at it's start the test for the debugging indicator (whatever you want to use - I tend to do this the opposite way round, and have the debugging code load by default, and have an indicator 'PRODUCTION', which is set to turn off the debugging). The first 90% will be the definitions for the various routines, while the second part has the 'null' definitions that do nothing when debugging is disabled.
Then I'll have perhaps a define for 'debug_pulse', which toggles a pin, or generates a short pulse, together with a few defines for whatever type of variable displays/output I want. Typically 'debug_int' which displays one int variable, and sometimes some others that display other variable types, or multiple variables. I'll also sometimes use a 'debug_eeprom' definition, that writes a value to a location in the EEPROM. All 'debug' definitions begin with the word debug, so can easily be found if required.

Now, the generic function suggested by Ckielstra won't work on CCS, because printf, is parsed at compile time, and is not a included in the code as a 'universal' function. The compiler works out what subsections are needed and only includes these in the final code, so can't handle variables being handed to this function.

Realistically the multi-version debug that Douglas wants can be handled by the wrapper approach just as easily as the single line, by having two or three debug variants, something like 'debug_one_var', and debug_three_vars' for example. Avoid having too many versions though....

Best Wishes

[Douglas Kennedy]

Ttelmah thanks for the excellent idea on technique. I've been using the text editor replacing debug with //debug and reversing it //debug to debug. I'm switching to PRODUCTION rather than DEBUG in the directive.....PRODUCTION is a much more positive.

Now is there was a way for #DEFINE to do pure text editor replacement
as follows?

[asmboy]

now that i see what is being discussed, this approach has always been simple enough for me to deal with and the structure i have fallen into is this:

[SherpaDoug]

If you want to keep doing it your old way you can replace

#if (1==debug)

with

#if (debug)

That saves the PIC doing a subtraction in the if() statement, and makes more liguistic sense.
_________________
The search for better is endless. Instead simply find very good and get the job done.