Tool Chain Nightmare

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Tool Chain Nightmare
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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!
We've slightly trimmed the long signature. Click to see the full one.
Re: Tool Chain Nightmare
Quoted text here. Click to load it
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
We've slightly trimmed the long signature. Click to see the full one.
Re: Tool Chain Nightmare
Quoted text here. Click to load it

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.

Quoted text here. Click to load it
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
We've slightly trimmed the long signature. Click to see the full one.
Re: Tool Chain Nightmare
On Sat, 14 Aug 2004 08:27:55 +0200, "Ulf Samuelsson"

Quoted text here. Click to load it

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.



Re: Tool Chain Nightmare
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

I shall pass this on, thanks,


Quoted text here. Click to load it


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.

Re: Tool Chain Nightmare
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: Tool Chain Nightmare
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 snipped-for-privacy@hotmail.com (HowComeVBPaysMoreThanEmbedded?) wrote in message
Quoted text here. Click to load it

Re: Tool Chain Nightmare

Quoted text here. Click to load it

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

Site Timeline