Reply by Ulf Samuelsson●January 17, 20062006-01-17
"Anders" <nospam@spam.com> skrev i meddelandet
news:i_Tyf.20364$or4.8909@newssvr12.news.prodigy.com...
> Sagaert Johan wrote:
>> have a look here
>>
>> http://www.keil.com/benchmks/carm_v0code.htm
>
> 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...
Why not use an ARM7 with built in AES H/W then...
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB
Reply by Anders●January 17, 20062006-01-17
Gene S. Berkowitz wrote:
> Take a look at CrossStudio for ARM.
> It is a custom IDE using GCC for the grunt work.
> www.rowley.co.uk
>
> --Gene
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!
Reply by Chuck F.●January 16, 20062006-01-16
John Devereux wrote:
>
... snip ...
>
> "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
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: <http://cfaj.freeshell.org/google/>
Reply by Gene S. Berkowitz●January 16, 20062006-01-16
In article <ZJRyf.11448$PL5.4462@newssvr11.news.prodigy.com>,
nospam@spam.com says...
> 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>
Take a look at CrossStudio for ARM.
It is a custom IDE using GCC for the grunt work.
www.rowley.co.uk
--Gene
Reply by John Devereux●January 16, 20062006-01-16
"Karl Olsen" <kro@nospam.post3.tele.dk> writes:
> John Devereux <jdREMOVE@THISdevereux.me.uk> wrote:
>>
>> 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!
>
> 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.
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
Reply by Karl Olsen●January 16, 20062006-01-16
John Devereux <jdREMOVE@THISdevereux.me.uk> wrote:
> "larwe" <zwsdotcom@gmail.com> writes:
>
>> Anders wrote:
>>
>>>> http://www.keil.com/benchmks/carm_v0code.htm
>>>
>>> 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
>>
>> Yes, I'm sure it's totally unbiased :)
>
> 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!
> Anders wrote:
>
>> > http://www.keil.com/benchmks/carm_v0code.htm
>>
>> 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
>
> Yes, I'm sure it's totally unbiased :)
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
Reply by Anders●January 16, 20062006-01-16
> 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.
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.
Reply by larwe●January 16, 20062006-01-16
Anders wrote:
> > http://www.keil.com/benchmks/carm_v0code.htm
>
> 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
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.
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...