Hi Herbert I too came/fumbled to the same conclusion as you did whilst using debuggers with HLLs i.e. just run to break points instead of trying to single step through a line of HLL code that disassembles to many lines in assembler. BTW I think bang for the bucks and flexibility the IDC is a good product compared to the few others I've used. It has its quirks but for what it is supposed to be it does a good job. I would of course buy a "real programmer from Olin or someone when mass production/higher volume time comes. The most annoying thing for me when using the ICD2 with MPLAB is that MPLAB wants to go to the current line being executed instead of staying in the current module I'm editing. Let's say I am debugging a fore ground task and I see that I'm not doing something properly (a common occurrence in my code). I then halt the device and MPLAB leaps to open another window and show me the exact line of the ISR I'm executing at the moment in the background. Usually I always have an ISR in the background so each time I halt the debugger I'm moving a window out of my way to get back to the code I'm working on. While sometimes when I have no idea what is going on in my code (another common occurrence) and I am trying to figure what in the heck is really going on/ where I'm at, this is helpful most times it is nothing but an annoyance. Can you or anyone else suggest how to avoid this? There is a setting in configure/setting/debugger tab to reset device to beginning of main function which saves me from looking at the start up code every time I build and program...certainly a blessing. Do you have a clever/obvious to the non stoopid suggestion to keep MPLAB from throwing open windows every time and heading to the current line being executed each time I halt the debugger? Thanks in advance. Phillip Things should be as simple as possible but no simpler Phillip Coiner CTO, GPS Source, Inc. Your source for quality GNSS Networking Solutions and Design Services, Now! -----Original Message----- From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of Herbert Graf Sent: Sunday, October 22, 2006 10:49 PM To: Microcontroller discussion list - Public. Subject: Re: [PIC] Debugging options for 3.3V PIC parts dsPIC33F, PIC24 andPIC18J On Sun, 2006-10-22 at 23:27 -0400, Xiaofan Chen wrote: > On 10/22/06, Herbert Graf wrote: > > On Sun, 2006-10-22 at 17:04 -0400, Xiaofan Chen wrote: > > > ICD2 is relatively cheap as well but it is really painful to use for > > > bigger Microchip MCUs like dsPIC33F/PIC24. > > > > Define "painful"? I have never noticed much of a speed difference in the > > usage of the ICD2 when dealing with large dsPIC parts, or small 12F > > parts. Yes, if you don't do things wisely (like leaving tons of watch > > windows open, or the whole SFR window open) then the larger parts WILL > > be slower in use since there's just so much more to update. > > > > I have a feeling most people don't realize how the ICD2 works, and > > simply blame the bigger parts as being "slower" then the smaller parts > > with using the ICD2. > > I am not that experienced with large PIC parts. But I have tried the > Explorer 16 demo board with ICD2. Without doing much, just stepping > through the code was very slow. I do not think I was doing stupid > things then but I will check again once I am back in Singapore. Single stepping IS slow, especially when dealing with HLLs since one line of code rarely corresponds to one op code, which is how the ICD2 operates in single stepping mode. Since using an HLL is a much larger possibility with "bigger" parts, people think the bigger parts are "slower" since each line of code takes longer. Even without any watch windows, since stepping will be relatively slow with the ICD2, regardless of what PIC you are using. That said, the solution is simple: don't single step. I have rarely needed to extensively single step any of my code. Yes, from time to time, when I've narrowed down the location of a problem I will single step a few lines, but that's about it. Breakpoints are MUCH more effective at narrowing down where a problem comes from, ignoring the speed advantage. In fact, when dealing with an HLL I'd recommend you never single step. Simply set the breakpoint at the next line. The result will be MUCH faster operation since the PIC will be allowed to run whatever it needs to to get to that line. For example, if you have a software division happening, the single step will cause the PIC to execute each op code of the division one at a time, at each step reporting back to the ICD2, with the ICD2 telling it to "keep going". If, OTOH, you set a break point at the next line, the ICD2 will instruct the PIC to break when the PC reaches the first op code of that line. There could be hundreds of steps between those two lines, but there will only be one "ICD2->go PIC, PIC->I'm done" transaction. > Maybe I am biased but I never think ICD2 is a good debugger. Of the debuggers I've used (which I admit isn't that extensive) the ICD2 is an excellent value for the money. It's not perfect. It has quite a few limitations. And it can be cranky (more so because of the crap Windows does sometimes then the actual hardware). But once you know how to PROPERLY use it, the ICD2 is a VERY effective tool, and WELL worth the money. Of the debuggers I have used, it has had the steepest learning curve (because of the quirks) but is the most effective. > As > a programmer, it is even worse. Well, as a programmer it also has limitations, but then, it was never meant to be a programmer. As such, it's pretty damn good. Device support is AMAZING. I used to continuously worry whether a new part would be supported by the programmer I was using that day. With the ICD2 I've stopped worrying. Yes, it has some VERY annoying limitations on smaller parts (i.e. no internal MCLR on the 12F675. Actually it warns and warns about that, but it still seems to program without a problem), and it holds the ICDCLK and ICDDAT lines for no good reason, but hey, it's meant to be a debugger, NOT a programmer. Personally, out of all the dev tools I've used, for chips varying from CPLDs, to FPGAs, to MCUs, the ICD2 has been the most useful to me. TTYL -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist