Stef Mientki wrote:
> thanks Mike,
>
> but ...
> ... a lot of (may all) things you mentioned, can be done through serial
>
> Mike Hord wrote:
>   
>> Breakpoints.
>>     
> can be done
>   
>>   The ability to monitor registers and change their values
>> on the fly.
>>     
> can be done
>   
>>   Single stepping through code.
>>     
> can be done
>   
>>   The ability to alter the
>> PC to begin execution of the code at a specific location.
>>     
> can be done
>   
>>   The fact
>> that you don't need to use the serial port for it, so you can debug a
>> serial application with it (it DOES cost two pins, but those are two
>> of the least painful pins to lose, since they have relatively few
>> peripherals associated with them).  The ability to do a hardware
>> reset.
>>   
>>     
> don't know
>   
>> FAR more powerful than serial debugging.  FAR FAR FAR more powerful.
>>   
>>     
> I'm willing to believe you, but I'm not convinced ;-)
> Maarten Hofman mentioned stack traces, is that possible ?
>
> Maybe it's the speed, serial debugging can be done at 1.25 MBaud,
> is ICD faster ?
>
> Are there any specifications about the ICD and maybe the commands ?
>
> The reason why all these questions ...
> ... I've the wild intention to create a combination of
> - programmer
> - uploader for a bootloader (probably Tiny)
> - high language debugger (with graph capabilities) + interaction with IDE
> - tuning device (e.g. PID tuning)
> - rapid prototyping board
> Most of the above I've already done, except the combination of it all ;-)
>
> Here is a first attempt of my JAL debugging
>   http://oase.uci.kun.nl/~mientki/data_www/pic/jalcc/help/jalcc_icd.html
>
> cheers,
> Stef Mientki
>
>   
I am becoming increasingly disappointed at MicroChip's failure to 
release the protocol for the ICD2.
There is simply NO excuse for it. The ICD2 is a really disappointing 
piece of test equipment, not really
worth $150.

Before ICD2, I debugged very complex code using an RS232 interface to 
uPs. I have since developed an
interface using manchester code which is independent of oscillator 
speed.  But in any case I was always able
to:

1. See any ram space.
2. Change any register or block of registers..
3. Force execution at a certain place (but afterward, a WDT would force 
a timeout reset to correct the stack).

The manchester code means that a single pin (not two pins!) can send 
commands and receive data from the
device, albeit slower than the ICD2 (because it is just one pin, thruput 
is less than half). It would be nice to
run the manchester interface code through the PGM pin, which is useless 
90% of the time anyway. I can fit
the code and bootloader into 256 code words. Remember that the 
configuration byte can't be changed in
this way, but I think I CAN squeeze in writes to the EEPROM.

I'd be interested in supporting you in this for the PIC16F87XX, 
PIC16F8X, and a few selected PIC18Fxxx. I
can easily handle the bootloaders, and can interface a FT232R for you (a 
VERY nice component- NO clocks
needed, and it can supply 6/12/24mhz clock, too) if RS232 is used. It is 
not helpful for devices that can't be
programmed thru a bootloader.

--Bob
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist