Keil or IAR compiler for arm - Page 1
Forum section: electronics / general

author: michaelym
author_rank: Regular Contributor
timestamp: February 12, 2014, 10:54:57 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 12, 2014, 11:02:57 am
content: Free or paid they are all based on GCC or ARM's own compiler (if they haven't switched to GCC yet).

author: dannyf
author_rank: Super Contributor
timestamp: February 12, 2014, 12:12:51 pm
content: QuoteThere 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 12, 2014, 12:13:16 pm
content: QuoteYeah right,

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 12, 2014, 12:20:12 pm
content: 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.

author: free_electron
author_rank: Super Contributor
timestamp: February 12, 2014, 04:41:58 pm
content: Quote from: nctnico on February 12, 2014, 11:02:57 amDream on ....

author: nctnico
author_rank: Super Contributor
timestamp: February 12, 2014, 05:00:31 pm
content: Show me...

author: AndyC_772
author_rank: Super Contributor
timestamp: February 12, 2014, 06:02:26 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: February 12, 2014, 06:23:28 pm
content: QuoteWhy 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.

author: free_electron
author_rank: Super Contributor
timestamp: February 12, 2014, 07:29:41 pm
content: Quote from: nctnico on February 12, 2014, 05:00:31 pmthe 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/

author: nctnico
author_rank: Super Contributor
timestamp: February 12, 2014, 08:23:01 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 12, 2014, 09:02:54 pm
content: QuoteThe fact that Mohamad Ali refused to fight you must mean that you are a better fighter than he ever was.Food for thought,

author: AndyC_772
author_rank: Super Contributor
timestamp: February 12, 2014, 09:08:41 pm
content: Quote from: nctnico on February 12, 2014, 08:23:01 pmBecause 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 12, 2014, 09:25:38 pm
content: Quote from: AndyC_772 on February 12, 2014, 09:08:41 pmThat almost sounds like FUDPerhaps 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).

author: andersm
author_rank: Super Contributor
timestamp: February 12, 2014, 09:26:39 pm
content: Quote from: AndyC_772 on February 12, 2014, 09:08:41 pmToo bad they're not as scrupulous when they're the ones doing the benchmarking.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: February 12, 2014, 09:59:56 pm
content: Quote from: dannyf on February 12, 2014, 09:02:54 pmNot food for thought but nonsense.There is no useful analogy there.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: February 12, 2014, 10:00:20 pm
content: QuoteLove to see that, for arm cortex.with LLVM if possible.

author: free_electron
author_rank: Super Contributor
timestamp: February 12, 2014, 10:36:32 pm
content: Quote from: nctnico on February 12, 2014, 08:23:01 pmBecause 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

author: AlfBaz
author_rank: Super Contributor
timestamp: February 12, 2014, 11:09:05 pm
content: Quote from: free_electron on February 12, 2014, 10:36:32 pmThat may be the case for the main gcc distro but trunks (or is it branches, I never get it right) such asARM'ssurely don't fall under those restrictions. I mean, who better to code a compiler than the designers of the core

author: dannyf
author_rank: Super Contributor
timestamp: February 12, 2014, 11:12:18 pm
content: Quote from: nctnico on February 12, 2014, 11:02:57 amComing from an expert like you, that's pretty shocking actually.

author: dannyf
author_rank: Super Contributor
timestamp: February 12, 2014, 11:19:20 pm
content: 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.

author: free_electron
author_rank: Super Contributor
timestamp: February 12, 2014, 11:38:59 pm
content: Quote from: AlfBaz on February 12, 2014, 11:09:05 pmthey 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 13, 2014, 12:02:21 am
content: Quote from: free_electron on February 12, 2014, 10:36:32 pmI 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.

author: AlfBaz
author_rank: Super Contributor
timestamp: February 13, 2014, 12:09:15 am
content: Quote from: free_electron on February 12, 2014, 11:38:59 pmLOL, I was thinking of trees, when I should of been thinking about cutleryQuoteWhilst 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 unansweredQuoteI 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

author: Koustrup
author_rank: Newbie
timestamp: February 13, 2014, 08:52:09 am
content: Quote from: michaelym on February 12, 2014, 10:54:57 amWhy 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?

author: Kjelt
author_rank: Super Contributor
timestamp: February 13, 2014, 11:37:31 am
content: 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).

author: nctnico
author_rank: Super Contributor
timestamp: February 13, 2014, 12:41:54 pm
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: February 13, 2014, 01:36:41 pm
content: <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>

author: dannyf
author_rank: Super Contributor
timestamp: February 13, 2014, 02:00:43 pm
content: QuoteCompound 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.

author: free_electron
author_rank: Super Contributor
timestamp: February 13, 2014, 04:23:20 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 13, 2014, 04:26:26 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 13, 2014, 04:41:18 pm
content: Quote from: free_electron on February 13, 2014, 04:23:20 pmAbout 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.

author: free_electron
author_rank: Super Contributor
timestamp: February 13, 2014, 07:40:42 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 13, 2014, 08:17:49 pm
content: Quote from: free_electron on February 13, 2014, 07:40:42 pmShooting 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 13, 2014, 08:40:41 pm
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: February 13, 2014, 09:38:01 pm
content: Quote from: mikeselectricstuff on February 13, 2014, 08:40:41 pmGCC 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.

author: free_electron
author_rank: Super Contributor
timestamp: February 13, 2014, 10:06:33 pm
content: Quote from: nctnico on February 13, 2014, 08:17:49 pmah. 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 13, 2014, 10:33:08 pm
content: QuoteSounds more like an advantage of C.

author: AlfBaz
author_rank: Super Contributor
timestamp: February 13, 2014, 11:16:21 pm
content: Quote from: dannyf on February 13, 2014, 10:33:08 pmSeriously??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?

author: dannyf
author_rank: Super Contributor
timestamp: February 13, 2014, 11:28:28 pm
content: QuoteYou 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.QuoteI 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.QuoteDepends on how you define "capable".QuoteSure, if you think talking about the pros / cons of a tool is putting down its users.

author: AlfBaz
author_rank: Super Contributor
timestamp: February 14, 2014, 12:46:52 am
content: Quote from: dannyf on February 13, 2014, 11:28:28 pmThe 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 compilerQuoteMany 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 conclusionsQuoteOne 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 solutionQuotePerhaps 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 useregQuote

author: nctnico
author_rank: Super Contributor
timestamp: February 14, 2014, 01:28:11 am
content: Quote from: AlfBaz on February 13, 2014, 11:16:21 pmIMHO 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 14, 2014, 02:44:02 am
content: QuoteSo it is up to you to decide if we are qualified to criticise something? What makes you so special?QuoteYeah, as long as we have been qualified by you to criticise.

author: dannyf
author_rank: Super Contributor
timestamp: February 14, 2014, 02:44:43 am
content: QuoteThen define "performance".

author: dannyf
author_rank: Super Contributor
timestamp: February 14, 2014, 02:46:34 am
content: QuoteMaybe 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.

author: AlfBaz
author_rank: Super Contributor
timestamp: February 14, 2014, 03:03:29 am
content: Quote from: dannyf on February 14, 2014, 02:44:02 amI wear special shoes

author: andersm
author_rank: Super Contributor
timestamp: February 14, 2014, 07:23:49 am
content: Quote from: dannyf on February 13, 2014, 10:33:08 pmBecause the nuts and bolts of every compiler are obviously the same.

author: nctnico
author_rank: Super Contributor
timestamp: February 14, 2014, 10:59:24 am
content: Quote from: andersm on February 14, 2014, 07:23:49 amNot 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.

author: andersm
author_rank: Super Contributor
timestamp: February 14, 2014, 11:24:19 am
content: Quote from: nctnico on February 14, 2014, 10:59:24 amThe word of today is "sarchasm".

author: westfw
author_rank: Super Contributor
timestamp: February 14, 2014, 02:08:20 pm
content: QuoteThat'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"...))

author: dannyf
author_rank: Super Contributor
timestamp: February 14, 2014, 02:43:08 pm
content: QuoteYou are absolutely correct.

author: free_electron
author_rank: Super Contributor
timestamp: February 14, 2014, 03:14:54 pm
content: @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.

author: andersm
author_rank: Super Contributor
timestamp: February 14, 2014, 06:25:53 pm
content: Quote from: dannyf on February 14, 2014, 02:43:08 pmOnly 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 14, 2014, 06:34:12 pm
content: -Only for the most trivial usage-you are too modest. Your statement is certainly true universally.

author: Kjelt
author_rank: Super Contributor
timestamp: February 14, 2014, 07:37:38 pm
content: Quote from: free_electron on February 14, 2014, 03:14:54 pm$99 with Ulink or stlink support? Where? I can not find anything decent under $2k32k 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 32kBAlso support for a Ulink debugger or STlink debugger is a must if you ever have to seriously debug your code.

author: dannyf
author_rank: Super Contributor
timestamp: February 14, 2014, 08:17:02 pm
content: QuoteYeah. Try to compile emWin and / or those dsp stuff and there isn't a whole lot of space left in the 32k limit.

author: westfw
author_rank: Super Contributor
timestamp: February 15, 2014, 02:50:46 am
content: QuoteQuoteIt 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...)

author: Kjelt
author_rank: Super Contributor
timestamp: February 15, 2014, 09:27:25 am
content: 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.

author: resistor
author_rank: Regular Contributor
timestamp: February 15, 2014, 10:14:23 am
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 15, 2014, 10:46:00 am
content: QuoteThis 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.

author: gocemk
author_rank: Regular Contributor
timestamp: February 15, 2014, 02:12:57 pm
content: 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-

author: dannyf
author_rank: Super Contributor
timestamp: February 15, 2014, 03:06:07 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 15, 2014, 04:13:04 pm
content: I particularly liked this comment:QuoteThe most valuable thing for a software shop is that proprietary software layer (middleware).A huge competitive differentiator.

author: westfw
author_rank: Super Contributor
timestamp: February 16, 2014, 05:38:52 am
content: 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.)

author: redben
author_rank: Contributor
timestamp: February 17, 2014, 05:32:44 pm
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: February 17, 2014, 06:18:23 pm
content: Quote from: westfw on February 16, 2014, 05:38:52 amIt usually is the linker that is terribly manufacturer dependent.