Forums

IDE for Atmel ARM processor

Started by Fred July 8, 2005
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.



Hello Fred,

In article <42ce4ef5$0$7917$fa0fcedb@news.zen.co.uk>, Fred@nospam.com 
says...
> 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. >
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.
In article <HzfBe.7233$rF5.5113@tornado.socal.rr.com>, Hw
<localhost@com.com> writes
>Hello Fred, > >In article <42ce4ef5$0$7917$fa0fcedb@news.zen.co.uk>, Fred@nospam.com >says... >> 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. >> > >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.
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 /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Thu, 14 Jul 2005 09:57:31 +0100, Chris Hills <chris@phaedsys.org>
wrote:

[...]
> >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?
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.

Dave Hansen wrote:
> On Thu, 14 Jul 2005 09:57:31 +0100, Chris Hills <chris@phaedsys.org> > wrote: > > [...] > > > >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? > > 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.
Girls prefer a ferrari if that's a requirement;)
In article <42d6532f.1787840968@news.aioe.org>, Dave Hansen
<iddw@hotmail.com> writes
>On Thu, 14 Jul 2005 09:57:31 +0100, Chris Hills <chris@phaedsys.org> >wrote: > >[...] >> >>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? > >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.
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 /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills wrote:
>
... snip ...
> > 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.
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 "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer wrote:
> Chris Hills wrote: > > > ... snip ... > > > > 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. > > 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.
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.
> > -- > "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
In article <1121368982.288797.117290@f14g2000cwb.googlegroups.com>, toby
<toby@telegraphics.com.au> writes
> > >CBFalconer wrote: >> Chris Hills wrote: >> > >> ... snip ... >> > >> > 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. >> >> 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. > >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.
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 /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Thu, 14 Jul 2005 21:17:02 +0100, Chris Hills <chris@phaedsys.org>
wrote:

[...]
> >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.
I'm sorry, but I just can't parse this. Can you try again? Regards, -=Dave -- Change is inevitable, progress is not.