How does PICkit 2 compare to ICD2, when used for debugging (specifically,
the 18F series)? We have ICD2 and RealCE, and are looking to buy another
ICD2, but if PICkit 2 has similar performance...
I do not know any of those, I was just thinking if you buy 5pcs cheap stuff
you are at the same money as ICD2 (original) but until each works 5 firmware
engineers could work simultaneously. I may wrong on this approach and there
are other things for sure not just price/reliability/debugging capability...
BTW I am not sure if you can debug with Olin's usb programmer?
Regards
Tamas
On 11/1/07, Vitaliy <spam_OUTspamTakeThisOuTmaksimov.org> wrote:
>
> Resending with a new subject.
>
> How does PICkit 2 compare to ICD2, when used for debugging (specifically,
> the 18F series)? We have ICD2 and RealCE, and are looking to buy another
> ICD2, but if PICkit 2 has similar performance...
>
>
> -
On 11/2/07, Vitaliy <.....spamKILLspam@spam@maksimov.org> wrote:
> Resending with a new subject.
>
> How does PICkit 2 compare to ICD2, when used for debugging (specifically,
> the 18F series)? We have ICD2 and RealCE, and are looking to buy another
> ICD2, but if PICkit 2 has similar performance...
Maybe you want to consider PICkit 2 instead. I believe MPLAB 8.0
will make PICkit 2 debugging better than now (may not catch
ICD2, but good enough for 16F/18F). PICkit 2 is already a
better programmer than ICD2.
>
> I do not know any of those, I was just thinking if you buy 5pcs cheap stuff
> you are at the same money as ICD2 (original) but until each works 5 firmware
> engineers could work simultaneously. I may wrong on this approach and there
> are other things for sure not just price/reliability/debugging capability...
>
> BTW I am not sure if you can debug with Olin's usb programmer?
>
> Regards
> Tamas
>
> "Never actually use the PK2 or ICD2 as a debugger."
>-- what?! Why not? I use ICD2 for debugging, very happy with it..
I do not use PICs right now at work so no real need for debugging.
I did not like quite ICD2 as a debugger last time I tried with dsPIC33
and PIC24 on the Explorer 16 board. It is quite slow. And PICKit 2
will be similar if it supports PIC24/dsPIC33 later. I have
not played with Real-ICE. I liked MPLAB ICE2000 better but it
does not support 3.3V parts like 18J/PIC24/dsPIC33.
In fact, I like J-Link for ARM7 MCUs better than ICD2. I also
liked the JTAG debugger for Silabs 8051 MCU and MSP430
MCUs even though I only played a bit.
In terms of debugging capability, PICkit 2 is capable as ICD2
in terms of hardware. Walter (PICkit 2 developer) is working
hard to get more debugging support for PICkit 2.
On 11/2/07, Vitaliy <EraseMEspamspam_OUTTakeThisOuTmaksimov.org> wrote:
> "Never actually use the PK2 or ICD2 as a debugger." --
> what?! Why not? I use ICD2 for debugging, very happy with it..
By the way, I do not think I wrote this in the forum post.
I've used both and I do not like either of them. It is quite usable
for the 16F917 I tested. I also used ICD2 last time for 12F629,
a real pain to use because of the limitations. I've tried to use
ICD2 with PIC24/dsPIC33 on the Explorer 16 demo board,
I think it is not good, much worse compared to using J-Link
on the TMS470 ARM7 MCU.
For debugging, I would recommend ICE2000 or other professional tools for beginners who doesn't have much experience on PICs. The pain on ICE2000 is you need spend extra money to buy modules everytime for new chipsets.
For PIC experts, who already has lots of C code to be reused and knows a lot about PICs, both the ICD2 and PICkit2 are good toolsets for them.
Most of the time, the experts just need a tool to verify the code design by set up limited break-points and watch window for variables.
I personally spend very few time for debugging (I own ICE2000, ICD2 and PICkit2). Most of the time, the C code I wrote runs correct in the first shot. I think the HI-Tech C compilor also helps a lot.
I may be wrong here: I spend many time thinking about my code instead debugging my code.
Funny NYPD wrote:
> For debugging, I would recommend ICE2000 or other professional tools for beginners who doesn't have much experience on PICs. The pain on ICE2000 is you need spend extra money to buy modules everytime for new chipsets.
>
>
Maybe if you have a lot of money and need to sort out a particularlly
difficult problem, for most begginers though I don't think it is
suitable for three reasons.
1: the cost of the ice2000 itself
2: the cost of the heads
3: the fact that you have to work out how to integrate the head into the
setup being debugged, this is much harder than hooking a couple of wires
to pgc and pgd
For beginners the best I think is an emulator, something like
Virtualbreadboard or Proteus. I've learnt PIC basically on MPSIM. Then you
can have a demo board that is built together with the programmer.
BTW I still prefer emulator to test some algorithm if the theory behind it
is ok (of course for final test a real circuit debugger or a "test and hope"
is better once that algo works fine on the sim).
>
> Funny NYPD wrote:
> > For debugging, I would recommend ICE2000 or other professional tools for
> beginners who doesn't have much experience on PICs. The pain on ICE2000 is
> you need spend extra money to buy modules everytime for new chipsets.
> >
> >
> Maybe if you have a lot of money and need to sort out a particularlly
> difficult problem, for most begginers though I don't think it is
> suitable for three reasons.
>
> 1: the cost of the ice2000 itself
> 2: the cost of the heads
> 3: the fact that you have to work out how to integrate the head into the
> setup being debugged, this is much harder than hooking a couple of wires
> to pgc and pgd
>
Yes that's true. For that there is the demo board - for a beginner,
experiencing the de-bouncing problem for example those are perfect. To learn
programming and architecture, and also how to drive an LCD for instance
these emulators are quite good in my opinion.
Tamas
On 11/2/07, peter green <@spam@plugwashKILLspamp10link.net> wrote:
>
> Tamas Rudnai wrote:
> > For beginners the best I think is an emulator, something like
> > Virtualbreadboard or Proteus.
>
> Yes and no, I think such tools are usefull but they are no substitute
> for gaining experiance with real hardware.
>
>
> -
For me it's easier to solder some circuit than learn how to use simulator:)
On 11/2/07, Tamas Rudnai <KILLspamtamas.rudnaiKILLspamgmail.com> wrote:
> Yes that's true. For that there is the demo board - for a beginner,
> experiencing the de-bouncing problem for example those are perfect. To learn
> programming and architecture, and also how to drive an LCD for instance
> these emulators are quite good in my opinion.
>
> Tamas
>
> On Behalf Of peter green
>
> Tamas Rudnai wrote:
> > For beginners the best I think is an emulator, something like
> > Virtualbreadboard or Proteus.
>
> Yes and no, I think such tools are usefull but they are no substitute
> for gaining experiance with real hardware.
And producing an expected result in an emulator is nothing like the buzz you
get from making real hardware do what you intended - even if it's just
lighting a LED or writing "Hello world" on an LCD. Sure, the learning is
the same as with an emulator, but after a while that's a bit boring compared
with making something real happen - and maintaining interest is important
for learning.
Yes, I agree with this one too, but there are some circumstances where a
simulator is better than a real hw. For example I've made a small signal
filter and something was wrong with my code. To find out what is the problem
I needed to debug the code line by line (as written in assembly, cycle by
cycle). The failure dependent on couple of us so you cannot even track it
down on debug hw I suppose. Just made a good stimulus file (actually
digitalized an input sample and transformed into SCL) and the rest was easy.
Of course I've enjoyed the result on the real thing, not on the screen :-)
>
> > On Behalf Of peter green
> >
> > Tamas Rudnai wrote:
> > > For beginners the best I think is an emulator, something like
> > > Virtualbreadboard or Proteus.
> >
> > Yes and no, I think such tools are usefull but they are no substitute
> > for gaining experiance with real hardware.
>
> And producing an expected result in an emulator is nothing like the buzz
> you
> get from making real hardware do what you intended - even if it's just
> lighting a LED or writing "Hello world" on an LCD. Sure, the learning is
> the same as with an emulator, but after a while that's a bit boring
> compared
> with making something real happen - and maintaining interest is important
> for learning.
>
>
> David Meiklejohn
> http://www.gooligum.com.au
>
>
On 11/3/07, peter green <spamBeGoneplugwashspamBeGonep10link.net> wrote:
> Funny NYPD wrote:
> > For debugging, I would recommend ICE2000 or
> > other professional tools for beginners who doesn't
> > have much experience on PICs. The pain on ICE2000
> > is you need spend extra money to buy modules
> > everytime for new chipsets.
> >
> >
> Maybe if you have a lot of money and need to sort out a
> particularlly difficult problem, for most begginers though
> I don't think it is suitable for three reasons.
>
> 1: the cost of the ice2000 itself
> 2: the cost of the heads
> 3: the fact that you have to work out how to integrate
> the head into the setup being debugged, this is much
> harder than hooking a couple of wires
> to pgc and pgd
>
Actually I started with PIC at work and had the luxury
to buy all the best tools at the time (early year
2000): ICE2000, Promate II and HiTech PICC 7.85.
It was a smooth start and I finished the learning
and coding process pretty fast.
The problem is that ICE2000 does not support the
new 3.3V only PICs like PIC18J/PIC24/dsPIC33.
Real-ICE is said to be the tools of choice for
PIC24/dsPIC33. I think ICD2 is ok for its price. However
for professional work and larger program (like
bigger 18F, PIC24 and dsPIC33), it is not so good.
On 11/3/07, Tamas Rudnai <TakeThisOuTtamas.rudnaiEraseMEspam_OUTgmail.com> wrote:
> Yes, I agree with this one too, but there are some circumstances where a
> simulator is better than a real hw. For example I've made a small signal
> filter and something was wrong with my code. To find out what is the problem
> I needed to debug the code line by line (as written in assembly, cycle by
> cycle). The failure dependent on couple of us so you cannot even track it
> down on debug hw I suppose. Just made a good stimulus file (actually
> digitalized an input sample and transformed into SCL) and the rest was easy.
> Of course I've enjoyed the result on the real thing, not on the screen :-)
>
> Tamas Rudnai wrote:
>> For beginners the best I think is an emulator, something like
>> Virtualbreadboard or Proteus.
>
> Yes and no, I think such tools are usefull but they are no substitute
> for gaining experiance with real hardware.
The point isn't an either-or, it's that if a program doesn't run in the
simulator, there is little chance that it will run on the target hardware
(if the simulator works correctly). Getting to that point is often already
a challenge, especially for beginners, and a simulator provides much better
tools for this than the normally restricted budget of a hobbyist can afford
for working on the target hardware. Once the program runs correctly in the
simulator, it's much easier to make it work on the target hardware.
Xiaofan Chen wrote:
>> "Never actually use the PK2 or ICD2 as a debugger." --
>> what?! Why not? I use ICD2 for debugging, very happy with it..
>
> By the way, I do not think I wrote this in the forum post.
No, someone else made that comment, and I did not quote verbatim.
maksimov.org> wrote:
