Brian Murtha wrote:

> 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 

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

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

> > 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.

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.

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

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

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

>#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.

> 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