Tool Chain Nightmare

Hello All,

I am to develop some medium size applications using the AT91 devices and have been presented with the IAR Embedded Workbench for Arm ( initially version 3.4 ) and a BDI JTag debug interface.

The segmentation was a real mess especialy where the embedded libraries are concerned wich makes the relocation of code a painful process. Also during some basic tool tests the and the error/warning messages missed some really basic things (multiple definitions of functions accross modules) so I upgraded to version 4.11 which looks prettier but if you repeatedly use the C-Spy debugger the whole thing seems to grind to a halt (it only takes about 10-15 debug, edit cycles to achieve a total lock up) and the problems with the parser are still present I can give a global variable the same name as a function of local scope and define another function with an external interface in a seperate module with the same name and not a peep out of the parser. Dare I try function pointers ? .. there is more,

Has anyone else out there had problems with this toolset and which one did you switch too ?

Mike Kean

Reply to
HowComeVBPaysMoreThanEmbedded?
Loading thread data ...

So why not use the GNU tools, like the majority of the known world working on ARM targets?

I have yet to read anyone with anything good to say about IAR's tools. Where I work, we are actively getting rid of their tools wherever we can (MSP430, NEC 78K0, ...). Expensive, in general poorly suppoted, buggy... for example, this bit me just the other day in their MSP430 compiler:

#define FRED(x) (myarray[x] & 0x10)

int myarray[10];

// typographical error: if (FRED(myarray[xyz])) ; // I meant to write FRED(xyz)

generates no code in the object file.

--
 -- Lewin A.R.W. Edwards (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
 Click to see the full signature
Reply to
Lewin Edwards

I have no idea for ARM, but tests for the AVR show that they generate much less code than any other compiler. As for support, I don't have a problem (but then I know the guys quite well). Have you tried sending email directly to their "support at iar dot se" email?

Support can be measured in several ways. Some people think that releasing a fix the day after you report a bug is good support. Others are aware that it is a lengthy process to fully test a compiler suite. Releasing a new version shows that there is no inherent quality checks. Think it takes 3-4 weeks for IAR to go through their test suite for a new release so they make a couple of releases maximum per year. I have talked to customers who are pissed off, because this PROVES that the quality thinking is non-existing. "A professional compiler cannot have a new release more than one a year!".

-- Best Regards Ulf Samuelsson snipped-for-privacy@a-t-m-e-l.com This is my personal opinion which may (or may not) be shared by my employer Atmel Nordic AB

Reply to
Ulf Samuelsson

"Lewin Edwards" skrev i meddelandet news:F2bTc.23874$ snipped-for-privacy@newsread3.news.atl.earthlink.net...

Atmel traditionally focus its supports on ARM ADS 1.2 and Green Hills Multi

2000 and with the release of the AT91SAM7 series, IAR will also get attention. Support here means FAE experience and software packages (AT91 library) ported. GNU is not supported from Atmel yet but there is plenty of people running GNU with Atmel AT91s. Most packages are in C anyway, so the porting effort to a new compiler would not be so great.

Most Atmel FAEs have Green Hills for normal work, and GNU for Linux stuff. I expect with the release of the AT91SAM7 series more people than myself will get experience with the IAR ARM tools.

I have no comprehensive data for ARM, but tests for the AVR show that they generate much less code than any other compiler. As for support, I don't have a problem (but then I know the guys quite well). Have you tried sending email directly to their "support at iar dot se" email?

Support can be measured in several ways. Some people think that releasing a fix the day after you report a bug is good support. Others are aware that it is a lengthy process to fully test a compiler suite. Releasing a new version shows that there is no inherent quality checks. Think it takes 3-4 weeks for IAR to go through their test suite for a new release so they make a couple of releases maximum per year. I have talked to customers who are pissed off, because this PROVES that the quality thinking is non-existing. "A professional compiler cannot have a new release more than one a year!".

-- Best Regards Ulf Samuelsson snipped-for-privacy@a-t-m-e-l.com This is my personal opinion which may (or may not) be shared by my employer Atmel Nordic AB

Reply to
Ulf Samuelsson

The one with more frequent releases may have more uncertainty about the quality, but the severity of the bugs is generally not worse that than the IAR product. For a use in a released product, the solution is to use the previous version of the compiler.

regards, Johnny.

Reply to
Johnny

Its not a choice thing the company I am working for use IAR for legacy products but this is the first using ARM, and sensibly enough believed that keeping the same tools provider would be a good thing when it comes to maintenance and portability. I am a BIG fan of GCC but when my contract is completed that would leave a learning curve for simple maintenance issues to the poor victim picking up the pieces.

I shall pass this on, thanks,

Try testing a bit higher than bit 15 ! on ewarm :

if ( ( SomeRegisterValue & 0x80000000 ) != 0 ) { // will NEVER execute } else { // is ALWAYS called }

the implicit conversions are always 16 bit !! even in ARM mode as opposed to compile thumb code.

you have to use :

if (( SomeRegisterValue & 0x8000000 ) == 0x80000000 ) {

}.....

liked shoestring btw, hard to get hold of in the uk but picked it up last time I was over in the big country.

Reply to
HowComeVBPaysMoreThanEmbedded?

I haven't tried IAR's ARM tools either, but I have such a bad taste from their other software that I would never try it. Also it's dongled. Fuck that, talk about insult on injury.

We are migrating to Crossworks for MSP430, and I think we already standardized on Keil for 8051, and NEC's proprietary assembler and compiler for the 78K0. I _think_ we use all-assembly on our AVR projects {I was surprised to learn we use quite a lot of AVRs). These are "safety critical" applications so although I don't necessarily believe that, say, Keil's code is intrinsically safer than the output of say mspgcc, having a vendor (with a valid liability insurance policy) to point fingers at is reassuring to management. And I do like the Crossworks IDE. Still waiting for my development board to arrive so I can start coding... (fingers itching). Maybe today.

For 32-bit products, 95% of the IP we have or that we would acquire was developed with GNU tools anyway. And size or speed inefficiencies are much less noticeable. It is MUCH more important for us to be speaking the same language - i.e. GNU - as the other programmers in the [global] project than it is for us to get some mythical imprimatur from a compiler vendor.

It depends on the nature of the release. Not infrequently we will report a bug in other tools, and the vendor will send us a hot-patch fix for it. That's an immediate response to a problem. Sometimes the vendor makes that patch available for download, with appropriate caveats. Anyone else who downloads that patch and gets bitten, that's their problem. But we needed the fix right away.

Total man-hours I have expended trying to work around odd behaviors in IAR's tools is more than the equivalent time I spent getting to understand gcc for ARM anyway.

Reply to
Lewin A.R.W. Edwards

Such tool chain nightmares could be an argument for getting one's chips, boards, compiler, driver libraries, debugger and operating system all from the same company:

formatting link
formatting link

Reply to
Brian Murtha

Especially when you work that one company, eh Brian? :)

The other side of the coin is that it's often a huge benefit to not be locked in to one proprietary set of tools. It's relatively recent that Dynamic C even supports 'make'. When will it support 'lint'? ANSI C? Posix threads? A linker? JTAG? USB?

Kelly

Reply to
Kelly Hall

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.