The stuff I have done so far (which I admit isn't much) I have gotten away = with debugging with the simulator. =A0Burn a chip, then see if it works, an= d if it doesn't, then it's back to the simulator to see what is going on. = =A0I do admit, though, that it doesn't cover scenarios involving internal p= ull-ups and other things. =A0I mostly work with the low and mid-range chips= such as the 10 and 12 and sometimes the 16 series, though, and never with = anything over a 16. =A0I imagine those are a different ballgame. ---------------------------------------- > Date: Mon, 18 Aug 2014 09:22:53 +0100 > Subject: Re: [PIC] Better programmer/debugger? > From: dcb.home@gmail.com > To: piclist@mit.edu > > Debugging without an ICD is like walking round a strange house at night > without lights. You can feel your way cautiously but will trip up > eventually > > The main hardware overhead for using ICD is that you need to reserve two > pins for the debugger. The same number of pins that you need for a > "couple of status LEDS". And if you want to have the option to reprogram > in circuit you have to reserve those same two pins. Often, with a couple > of links, you can use those pins for less demanding I/O. > > Apart from reserving a few RAM locations there doesn't seem to be any > software overhead. I have written some very finely timed IO and have had > no difficulty tuning it to an instruction cycle. > > > > > > > On 18 August 2014 08:23, Jesse Lackey wrote: > >> Hi - I consider the ICD3 indispensable. LEDs and serial output ("printf >> debugging") methods work but is definitely a building a house with only >> hand tools approach. IMHO... >> >> Look at it this way, you can always use an ICD3 and still LED/printf >> debug. :) >> >> J >> >> Neil wrote: >>> Getting back into some PIC dev lately, I and I can't read-back 18F46K22 >>> code with my trusty old Pickit 2. The Pickit 3 standalone app is an >>> apparently abandoned joke. The MPLAB X IPE does not work either (not >>> connecting). And yes I fully erased the chip and reprogrammed it with >>> all protection fuses off. I'm thinking it's time to some updated tools >>> anyway. >>> >>> I've traditionally not been big on debuggers/ICE's, as it seemed to >>> required hardware and some software changes to account for the >>> debugging, so I've generally preferred to build in a serial output for >>> an LCD or even just a couple status LEDs, and the Saleae logic I got >>> some years has been indispensible. Also, some developers that have done >>> coding for me also don't bother with ICD's. But it's time I revisit >> this. >>> >>> Are any of you really using an ICD to its full intent and can say that >>> it's useful? Do I really need to change much of my circuit/code to use >>> an ICD? An ICD3 is only a couple hundred bucks... are there any better >>> options for a bit more? FWIW, my applications usually have a lot of >>> external analog sensing and very finely timed digital interfacing, some >>> with non-standard protocols. Will I be unable to properly debug any of >>> this with an ICD? >>> >>> Cheers, >>> -Neil. >>> >> -- >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> > > > > -- > __________________________________________ > David C Brown > 43 Bings Road > Whaley Bridge > High Peak Phone: 01663 733236 > Derbyshire eMail: dcb.home@gmail.com > SK23 7ND web: www.bings-knowle.co.uk/dcb > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist =20 --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .