Keil or IAR compiler for arm

[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"...))