Forums

Tool Chain Nightmare

Started by HowComeVBPaysMoreThanEmbedded? August 13, 2004
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
> I am to develop some medium size applications using the AT91 devices > and have been presented with the IAR Embedded Workbench for Arm (
So why not use the GNU tools, like the majority of the known world working on ARM targets?
> Has anyone else out there had problems with this toolset and which one > did you switch too ?
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! http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20
>#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.
I'm not sure why it would generate any code unless myarrary is declared as volatile. A test is made and a null statement is run if the test is true. Might as well just optimize it out.
Hi Gary,

> >#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. > > I'm not sure why it would generate any code unless myarrary is declared as > volatile. A test is made and a null statement is run if the test is true. Might
Sorry, my example was silly. I meant this was code that actually did some action in either case, i.e. it was more like: if (FRED(myarray[xyz])) { // something1 } else { // something2 } We observed that something1/2 would happen independently of the value of the relevant member of myarray. Investigating, we found out that the if... line was generating no code! The next line in the listing output from the compiler was testing a register that contained a value left over from a previous calculation, nothing to do with myarray at all. It was at that point that we realized the typo. Fixing the typo made the code work. But it's a very strange thing, for it to generate no warning or error or OBJECT CODE! -- -- Lewin A.R.W. Edwards (http://www.zws.com/) Learn how to develop high-end embedded systems on a tight budget! http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20
> > I am to develop some medium size applications using the AT91 devices > > and have been presented with the IAR Embedded Workbench for Arm ( > > So why not use the GNU tools, like the majority of the known world > working on ARM targets? > > > Has anyone else out there had problems with this toolset and which one > > did you switch too ? > > 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: >
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 ulf@a-t-m-e-l.com This is my personal opinion which may (or may not) be shared by my employer Atmel Nordic AB
"Lewin Edwards" <larwe@larwe.com> skrev i meddelandet
news:F2bTc.23874$Jp6.21671@newsread3.news.atl.earthlink.net...
> > I am to develop some medium size applications using the AT91 devices > > and have been presented with the IAR Embedded Workbench for Arm ( > > So why not use the GNU tools, like the majority of the known world > working on ARM targets? > > > Has anyone else out there had problems with this toolset and which one > > did you switch too ?
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 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! > http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20 >
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 ulf@a-t-m-e-l.com This is my personal opinion which may (or may not) be shared by my employer Atmel Nordic AB
On Sat, 14 Aug 2004 08:27:55 +0200, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:

> >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!".
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.
Lewin Edwards <larwe@larwe.com> wrote in message news:<F2bTc.23874$Jp6.21671@newsread3.news.atl.earthlink.net>...
> > I am to develop some medium size applications using the AT91 devices > > and have been presented with the IAR Embedded Workbench for Arm ( > > So why not use the GNU tools, like the majority of the known world > working on ARM targets? >
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.
> > Has anyone else out there had problems with this toolset and which one > > did you switch too ? > > 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: >
I shall pass this on, thanks,
> #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.
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.
> > 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... > > > I have no idea for ARM, but tests for the AVR show that they generate much > less code than any other compiler.
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.
> Releasing a new version shows that there is no inherent quality checks.
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.
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:

  www.rabbitsemiconductor.com
  www.zworld.com 

moose_punk@hotmail.com (HowComeVBPaysMoreThanEmbedded?) wrote in message news:<f376579.0408131316.1ccd9504@posting.google.com>...
> 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