LPC213x IDE

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!)

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

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 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,

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.

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.

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

have a look here

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...

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.

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.

That page is starting to get me really annoyed.

Look at this:

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

Also see this:

with results that are much more in line with my (limited) experience with the Keil compiler.

Karl Olsen

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

1. Code Size (with FP)

2.3 2.3 1.1 1.2 1.0

1.0 4. Speed ARM ARM (with FP)

--

John Devereux

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

--Gene

... snip ...

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
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at:

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!