LPC213x IDE

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Friends,

For a current LPC213x project we purchased the IAR Embedded Workbench
development kit (about $4k if I remember right) with a J-link USB->JTAG.
It's "ok", but it doesn't give me that warm and fuzzy feeling of
complete trust. The UI behaves funky (resizing toolboxes by itself,
suddenly refusing to set breakpoints, etc.), the compiler seems to be
a bit buggy sometimes, and the C library have a few quirks too.

Did anyone out there try the Keil IDE for ARM7? Anyone with experience
from both IAR and Keil? Is the GNU stuff an option if I don't want to
spend two months setting up my debugging environment?

Thanks,
  </A>

Re: LPC213x IDE


Quoted text here. Click to load it

I have a longtime loathing for IAR.

JTAG oddities are, however, not necessarily the toolchain's fault -
there's a lot of potential bringup hair-pulling caused by the target.
I've just squashed a very annoying intermittent problem I was having
with my AVR JTAG debugging setup, which turned out to be caused by
fluctuations in VREF (nowhere in the documentation can I find it stated
that the JTAG interface requires VREF, by the way!)

Quoted text here. Click to load it

gcc is my preferred ARM development environment. I don't know how well
you will fare with that particular JTAG adapter, though.


Re: LPC213x IDE
Quoted text here. Click to load it

 > JTAG oddities are, however, not necessarily the toolchain's fault -
 > there's a lot of potential bringup hair-pulling caused by the target.

One annoying issue I have is that the JTAG doesn't stop the timers.
That causes my OS to freak out since it's missing ticks and effectively
limits debugging to having to reset after every breakpoint. If I had any
hair I would have pulled it by now - but like you say, that's not the
tools fault ;)

 > gcc is my preferred ARM development environment. I don't know how well
 > you will fare with that particular JTAG adapter, though.

gcc is just the compiler, right? I'd need a debugger too I guess?
Is there a package put together with compiler/linker/debugger
all-in-one, ready to install and run? What adapter should I get?

Thanks,
  </A>

Re: LPC213x IDE


Quoted text here. Click to load it

When I say "gcc" I'm really referring to the complete GNU toolchain,
comprising GNU make, gas assembler, gcc compiler, ld linker, gdb
debugger, etc. If you require graphical frippery, insight is the
graphical layer over gdb.

http://www.macraigor.com/swproducts.htm is one fast place to get
precompiled binaries for ARM. I have their Wiggler cheap low-end
parallel port JTAG tool. Olimex sells one much cheaper which is
essentially the same hardware.


Re: LPC213x IDE
Quoted text here. Click to load it

If you can afford it, I can recommend GreenHills Multi2000. Excellent tools,
once you get used to it. Although, I am not using it with flash-based
devices,
but I debug code from RAM...

- Dejan



Re: LPC213x IDE
have a look here

http://www.keil.com/benchmks/carm_v0code.htm

Quoted text here. Click to load it



Re: LPC213x IDE
Quoted text here. Click to load it

Thanks,
I've seen that, and even though I'm sure it's biased a bit I must
admit it scares me from using gcc stuff. I'm doing some pretty
serious cruching (AES,GSM,tight comms timing) so a compiler that
spits out slow code is the last thing I want.
..but I'll try anything once ;)

I've used uVision before on other targets, but not the debugger.

Does it support profiling/code coverage through JTAG or is that
a limitation of the target? IAR has the feature, but it only works
in simulation mode so it's useless for me...

Re: LPC213x IDE


Quoted text here. Click to load it

Yes, I'm sure it's totally unbiased :)

Since Keil is now owned by ARM, I would expect their compiler quality
to be at the forefront of ARM technology, if not now then soon.

In my projects _to date_ this has not been critical. Once in a while I
have asked colleagues to compile code snippets for me in alien
compilers to see if there is a significant performance difference. I
have not so far found any difference that would lead to my use of gcc
requiring a "bump" in CPU performance. The optimizations that mean the
most to me stem from judicious choice of algorithms and (where
necessary) snippets of assembly language. YMMV, of course.


Re: LPC213x IDE
Quoted text here. Click to load it

Aha! That was a piece of news I had missed. That certainly gives Keil
an edge for the future. Now I know what to put in my budget for 2006 :)

Thanks for the insight!

I'll still give gcc a go some day. If I get my stuff to run I'll
post the results.

Re: LPC213x IDE

Quoted text here. Click to load it

That page is starting to get me really annoyed.

Look at this:

<http://www.compuphase.com/dhrystone.htm

It looks like Keil did not even turn on optimization for GNU (but they
did for their own tools!).

Surprise surprise - their tools, *with* optimisation, were better than
free tools, *not* optimised. But the real surprise is that when
optimisation was turned on for both, it was the *free* tools that were
better than Keils!


--

John Devereux

Re: LPC213x IDE
Quoted text here. Click to load it

Also see this:
http://www.raisonance.com/products/STR7/benchmark.php
with results that are much more in line with my (limited) experience with
the Keil compiler.

Karl Olsen




Re: LPC213x IDE

Quoted text here. Click to load it

Thanks, I was not aware of that.

"These results show clearly that the GNU C Compiler is a good choice
in comparison with the other compilers tested here in terms of both
code size and speed optimizations. However, when code size is an issue
in your embedded application, users need to be aware of the impact GNU
libraries such as printf can have on code size.  The Code Size tests
run in this benchmark demonstrate the extent to which the GNU Compiler
can be handicapped by a very complete printf library that serves
little purpose in embedded applications. Excluding printf, IAR, GNU
and ARM Compilers produced similar, consistent results in terms of
Pure C Code Size, which we have considered a better measure for
embedded applications than Code Size including printf. In addition,
for embedded applications that use printf, or other GNU libraries, the
results demonstrate that using a simplified version of the GNU
libraries can improve results so that they are in line with the other
tested compilers.  In speed tests without floating point numbers, GNU
attained the best results when compiling in Normal Mode and was a very
close second to ARM when compiling in Thumb Mode. In addition, for
speed tests with floating point numbers, GNU's speed of execution
result is nearly as good as the best speed result from ARM."

The following table summarizes the main results in this comparison:

             Summary A: Ratios for "Pure C Code size" and Speed for 10 programs.
                 The Code size is measured without the libraries (printf
removed).

                    KEIL                IAR              GNU               ARM  
         BEST
              Normal    Thumb    Normal   Thumb    Normal   Thumb    Normal  
Thumb   Normal Thumb


                 1.7      1.3      1.1       1.1     1.2       1.1      1      
 1
1. Code Size
                                                                                
      ARM   ARM
   (no FP)


                 1.8      1.6      1.1       1.2      1         1      1.1      
 1
  2. Speed
                                                                                
      GNU   ARM
    (no FP)



             Summary B: Ratios for "Pure C Code size" and Speed for "Whetstones"
                          (calculation with 64-bit floating point numbers)

                                    1         1       1         1      1.2    
1.1
3. Code Size
  (with FP)


                                   2.3       2.3     1.1       1.2     1.0      
1.0
  4. Speed
                                                                                
      ARM   ARM
 
 (with FP)



--

John Devereux

Re: LPC213x IDE
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

I am in the process of revising my txtio package for some general
improvements.  At present it contains only numeric input, but I
also have various output routines which I hope to add real soon
now.  The common theme is that they do not require buffers, and
work with C streams.  The input routines are well behaved, so that
the programmer can know what terminated a field, and whether a line
has been absorbed.  They also report overflows.

Using these you can avoid such monstrous interpreters being loaded.

You can snoop about on my site, URL in the organization header.

--
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: LPC213x IDE
snipped-for-privacy@spam.com says...
Quoted text here. Click to load it

Take a look at CrossStudio for ARM.
It is a custom IDE using GCC for the grunt work.
www.rowley.co.uk

--Gene

Re: LPC213x IDE
Quoted text here. Click to load it

I downloaded it and got a trial key.
First impression is .. WOW !
It just worked out of the box - even my j-link USB-JTAG
widget was recognized and worked. Awesome!
No fooling with Cygwin or obscure command-line switches.
Even comes with a basic task manager - royalty free.
For the low end stuff I can probably use that instead of
my $18k OS :) Love it! Thanks!

Site Timeline