AVR Dragon: Debug Frequency

I believe I may have found a two part solution for my particular problem. I currently own an Arduino Diecimila (which has the ATMEGA168 with the problem) and also a new Arduino Nano 3.0. I went ahead and flashed the Arduino Nano with the ArduinoISP firmware. I then picked up 3 28 Pin ATMEGA328P DIP chips for $5.00 each at the local electronics store.

I used the ArduinoISP to flash one of the virgin chips with the Arduino Firmware using the above link with a crystal. I plan to now flash one of the other ATMEGA328Ps with the High Voltage Programmer firmware. This chip along with a bit of wiring on a breadboard should allow me to reset all of the fuses on the original ATMEGA168. Once that is done, I will be able to use the Arduino Nano to reprogram the chip.

Since the ATMEGA328Ps only cost $5 each, my end goal is to setup one 328 as an Arduino ISP programmer, setup the 168 as a HV Programmer, keep one 328 chip in my current Arduino Diecimila (upgrade!!), and I'll have one left over for whatever. I can then either switch chips on the Diecimila or build out a real board for the ISP and HV Programmer boards.

I still have not tested the JTAG ICE MKII yet with a logic/oscilloscope. Not sure if it is the root of the problem or not. I will address this issue after I build the HV Programmer.

I will report back on the success/failure of the HV Programmer. I just need to go get a few more 1K resistors to pull it off. Anyone ever tried the HV Programmer? Any other suggestions? If nothing else, hope this helps someone.

Yes you need to write good code intended to be maintainable and to make it easy to catch mistakes before you run it. However, debugging is still a reality. In a small embedded system, you can't put print statements all over the place. There is no place to print to. You also can't test the code in the same language on a PC because on a microcontroller you're always dealing with the hardware which isn't present on the PC.

A simulator on a PC can be a useful tool, but the more your code has to interact with external hardware, the less useful it becomes. Eventually you need to test and debug on the real target hardware. People telling you they don't do that or that you don't need it obviously haven't done a lot of real microcontroller projects.

I don't know the Atmel debugging environment, so can't compare it to that of PICs. Both processor families can do what you want. If one of them has better availability in your area or you think the setup has a cost advantage, go for it. You're certainly not going to go wrong with PICs, although that's probably true of any of the major microcontroller lines.