Are free tools rubbish?

[Harvs]

So I was asking around at work today for any suggestions on getting into a new 32b micro for my next project, possibly TI's Stellaris Cortex M3 or the like.

So I said one of my requirements was to have a cheap/free compiler/IDE.  One of the guys there was adamant that it was a bad idea and I should be putting money into acquiring a decent software tool suite because the free stuff is rubbish.

At first I thought he was just being a D&@khead, as I've been using AVRGCC, Atmels tools for AVR32, FreeRTOS and some free PIC tools for years and never seemed to have significant problems.  But then I have never had something like IAR workbench or the like, which makes me wonder, are they actually that much better than something like AVRstudio and its integrated C compiler and software framework? 

Should I actually be looking at shelling out for a tool suite?  It wouldn't kill me to spend a couple of hundred, but thousands are out of the question.

[Psi]

which makes me wonder, are they actually that much better than something like AVRstudio and its integrated C compiler and software framework? 

Well if you download AVRStudio 5 you will still end up with AVRGCC.   AVRGCC is its integrated C compiler. 

Free tools come in all shapes and sizes. Some of them are awesome and better than the paid tools. Others are a pile of shit.

[JuKu]

Paid tools come in all shapes and sizes. Some of them are awesome and better than the free tools. Others are a pile of shit. 

[mikeselectricstuff]

Broadly speaking, you get what you pay for, but there are exceptions. GCC has such a wide user base that most of the bugs will have been either fixed or at least documented. 
However free, and OSS tools in particular are likely to have been developed to the point where they work, but not much further, so things like code size and/or speed efficiency and debug capabilities will probably be poorer than a commercial compiler.

There are different versions of free - manufacturers sometimes provide free tools which are cut-down versions of commercial tools, e.g. the kickstart versions of IAR, typical limitations being locking to a specific device, code size limits, or in a particularly stupid move by Microchip*, code optimization levels.

In a commercial environment, the cost of a commercial tool will often pay itself back  in terms of support, stability, debug capabilities and efficiency.

Another aspect is that any tool supplied by the manufacturer will be likely to support new devices earlier. Paid-for commercial tools also need to keep up with new developments, although they may charge for new device support.

*By having their free 8-bit compiler produce crappy code, it makes their chips look inefficient.

[Harvs]

Thanks for the info, it's interesting.  I'm going to download the 30-day eval of IAR for AVR32 and give it a shot.  I doubt I could justify the cost of IAR though, it's not known for being a cheap tool set.

That Microchip optimization crippling is actually the one reason I've never even looked at PIC32's.  Maybe to my detriment.

I'm not using it in a truly commercial environment.  I may or may not end up selling a few of what I make, but nothing that would recover the supposed $3k price tag of IAR (I've only got that off forums, they don't actually say what it costs on their website.)

Thanks again.

[Psi]

Paid tools come in all shapes and sizes. Some of them are awesome and better than the free tools. Others are a pile of shit.

hehe, yeah, that too

[westfw]

gcc is good stuff.   Many commercial packages use it as their compiler, adding an IDE, libraries, documentation, debugging capabilities, and SUPPORT.

Most commercial software packages are not really very expensive compared to the engineer using them.  Most are not too expensive compared to the fraction of an engineer it takes to internally support open source SW.  That's why companies will pay big bucks to buy a supported gcc or linux.  OTGH, it's real money vs funny money, and there's still going to be internal support needed for a "real" commercial compiler too, so YMMV...

IDEs are all the rage.  Not everyone likes them.

Some commercial SW is crappy.

The microchip optimization-crippling doesn't affect pic32; it's a pic16/pic18 thing.

[mikeselectricstuff]

The microchip optimization-crippling doesn't affect pic32; it's a pic16/pic18 thing.

Yes - it's basically the Hitech 8-bit compiler, the full version of which is very good, but the free version generates code that almost looks like it's being deliberately padded!
The architecture of the 8-bit parts really needs a clever compiler to get reasonable code density, whearas the 16 & 32 bit ones have been designed with C in mind, and there is a lot less difference between optimisation levels. 

[Harvs]

The microchip optimization-crippling doesn't affect pic32; it's a pic16/pic18 thing.

Yes - it's basically the Hitech 8-bit compiler, the full version of which is very good, but the free version generates code that almost looks like it's being deliberately padded!
The architecture of the 8-bit parts really needs a clever compiler to get reasonable code density, whearas the 16 & 32 bit ones have been designed with C in mind, and there is a lot less difference between optimisation levels.

Really! Wow ok, I just read this page:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454

and basically ruled them out.  Not that I'm saying $895USD is too much for a commercial compiler, just that it's too much for my application when there's other options like the AVR32 and Stellaris Cortex M3 that will do the job perfectly well with freely available tools or low cost tools like the code sourcery toolchain.

I may have another look at PIC32 then.

Cheers

[McMonster]

With so many commercial apps that cost unbeliveable money and are still heavily based on GCC, Eclipse and some other things I'd say someone who said they're crap is a dickhead.

Though in the case of ARMs open tools are a bit backward, like OpenOCD still not supporting SWD, but this is supposed to change in the next release according to some of the better informed.

[Thomas]

How about Crossworks?
I think it is reasonably priced at $150 for a personal licence, and it supports a wide range of ARM devices and JTAG debuggers.
Good documentation and support, good debugger and simulator. Rowley even helped me with my debugger (modified the configuration file).

I used it at a previous job and liked it a lot. Started with Yagarto, but got fed up with OpenOCD. Might have improved now, though.

[alm]

How about Crossworks?
I think it is reasonably priced at $150 for a personal licence, and it supports a wide range of ARM devices and JTAG debuggers.
Good documentation and support, good debugger and simulator. Rowley even helped me with my debugger (modified the configuration file).

And which compiler does Rowley use for ARM?

Some free tools are crap, but so are some very expensive tools. I'm not sure if the good/crap ratio is much worse for free tools compared to commercial, it might be similar.

GCC tends to be quite good, main exception is architectures not very well suited to C, like PIC16. Commercial compilers (note that there are much fewer commercial compilers than Eclipse/Netbeans + Gcc + support packages) will sometimes have better code density and performance, but unless you're almost running out of space or performance (in which case you should've probably picked a bigger part), the extra 10% or so may not be worth a lot of money.