Hi Paul,
We should meet, I am a newbie to these groups despite be so ancient
(36) to obtain a CEng! I am not responsible for everything at IAR,
coding is my hobby! I just do my best to listen and learn from
customers -certainly I do not set the price of the IAR tools -be it
$10 or $1800 !!
I would hope that the free IAR 4K C compiler and JTAG compiler was
good value for money! -although I'm sure others would argue to the
contrary!!
I guess I use IAR compilers because I had a 6812 project in the early
90s and it was what I chose from a very short shortlist! (DOS command
line and all!).
I'm sorry if it sounded like I said IAR's compiler/debugger was
better because it's more expensive. It's definetely more expensive
and it's definitely up to the tool evaluator/buyer to decide if
it's
worth the extra.
Please excuse all typos and deviant English -I am a product of a 1989
Engineering degree and only just got my O level English pass for Uni!
What my skills do allow me to do is look into that toupper bug IAR's
old version ...of to gym ..then home to compiler ..and family.
Jason CEng ;-)
Sunny Northampton
Good Compiler for the MSP430
Started by ●February 13, 2004
Reply by ●March 4, 20042004-03-04
Reply by ●March 4, 20042004-03-04
Hi Jason,
> Hi Paul,
>
> We should meet, I am a newbie to these groups despite be so ancient
> (36) to obtain a CEng! I am not responsible for everything at IAR,
> coding is my hobby! I just do my best to listen and learn from
> customers -certainly I do not set the price of the IAR tools -be it
> $10 or $1800 !!
The price of tools is a subject in itself. I find IARs financials
illuminating reading.
> I would hope that the free IAR 4K C compiler and JTAG compiler was
> good value for money! -although I'm sure others would argue to the
> contrary!!
I'm sure the 4K compiler was funded by TI, and doesn't spring from any
philanthropy on IAR's part. It's a marketing tool for sure. We don't
offer 4K compilers and we do OK.
> I guess I use IAR compilers because I had a 6812 project in the early
> 90s and it was what I chose from a very short shortlist! (DOS command
> line and all!).
I used a IAR 68HC11 compiler. It was old, it was crufty, I used it for
one project because I was forced to. It's gathering dust in the
software relics cupboard along with the Meiko Computing Surface tools.
> I'm sorry if it sounded like I said IAR's compiler/debugger was
> better because it's more expensive. It's definetely more expensive
> and it's definitely up to the tool evaluator/buyer to decide if it's
> worth the extra.
I've learnt that it's pretty easy to p*ss people off on this forum by
writing something that's taken in the wrong way. Just consider this as
a vendor deathmatch thing--you know, put you head above ground for the
first time, and have it taken off with a unified salvo... ;-)
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
> Hi Paul,
>
> We should meet, I am a newbie to these groups despite be so ancient
> (36) to obtain a CEng! I am not responsible for everything at IAR,
> coding is my hobby! I just do my best to listen and learn from
> customers -certainly I do not set the price of the IAR tools -be it
> $10 or $1800 !!
The price of tools is a subject in itself. I find IARs financials
illuminating reading.
> I would hope that the free IAR 4K C compiler and JTAG compiler was
> good value for money! -although I'm sure others would argue to the
> contrary!!
I'm sure the 4K compiler was funded by TI, and doesn't spring from any
philanthropy on IAR's part. It's a marketing tool for sure. We don't
offer 4K compilers and we do OK.
> I guess I use IAR compilers because I had a 6812 project in the early
> 90s and it was what I chose from a very short shortlist! (DOS command
> line and all!).
I used a IAR 68HC11 compiler. It was old, it was crufty, I used it for
one project because I was forced to. It's gathering dust in the
software relics cupboard along with the Meiko Computing Surface tools.
> I'm sorry if it sounded like I said IAR's compiler/debugger was
> better because it's more expensive. It's definetely more expensive
> and it's definitely up to the tool evaluator/buyer to decide if it's
> worth the extra.
I've learnt that it's pretty easy to p*ss people off on this forum by
writing something that's taken in the wrong way. Just consider this as
a vendor deathmatch thing--you know, put you head above ground for the
first time, and have it taken off with a unified salvo... ;-)
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
Reply by ●March 4, 20042004-03-04
Hi,
I'm not so experienced in coding and compilers to compare one to the
other, but the vendors provided a little insight into their support:
06/03/2002 we bought an IAR EWB430 V1.25A with 22% discount for our
university.
02/12/2003 I got the one and only free "update" onto V1.26(!).
Next information was the statement from IAR Munich, that the last
chance for the prolongation of the maintenance contract would end
22/02/2003, but with the possibility of paying 20% of the list price
(448,-Euro) for another year.
At the 430ATC 19/02/2003 I asked the IAR-guy for the 2.0-update, which
he introduced there. He was not responsible for that, I should ask IAR
in Munich. I did, they told me, to ask IAR in Sweden. I did by email,
no reaction.
On the occasion of the 430ATC 02/12/2003 in Munich I switched to the
Rowley compiler. The support is well-known here, do you also know
their educational-discount? This seems to be the better way for
people, paid by public authorities and public project executing
organisations.
Regards, Timo
I'm not so experienced in coding and compilers to compare one to the
other, but the vendors provided a little insight into their support:
06/03/2002 we bought an IAR EWB430 V1.25A with 22% discount for our
university.
02/12/2003 I got the one and only free "update" onto V1.26(!).
Next information was the statement from IAR Munich, that the last
chance for the prolongation of the maintenance contract would end
22/02/2003, but with the possibility of paying 20% of the list price
(448,-Euro) for another year.
At the 430ATC 19/02/2003 I asked the IAR-guy for the 2.0-update, which
he introduced there. He was not responsible for that, I should ask IAR
in Munich. I did, they told me, to ask IAR in Sweden. I did by email,
no reaction.
On the occasion of the 430ATC 02/12/2003 in Munich I switched to the
Rowley compiler. The support is well-known here, do you also know
their educational-discount? This seems to be the better way for
people, paid by public authorities and public project executing
organisations.
Regards, Timo
Reply by ●March 4, 20042004-03-04
> spirit. And Kris, you know IAR aren't all
bad, all compiler vendors
> have fallen foul of simple problems--chill out, my friend, your parts
> will soon be with you, and you'll have better things to do! :-)
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
Thanks Paul,
Without bugs a JTAG or software debugger would not be sold -and the
richest man in the world wouldn't be so rich.
I had a pretty slow swim tonight (I am a very amateur Triathlete!) a
bit worried I had enraged the entire internet.!!! I only got my alway-
on (802.11b wireless but I dont have a go at BT for my living in a
sleepy village) connection to the 'net this week!.
It's likely Rowley, Quadravox or Codevision will grow to the size of
IAR ...and I might be a startup developing a compiler for a new 64
bit embedded micro (with 32 pins ;-) ). Then it would all flip on
it's head.
Anders (the A in IAR) was at the recent 20th birthday of IAR. So in
not one generation IAR has grown from 1 to lots of people all around
the world. Certainly tonight I feel IAR is a victim of it's own
(perhaps much earlier) success.
As my 10 year old son would say 'quits'? ...it used to be 'truce'?
> have fallen foul of simple problems--chill out, my friend, your parts
> will soon be with you, and you'll have better things to do! :-)
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
Thanks Paul,
Without bugs a JTAG or software debugger would not be sold -and the
richest man in the world wouldn't be so rich.
I had a pretty slow swim tonight (I am a very amateur Triathlete!) a
bit worried I had enraged the entire internet.!!! I only got my alway-
on (802.11b wireless but I dont have a go at BT for my living in a
sleepy village) connection to the 'net this week!.
It's likely Rowley, Quadravox or Codevision will grow to the size of
IAR ...and I might be a startup developing a compiler for a new 64
bit embedded micro (with 32 pins ;-) ). Then it would all flip on
it's head.
Anders (the A in IAR) was at the recent 20th birthday of IAR. So in
not one generation IAR has grown from 1 to lots of people all around
the world. Certainly tonight I feel IAR is a victim of it's own
(perhaps much earlier) success.
As my 10 year old son would say 'quits'? ...it used to be 'truce'?
Reply by ●March 4, 20042004-03-04
Jason,
> It's likely Rowley, Quadravox or Codevision will grow to the size of
> IAR ...and I might be a startup developing a compiler for a new 64
> bit embedded micro (with 32 pins ;-) ). Then it would all flip on
> it's head.
I feel it unlikely that RAL will grow to the size of IAR because that's
not what I want. I'd rather RAL stays as profitable as it has been
since its inception--at least I get a sound nights sleep each and every
night. And I don't need to worry about investors, making a profit, or
whether I'm going to lose my job.
-- Paul.
> It's likely Rowley, Quadravox or Codevision will grow to the size of
> IAR ...and I might be a startup developing a compiler for a new 64
> bit embedded micro (with 32 pins ;-) ). Then it would all flip on
> it's head.
I feel it unlikely that RAL will grow to the size of IAR because that's
not what I want. I'd rather RAL stays as profitable as it has been
since its inception--at least I get a sound nights sleep each and every
night. And I don't need to worry about investors, making a profit, or
whether I'm going to lose my job.
-- Paul.
Reply by ●March 4, 20042004-03-04
Hi Timo,
Glad you're still alive and well. :-)
> On the occasion of the 430ATC 02/12/2003 in Munich I switched to the
> Rowley compiler. The support is well-known here, do you also know
> their educational-discount? This seems to be the better way for
> people, paid by public authorities and public project executing
> organisations.
The last ATC in Meisbach was great. Just to say that our price for
educational seats is just 99 GBP, about EUR 150 or USD 180. That's 80%
off of an already reasonably priced compiler. Same product as the
commercial offering, just not for commercial use.
Best regards,
-- Paul.
Glad you're still alive and well. :-)
> On the occasion of the 430ATC 02/12/2003 in Munich I switched to the
> Rowley compiler. The support is well-known here, do you also know
> their educational-discount? This seems to be the better way for
> people, paid by public authorities and public project executing
> organisations.
The last ATC in Meisbach was great. Just to say that our price for
educational seats is just 99 GBP, about EUR 150 or USD 180. That's 80%
off of an already reasonably priced compiler. Same product as the
commercial offering, just not for commercial use.
Best regards,
-- Paul.
Reply by ●March 4, 20042004-03-04
Having recovered further from my swim -and now more with oxygenated
blood feeding my brain...
By saying 'you get what you pay for' I should have qualified that
much more. You may not get smaller code or better debugging or less
bugs with an expensive compiler versus an economic or free one. You
pay for things like international offices, the ability to email your
code to Japan and have you Japanese colleagues buy the compiler and
be supported in Japanese!
Kris could quite rightly say 'who needs Japanese compilers?' and he
would be right for all but those few big companies that develop code
for and in all regions of the world....
http://www.iarsys.co.jp/
Being a big compiler company isn't as easy as you might think. But I
for one will only sell if i think the product is fit for purpose ..so
I have pointed customers at other compiler companies now and then.
blood feeding my brain...
By saying 'you get what you pay for' I should have qualified that
much more. You may not get smaller code or better debugging or less
bugs with an expensive compiler versus an economic or free one. You
pay for things like international offices, the ability to email your
code to Japan and have you Japanese colleagues buy the compiler and
be supported in Japanese!
Kris could quite rightly say 'who needs Japanese compilers?' and he
would be right for all but those few big companies that develop code
for and in all regions of the world....
http://www.iarsys.co.jp/
Being a big compiler company isn't as easy as you might think. But I
for one will only sell if i think the product is fit for purpose ..so
I have pointed customers at other compiler companies now and then.
Reply by ●March 4, 20042004-03-04
At 07:49 PM 3/4/2004 +0000, jason_ceng wrote:
>...
>It's likely Rowley, Quadravox or Codevision will grow to the size of
>IAR ...and I might be a startup developing a compiler for a new 64
>bit embedded micro (with 32 pins ;-) ). Then it would all flip on
>it's head.
>...
Slip o' the tongue from AVR compiler vendors? :-)
It's likely the ImageCraft will not grow much beyond what we are now, for
similar reasons that Paul says. This model works for us. Rather than
growing bigger and get bought up or retiring with millions from stock sales
etc., I have much more freedom to do what we want to do right now. Why
trade it off? There are very few instances where a small embedded compiler
company grows and becomes both good for the founders (retiring in Hawai'i)
AND for the customers. Either the company just dies, or the customers just
plain lose a good compiler vendor.
// richard (This email is for mailing lists. To reach me directly, please
use richard@rich...)
>...
>It's likely Rowley, Quadravox or Codevision will grow to the size of
>IAR ...and I might be a startup developing a compiler for a new 64
>bit embedded micro (with 32 pins ;-) ). Then it would all flip on
>it's head.
>...
Slip o' the tongue from AVR compiler vendors? :-)
It's likely the ImageCraft will not grow much beyond what we are now, for
similar reasons that Paul says. This model works for us. Rather than
growing bigger and get bought up or retiring with millions from stock sales
etc., I have much more freedom to do what we want to do right now. Why
trade it off? There are very few instances where a small embedded compiler
company grows and becomes both good for the founders (retiring in Hawai'i)
AND for the customers. Either the company just dies, or the customers just
plain lose a good compiler vendor.
// richard (This email is for mailing lists. To reach me directly, please
use richard@rich...)
Reply by ●March 4, 20042004-03-04
Hi All,
I use the IAR AVR toolset and have been extremely pleased with it. I have
only found one 'bug' and got very good support and a workaround in less than
48 hours. I have had technical backup on several occasions and was
completely satisfied with the level of support.
For the MSP430 however I am using Quadravox based on price. I needed more
than 2K (which was the kickstart kit limit then) and tried the Quadravox
demo. Since it did what I needed I couldn't justify paying 4 times the
price to go for IAR for 1 project which was all I had a guarantee of at the
time and the client wasn't time sensitive for that item as it didn't
dominate their production runup. The injection molding tooling was the main
factor there.
According to both the local TI rep and IAR rep here in Australia, IAR are
not directly responsible for the Kickstart toolset but TI did them using
their own team but based on the IAR codebase. It was, as someone else
suggested, a purely commercial arrangement. According to the IAR rep the
full commercial IAR offering is a much solider product than the kickstart
version. I haven't tested this assertion either way by trying their free 30
day demo but I independently got the same story from both. Maybe a TI or
IAR rep on the forum could either confirm, deny or correct this assertion.
I think your choice of toolset is a critical factor in ease of success with
your projects. I run the best toolsets I can afford because I want the best
outcome commercially for my own company but also for my clients. If a
US$2000 toolset reduces the total project time to production by more than a
week then it has usually paid for itself on that project alone. Like all
other value equations, it is an issue of the best return on investment. And
its not just the ratio that's important. I look at margin too. I don't
just go for a cheap tool because it is cheap. It also has to do the job.
An expensive tool is not necessarily better than a cheap one. I try them
out if I can. If the cheaper tool does the job you need and there are no
other penalties to the project then it is clear that you only need to invest
that amount.
I have been working around toolset issues my entire career as a developer.
Intel used to release a 'known infelicities' list with their 8086 C command
line driven compiler/linker/librarian. This section of the documentation
was larger than the implementation details section and also included
workarounds. Any large codebase will have some bugs/infelicities/drawbacks.
We have all had bad experiences at some stage but I would rather talk things
up than down. If we want a better life we won't get there but dragging
others through the mud. But robust discussion on the merit and drawbacks of
various approaches is helpful as it can introduce new ideas or ideas from
other areas, highlighting weaknesses in approach or implementation and can
lead to better next versions. There is room for a range of toolsets with a
range of value sets in the market for each processor family and the better
they all become the easier it is for us to do good work and deliver great
products.
Ray
I use the IAR AVR toolset and have been extremely pleased with it. I have
only found one 'bug' and got very good support and a workaround in less than
48 hours. I have had technical backup on several occasions and was
completely satisfied with the level of support.
For the MSP430 however I am using Quadravox based on price. I needed more
than 2K (which was the kickstart kit limit then) and tried the Quadravox
demo. Since it did what I needed I couldn't justify paying 4 times the
price to go for IAR for 1 project which was all I had a guarantee of at the
time and the client wasn't time sensitive for that item as it didn't
dominate their production runup. The injection molding tooling was the main
factor there.
According to both the local TI rep and IAR rep here in Australia, IAR are
not directly responsible for the Kickstart toolset but TI did them using
their own team but based on the IAR codebase. It was, as someone else
suggested, a purely commercial arrangement. According to the IAR rep the
full commercial IAR offering is a much solider product than the kickstart
version. I haven't tested this assertion either way by trying their free 30
day demo but I independently got the same story from both. Maybe a TI or
IAR rep on the forum could either confirm, deny or correct this assertion.
I think your choice of toolset is a critical factor in ease of success with
your projects. I run the best toolsets I can afford because I want the best
outcome commercially for my own company but also for my clients. If a
US$2000 toolset reduces the total project time to production by more than a
week then it has usually paid for itself on that project alone. Like all
other value equations, it is an issue of the best return on investment. And
its not just the ratio that's important. I look at margin too. I don't
just go for a cheap tool because it is cheap. It also has to do the job.
An expensive tool is not necessarily better than a cheap one. I try them
out if I can. If the cheaper tool does the job you need and there are no
other penalties to the project then it is clear that you only need to invest
that amount.
I have been working around toolset issues my entire career as a developer.
Intel used to release a 'known infelicities' list with their 8086 C command
line driven compiler/linker/librarian. This section of the documentation
was larger than the implementation details section and also included
workarounds. Any large codebase will have some bugs/infelicities/drawbacks.
We have all had bad experiences at some stage but I would rather talk things
up than down. If we want a better life we won't get there but dragging
others through the mud. But robust discussion on the merit and drawbacks of
various approaches is helpful as it can introduce new ideas or ideas from
other areas, highlighting weaknesses in approach or implementation and can
lead to better next versions. There is room for a range of toolsets with a
range of value sets in the market for each processor family and the better
they all become the easier it is for us to do good work and deliver great
products.
Ray
Reply by ●March 5, 20042004-03-05
> We have all had bad experiences at some stage but
I would rather talk things
> up than down.
That's great if you're in marketing, but not disclosing known bugs
and their workarounds is very much a disservice to everyone who buys
your product because they end up discovering the same bug that
someone else already knew about. Far too many companies these days
seem to believe that publishing a bug list for their tools somehow
makes them look inferior to a company that doesn't, and _that_ is
particularly insulting to the intelligence of the would-be customers.
Granted, the line between someone pointing out a product's
deficiencies and starting to bash it can be awfully difficult to
ascertain at times...
---Joel Kolstad
P.S. -- Another pet peeve of mine is the now near-ubiquitous use of
euphemisms when discussing product bugs. I.e., the use of the
word 'issue' rather than 'bug' or 'defect,' etc., and the use of the
word 'may' rather than 'will' (as in, 'the program may not work if
you do thus and so,' when, in reality, it's 100% guaranteed not to
work in such a case).
> up than down.
That's great if you're in marketing, but not disclosing known bugs
and their workarounds is very much a disservice to everyone who buys
your product because they end up discovering the same bug that
someone else already knew about. Far too many companies these days
seem to believe that publishing a bug list for their tools somehow
makes them look inferior to a company that doesn't, and _that_ is
particularly insulting to the intelligence of the would-be customers.
Granted, the line between someone pointing out a product's
deficiencies and starting to bash it can be awfully difficult to
ascertain at times...
---Joel Kolstad
P.S. -- Another pet peeve of mine is the now near-ubiquitous use of
euphemisms when discussing product bugs. I.e., the use of the
word 'issue' rather than 'bug' or 'defect,' etc., and the use of the
word 'may' rather than 'will' (as in, 'the program may not work if
you do thus and so,' when, in reality, it's 100% guaranteed not to
work in such a case).
