In general I agree with Mr Brownout there. As Simon and Garfunkel said, "I get all the news I need on the serial port".

As for the yellow peril, it seems I can't say yes or no for the debugger. I've looked around for other people's experiences, and they say my processor (PIC16F690) doesn't support in-circuit debugging. There's nothing in the data sheet to tell you this! I've got some other PIC processors around and maybe there's another one I can use.

 

Debuggers are like power windows, in your car. You probably had a car for many years with no power windows and wondered what he big deal was. One day you got power windows in a car because that is the way it came and you would never go back to a car with no power windows.

The same for a debugger.

 

Debuggers are like power windows, in your car. You probably had a car for many years with no power windows and wondered what he big deal was. One day you got power windows in a car because that is the way it came and you would never go back to a car with no power windows.

The same for a debugger.

You know what, that's a very good point. I started without a debugger--wrote several basic programs and had no idea how the debugger worked. Had no need for it, as I found other ways to find the problems. But once I got into writing more complex programs and learned how to use it, it became an extremely useful tool that allowed me to find problems I probably never would have found otherwise.

I guess it really depends on what kinds of programs you're writing whether or not a debugger is a necessary feature.

Matt

 

Debuggers are essential for walking your code, or seeing it execute instruction step by instruction step to insure it does what you want it to do.

What? You don't walk your code? Don't you care if it works?

 

Never had power windows either. Never been too lazy to use a crank.

 

Man, my code doesn't walk. It runs!

Another debug method that I use all the time is to have the processor drive a couple of pins with pulses at critical points in the code, and connect up an oscilloscope. I assume not everyone has that available, but I'd feel lost without it.

 

Man, my code doesn't walk. It runs!

If you don't walk it you'll never know when you code has the runs.

Note: Not "if." "When."

 

I have enough interest in this that I changed the processor over to a PIC16F877A, which does have the debug capability. Here's a picture of the setup with the Yellow Peril connected to the computer, with MPLab on the screen. The processor is wired to flash an LED on pin 20, portd.1:
https://dl.dropboxusercontent.com/u/28291527/yperil.jpg

Here's the program I'm running, as written for Sourceboost C.

#include <system.h>  // device dependent interrupt definitions. Processor is PIC16F877A

#pragma DATA _CONFIG, _CP_OFF & _DEBUG_OFF & _WRT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _PWRTE_ON & _WDT_OFF & _HS_OSC

void main(void){
 
	unsigned char i, j, k;

	trisd = 0b11111101;
	
	i = j = k = 0;

	while (1)
	{
		i++;
		if (i == 0)
		{
			j++;
			if (j == 0)
			{
				k++;
				if (test_bit(k, 0))
					set_bit(portd, 1);
				else
					clear_bit(portd, 1);
			}
		}
	}								// End of while(1)
}

What I found is that the debugger does work, but it is absolutely minimal. Remember I'm a total ignoramus about debuggers, but what I expected was that you could set breakpoints, and when the progam halted at one of them, you'd be able to see what the values held in any register would be. Well, it does allow you to have an "animate" mode where a little pointer runs up and down your code listing. And you can set a breakpoint (only a single one is accepted) and it will halt there, but there's no way to interrogate memory. So now I'm curious--is it likely that there's a feature that I haven't found, which would make the debugger do more, or is there a limit on what the PICKit clone can do, where other units would be more capable? Now that I'm seeing this in action, I'd like to get more use out of it.

 

Answering my own question--it's a little confusing because you have to look under the "View" heading in MPLab and not under Debugger, but I see it is possible to see any register or SFR. This is starting to look interesting.

So, how does Yellow Peril compare to other programmer/debugger units?

 

So, how does Yellow Peril compare to other programmer/debugger units?

If it just has a single breakpoint then it does not compare so well. The PICkit 2 and # both have 3 breakpoints, with the limitation when using all 3 you cannot single step the code.

With the debugger enables take a fresh look at the View menu. You can see a dissassembly listing, code memory, Special Function Registers (all of them), and my favorite: the Watch window, where just the registers and variables of your program can be viewed, and when paused even changed.

When you turn mouseover on you get the contents in a popup on either the watch or code window, and when the target is a bitfield it breaks it up into all the named portions.

Most of this comes from MPLAB not the PICkit.

 

Here is my debugger. Controller program validation needs to be done all the way to the end of the wire. I'm debugging an application and ensuring the output is correct before the interface chips arrive from Spark Fun. The LED's are soldered on a header which can be removed so that the chip can be inserted into it's place See the little pushbutton? That's my "break point/single step" feature. My design uses resources that the Pickit 3 needs to do debugging, so using it for debug is out of the question. To use the button, I insert "breakpoints" into my code that calls the function shown below. To insert the breakpoint, I use the function name, like so..

... brilliant code that is being debugged
wait_for_swinp();//The break point
... more brilliant code...

Here is the function that implements the breakpoint/single step:

void wait_for_swinp()
{
  unsigned int sw_cnt = 0;
  unsigned int MinSwDet = 10;
  do{
    if(PORTAbits.RA3 == 0)
     sw_cnt ++;
    else
     sw_cnt = 0;
  }while (sw_cnt < MinSwDet);
 
  do{
    if(PORTAbits.RA3 == 1)
     sw_cnt ++;
    else
     sw_cnt = 0;
  }while (sw_cnt < MinSwDet);
return;
}

Of course, this work better in a loop so that the output can be checked for each iteration. It would be impractical to try to implement actual single stepping this way.