Hi there, James. I'm sorry that I wasn't clear enough. The Debug Header for the 12f675 allows you to use all 5 i/o lines for=20 your application. The debug chip on the header is 6 pins larger than the chip that you=20 are debugging. Those extra 6 lines are used for pgc & pgd as well as=20 Vpp, reset (I think) and to enable or disable the a/d section (the=20 same header can debug the 12f675 or 12f629). That means that you CAN=20 use pins gpio 0, 1, 2, 4, 5 in your project and not have any of those=20 pins eaten up by the debugger. But, as usual, Microchip made mistakes when designing that debug=20 chip. That's why the problems with gpio1 and not being able to use=20 gpio3 as an input while debugging. It also looks as if they aren't=20 going to bother fixing those mistakes. I've been using both the 12f675 and 16f676 debug headers with an ICD2=20 for several years now - they allow me to debug projects that aren't=20 well suited to the simulator (dealing with multiple asynchronous inputs). One suggestion: if you do decide to pony up the cash for one of the=20 ICD units, get the ICD3. Its been WAY less hassle than the ICD2 has=20 ever been. Much, much more stable and consistent. Another suggestion: if you think that you might ever want to use the=20 14 pin variants of that family (16f676, 16f630), get that debug=20 header instead. The top 8 pins (1,2,3,4:14,13,12,11) map out exactly=20 to the 12f675. You will have to put conditional compile switches in=20 your code to deal with the differences in the a/d convertor, though. dwayne At 09:37 PM 11/19/2010, James Newton wrote: >There are only 5 GPIO lines on the 12F675, so subtract 2 and that leaves 3= .. > >-- >James Newton >1-970-462-7764 > >-----Original Message----- >From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf O= f >Dwayne Reid >Sent: Wednesday, November 17, 2010 09:24 >To: Microcontroller discussion list - Public. >Subject: RE: [PIC] pickit2 unreliable debug 12F675 > >At 11:38 PM 11/16/2010, Steve Smith wrote: > >I have to say the last app I wrote for a 675 / 629 I did entirely on an >f877 > >and wrote the IO conditionally so there were two compile methods and fou= nd > >that was the best way of working with an 8 pin... Its quite restrictive > >having only 3 I/O available whilst debugging and the F877 solution was > >reasonably simple in terms of a work around that ICD2 could handle > >I'm not sure why you say "having only 3 i/o available while >debugging". You need to have the 12f675 debug header if you are >going to use the debug feature and that header brings out all 6 i/o lines. > >There are caveats: gpio3 cannot be used as an input and one pin >(gpio2?) must be in a particular logic state in order to send the >program into the flash memory but other than that, you do have access >to all 5 i/o lines. As mentioned: the 6th (input) line must be used as >!MCLR. > >dwayne > >-- >Dwayne Reid >Trinity Electronics Systems Ltd Edmonton, AB, CANADA >(780) 489-3199 voice (780) 487-6397 fax >www.trinity-electronics.com >Custom Electronics Design and Manufacturing > >-- >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 --=20 Dwayne Reid Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax www.trinity-electronics.com Custom Electronics Design and Manufacturing --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .