Keil or IAR compiler for arm

[michaelym]

Hello,

Does any one know of a way to get the Keil/IAR arm compiler and linker for cheaper than the retail price ($3200-$3500).

For example with the Silabs 8051 processors you can get the keil C51 compiler for free.

Maybe there is another development environment that the compiler comes for free (not gcc)?

I am using is the Energy Micro (now Silabs) arm processor and aside for the prohibitively expensive compiler their free in house tools are great.

[nctnico]

Free or paid they are all based on GCC or ARM's own compiler (if they haven't switched to GCC yet).

[dannyf]

Maybe there is another development environment that the compiler comes for free (not gcc)?

There are various crippleware or kickstart versions of the compilers / ide.

Or maybe education pricing, or site licenses, etc. depending on who you are and whom you are associated with.

Those are excllent compilers / ides, particularly in the case of IAR - the ability to use one IDE on multiple mcus is priceless.

[dannyf]

Free or paid they are all based on GCC or ARM's own compiler (if they haven't switched to GCC yet).

Yeah right,

[mikeselectricstuff]

There are free kickstart versions of most of the IAR compilers, with code size limit, and for some MCUs that limit is the whole flash (32K for ARM last time I looked). For some products  there are also cheaper versions of some products with higher code-size limits.
If looking at buying a full version, it's worth talking to a sales rep as significant discounts are often available.
 

[free_electron]

Free or paid they are all based on GCC or ARM's own compiler (if they haven't switched to GCC yet).

Dream on ....

[nctnico]

Show me...

[AndyC_772]

Have you looked into CrossWorks for ARM? The full version is cheaper than most other commercial alternatives, and if you're using it for non-commercial purposes then you can get a special licence which is considerably cheaper again.

[westfw]

(not gcc)

Why not?

Neither Keil nor IAR is gcc based, as far as I know.  I imagine they're quite careful to stay that way.  (I KNOW that Intel jumps through hoops to keep their x86 compiler "pure" from gcc contamination.)

ImageCraft now has an ARM compiler as well; also not gcc based, AFAIK.

TI also has their own ARM compiler that is somewhat reasonably priced.  I don't know whether it's legally or technically possible to get it to produce code for non-TI chips.

[free_electron]

Show me...

the IAR compiler is not based on GCC. Neither is the Keil compiler.

http://www.iar.com/About/Pressroom/Press-releases/2012/6/IAR-Systems-delivers-outstanding-speed-optimizations-for-ARM-Cortex/

[nctnico]

Food for thought: how can a commercial compiler vendor compete with the enormous amount of (ongoing) effort thrown at the development of GCC? Chip makers like Atmel, TI and ARM are also contributing to the development of GCC. And why is it that real world comparisons between compilers are so scarse? None can be found on the websites of compiler vendors. Worse, compiler vendors explicitly forbid their customers to publish any comparison results. Why would they do that if their product is superior?

Interesting fact: Keil got burned quite badly a few years ago when they compared their own ARM compiler with GCC on their website. The sneaky bastards 'forgot' to turn on GCC's optimisations after which GCC beat Keil's ARM compiler hands down. Nowadays Keil (owned by ARM) ships the ARM compiler (developed by ARM) and GCC with uVision.

[dannyf]

Worse, compiler vendors explicitly forbid their customers to publish any comparison results. Why would they do that if their product is superior?

The fact that Mohamad Ali refused to fight you must mean that you are a better fighter than he ever was.

Food for thought,

[AndyC_772]

Worse, compiler vendors explicitly forbid their customers to publish any comparison results. Why would they do that if their product is superior?

Because it's too easy to perform tests which are misleading, unrepresentative, and easily misinterpreted. They're trying to protect their reputation from half-arsed "experts" and the people whose purchasing decisions might be swayed by them.

[nctnico]

Worse, compiler vendors explicitly forbid their customers to publish any comparison results. Why would they do that if their product is superior?

Because it's too easy to perform tests which are misleading, unrepresentative, and easily misinterpreted. They're trying to protect their reputation from half-arsed "experts" and the people whose purchasing decisions might be swayed by them.

That almost sounds like FUD 
Perhaps we (the users of this forum) could put a test suite together, agree on test methods and create a comprehensive compiler comparison. The most interesting numbers are the efficiency of the the compiler (optimised for speed and optimised for size) is and how efficient the C library is. I for one am not convinced to spend serious cash if I don't get a significant improvement. In the current situation it is impossible to tell if a commercial compiler is good or a total piece of crap.

Regarding the C library: I recall seeing a drystone comparison between Rowley's Crossworks and plain GCC. Even though Crossworks is also using GCC it produced slightly faster code due to a more efficient C library (which is an unwanted side effect from the drystone test BTW).

[andersm]

Because it's too easy to perform tests which are misleading, unrepresentative, and easily misinterpreted. They're trying to protect their reputation from half-arsed "experts" and the people whose purchasing decisions might be swayed by them.

Too bad they're not as scrupulous when they're the ones doing the benchmarking.

[HackedFridgeMagnet]

Worse, compiler vendors explicitly forbid their customers to publish any comparison results. Why would they do that if their product is superior?

The fact that Mohamad Ali refused to fight you must mean that you are a better fighter than he ever was.

Food for thought,

Not food for thought but nonsense.
There is no useful analogy there.

[HackedFridgeMagnet]

Perhaps we (the users of this forum) could put a test suite together, agree on test methods and create a comprehensive compiler comparison.

Love to see that, for arm cortex.
with LLVM if possible.

[free_electron]

Food for thought: how can a commercial compiler vendor compete with the enormous amount of (ongoing) effort thrown at the development of GCC? Chip makers like Atmel, TI and ARM are also contributing to the development of GCC. And why is it that real world comparisons between compilers are so scarse? None can be found on the websites of compiler vendors. Worse, compiler vendors explicitly forbid their customers to publish any comparison results. Why would they do that if their product is superior?

Interesting fact: Keil got burned quite badly a few years ago when they compared their own ARM compiler with GCC on their website. The sneaky bastards 'forgot' to turn on GCC's optimisations after which GCC beat Keil's ARM compiler hands down. Nowadays Keil (owned by ARM) ships the ARM compiler (developed by ARM) and GCC with uVision.

Because the commercial vendors have access to design documents of the core under NDA that the developers of GCC not have access to.
furthermore their compiler does not have to support 25 different architectures like GCC. The compiler is targeted toward 1 architecture.
GCC tries to be a compiler for all

[AlfBaz]

Because the commercial vendors have access to design documents of the core under NDA that the developers of GCC not have access to.
furthermore their compiler does not have to support 25 different architectures like GCC. The compiler is targeted toward 1 architecture.
GCC tries to be a compiler for all

That may be the case for the main gcc distro but trunks (or is it branches, I never get it right) such as ARM's surely don't fall under those restrictions. I mean, who better to code a compiler than the designers of the core

[dannyf]

Free or paid they are all based on GCC or ARM's own compiler (if they haven't switched to GCC yet).

Coming from an expert like you, that's pretty shocking actually.

[dannyf]

Benchmarking is simple to say but much harder to do.

We all have to agree to a set of "common tasks" - impossible;
We will need to make sure that those compilers are not purposely optimized for those tasks - impossible once the set of tasks is determined and known;
We will need to code against / around potential optimization -  very hard to do;
...

Having said that all, the limited amount of work I have done would suggest that speed-wise, GCC can give the commercial compilers a run for their money, if not beat them slightly.

Not a surprise to me: I use Keil / IAR not for their speed, or even small code size - even if Keil / IAR could beat GCC in those benchmarks. I use them for support (accountability?) and for certification (reliability / reputation?). I would venture that I am not unique in that regard.

[free_electron]

Because the commercial vendors have access to design documents of the core under NDA that the developers of GCC not have access to.
furthermore their compiler does not have to support 25 different architectures like GCC. The compiler is targeted toward 1 architecture.
GCC tries to be a compiler for all

That may be the case for the main gcc distro but trunks (or is it branches, I never get it right) such as ARM's surely don't fall under those restrictions. I mean, who better to code a compiler than the designers of the core

they may have started off as forks , but they got very little in common with the main thread of GCc now. the runtime libs are completely different, the optimiser is heavily customised and the frontend has all kinds of things like MISRA and other stuff.
None of that stuff finds its way back into mainstream GCC.

And the big key is support. good luck finding support on the forums. it's and endless vi<>emacs and gnome<>kde war ... let alone the 'you;r using the wrong operating system' bullshit.

Buy IAR or KEIL. install and develop. problem? 24/24 call let' you talk to the developers and they will fix it.

[nctnico]

Food for thought: how can a commercial compiler vendor compete with the enormous amount of (ongoing) effort thrown at the development of GCC? Chip makers like Atmel, TI and ARM are also contributing to the development of GCC. And why is it that real world comparisons between compilers are so scarse? None can be found on the websites of compiler vendors. Worse, compiler vendors explicitly forbid their customers to publish any comparison results. Why would they do that if their product is superior?

Interesting fact: Keil got burned quite badly a few years ago when they compared their own ARM compiler with GCC on their website. The sneaky bastards 'forgot' to turn on GCC's optimisations after which GCC beat Keil's ARM compiler hands down. Nowadays Keil (owned by ARM) ships the ARM compiler (developed by ARM) and GCC with uVision.

Because the commercial vendors have access to design documents of the core under NDA that the developers of GCC not have access to.
furthermore their compiler does not have to support 25 different architectures like GCC. The compiler is targeted toward 1 architecture.
GCC tries to be a compiler for all

I guess the people from TI, ARM, etc working on GCC have access to those documents as well. Besides that GCC is not some universal compiler framework. The backend (the part that produces the machine code and does the optimalisation) is specifically written for each target. Which also means that the speed/code density may vary for different platforms.

Commercial compiler vendors basically follow the same recipy: a front-end which deals with C/C++ and a back-end which does the target specific optimisations. They certainly won't write a compiler from scratch for every target.

My own experience with support is that the problems I run into are usually new for the support staff as well so I end up firing up Google or debug/fix a problem myself.

[AlfBaz]

they may have started off as forks

LOL, I was thinking of trees, when I should of been thinking about cutlery

And the big key is support. good luck finding support on the forums. it's and endless vi<>emacs and gnome<>kde war ... let alone the 'you;r using the wrong operating system' bullshit.

Whilst I have seen those tiresome squabbles here and there, the support forum for ARM's gcc seems to be pretty good in that the developers will soon respond and try addressing any real compiler issues. As it's free you do get a lot of students/hobbyists asking questions that go unanswered

Buy IAR or KEIL. install and develop. problem? 24/24 call let' you talk to the developers and they will fix it.

I had a quick look at there limited free options. If I had the cash, this would certainly be the road to travel... Install, code and debug, no messing around

[Koustrup]

Maybe there is another development environment that the compiler comes for free (not gcc)?

Why not GCC?
I am using GCC for ARM, AVR, PowerPC and native (for my PC) development. I find it very useful not having to switch toolchain to do test on PC or to switch target architecture.

That may a benefit that is worth remembering?   

[Kjelt]

From a hobbieist non-commercial point of view Keil and IAR are way outside a normal budget.
I talked to a salesrap of IAR and if I signed a non-commercial waver, and no support I could get aprox. 40% discount, leaving a price still way above $2000 for a single year license without support. After that year I got no new updates nothing.

Is there anyone on this forum who has not won the lottery or have a bankaccount with >6 figures, who does not make money with their product/software, and has actually bought an official full Keil/IAR compiler?
It is so sad that these companies don't offer normal priced non-commercial licenses (<$500 would be ok I guess).

And yeah I know there are 32kB limit free offerings but with current affordable uC's having 512kB and needing 50kB for an IP stack that is pretty useless except for the blinky projects (i know I exaggerate here).

[nctnico]

Back in the old days semiconductor distributors would let their clients 'borrow' the software in order to sell chips.

I have used IAR's and Keil's software in the past but their IDE's didn't manage to impress me though. A couple of years ago I needed to do some programming for a PIC. I didn't even bother to start MPLAB. I just wrote a wrapper so PICC looks like GCC and used Eclipse.

[andyturk]

<asbestos>
Seems like some folks here pick a favorite compiler/IDE the same way they pick a favorite schematic/PCB tool. There doesn't have to be much logic behind the decision, and it's probably more related to whatever the person used on the last project (or the last 10 projects). These are often the same people that think C++ is "too inefficient" for mcu projects, which suggests that they haven't spent much time looking at generated code (or they're using a really crappy compiler).

Proprietary compilers will usually be the way to go for new architectures. But if you're using a mature instruction set, it's going to be really hard to beat GCC significantly.
</asbestos>

[dannyf]

it's probably more related to whatever the person used on the last project (or the last 10 projects).

Compound that with the fact that nobody knows which posters really have actually experience on the said subject, it makes the usability of a forum advice highly questionable.

Anecdote is helpful as long as the reader takes all of them collectively into consideration. It becomes counter productive when people try to convince others of the superiority of their own anecdote.

[free_electron]

The other thing is debugger integration.

Install iar, connect j-link and off you go. Same with keil. Install, connect and done. No messing about with config files,eclipes config and other wastes of time.

NOBODY i his right mind debugs using printf statements.

[dannyf]

The whole thing boils down to why you use those tools.

For a hobbyist, spending your time learning the tools and debugging the tools is part of the fun.

For those making a living using those tools, they should be the last thing to worry about. For those people, a free tool is simply too expensive to use.

[nctnico]

The other thing is debugger integration.

Install iar, connect j-link and off you go. Same with keil. Install, connect and done. No messing about with config files,eclipes config and other wastes of time.

NOBODY i his right mind debugs using printf statements.

About half the embedded software engineers use printf to debug. Then again, does a CLI which allows to query status information and change settings still count as debug? BTW there is not much point stepping through microcontroller firmware. For realtime stuff it is too slow and for generic debugging (algorithm verification) a PC is much more suitable.

[free_electron]

you must not be doing serious embedded code then....
printf... you screw up the entire timing and behavior. and don't even try to do regressions testing between debug and release where the printf are disabled.

It is perfectly possible to trace and debug realtime stuff. even algorithm verification.
Just a matter of having a processor  core with debug assist , a fast debug adapter ( American Arium for example) or an ICE pod.

I got harddisks that are actively reading/writing data while i debugging the firmware through the debug port (DAP)

Note that in this case the debug port is NOT a simple JTAG.... there is much more involved. Serious ARM processors have a dedicated debug port (DAP). The tracer can work concurrently and has access to all registers, the entire memory space without stalling the processor.

Arm , Lauterbach and American Arium make that hardware. I use the ARm Trace-2 together with the ARM ICE.

[nctnico]

you must not be doing serious embedded code then....

Shooting from the hip again... Next time you attend a seminar ask other embedded developers (also the ones from small companies) what they use for debugging. You'll find half don't use on-target debugging.

[mikeselectricstuff]

One thing I like about IAR is good compiler-IDE integration. In particular, it will automatically pull all included files into the project tree. This can save a lot of time finding all the manufacturer-supplied header files to look up a register name (or check for errors!)

IAR are also good at providing multiple example projects, which are invaluable when getting up to speed with any new environment or device.

My only experience with GCC is via the Microchip 16 and 32 bit compilers, but my impression is that IAR is better at providing helpful diagnostics and warnings, e.g. stuff like "did you really mean if(a=b) and not if (a==b)", and warning about possible issues of access order of multiple volatile variables in expressions.

[andersm]

My only experience with GCC is via the Microchip 16 and 32 bit compilers, but my impression is that IAR is better at providing helpful diagnostics and warnings, e.g. stuff like "did you really mean if(a=b) and not if (a==b)", and warning about possible issues of access order of multiple volatile variables in expressions.

GCC can produce a lot of diagnostics, but a lot of them are not enabled by default. There's a checkbox for warnings in the project settings of MPLAB X which I think corresponds to GCC's -Wall option, and you can add even more flags (-Wextra, -pedantic) manually.

One advantage of GCC is that it supports so many architectures. Once you know how to use it with ARM, you pretty much know how to use it on AVR, MIPS, MSP430, x86 and so on.

[free_electron]

(also the ones from small companies) what they use for debugging. You'll find half don't use on-target debugging.

ah. now i see the light. small companies. like in 'doesn't have any money to buy a screwdriver ...' . is that it ?

that is something that, even as a hobbyist, i have always fought against. I want the damn good stuff !. IAR has a 32k kickstarter version. free. buy the 99$ devkit from ST and it comes with a j-link. minimal investment. maximum return. let's go that way.

[dannyf]

One advantage of GCC is that it supports so many architectures.

Sounds more like an advantage of C.

[AlfBaz]

One advantage of GCC is that it supports so many architectures.

Sounds more like an advantage of C.

Seriously??

I have no idea what's going on with this thread. If you don't have time to setup a tool chain then go ahead and pay your $5k+ and your yearly subscription. If you don't have $5+k then go ahead and spend some time setting up a free tool chain, which in spite of the derision given to the latter, is just as capable as the former.

So what's next are we going to start putting down people who don't have 32G scopes?

[dannyf]

Seriously??

You bet: I can write a one-line code under GCC that will run on (say) AVR but will not run  on any other platforms also supported by GCC.

I have no idea what's going on with this thread.

I can help you there:

1) people's needs are diverse. So pick the tools that work for you.
2) many people cannot comprehend that apparently.

is just as capable as the former.

Depends on how you define "capable".

So what's next are we going to start putting down people who don't have 32G scopes?

Sure, if you think talking about the pros / cons of a tool is putting down its users.

[AlfBaz]

Seriously??

You bet: I can write a one-line code under GCC that will run on (say) AVR but will not run  on any other platforms also supported by GCC.

The original statement was the gcc supported many architectures which you responded to by saying that it was more the advantage of the language C.
The language and it's various extensions have nothing to do with the different opcodes required by different architectures. The opcodes required for multi-architecture support are solely the domain of the compiler

I have no idea what's going on with this thread.

I can help you there:

1) people's needs are diverse. So pick the tools that work for you.
2) many people cannot comprehend that apparently.

Many people try one thing and not the other but somehow feel qualified to criticise the one they have not had much experience with.
In a perfect world each would talk about what they know, allowing readers to reach unbiased conclusions

is just as capable as the former.

Depends on how you define "capable".

One would reasonably assume that capable, in the context of this thread is the performance of the final output.

If there are some performance gains to be had from optimised libs or compiler heuristics over free tool-chains then the often touted paradigm, that I have seen you champion more than once, of picking the right mcu for the job would seem to be an acceptable solution

So what's next are we going to start putting down people who don't have 32G scopes?

Sure, if you think talking about the pros / cons of a tool is putting down its users.

Perhaps you read things the same way you write, vaguely.
There have been subtle and not so subtle implications with regards to the type of tool-chain user
eg

Compound that with the fact that nobody knows which posters really have actually experience on the said subject, it makes the usability of a forum advice highly questionable

[nctnico]

I have no idea what's going on with this thread. If you don't have time to setup a tool chain then go ahead and pay your $5k+ and your yearly subscription. If you don't have $5+k then go ahead and spend some time setting up a free tool chain, which in spite of the derision given to the latter, is just as capable as the former.

IMHO it has to do whether you are a power user or not. If you develop software occasionally then a paid package or a devkit is probably the way to go. If you need more freedom like being able to have multiple platforms/targets in one project, support for GIT and subversion to work in a team, share sourcecode between targets and manage really large software projects (like the Linux kernel) then you need something more powerful which (strangely enough) is free but takes more time to setup. I have never looked but I don't think $5k buys me an equally capable setup than GCC + Eclipse offers me now.

[dannyf]

Many people try one thing and not the other but somehow feel qualified to criticise the one they have not had much experience with.

So it is up to you to decide if we are qualified to criticise something? What makes you so special?

In a perfect world each would talk about what they know, allowing readers to reach unbiased conclusions

Yeah, as long as we have been qualified by you to criticise.

[dannyf]

One would reasonably assume that capable, in the context of this thread is the performance of the final output.

Then define "performance".

[dannyf]

There have been subtle and not so subtle implications with regards to the type of tool-chain user
eg
Quote
Compound that with the fact that nobody knows which posters really have actually experience on the said subject, it makes the usability of a forum advice highly questionable

Maybe you want to read it again. That particular statement you quoted is neutral with regards to any tool chains. It may apply to GCC, and it may apply to other commercial packages.

[AlfBaz]

What makes you so special?

I wear special shoes 

[andersm]

One advantage of GCC is that it supports so many architectures.

Sounds more like an advantage of C.

Because the nuts and bolts of every compiler are obviously the same.

[nctnico]

One advantage of GCC is that it supports so many architectures.

Sounds more like an advantage of C.

Because the nuts and bolts of every compiler are obviously the same.

Not really. Every compiler has it's own C slang even though C is supposed to be standard. Pragmas, attributes, types (Keil is strong at this), allowed 'slip ups' which can make it hard to compile a piece of code with a different compiler. Things have improved over the years though.

[andersm]

Not really.

The word of today is "sarchasm".

[westfw]

For those making a living using those tools ... a free tool is simply too expensive to use.

That's not a particularly good excuse avoiding gcc; you can always pay more to reduce your costs :-)
That *is* what the various vendors who charge for gcc are supposed to be doing; providing the ease-of-use, customer-support, maintenance, and testing and "version change caution" on top of what the OSSW hackers who actually modify gcc are inclined to do.  In theory, the chip vendors (Atmel, Microchip) provide similar assistance when they provide "custom" gcc-based tools.

And there is still scaling in more ways than one.  When I worked at cisco, we used gcc pretty exclusively.  Starting on various 68k cpus, adding PPC, MIPS, x86, Sparc, ARM, and others as time went on.  In the beginning, we were looking at one poorly supported not-very-good free compiler (pcc, as shipped on various early 68k workstations?) with a new compiler (gcc) that created noticeably better code (more than 10% smaller over a large system.)  As we added processors, architectures, people, and code, gcc pretty much kept up with us, and despite "looking", we didn't find any compelling competitors until Intel added bi-endian support for x86 (~2006)   There were of course issues:
1) (in the early days) We had some compiler hackers.  And lots of people who could argue with compiler hackers over whether various behaviors were bugs in the compiler or not.
2) We started paying (cygnus) for stable versions of gcc.
3) being able to patch the compiler and associated tools was invaluable.
4) We had a "compiler support team" that would apply our custom patches, interface with cygnus, carefully version-control and test new versions to see whether there were surprises, and integrate the compilers into what was eventually a rather baroque build environment.  Also a "tools team" that did non-compiler tools.
5) keeping the same gcc compiler as we switched cpus was a MAJOR advantage; for a very large embedded system, the toolset surrounding your compiler becomes very large, and it's probably not practical to duplicate it for multiple vendors.
6) running on multiple platforms was a major advantage; no windows PC environment was likely to work as we went from 68k workstations to solaris servers to farms of linux devices and/or personal linux systems.
7) Even so, gcc underwent significant and apparently random "churn" that kept us several versions behind while we figured out how to procede.  If we had had a particular compiler vendor, we might have been able to bend them to our needs, and that might have been bad for us in the long run (dealing with Intel was "interesting."  (really random things turned out to be major issues: discontinuation of multi-line string literals; change in ordering of macro expansion vs string argument concatenation; Weird things.  It's amazing how much stuff ends up in a large C program that isn't officially "specified" somewhere.  (or that "wasn't."  Having a language standards committee make a decision counter to the way you've been doing things... sucks.)
I don't know that we ever used much 'real time debugging.'  I never did.  We had gdb working over serial (or network) connections to the DUT, plus our own debugging capabilities (not so different from printf.)  But it wasn't really a real-time system, either.
9) we reached a point where our code was pretty much too big and too monolithic for other compilers to handle. :-(  Tools like eclipse that like to build and read a database of the full code base were ... extremely outmatched.
10) I don't remember "code quality" ever being a significant issue.  And we had people that would pour over generated code and do heavy-duty runtime analysis.  gcc might not be the absolute best compiler around, but it was pretty good.  Across ALL the cpus we used it on.
11) There's a tremendous amount of effort that SHOULD go into using a compiler in a professional environment that I think a lot of smaller companies tend to overlook.  (ie: you should version-control your compiler and the entire toolchain used to build your system.  And do massive testing anytime any of it changes.)  (It's really "not impressive" when a chip vendors IDE (v2) fails to compile their "demo system example program (originally shipped with V1 IDE.)  Sigh.)
12) Being tied to a single compiler vendor for your platform is not particularly good.  It's somewhat (a lot) better if that compiler is OSSW, though.  (FTDI, Cypress, Zilog Z8, PIC8...  All make me nervous.)

(ramble, ramble.)

So ... is gcc suitable for professional development?  Hell yes!

Is it really "free" ?  Almost certainly not; you always have to spend time and energy supporting your compiler.  The more support you get from somewhere else, the less you have to spend on your own.  Ideally, you find a vendor whose support strengths compliment your own.  A compiler vendor who spends a lot of time "supporting" C beginners may not be useful if your level of tool expertise is relatively deep.  If your tool expertise is NOT deep, you want a vendor and toolset that corrects for that.  (I mean, I can (probably) build a ARM gcc from source, figure out which switches are needed to support the combination of features on the particular ARM chip I'm using, import (or even write) the .h files defining the the on-chip registers for core and peripherals from the vendor's tools or datasheet.  But I'd really rather not...)

Is it cheaper than other compilers in the long run?  A complicated question, that depends on a lot of things.

What about for ARM?  (This was a thread about ARM compilers...):  I would not have any hesitation about using a gcc-based compiler for ARM.  However, I would not be happy about trying to build my own gcc-arm toolchain from scratch for any particular ARM chip.  One of the "relatively inexpensive" gcc "plus" IDEs would be attractive, though.  OTOH, I'm not religiously inclined to have a strong preference for open source compilers, either.  If the company/class/eval-kit provides Keil or IAR or Green Hills (no one has mentioned GH yet?), I'm not going to throw a tantrum about wanting to use OSSW instead.  (you laugh - but this is going on NOW in the UTexas Embedded System MOOC.  Sigh. (Not a lot.  There are about 30k people supposedly signed up for the class.  Maybe a score have expressed some reservations in the discussion forums about being able to continue (the class is using Keil) without the 32k limitation, after the class is over.  And one "trantrum"...))

[dannyf]

Because the nuts and bolts of every compiler are obviously the same.

You are absolutely correct.

[free_electron]

@westfw. Your point number 4 is the key. Cisco is large enough to have a dedicated compuler support team. As a coder tasked with writing the routine to implemenet a specific function you would not set up your own compile environment, configure eclipse or other editor to mesh , or write your own processor def files. Or figuere out how to install the debugger.

That is my mode of working. I am tasked putting a screw in a hole. I do not want to build scredrivers or screws. I go get the appropriate screw and screwdriver. There are 8 working hours i am being paid for. I have no interest in creating more work for myself delving into compiler code, altering scripts or debugging with printf. Gimme a prepackaged tool that works out of the box.
If my boss is to cheap to provide me with a screwdriver he'll have to find someone else to get it in.

Same applies for home use. You can get starter versions for 99$. 32k is a lot of memory. Of course if you begin your design by wanting to plonk a linux kernel on a chip to blink an LED ...  But then you are overdoing it or you need to learn proper programming.

[andersm]

Because the nuts and bolts of every compiler are obviously the same.

You are absolutely correct.

Only for the most trivial usage. Once you have to start dealing with memory layouts and other linker behaviour, things are different. Switching platforms is much less of an issue when you can take your tools and your knowledge with you.

[dannyf]

-Only for the most trivial usage-

you are too modest. Your statement is certainly true universally.

[Kjelt]

Same applies for home use. You can get starter versions for 99$. 32k is a lot of memory. Of course if you begin your design by wanting to plonk a linux kernel on a chip to blink an LED ...  But then you are overdoing it or you need to learn proper programming.

$99 with Ulink or stlink support? Where? I can not find anything decent under $2k

32k is a lot of memory for microcontrollers that do their own proprietary thing and do not need to be connected to the outside world talking large protocols. But then you wouldn't need a 32 bit ARM anyway.
If you do need a full 32 bit ARM chip you probably are doing fancy things like touchscreen LCD with GUI and for communication an IP stack, 32k is then way too little. Nowadays you can buy for $10 to $15 a complete pcb with micro and hardware that have a fully loaded ARM chip with 512kB ROM and 128kRAM, too sad if you can only use 32kB    Also support for a Ulink debugger or STlink debugger is a must if you ever have to seriously debug your code.

[dannyf]

32k is a lot of memory for microcontrollers that do their own proprietary thing and do not need to be connected to the outside world talking large protocols. But then you wouldn't need a 32 bit ARM anyway.

Yeah. Try to compile emWin and / or those dsp stuff and there isn't a whole lot of space left in the 32k limit.

[westfw]

I do not want to build scredrivers or screws. I go get the appropriate screw and screwdriver.

Cisco is large enough to have a dedicated compiler support team.

It is NOW.  It wasn't always.  Somehow, it manged to become that big, using a gcc environment.  That should mean something, too...

At one extreme you have the coder who wants his computer to boot into the Keil environment, but is pretty lost when it comes to the windows environment, and can't even install it himself (because "I never figured out how to get around those windows8 driver permissions issues.  W8 sucks!", or something.)
At the other extreme you have the guy who is going to make everything exactly the way he wants it; builds the compiler himself with custom ("useful") patches from multiple sites, uses a different editor than everyone else, constructs incomprehensibly complex Makefiles from scratch, and so on.

Frankly, I'd rather not work with either of those people.  Fortunately, there is lot of room in between.  (The advantage of a bigger company is that you end up with a spectrum.  The disadvantage of a small company is that you have to pick a spot...)

[Kjelt]

Well for big companies Keil is also not always a blessing, lot of license issues where you pay a couple of $100k a year for some floating licenses but you are not even allowed to use them worldwide (because of the different dealers on the continents). So you're forced to set up floating license servers per continent ,do the negotiations per continent, pay the fees per continent. The floating license of the old version lives for one hour per computer, so if you have for example 100 SW engineers and 40 floating licenses this could not be enough if in one hour timeperiod more then 40 SW engineers and test and build servers build the SW. So what you would like is that it would release the license within a minute when the build is over, at least that would be logical. Now on a daily basis we burn tens if not hundreds of engineering hours because the licenses are not available. Takes back the good old times, write your software and study it over and over again before daring to press the build button (or as in the good ol' days, handing in your pile of punchcards and wait a day till you were delivered a pile of paper with the printout (no that was way before my days)).
Then you switch to a newer (not backwards compatible) version of the compiler but wait all the old products which are still under life cycle management still have to be able to be serviced and build so you also need to have the old version license, or spent hundreds of eng. hours converting the old projects, testsetups and buildservers. From an outside perspective (i have luckily nothing to do with those negotiations) it starts to look like a scam, once hooked you're in it for life.

Still I must say I would love to have a Keil compiler for my home projects, working with the ulink2 and everything taken care of is comfortable.

[resistor]

Horses for courses, and all of that.

Different people have different skill sets.  I have a lot of experience with Unix-ish software, including building and configuring toolchains, so it's simply not a hurdle for me to setup and use a GCC toolchain for a new target.  In fact, it's typically easier for me than trying to learn a vendor's IDE.  I can whip up some Makefiles and headers in a few hours, and be off and productive in my preferred coding environment without having to figure out what checkboxes this particular vendor has mapped to which compiler flags.

[dannyf]

once hooked you're in it for life.

This is where generally speaking software shops have been very careful with anything from the compiler vendors. IAR's state machine software, for example, is absolutely state of the art. Yet, you will not find many people using it, because it is so tightly integrated with its tool chains.

The same with compiler upgrades.

[gocemk]

Hey guys,

I found an interesting article on embedded.com called "What’s more important than a processor?" which i think has more in common with this topic than it's title suggests. A survey was conducted on a few thousand embedded engineers and they were asked what would they choose if they were stranded on a desert island: their preferred processor, preferred OS, or preferred development tools. The majority of them answered - their development tools. So, i really think it's tough to convince someone whose preferred toolchain is GCC to switch to some proprietary tollchain like IAR/Keil and vice versa. For me for example, CooCox IDE worked straight out of the box with the STM32 F3 discovery board. So i can't complain, but on the other hand, i'm saying this from a hobbyist perspective.

Here's a link to the above mentioned article:

http://www.embedded.com/electronics-blogs/significant-bits/4427807/What-s-more-important-than-a-processor-

[dannyf]

Its nuts to worry about your tool when you are stranded on an island.

having said that it does confirm two things:
- processors are largely unimportant if you code in a hll.
- if your livelihood is on the line, you don't want to mess with your tools.

unfortunately, it did break down the tools used.

my casual observation would be 50 perc uar, 40 perc keil, etc.

[dannyf]

I particularly liked this comment:

For most companies, most of the investment is in their software layers.

If that software can be ported easily, then the software can be easily moved around from one set of silicon to another and products can grow easily.

The most valuable thing for a software shop is that proprietary software layer (middleware).

A huge competitive differentiator.

[westfw]

There is, of course, some "science" to writing your software in such a way that it is NOT compiler-dependent.
It seems to be a lot harder than it ought to be.  Something that implements a standard like C ought not get a label of "proprietary toolchain" (reserve that for things like Spin, or the semi-custom version of BASIC, or other REALLY proprietary languages.)

[redben]

I'm really pleased of Keil uVision software to program my diverse arm developpement boards.
I'm really satisfied with the evaluation version of the soft.
Hopefully it helped.

Good luck with your research of satisfaction.

[Kjelt]

There is, of course, some "science" to writing your software in such a way that it is NOT compiler-dependent.

It usually is the linker that is terribly manufacturer dependent.