IDE for Atmel ARM processor

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

Translate This Thread From English to

Threaded View
Which environment would people here recommend?  What sort of price would I
expect to have to pay?

Do they all require a monitor in external Flash or can they use the on chip
ROM modules?

Many thanks in advance.




Re: IDE for Atmel ARM processor
Hello Fred,

says...
Quoted text here. Click to load it

If you use the GCC (GNU) compiler, you don't have to pay anything.  ARM,
and various other companies have their own compilers that cost from $500
to $5k.

If you do go with GNU, Eclipse is a free popular IDE.

Check this article for some info:

http://www.newmicros.com/download/appnotes/ARM/TiniARM_Dev_Eclipse.pdf

There is a more generic PDF written by the same guy (Lynch) but I can't
find it at the moment.

H.

Re: IDE for Atmel ARM processor
Quoted text here. Click to load it


Not all ARM compilers are equal.

You need to look at:
   code density,
   Speed of execution
   targets  and hosts supported
   Other tools that work with it.
   Support from vendor (et al)

The headline cost of the purchase price is not all there is to it. In
some cases Linux is the most expensive option!

It is like buying automobiles.  Some one my give you a Ferrari but can
you afford to run or insure it?


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: IDE for Atmel ARM processor

[...]
Quoted text here. Click to load it

Bad analogy, IMHO, particularly the bit about insurance.  A better
analogy might be purchasing a Ferrari vs. fixing up your old Chevy.

The Ferrari has higher initial cost but higher performance.  Ferrari
will give you a (limited) warranty, but that will run out after some
amount of time, so you'll need to cough up more money later for an
extended warranty (support).  And if something does break, there are
only a limited number of mechanics who are qualified to fix it.

The Chevy won't go as fast or handle as well, but it will be good
enough most most uses (the speed limit on the freeway is still 70 MPH,
no matter what vehicle you drive).  It'll get most people where they
need to go.  It might break down once in a while, maybe even more
often than the Ferrari (or maybe not), but finding a mechanic who can
fix it is easier -- shoot, you might be able to do it yourself, if
you're feeling plucky.

Some people need a Ferrari.  Or believe they do.  If you do need it,
the Chevy ain't gonna cut it.  But if you don't require a Ferrari, the
Chevy beats walking.

Regards,


                               -=Dave
--
Change is inevitable, progress is not.

Re: IDE for Atmel ARM processor


Quoted text here. Click to load it

Girls prefer a ferrari if that's a requirement;)


Re: IDE for Atmel ARM processor
Quoted text here. Click to load it

good point.

How ever by coincidence today I have come across a company that has
found using GNU has cost it dearly.

They have run out of code space. They are now in mid project going to
have to port al the code to a commercial compiler that is more
efficient.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: IDE for Atmel ARM processor
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Sounds like a silly characterization.  They have obviously been
able to produce in the past, with minimal toolchain expenses.  The
fact that they don't want to spend the effort building better code
generators has nothing to do with that.  If they wrote non-standard
code and didn't keep the system specific stuff separate, that is
their own fault.  For all we know their bloat problems may have to
do with the size and organization of the system library, or the
unnecessary usage of big modules such as scanf and printf.

--
"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: IDE for Atmel ARM processor


Quoted text here. Click to load it

Yes, or just semi-competent programmers. I picked up a firmware project
recently (in C) and fully expect to be able to *halve* the code size
with a bit of obvious refactoring.

Quoted text here. Click to load it


Re: IDE for Atmel ARM processor
Quoted text here. Click to load it

It still doesn't get away from the fact that the they reckon just be
recompiling with a commercial compiler instead of GNU the code size was
halved.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: IDE for Atmel ARM processor

[...]
Quoted text here. Click to load it

I'm sorry, but I just can't parse this.  Can you try again?

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: IDE for Atmel ARM processor
Quoted text here. Click to load it

That may well be.  However, that has not "cost it dearly".  In
fact, it has cost them exactly nothing.  They are way ahead of the
game.  If they were doing the complaining I would consider them
ungrateful boneheads.  I have no idea of your motives, but I am
sure some exist.

--
"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: IDE for Atmel ARM processor
Quoted text here. Click to load it

If that's true (half the codesize just by switching compilers) I have a hard
time imagining that only be due to miss-optimizations. There's a
little-known fact of GCC: by default they put all non-referenced functions
in modules into the final binary. This is due to their default sectioning of
the object modules. To enable 'garbage-collection', you would have to
specify:

-fdata-sections -ffunction-sections for the compiler and
--gc-sections for the linker

Do you know if they did that?

Regards,
Andras Tantos



Re: IDE for Atmel ARM processor


Quoted text here. Click to load it

It's certainly implausible on any architecture I'm familiar with, but I
defer to Mr Hills' ARM-specific knowledge.

Quoted text here. Click to load it


Re: IDE for Atmel ARM processor


Quoted text here. Click to load it

Shouldn't the compiler and linker do this automatically? Removing
unused functions is an essential feature that should be on by default.

It is well known that the default settings of GCC are terrible. Last year
there was a paper on the GCC conference that showed how using 20+
options could reduce codesize by 5% on ARM. I don't know whether
they have changed them to be the default since then, but that would be
the obvious thing to do - I can't imagine anybody remember even half
of them! I also wonder whether the latest GCC has finally dropped that
expensive 60's style frame pointer...

Wilco



Re: IDE for Atmel ARM processor
Quoted text here. Click to load it

I'd like to see how the other compiler compares with
GCC and option -Os. When looking at the generated
assembly code (-S or -Wa,-ahlms), it's hard to believe
that a compiler could generate 50 % smaller code
if it compiles it all.

--

Tauno Voipio
tauno voipio (at) iki fi


Re: IDE for Atmel ARM processor


Quoted text here. Click to load it

Which default settings do you mean? Regarding optimisation, gcc
"defaults" to -O0 if one forgets to specify anything else. Switching to
-O2 should make at least a 5% difference, but even 5% is well within
the range of variation I'd expect from different vendors' compilers.

gcc targets an enormous number of architectures, and nobody can
reasonably expect it to be the best compiler for all of them.
Nonetheless it remains the de facto standard on many architectures
simply because it does a pretty good and reliable job. Few applications
could not tolerate 5% larger code, and those that cannot, should
perhaps consider assembler or finding smarter C programmers, since that
factor alone can certainly account for a 50%+ code bloat even with the
best available compiler!

Quoted text here. Click to load it


Re: IDE for Atmel ARM processor

Quoted text here. Click to load it

I mean starting from -O2 -Os. The settings of Os do not switch on
many of the space saving optimizations or switch off optimizations
that are bad for codesize (Andras mentioned a few). So at least some
of the gap between GCC and commercial compilers is explained by a
bad choice of default settings.

Quoted text here. Click to load it

The difference between -O0 and -O2 is much more than 5% - I don't
have recent numbers, but it is more like 50%.

The variation between compilers of different vendors (at their best
settings) is easily over 30% for codesize, and 50% for performance.

Quoted text here. Click to load it

I know companies who would do anything to get just a 0.5% codesize
improvement so they can add a new feature in their latest phone without
increasing the flash size. It all depends...

Anyway finding the best compiler and options is easier compared to
rewriting your code for space. Using assembler is never worth the
effort - modern compilers generate better code than the average
assembly programmer. Of course if the code was designed with
codesize in mind you may not have a problem in the first place.

Wilco



Re: IDE for Atmel ARM processor
Quoted text here. Click to load it

You could file a bug on that.

Quoted text here. Click to load it

Yes, I would expect much better than 5%.

Quoted text here. Click to load it

Their options remain the same: switch to assembler for all/part;
refactor; change compilers. I'd be amazed if they had exhausted all
space saving possibilities in the source code.

Quoted text here. Click to load it

That's less true of microcontrollers than it is of larger systems. It's
certainly not true of most C programmers :-)

Quoted text here. Click to load it

Compactness is usually a natural side effect of simple design and
thoughtful modularity.

Quoted text here. Click to load it


Re: IDE for Atmel ARM processor

Quoted text here. Click to load it


This is 16 or 32MBytes of flash, so assembler is obviously out of the
question. Improving the source code is not trivial for projects of this size.
It turns out it is cheaper/faster/lower risk to upgrade to a compiler which
simply squeezes the code by a few more percent.

Quoted text here. Click to load it

It depends a lot on which architecture. Compilers on 8/16-bit systems
have a difficult task due to the complex instruction sets. 32-bit RISCs
make it a lot more difficult for an assembly programmer to beat a
good compiler even on small amounts of code.

Few assembly programmers will use global inlining or common
subexpression elimination to improve codesize, but compilers can do
this routinely and consistently on any amount of code. As compilers
get better the usefulness of assembler is restricted to code that is difficult
to write in C (eg. process switch) or inner loops where saving a single
instruction can speed up the application by a few percent.

Quoted text here. Click to load it

Absolutely - and good coding practices. But a lot of code is borrowed
from previous projects (because of cost, risk or time to market), and
often you have to make the best of what is available.

Wilco



Re: IDE for Atmel ARM processor


Quoted text here. Click to load it

That's pretty much what I was saying; although maybe your
generalisation remains true of the "average" assembly programmer. :)
Spend enough time at http://www.hugi.scene.org/compo/hcompo.htm and you
realise it's far from true for top assembly programmers.

Quoted text here. Click to load it

Yes, I have seen this first hand...

--Toby

Quoted text here. Click to load it


Site Timeline