I have heard many good reports on ICD3. The most notable was the programming speed on the high end MCU from Microchip. Anymore added features compared to ICD2? Are you going to get it for Christmas?
> From: Alan B. Pearce <.....Alan.B.PearceKILLspam@spam@stfc.ac.uk>
> Subject: Re: [PIC] Getting ICD3 ?
> To: "Microcontroller discussion list - Public." <piclistKILLspammit.edu>
> Date: Friday, November 21, 2008, 5:49 PM
> >Are you going to get it for Christmas?
>
> Well, mine has arrived in the UK, and I haven't even
> started on the Advent
> calendar yet ... ;))
>
> --
Umm, don't know yet, plugged it in and installed the driver, that's about as
far as I have got. Still got a heap of paper to read to learn about USB
programming.
Currently ing at the 24FJ256GB110 PIM not having any useful USB accessible
items in the test software it comes loaded with. Looks like to play with
that side of things one has to do your own interface to see anything of that
work.
Still have to do something along those lines anyway, but it would have been
nice to have something that just plugged in and displayed the relevant bits
it displays on the LCD, on a computer screen.
I just completed the USB feedback on Circuit Cellar. It is a very good piece of tutorial there. I have learnt USB from basic knowledge to firmware programming. I ran the low pin count USB module tutorial. I did not have the chance to play with the bigger PIC.
> From: Alan B. Pearce <EraseMEAlan.B.Pearcespam_OUTTakeThisOuTstfc.ac.uk>
> Subject: Re: [PIC] Getting ICD3 ?
> To: "Microcontroller discussion list - Public." <piclistspam_OUTmit.edu>
> Date: Friday, November 21, 2008, 7:38 PM
> >How is ICD3 performing?
>
> Umm, don't know yet, plugged it in and installed the
> driver, that's about as
> far as I have got. Still got a heap of paper to read to
> learn about USB
> programming.
>
> Currently ing at the 24FJ256GB110 PIM not having any useful
> USB accessible
> items in the test software it comes loaded with. Looks like
> to play with
> that side of things one has to do your own interface to see
> anything of that
> work.
>
> Still have to do something along those lines anyway, but it
> would have been
> nice to have something that just plugged in and displayed
> the relevant bits
> it displays on the LCD, on a computer screen.
>
> John Chung wrote:
>> How is ICD3 performing? For Christmas I can only think of ICD3....
>
> Why would you want a ICD3 over a RealIce? As far as I can tell, the
> RealIce
> is better in just about all respects.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014. Gold level PIC consultants since 2000.
On Fri, Nov 21, 2008 at 11:08 PM, Alan B. Pearce
<@spam@Alan.B.PearceKILLspamstfc.ac.uk> wrote:
> Currently ing at the 24FJ256GB110 PIM not having any useful USB accessible
> items in the test software it comes loaded with. Looks like to play with
> that side of things one has to do your own interface to see anything of that
> work.
Did you buy the Explorer 16 board and the PICtail+ USB board? If
not, the USB PIM itself is rather useless.
> On Fri, Nov 21, 2008 at 11:08 PM, Alan B. Pearce
> <KILLspamAlan.B.PearceKILLspamstfc.ac.uk> wrote:
>
>> Currently ing at the 24FJ256GB110 PIM not having any useful USB accessible
>> items in the test software it comes loaded with. Looks like to play with
>> that side of things one has to do your own interface to see anything of that
>> work.
>>
>
> Did you buy the Explorer 16 board and the PICtail+ USB board? If
> not, the USB PIM itself is rather useless.
>
> Xiaofan
>
On Mon, Nov 24, 2008 at 3:35 AM, Stefano Vanzo <RemoveMEpicsTakeThisOuTvanzo.it> wrote:
> Does someone know if it is pin compatible with the ICD2 cable.
> Will it just plug in the same socket on the Explore 16 ?
Yes. You can check out the help file within MPLAB 8.15.
> Did you buy the Explorer 16 board and the PICtail+ USB board? If
> not, the USB PIM itself is rather useless.
Yes, I have both, my surprise is that there doesn't seem to be a USB
application in the code that is supplied already programmed into the PIM, so
one can verify the setup before 'hitting the road' with your own project.
I was working with a small programmer which I bought from kitsrus.com. I used it a few times to learn PIC and now I was ready to do some commercial work. I ordered an ICD2. A few weeks after I received my ICD2, microchip released ICD3. I am totally bummed now. I hope they don't obsolete ICD2 anytime soon.
On Mon, Nov 24, 2008 at 7:28 PM, Hasan Khan <spamBeGonehasanspamBeGonekhansden.com> wrote:
> I was working with a small programmer which I bought from kitsrus.com. I used
> it a few times to learn PIC and now I was ready to do some commercial work.
> I ordered an ICD2. A few weeks after I received my ICD2, microchip released
> ICD3. I am totally bummed now. I hope they don't obsolete ICD2 anytime soon.
No need to panic. ICD 2 is fine for PIC12/16/18. It is just too slow for bigger
dsPIC, PIC24 and PIC32. ICD 2 will still be supported. So if you are
doing work with PIC12/16/18, you are fine.
On Mon, 2008-11-24 at 20:37 +0800, Xiaofan Chen wrote:
> On Mon, Nov 24, 2008 at 7:28 PM, Hasan Khan <TakeThisOuThasanEraseMEspam_OUTkhansden.com> wrote:
> > I was working with a small programmer which I bought from kitsrus.com. I used
> > it a few times to learn PIC and now I was ready to do some commercial work.
> > I ordered an ICD2. A few weeks after I received my ICD2, microchip released
> > ICD3. I am totally bummed now. I hope they don't obsolete ICD2 anytime soon.
>
> No need to panic. ICD 2 is fine for PIC12/16/18. It is just too slow for bigger
> dsPIC, PIC24 and PIC32. ICD 2 will still be supported. So if you are
> doing work with PIC12/16/18, you are fine.
Frankly Xiaofan I've seen you say this multiple times, and I just don't
agree.
The ICD2 works fine with the 16bit PICs (DSPIC and PIC24F). As long as
you don't go to crazy with what you're watching it's more then speedy
enough to be very useful. I haven't personally hooked mine up to a PIC32
so for that one I can't say.
Hasan, the ICD2 is a wonderful tool, you haven't made a mistake. The
ICD3 is supposedly faster and more robust, but for me I'll stick with
the ICD2. TTYL
On Mon, Nov 24, 2008 at 10:20 PM, Herbert Graf <RemoveMEmailinglist4TakeThisOuTfarcite.net> wrote:
>> No need to panic. ICD 2 is fine for PIC12/16/18. It is just too slow for bigger
>> dsPIC, PIC24 and PIC32. ICD 2 will still be supported. So if you are
>> doing work with PIC12/16/18, you are fine.
>
> Frankly Xiaofan I've seen you say this multiple times, and I just don't
> agree.
>
> The ICD2 works fine with the 16bit PICs (DSPIC and PIC24F). As long as
> you don't go to crazy with what you're watching it's more then speedy
> enough to be very useful. I haven't personally hooked mine up to a PIC32
> so for that one I can't say.
Try it and you will know how bad it is for PIC32.
I also tried it with bigger PIC24. It is really slow to me.
Xiaofan Chen wrote:
> On Mon, Nov 24, 2008 at 10:20 PM, Herbert Graf <mailinglist4EraseME.....farcite.net> wrote:
>>> No need to panic. ICD 2 is fine for PIC12/16/18. It is just too slow for bigger
>>> dsPIC, PIC24 and PIC32. ICD 2 will still be supported. So if you are
>>> doing work with PIC12/16/18, you are fine.
>> Frankly Xiaofan I've seen you say this multiple times, and I just don't
>> agree.
>>
>> The ICD2 works fine with the 16bit PICs (DSPIC and PIC24F). As long as
>> you don't go to crazy with what you're watching it's more then speedy
>> enough to be very useful. I haven't personally hooked mine up to a PIC32
>> so for that one I can't say.
>
> Try it and you will know how bad it is for PIC32.
>
> I also tried it with bigger PIC24. It is really slow to me.
>
> Xiaofan
I second that.
It's clear that the ICD2 wasn't designed with the larger parts in mind.
ICD3 uses a full speed (or high speed, doesn't matter..) USB interface
that will allow it to work much quicker. While the ICD2 programs my
18F4525 very quickly, it is very slow on my PIC24 and barely works at
all on my PIC32.
Well, as far as I am concerned, this is not an issue. For the kind of projects I am going to do, I think I can get by with PIC 16 and 18. By the time I progress to higher level PICs, I'll be able to justify getting an ICD3.
On Tue, 2008-11-25 at 07:36 +0800, Xiaofan Chen wrote:
> On Mon, Nov 24, 2008 at 10:20 PM, Herbert Graf <EraseMEmailinglist4farcite.net> wrote:
> >> No need to panic. ICD 2 is fine for PIC12/16/18. It is just too slow for bigger
> >> dsPIC, PIC24 and PIC32. ICD 2 will still be supported. So if you are
> >> doing work with PIC12/16/18, you are fine.
> >
> > Frankly Xiaofan I've seen you say this multiple times, and I just don't
> > agree.
> >
> > The ICD2 works fine with the 16bit PICs (DSPIC and PIC24F). As long as
> > you don't go to crazy with what you're watching it's more then speedy
> > enough to be very useful. I haven't personally hooked mine up to a PIC32
> > so for that one I can't say.
>
> Try it and you will know how bad it is for PIC32.
>
> I also tried it with bigger PIC24. It is really slow to me.
Well FWIW I don't have a PIC32 to try. To be honest, I've been slowly
drifting away from PICs, shame really.
As for the PIC24, I recently did some work with it and while slower then
an 18F part, the ICD2 was still more then usable.
I suppose it's a perception thing. In my field I'm used to compiles
taking half a day, the ICD2 seems very speedy in it's operations
compared to that.
On Wed, Nov 26, 2008 at 12:18 AM, Herbert Graf <RemoveMEmailinglist4EraseMEEraseMEfarcite.net> wrote:
> As for the PIC24, I recently did some work with it and while slower then
> an 18F part, the ICD2 was still more then usable.
>
> I suppose it's a perception thing. In my field I'm used to compiles
> taking half a day, the ICD2 seems very speedy in it's operations
> compared to that.
I see. So you have huge programs. Even the Linux kernel
can be build less than 1 hour now (I have not done this
for a while).
>> In my field I'm used to compiles taking half a day, the ICD2 seems
>> very speedy in it's operations compared to that.
>
> I see. So you have huge programs.
Yeah; He's probably in the same business as I am. It wouldn't be so
bad if after the 1/2 day compile, everything worked, instead of
discovering that someone checked in bad code and now you have to wait
for them to fix it, update your copy, and do the whole thing AGAIN.
> Even the Linux kernel can be build less than 1 hour now
The linux kernel is small. Consider building EVERYTHING for a modern
desktop linux system, including several of the larger specialized apps
(and ALL the normal little apps!) Or binaries with 50MB of code...
>Just for how care's......
>I just got it and first test on PIC24FJ128GA006 with a Program memory
>26871 bytes
>
>programming in debug mode
>
>ICD 2 ---> 52 seconds
>ICD 3 ---> 4 seconds
>
>wow... it's fast
Hmm, I would hope so - the active internals of the ICD3 are an FPGA and a
PIC33, instead of an 18F. The FPGA is a Xilinx Spartan range, which I think
is a RAM device and have an external EEPROM to store the code. Certainly
MPLAB reports the FPGA code revision.
On Wed, 26 Nov 2008 13:25:08 +0100, Vanzo Stefano wrote:
> Hi
> Just for how care's......
> I just got it and first test on PIC24FJ128GA006 with a Program memory
> 26871 bytes
>
> programming in debug mode
>
> ICD 2 ---> 52 seconds
> ICD 3 ---> 4 seconds
>
> wow... it's fast
How is it for debugging speed? (Single stepping, updating watch windows,
displaying registers, etc.) That's always been my biggest gripe with
MPLAB/ICD2. Of the dozen or so inexpensive serial debuggers I have for
various MPUs, that combination is the slowest and most cumbersome. I rarely
use it because of that.
I would think it should be much faster as well since the same serial data
transfer mechanism is used to both program and debug.
It looks like the ICD3 is a step in the right direction.
On Wed, 2008-11-26 at 17:22 +0800, Xiaofan Chen wrote:
> On Wed, Nov 26, 2008 at 12:18 AM, Herbert Graf <RemoveMEmailinglist4spam_OUTKILLspamfarcite.net> wrote:
> > As for the PIC24, I recently did some work with it and while slower then
> > an 18F part, the ICD2 was still more then usable.
> >
> > I suppose it's a perception thing. In my field I'm used to compiles
> > taking half a day, the ICD2 seems very speedy in it's operations
> > compared to that.
>
> I see. So you have huge programs. Even the Linux kernel
> can be build less than 1 hour now (I have not done this
> for a while).
Actually they aren't programs, it's HDL work, but yes, they're huge, and
no matter how fast a machine we get, no matter the number of cores, the
designs just keep getting bigger! :)
That and my FPGA work. Sometimes I can get away with 10 minute compile
+P&R, but often it can reach an hour for a simple change.
>> Try it and you will know how bad it is for PIC32.
>>
>> I also tried it with bigger PIC24. It is really slow to me.
>
> Well FWIW I don't have a PIC32 to try. To be honest, I've been slowly
> drifting away from PICs, shame really.
>
> As for the PIC24, I recently did some work with it and while slower then
> an 18F part, the ICD2 was still more then usable.
>
> I suppose it's a perception thing. In my field I'm used to compiles
> taking half a day, the ICD2 seems very speedy in it's operations
> compared to that.
For PIC32, ICD 2 currently is really not usable. Please refer to
the following threads.
Quote from the above thread of Microchip support's answer.
"Microchip support:
When you select PIC32 device from MPLAB IDE >
Configure > Select device, the yellow LED is observed
in front of the MPLAB ICD 2 debugger. This suggests
that the ICD 2 is in the beta testing version for the
PIC32 devices. Therefore, it may not work correctly.
Also, ICD 2 is slower for the PIC32 devices.
You can use MPLAB ICD 3 or MPAB REAL ICE to
debug the PIC32 devices."
Slow is one thing, buggy and unreliable are more
serious problems. Hopefully Microchip will try
to fix the bugs of ICD 2 more proactively now that
they have the ICD 3 out.
I have to say my icd3 arrived yesterday ! and although I am only doing an
app for a f690 at the moment its rapid compared to the icd2 and it doesn't
keep locking the USB up like the icd 2 used to....
Ns most important..... its got a blue active led !!!! that's so bright it
spills down the other two light pipes... so there is a redish blue on the
status and a greenish blue on the power....
>Hopefully Microchip will try to fix the bugs of
>ICD 2 more proactively now that they have the ICD 3 out.
Not sure they would worry.
1. The ICD2 is known to have problems with buffers dying on the ICD
interface. The ICD3 is claimed to be more rugged in this area.
2. The ICD3 is much faster - the MPLAB help claims it runs at High Speed,
where the 18F USB chip in the ICD2 can only run at Full Speed, so why fix a
slower device?
3. Because of (2), and also the slower processor speed, the ICD2 will always
be considerably slower, whatever it is doing, be it programming or
debugging. Peoples perception of how 'good' a device is will be dominated by
speed (just like speed cameras are used as a dominant way of reducing
accidents), no matter how bug free other aspects of the slower device are
compared to the faster but possibly more bug ridden aspects of the faster
device.
On Thu, Dec 4, 2008 at 5:11 PM, Alan B. Pearce <EraseMEAlan.B.PearcespamspamBeGonestfc.ac.uk> wrote:
>>Hopefully Microchip will try to fix the bugs of
>>ICD 2 more proactively now that they have the ICD 3 out.
>
> Not sure they would worry.
>
> 1. The ICD2 is known to have problems with buffers dying on the ICD
> interface. The ICD3 is claimed to be more rugged in this area.
>
> 2. The ICD3 is much faster - the MPLAB help claims it runs at High Speed,
> where the 18F USB chip in the ICD2 can only run at Full Speed, so why fix a
> slower device?
>
> 3. Because of (2), and also the slower processor speed, the ICD2 will always
> be considerably slower, whatever it is doing, be it programming or
> debugging. Peoples perception of how 'good' a device is will be dominated by
> speed (just like speed cameras are used as a dominant way of reducing
> accidents), no matter how bug free other aspects of the slower device are
> compared to the faster but possibly more bug ridden aspects of the faster
> device.
They should worry because ICD 2 has a very big user base. The
bad words from these broad user base will damage Microchip's
image and transfer to the gains of Atmel. ;-)
> From: Steve Smith <xygaxSTOPspamspam_OUTblueyonder.co.uk>
> Subject: RE: [PIC] Getting ICD3 ?
> To: "'Microcontroller discussion list - Public.'" <spamBeGonepiclistSTOPspamEraseMEmit.edu>
> Date: Thursday, December 4, 2008, 12:36 PM
> I have to say my icd3 arrived yesterday ! and although I am
> only doing an
> app for a f690 at the moment its rapid compared to the icd2
> and it doesn't
> keep locking the USB up like the icd 2 used to....
>
> Ns most important..... its got a blue active led !!!!
> that's so bright it
> spills down the other two light pipes... so there is a
> redish blue on the
> status and a greenish blue on the power....
>
>
> Steve
>
I haven't had to reboot pc from ICD 2 ..... unplug the icd2 and plug it in
another usb port... wait for it to moan about the drivers and then repeat
put it back where it lives and use the connect button that always works for
me....
ICD3
So far so good its done about 9 continuous hours without a crash.... That
beats the ICD2 hands down sometimes its 5 mins before it hangs. Jury's out
til next week... I have to do an f877 at work so I will use it for that and
that will be the acid test....
> From: Steve Smith <EraseMExygaxEraseMEblueyonder.co.uk>
> Subject: RE: [PIC] Getting ICD3 ?
> To: "'Microcontroller discussion list - Public.'" <@spam@piclist@spam@spam_OUTmit.edu>
> Date: Thursday, December 4, 2008, 7:35 PM
> I haven't had to reboot pc from ICD 2 ..... unplug the
> icd2 and plug it in
> another usb port... wait for it to moan about the drivers
> and then repeat
> put it back where it lives and use the connect button that
> always works for
> me....
>
> ICD3
> So far so good its done about 9 continuous hours without a
> crash.... That
> beats the ICD2 hands down sometimes its 5 mins before it
> hangs. Jury's out
> til next week... I have to do an f877 at work so I will use
> it for that and
> that will be the acid test....
>
>
> Steve
>
> On Wed, Nov 26, 2008 at 12:18 AM, Herbert Graf <.....mailinglist4spam_OUTfarcite.net> wrote:
>> On Tue, 2008-11-25 at 07:36 +0800, Xiaofan Chen wrote:
>
>>> Try it and you will know how bad it is for PIC32.
>>>
>>> I also tried it with bigger PIC24. It is really slow to me.
>>
>> Well FWIW I don't have a PIC32 to try. To be honest, I've been slowly
>> drifting away from PICs, shame really.
>>
>> As for the PIC24, I recently did some work with it and while slower then
>> an 18F part, the ICD2 was still more then usable.
>>
>> I suppose it's a perception thing. In my field I'm used to compiles
>> taking half a day, the ICD2 seems very speedy in it's operations
>> compared to that.
>
> For PIC32, ICD 2 currently is really not usable. Please refer to
> the following threads.
>
> The poster has chosen to go for ICD 3:
> http://forum.microchip.com/tm.aspx?m=387649
>
> Microchip recommends the user to go for ICD 3 or Real ICE.
> http://forum.microchip.com/tm.aspx?m=383797
> http://forum.microchip.com/tm.aspx?m=387475
>
On the other hand, I am trying a few USB examples with
PIC24FJ256GB110 and ICD 2 works fine. Last year
when I tried ICD 2 with the other PIC24 and it was quite bad.
So there are some progress in this front. Hopefully they
will fix the PIC32 issues soon.
> I have to say my icd3 arrived yesterday ! and although I am only doing an
> app for a f690 at the moment its rapid compared to the icd2 and it doesn't
> keep locking the USB up like the icd 2 used to....
Yes. Mine arrived about 10 days ago and I also noticed that. I'm
just using it with a PIC18F252 and it seens way faster and reliabler
than the ICD2 (that I have but almost haven't used it because it locks a
lot on my laptop computer).
Next week I'll start with a project that uses a dsPIC33 and I think
it will be very usefull.
I also liked that when idle, it just pulls down the PGC and PGD
lines with a 4k7 resistor. That way you still can use it for programming
devices that have those lines connected to something (like LCD data
lines). ICD2 doesn't allows that. It seens that the PGC (or PGD, I don't
remember well) is always tied to an enabled output and your device can't
run correctly with it connected if your firmware/hardware uses PGC and PGD.
Of course, you can't debug (fully) if you use those pins.
> Ns most important..... its got a blue active led !!!! that's so bright it
> spills down the other two light pipes... so there is a redish blue on the
> status and a greenish blue on the power....
Yes, and it's very annoying. I hate overbright blue LEDs but it
seens that it's a tendency to put them in every new gadget.
I have an USB audio interface from M-Audio that does have a blue
LED to show it's powered. I had to put a piece of black adesive tape on
it because it was impossible to read anything on it's front panel when
the studio/stage lights were dimm.
Of course, I've opened my ICD3 and put a piece of white adesive
between the blue LED and it's lightpipe. Now I can see if the status LED
is red or orange.
Best regards,
Brusque
--
---------------------------------------------------------------------
Edson Brusque Stagetronics Eletro Eletrônicos Ltda
Research and Development Blumenau - SC - Brazil http://www.ryan.com.br/netiqueta.htmhttp://www.citronics.com.br
---------------------------------------------------------------------
> Of course, I've opened my ICD3 and put a piece of white adesive
> between the blue LED and it's lightpipe. Now I can see if the status LED
> is red or orange.
So isn't it possible to replace the blue-bright LED to something else which
is not that annoying? I mean by ourself - I doubt if MC would make that
change on future ICD3 runs.
> Hello!
>
> > I have to say my icd3 arrived yesterday ! and although I am only doing an
> > app for a f690 at the moment its rapid compared to the icd2 and it
> doesn't
> > keep locking the USB up like the icd 2 used to....
>
> Yes. Mine arrived about 10 days ago and I also noticed that. I'm
> just using it with a PIC18F252 and it seens way faster and reliabler
> than the ICD2 (that I have but almost haven't used it because it locks a
> lot on my laptop computer).
>
> Next week I'll start with a project that uses a dsPIC33 and I think
> it will be very usefull.
>
> I also liked that when idle, it just pulls down the PGC and PGD
> lines with a 4k7 resistor. That way you still can use it for programming
> devices that have those lines connected to something (like LCD data
> lines). ICD2 doesn't allows that. It seens that the PGC (or PGD, I don't
> remember well) is always tied to an enabled output and your device can't
> run correctly with it connected if your firmware/hardware uses PGC and PGD.
>
> Of course, you can't debug (fully) if you use those pins.
>
> > Ns most important..... its got a blue active led !!!! that's so bright it
> > spills down the other two light pipes... so there is a redish blue on the
> > status and a greenish blue on the power....
>
> Yes, and it's very annoying. I hate overbright blue LEDs but it
> seens that it's a tendency to put them in every new gadget.
>
> I have an USB audio interface from M-Audio that does have a blue
> LED to show it's powered. I had to put a piece of black adesive tape on
> it because it was impossible to read anything on it's front panel when
> the studio/stage lights were dimm.
>
> Of course, I've opened my ICD3 and put a piece of white adesive
> between the blue LED and it's lightpipe. Now I can see if the status LED
> is red or orange.
>
> Best regards,
>
> Brusque
>
> --
> ---------------------------------------------------------------------
> Edson Brusque Stagetronics Eletro Eletrônicos Ltda
> Research and Development Blumenau - SC - Brazil
> http://www.ryan.com.br/netiqueta.htmhttp://www.citronics.com.br
> ---------------------------------------------------------------------
>
>
>
>Of course, I've opened my ICD3 and put a piece of white adesive
>between the blue LED and it's lightpipe. Now I can see if the
>status LED is red or orange.
Must do that. I did put some black heatshrink on each light pipe to stop the
blue spilling over into the others.
Might be tempted to see what resistor value the blue LED has, and increase
it, as an alternative to using tape.
stfc.ac.uk> wrote:
