Compiler for AT91 ARM processors

Rowley CrossWorks for ARM gets my endorsement. A custom IDE and debugger using GCC for the compiler/linker.

--Gene

I've used the IAR ARM compiler and IDE for several years now. After one or two bugs (which IAR fixed or for which they sent me new source) in the first few months, it has run without problems and produced code that has done the job. It's rather expensive at about $4000 US.

I've been using gcc-arm for a few months now. I must admit that the system arrived on a laptop set up with Ubuntu Linux and I have no idea of the effort required to install the arm tool chain. It just works, and the code it generates runs without problems (other than those intrinsic to the project). I now understand just enough about the Linux system to do the specific programming tasks required. I'm sure others on this newsgroup can tell you more about gcc and Linux.

Mark Borgerson

I built the GNU toolchains for ARM under both Linux and Windows/Cygwin. A half-day job, properly done.

Since then, they have been used to produce some hundreds of kilobytes of very tight embedded code for Atmel AT91's.

--

Tauno Voipio
tauno voipio (at) iki fi

I'll add that getting Rowley CrossWorks up took all of about 9 minutes, as they have taken care of all the messy bits. Price is 495 GBP, or ~US $860.

--Gene

Their debugger is very comprehensive, and they also supply a nice USB JTAG interface - CrossConnect - for 99 GBP. Their software also works with low-cost Wiggler clones, which can cause problems when using GNU tools.

Leon

Op Wed, 15 Feb 2006 16:44:31 +0100 schreef Mark Borgerson :

For very low volumes, yes. For high volumes, it costs less than GNU. Assuming reduced code size means you can use a cheaper device, that is.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

And assuming that it does in fact out perform GNU. This is not at all obvious to me, in fact the reverse seems more likely.

--

John Devereux

Op Fri, 17 Feb 2006 12:25:53 +0100 schreef John Devereux :

Interesting article, but fairly irrelevant for a comparison between GNU and IAR (which is not Keil).

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Disclaimer - I have never used the ARM, and I don't know how the various ARM compilers compare in practice, so I'm just looking at this from a general viewpoint.

The IAR comparison page is slightly better than Keil's, but not much, for similar reasons. Other points are: there is no source code available for the benchmarks, there are no run-time speeds given (for all we know from this page, the extra code compactness has come at a large run-time penalty, which has its own cost), and there is no indication as to the libraries. Some of the benchmarks look very much like large extra sections of library were linked in (by gcc and Keil), which gives a large skew to the results. This is typical of things like full printf support. There are several ways to reduce this overhead, which will also depend on how the tools were set up in the first place. And of course, library overhead may not be as much of an issue in a real application if lots of other code sections use the libraries.

If I were considering using an ARM, and choosing a compiler toolkit with a view to generating fast and/or compact code, I would not consider IAR or Keil's pages to be worth the pixels they written on. I'd ask around, such as in this newsgroup, and I'd try out demo versions myself. Reading a vendor's own "benchmark" page is hardly an objective reference.

Follow the link in the article. It includes benchmark data for IAR and ARM, as well as KEIL. GCC beat IAR quite soundly on both codesize and Dhrystone performance. In face, IAR was by far the worst on code size, and tied for last on execution speed.

Image size Dhrystones/sec

GCC ARM 4536 51,488 GCC Thumb 3660 44,239 IAR 19892 40,983 Keil 10330 39,370 ARM ADS 10256 59,382

--
Grant Edwards                   grante             Yow!  Don't hit me!! I'm in
                                  at               the Twilight Zone!!!
                               visi.com

From the links in the article (still on the Keil website): "The Dhrystone benchmarks tests the C library as much as it tests the C compiler, which may not be fair when many embedded software engineers use custom libraries (e.g. for use with an RTOS)."

"Dhrystone consists of standard code and concentrates on string handling. It is heavily influenced by hardware and software design, compiler and linker options, code optimizing, cache memory, wait states, and integer data types."

So the only valid conclusion is that these benchmarks show that GCC is quite efficient in string handling. Whereas the IAR-benchmarks test real-world embbedded applications.

Sorry, wrong link.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

They only show code size... and (see other posts) you can't be sure if they've optimised appropriately.

..and I'll take this opportunity to point out that GCC supports C++, while IAR supports only the Embedded C++ subset, and Keil doesn't support it at all (at present).

--Gene

If code size and efficiency are important criteria for an embedded system, you're probably not going to use C++ or any other object- oriented language. I save those languages for the PC where memory and processor speed stopped being constraints some years back.

Mark Borgerson

[Slaps forehead] Too late, been doing it for years now. An embedded system can be large and inefficient in ANY language, and can be fast and compact in C++.

--Gene

A much better comparison than the Keil comparison can be found at:

It also clearly shows that gcc is quite good when compared with the other compilers. The biggest problem is that the newlib libraries are quite big. Porting or writing a library more appropriate to small embedded systems is all that its needed for gcc.

Regards Anton Erasmus

I guess that's so. My own biases may be showing, as I have been working on embedded systems with less than 64K of code space for most of the last 20 years. It's only in the last year or two that I've been using hardware with the RAM and processor power to make C++ a workable alternative to standard C. I would guess that writing good C++ for small systems involves concious decisions to avoid some features that lead to increased size and slower speed. But the same is true of C.

Mark Borgerson

Why do you think EC++ was developed in the first place? (and it wasn't by IAR) EC++ is used on systems where full C++ compilers are available because EC++ is a good idea for embedded systems. There are several compilers which have a C++/EC++ switch.

IAR could implement full C++ on several of their targets if they wanted to and it was a good idea.

The fact that GCC does not support EC++ is not a plus point for GCC it is a negative point.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I thought EC++ was dead as a standard.