Yeah, you'll probably have to do what I did: Hack the board for debugging to use different pins and add appropriate conditional definitions to your source to support it. Oh, and next time... tell the hardware guys that RB6 and RB7 are the _last_ pins that they're to touch. In my case the hardware had them on pushbuttons, which meant pushing the button looked suspiciously to the ICD like an external break ;-( Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) ----- Original Message ----- From: "David Cary" To: Sent: Monday, June 18, 2001 4:34 PM Subject: using PB6 and PB7 as outputs > Dear PIC users, > > I've become spoiled using the ``ICD'' board to single-step through my code. > > Now the hardware guys have wired up a PIC 16f876 to drive a 8 bit bus and a few > chip-select pins. > Naturally, they chose PortB to hook up to the 8 bit bus, since it's the only > port with all 8 pins available on that chip. > > Unfortunately, my ``ICD'' uses the top 2 lines of PortB to communicate back to > my big screen. > > I was hoping that a subroutine that > -- make PortB all outputs > -- write out the proper value on that data bus > -- pulse chip select and Read/Write lines properly > would actually do all that before ICD grabbed those 2 pins back again, > as long as I skipped through it with a breakpoint rather than single-stepping > through it. > But that doesn't seem to work (until I disable ``[] Enable Debug Mode'', which > makes it *very* hard to debug). > > Any hints, tips, work-arounds ? > > -- > David Cary > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.