Searching \ for '[EE] real ICE versus ICD2' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=icd
Search entire site for: 'real ICE versus ICD2'.

Exact match. Not showing close matches.
PICList Thread
'[EE] real ICE versus ICD2'
2007\04\13@144157 by Vasile Surducan

face picon face
Someone ask me if real ICE is a helpfull device for developing
prototypes. As long I have never use it, my impressions are based on
ICE and ICD2 datasheets.
The explanation I've found is on page 8 of ICD2 datasheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/51331B.pdf

If there is any ICE user here, I really appreciate any information
about how good emulation is providing the real ICE (mostly for PIC16F
series) and if there is a real
benefit in using ICE (as a real emulator) instead of ICD2.

thx,

2007\04\13@190141 by Xiaofan Chen

face picon face
On 4/14/07, Vasile Surducan <spam_OUTpiclist9TakeThisOuTspamgmail.com> wrote:
> If there is any ICE user here, I really appreciate any information
> about how good emulation is providing the real ICE (mostly for PIC16F
> series) and if there is a real
> benefit in using ICE (as a real emulator) instead of ICD2.
>

I am not a Real ICE user yet but Real ICE does not support PIC16F.

2007\04\13@203946 by Vitaliy

flavicon
face
Xiaofan Chen wrote:
> On 4/14/07, Vasile Surducan <.....piclist9KILLspamspam@spam@gmail.com> wrote:
>> If there is any ICE user here, I really appreciate any information
>> about how good emulation is providing the real ICE (mostly for PIC16F
>> series) and if there is a real
>> benefit in using ICE (as a real emulator) instead of ICD2.
>>
>
> I am not a Real ICE user yet but Real ICE does not support PIC16F.

It doesn't support PIC18F, either.

Vitaliy

2007\04\14@020143 by Vasile Surducan

face picon face
On 4/13/07, Vitaliy <spamspamKILLspammaksimov.org> wrote:
> Xiaofan Chen wrote:
> > On 4/14/07, Vasile Surducan <.....piclist9KILLspamspam.....gmail.com> wrote:
> >> If there is any ICE user here, I really appreciate any information
> >> about how good emulation is providing the real ICE (mostly for PIC16F
> >> series) and if there is a real
> >> benefit in using ICE (as a real emulator) instead of ICD2.
> >>
> >
> > I am not a Real ICE user yet but Real ICE does not support PIC16F.
>
> It doesn't support PIC18F, either.
>

Thanks, I found finally those info on page 20 of DS51616A. It seems is
good only for DSC/PIC24.

2007\04\14@044958 by Xiaofan Chen

face picon face
On 4/14/07, Vitaliy <EraseMEspamspam_OUTspamTakeThisOuTmaksimov.org> wrote:
> > I am not a Real ICE user yet but Real ICE does not support PIC16F.
>
> It doesn't support PIC18F, either.
>

It has some beta support for PIC18F.

2007\04\14@064136 by Gerhard Fiedler

picon face
Vasile Surducan wrote:

> [...] and if there is a real benefit in using ICE (as a real emulator)
> instead of ICD2.

In general, an ICE has a few advantages compared to something like an ICD2.
How extensive the advantages are depends a lot on the specific features.

One thing I liked when working with an ICE (it's been a while :) is
execution history. When you hit a breakpoint, you can see how it got there.
This can help a lot. Another thing are more complex breakpoint conditions:
want to see whether a certain data gets changed in a certain piece of code?
Just combine a data write to an address range with an execution pointer
range. (This feature is very different among different ICEs.)

Gerhard

2007\04\15@054153 by John Chung

picon face
I am quite satisfied with simple breakpoints. :) On
the PC most development involves print lines but
debuggers helps plenty at hardware level programming.

John


--- Gerhard Fiedler <listsspamspam_OUTconnectionbrazil.com>
wrote:

{Quote hidden}

> --

2007\04\15@093534 by Gerhard Fiedler

picon face
John Chung wrote:

> I am quite satisfied with simple breakpoints. :)

Well, I make do mostly even without them :)

But having a deep execution history is /really/ nice. Something goes wrong,
you stop it, and just browse through the history (that's linked to the
source code) and see exactly how and why it got there. With full bus trace
-- which means that you not only have the addresses where the code went,
you have all the values the CPU read or wrote also, be that registers,
memory locations, IO ports, HLL variable values, anything. This is not
something even a comfortable PC debugger can give you.

Of course, I know, emulators are for sissies... :)

(If you're interested, check out the ICE from http://www.lauterbach.com/ --
they're pretty neat.)

Gerhard

2007\04\15@105534 by Tony Smith

picon face
> John Chung wrote:
>
> > I am quite satisfied with simple breakpoints. :)
>
> Well, I make do mostly even without them :)
>
> But having a deep execution history is /really/ nice.
> Something goes wrong, you stop it, and just browse through
> the history (that's linked to the source code) and see
> exactly how and why it got there. With full bus trace
> -- which means that you not only have the addresses where the
> code went, you have all the values the CPU read or wrote
> also, be that registers, memory locations, IO ports, HLL
> variable values, anything. This is not something even a
> comfortable PC debugger can give you.


Quickbasic v3 (possibly v4 as well) would let you run programs backwards (up
to about 20 instructions IIRC) from a breakpoint.

I wrote an emulator that tracked everything, and would let you jump back to
any point, and then restart the program.  Thankfully it was a very HLL (sort
of) with very few instructions per second.

Tony

2007\04\15@233032 by John Chung

picon face
Yeah I can imagine trace history. Cool feature to
have. Easier on development. Still nothing bets well
placed debugging logic :) I try not to use a debugger
for not being to dependent on such assortment which
might not exist on other development tools.

Regards,
John


--- Gerhard Fiedler <@spam@listsKILLspamspamconnectionbrazil.com>
wrote:

{Quote hidden}

> --

2007\04\16@053438 by Matt Pobursky

flavicon
face
On Sun, 15 Apr 2007 20:30:31 -0700 (PDT), John Chung wrote:
> Yeah I can imagine trace history. Cool feature to have. Easier on
> development. Still nothing bets well placed debugging logic :)

There are plenty of circumstances there the application code can't tolerate
*any* additional code for debugging or it simply won't work. This is where
hardware emulators really shine.

> I try not to use a debugger for not being to dependent on such assortment
> which might not exist on other development tools.

Interesting, I find just the opposite. I rarely use a simulator, maybe once
or twice a year for a given MPU family. Most (90% ?) of my debugging is
with hardware hooked up to real world devices debugging those processes,
not the hardware independent aspects of the software.

I currently develop with 6-8 different MCU families and will freely switch
from one to another when it fits the project. When I'm looking at a new MCU
family, the first thing I look at is whether it has a good C compiler,
relatively non-intrusive on-chip debug facilities and a good IDE debugger
(tightly coupled with the C compiler).

As much as I like PICs, I think the available PIC tools are making a slow
slide downward versus what's available for a lot of other chip families.
The ICSP/ICD methods Microchip uses are getting a bit long in the tooth and
I'm finding it harder and harder to work around some of their warts.

I doubt I'll ever go completely away from developing with PICs but they
certainly aren't the easiest to develop with anymore and usually not my
first choice, all things being equal.

Matt Pobursky
Maximum Performance Systems


2007\04\16@054006 by Matt Pobursky

flavicon
face
On Mon, 16 Apr 2007 00:56:10 +1000, Tony Smith wrote:
{Quote hidden}

Well the whole point of the hardware emulator trace buffer is being able to
capture and analyze a large number (8K to 64K or more) of instructions non-
intrusively in real-time so that the process you are observing runs as it
will in the final application. There are many real-time applications that
can only be analyzed this way.

Matt Pobursky
Maximum Performance Systems


2007\04\16@060635 by Mike Harrison

flavicon
face
On Mon, 16 Apr 2007 04:34:35 -0500, you wrote:

>On Sun, 15 Apr 2007 20:30:31 -0700 (PDT), John Chung wrote:
>> Yeah I can imagine trace history. Cool feature to have. Easier on
>> development. Still nothing bets well placed debugging logic :)
>
>There are plenty of circumstances there the application code can't tolerate
>*any* additional code for debugging or it simply won't work. This is where
>hardware emulators really shine.

And features like 'trigger out' when certain instructions get executed can save an awful lot of
debug time...

>
>> I try not to use a debugger for not being to dependent on such assortment
>> which might not exist on other development tools.
>
>Interesting, I find just the opposite. I rarely use a simulator, maybe once
>or twice a year for a given MPU family. Most (90% ?) of my debugging is
>with hardware hooked up to real world devices debugging those processes,
>not the hardware independent aspects of the software.

I have never used a simulator - most embedded projects are so dependent on outside stimulus which is
hard/time-consuming or impractical to simulate.

{Quote hidden}

I'm surprised at this comment - I certainly agree  ICD can be somwhat primitive ( no WDT - er...
hello?), and being an early starter in the market, ICD is showing its age, but MPLAB ICE2000 is
streets ahead of most other offerings on similar-class micros - 'proper' ICEs like this are becoming
a rarity these days - Atmel seem to have abandoned their ICE range, although Debugwire/Jtag work
reasonably well as long as you use them with something less flaky than the dreadful AVR Studio.
Speed and packaging issues mean that we are probably seeing the end of 'real' ICEs, so the
limitation of on-chip debug systems will be an increasingly important factor.

>I doubt I'll ever go completely away from developing with PICs but they
>certainly aren't the easiest to develop with anymore and usually not my
>first choice, all things being equal.

All things being equal, I still tend towards PICs, for the sole reason that I have a proper ICE,
which can easily  save days of dev time, and MPLAB is solid and reliable.



2007\04\16@094843 by Gerhard Fiedler

picon face
Matt Pobursky wrote:

>>> But having a deep execution history is /really/ nice. [...] This is not
>>> something even a comfortable PC debugger can give you.
>>
>> Quickbasic v3 (possibly v4 as well) would let you run programs
>> backwards (up to about 20 instructions IIRC) from a breakpoint.
>>
>> I wrote an emulator that tracked everything, and would let you jump
>> back to any point, and then restart the program.  Thankfully it was a
>> very HLL (sort of) with very few instructions per second.
>
> Well the whole point of the hardware emulator trace buffer is being able
> to capture and analyze a large number (8K to 64K or more) of
> instructions non- intrusively in real-time so that the process you are
> observing runs as it will in the final application. There are many
> real-time applications that can only be analyzed this way.

And it's also a very helpful tool to track down compiler/interpreter bugs
-- for which a backtracking built into the interpreter might not be /that/
useful :)

Gerhard

2007\04\16@102056 by Matt Pobursky

flavicon
face
On Mon, 16 Apr 2007 11:06:41 +0100, Mike Harrison wrote:
> And features like 'trigger out' when certain instructions get executed
> can save an awful lot of debug time...

Yeah, I almost forgot about that -- hardware triggered hardware triggers!
An excellent resource for triggering your 'scope or logic analyzer on the
one condition that occurs only once in a blue moon while swinging a dead
cat... ;-)

>> Interesting, I find just the opposite. I rarely use a simulator, maybe
>> once or twice a year for a given MPU family. Most (90% ?) of my
>> debugging is with hardware hooked up to real world devices debugging
>> those processes, not the hardware independent aspects of the software.
>>
> I have never used a simulator - most embedded projects are so dependent
> on outside stimulus which is hard/time-consuming or impractical to
> simulate.

Same here. In fact I can't remember the last time I used a simulator. It
has to be at least 18 months or more. If I do use one, it's generally for
something like a math/filtering algorithm that truly is hardware and
outside stimulus independent.

It's funny but even though I do quite a bit of analog design, I find myself
using SPICE simulation only occasionally as well.

{Quote hidden}

I was really just referring to the ICSP/ICD interface. The ICE2000 is a
fine piece of kit. I wish more manufacturers made decent emulators. The
ICE2000 is reasonably priced too, for what you get. 3rd party emulator
makers are in a tough situation -- it takes enormous resources to develop
and maintain the hardware and software for an emulator family and they'll
never sell more than a few 1000 of them (if they're lucky). They also have
to worry about manufacturers dropping a chip family at any time and also
about whether they'll be able to get "bond-out" chips for the pods, etc.

We use AVRs, MSP430s, various flavors of ARMs and a few other families as
well as PICs in our designs. Right now, the least problematic tools are the
MSP430 and ARM tools. They cause us the least grief in hardware and have
the best debuggers.

We're using Rowley Associates Crossworks for the AVR and it's *so much
better* than AVR Studio it's not even a comparison. We also use their ARM
tools and they are equally excellent. We'll probably switch to their MSP430
tools at some point as well.

My biggest gripes with the PIC ICSP/ICD interface is with low voltage
programming and sharing port pins with the ICSP/ICD interface. The trend
with other manufacturers seems to be add more pins and use dedicated
OCD/programming pins. I like this trend. I do almost all SMD designs for
several years now and adding 3 or 4 pins at .5mm or .65mm pin spacing is
not a big space issue for me, even on the smaller packages. Working with
PICs at 3.3V or less is also a pin. We all know about no bulk erase below
4.5V. I won't add extra hardware to make my boards 5V tolerant or jerry rig
the power to the PIC just because the flash process is old or the on-chip
charge pumps can't make programming voltage at 3V. I really hope they
improve these things with the newer PICs of the future.

I also have issues with MPLAB (much like AVR studio but for different
reasons). C Source level debugging under MPLAB is kind of primitive,
especially with 3rd party compilers. And since Microchip only has one "ok"
compiler (C18, if you are using a 16F you are SOL), you're likely going to
be using a 3rd party compiler. I gave up on MPLAB for my PIC 16F and 18F
applications and use CCS C and their IDE/Debugger now since it covers both
16F and 18F families and the compiler and debugger are tightly coupled.

FWIW, I like the ICD pods from CCS better than Microchip's ICD2 also as
they are a lot smaller and only cost $75 each. They also supply a free
standalone programming application so for $75 I can setup a programming
station for clients or a production line.

>> I doubt I'll ever go completely away from developing with PICs but they
>> certainly aren't the easiest to develop with anymore and usually not my
>> first choice, all things being equal.
>>
> All things being equal, I still tend towards PICs, for the sole reason
> that I have a proper ICE, which can easily  save days of dev time, and
> MPLAB is solid and reliable.

I guess my main point was that with many of the newer chips I'm finding
less of a need for a hardware ICE. The MSP430 and ARM OCD functions are
pretty nice, I really like developing with them. Hopefully Microchip will
improve on their debugger and programming interfaces and not cling to basic
designs that were done in the late 90's...

Matt Pobursky
Maximum Performance Systems


More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...