Adding to what others have said, pretty much I agree, write the code so it'll run on both your desktop/laptop and your target hardware. Trying to debug functional processing which churns through enormous amounts of data remotely is always difficult. I am sure I don't need to tell you this, but make sure you use stdint types like int_16t, int_32t etc as necessary to force data size just in case.
When I need to run something audio-ish on the target, typically I use Goldwave for making and looking at audio files, it will take raw data in binary and ASCII as well as the usual WAV etc. so you can, if necessary, directly generate and examine data in batch mode to and from your target. You can also generate reproducible signals in Excel, convert it into a big array, and put that into your target's flash if necessary, in a global array for example.
And yes, there's nothing like toggling an LED for almost the ultimate in non-intrusive debugging.
I ran some trace examples on some PICs today using the RealICE debugger.
Using some of the PIC32MX series (the low pin count PIC32MX's don't support it) you can do real time instruction trace without any impact on performance. This requires eight or so pins of your device. You'll need a cable to do it, namely PIC32MX Trace Interface Kit (AC244006). You could also make up your own cable.
For some PICs, some (non-instruction) tracing is available using three different trace methods, namely Native trace, SPI trace and I/O Port trace. Native trace uses the debugger interface so takes no more pins than you'd otherwise use for debugging. SPI trace is a bit quicker, but uses up one of your SPI ports, and I/O Port trace uses 8 consecutive bits of a port. Not all PICs support this trace functionality, you can check which ones do by opening the device page on the Microchip website and looking at the Development Tools section, Emulators and Debuggers tab.
Regarding SPI trace, although Microchip says it's supported on some chips, I've found that those with MSSP rather than a bog standard SPI port don't compile __TRACE or __LOG commands, so you're left with Native and I/O Port tracing. You also need the Performance Pak for SPI trace, which presents an 8 pin 0.1" SIL header (standard 6 pin ICSP plus DAT[SDO] and CLK[SCK] from your chosen SPI port) or else hack something together somehow. The clock and data are outputs from the PIC, you need to know this if you're using a device with peripheral pin select, and you need to set up the PPS yourself.
For the I/O Port trace, you can use the cable that comes with the RealICE, it's terminated with standard 0.1" header female flying wires.
To give you an idea of the performance impact of __TRACE, I ran some tests using the following code measuring the rate of toggling:
while(1)
{
__TRACE(0x40);
LATBbits.LATB6=0;
LATBbits.LATB6=1;
}
dsPIC33FJ128GP802, Fcy=39.6MHz based on FRCNone 9.87MHz (__TRACE commented out)
Native 340kHz
SPI 746kHz
Port 1.13MHz
PIC24FV16KM202, Fcy=16MHz based on FRCNone 4MHz (__TRACE commented out)
Native 138kHz
SPI N/A (MSSP based SPI port so failed to compile)
Port 459kHz
So you need to be careful about where you put your __TRACE statements, the overhead can be quite dramatic in tight code.
I've had the RealICE for a long time, pretty much since it came out, its chip date codes are 2006, together with the Performance Pak and slightly more more recently PIC32MX Trace Interface Kit. This was before the ICD3 was introduced. It's the first time I've used the trace functionality, and to be honest I'm not particularly impressed. Maybe the real time instruction trace might have some value in tough-to-fathom edge cases, but the other trace facilities to me have less value: they're difficult to set up, slow, and two of the three options take up valuable pin and peripheral resources. Even worse, a lot of the trace features are unavailable on many devices, particularly the PIC32MX1xx/2xx which I use extensively.
The RealICE I have is really very old, and occasionally it just hangs with an inadvertent run-jump-catchfire instruction, and I have to let it cool down. I also had to apply a hardware fix on the standard debug adapter to do with it chucking out nasty voltages on VDD (
http://ww1.microchip.com/downloads/en/DeviceDoc/ETN-30_MPLAB_REAL_ICE_SOURCING_POWER.pdf). I was not a happy bunny that day! It also has trouble switching between MPLAB X and MPLAB 8.92 which I continually do, despite using the driver switcher. It needs its firmware completely reloading after switching to MPLAB 8.92.
I bought an ICD3 a couple of years ago due to the frustrations I was having with the RealICE as a back up just in case. The ICD3 is much more reliable than my RealICE, I have no problem switching between MPLABs, and it appears to debug just as fast. Until today there was nothing that I did with the RealICE that I couldn't do with the ICD3. But at least I know what the trace features are now, and have some idea of their limitations.
So yes, it's back to toggling an LED for me!