Developing/compiling software

In article <h9dnlq$39a$1@reader1.panix.com>, invalid@invalid.invalid 
says...
> On 2009-09-23, ChrisQ <meru@devnull.com> wrote:
> > Grant Edwards wrote:
> >
> >> IMO, the problem is even worse for commericial tools where
> >> it's quite obvious that in many cases the producers do not
> >> (nor have they ever attempted to) use the tools.
> >
> > None of the commercial tools i've used have been really bad.
> > They all compile code and seem to have few bugs. Even the
> > older stuff (>10yrs) more or less did what it said on the tin,
> > but by the time you get all the costs, lack of trust, dongles
> > and flexlm hassles onboard, they can turn into a real can of
> > worms totally unrelated to tool quality.
> 
> Don't get me started on dongles and flexlm...
> 
> In my view, that stuff is all part of the quality of the tools.
> If the products' developers had to fight with those, things
> would probably change for the better.  Having to cough up a
> bucket of cash just because you upgraded your workstation is a
> swindle.
> 
> > It's not the tools that are the problem, but sometimes the
> > attitude of the vendors, imho.
> 
> I remember one running battle with a cross-compiler vendor that
> lasted for months and months.  They had lost some of their
> customer records in a computer crash and were completely
> incapable of dealing with the situation.  They were relentless
> in trying to force people to buy new licenses instead of giving
> out the updates to which the customers were entitled.
> 
> > Anyway, the open source stuff, where available, is often as
> > good or better for all practical purposes. There's no real
> > reason not to use it and the open source model of cooperative
> > development is arguably more suited to the mindset of many
> > users. You just have to do some of the legwork yourself...
> 
> I've used gcc for embedded projects on a half-dozen different
> architectures, and have always been quite happy with it.  I'm
> told there are decent commercial tools from reputable firms,
> but I've had consistently bad luck with commercial tools as far
> as both support and quality are concerned.
> 
> 
Just goes to show how varied user experiences can be.  I've had
consistently good luck with Codewarrior(68K systems), IAR (ARM
systems), and ImageCraft (MSP430).  I've also used GCC for an
ARM system without major problems---except having to learn
linux  and support either another computer or a virtual machine.

Mark Borgerson

On 2009-09-23, Mark Borgerson <mborgerson@comcast.net> wrote:

> Just goes to show how varied user experiences can be.  I've
> had consistently good luck with Codewarrior(68K systems), IAR
> (ARM systems), and ImageCraft (MSP430).  I've also used GCC
> for an ARM system without major problems---except having to
> learn linux and support either another computer or a virtual
> machine.

You can use gcc cross-compilers under Cygwin.  But to be
honest, it's probably easier to run Linux on a VM.

-- 
Grant Edwards                   grante             Yow! My pants just went to
                                  at               high school in the Carlsbad
                               visi.com            Caverns!!!

On Sep 24, 7:30=A0am, Jon Kirwan <j...@infinitefactors.org> wrote:
> Last I checked (April, this year) Keil limits itself to 0x800 bytes
> (2k) without registration and to 0x1000 bytes (4k) after that. =A0So you
> _may_ be able to boost this to 4k if you register with them. =A0(I don't
> know their policies about registration in your country, though. =A0So
> you will just have to find out about it, I suppose.)

This HAS changed recently, with Cypress Claiming this:
[" Cypress also offers fully functional, free compilers with no code
size limitations for both the PSoC 3 and PSoC 5 device families."]

["Cypress already has agreements in place to offer free compilers for
both the PSoC 3 and 5 families. The Keil CA51 Compiler for PSoC 3 and
the GNU GCC-ARM compiler are bundled with Creator, which also includes
a debugger to support on-chip debug and trace functionality"]

My understanding is they now have a Full Keil, with reduced optimize
choices,
(and somehow Cypress Centric?)

> >.
> >R 39,335.81 ( this is equal to 5,326.93 USD) - for a single user license
>
> That's more than I would have expected. =A0I'm very sorry the situation
> is like that, for you. =A0I mean that very sincerely.

This high price seems to follow the Embarcadero (ex Borland) selling
model.
ie Target the deep pocket corporates, but have some fringe tools, that
are
somewhat usable.

PC comments : PC tool flows ARE quite useful for embedded work, for
algorithm development

Here, Embarcadero has Turbo Delphi, which is free, but is also
crippled enough
to not compile many web projects.
Meanwhile, MicroSoft has  quite usable versions of their C and Basic
flows,
(which DO compile most web projects...) and there are a number of
other free PC tool flows.

>
> Luckily, SDCC seems not a bad choice so far as I'm aware right now.

HiTech also had a legacy version of their compiler free, IIRC ?
Not sure of the current availability, perhaps on a mirror somewhere ?


> On a final note, you may still want to revisit the idea of using an
> 8031/2 core, at all. =A0Though I seem to recall that you've already
> written a lot of code on the basis of having selected this part which
> has better availability for you, and perhaps you've grown quite
> familiar with its details by now, so perhaps that's not really much of
> an option.

My advice to a novice, would to be to worry less about the compiler -
(as Silicon IS getting cheaper and larger all the time), but to focus
more on the Debug tool chain.

Unless you are intending to produce 10,000+ units into a price-
paranoid
market, then simply choosing the next-larger variant, is a better
solution.

You are always better to start with a more capable device and shrink
to the final application, than the other way around.

Atmel have an OSD in release, and the Silabs offering is mature and
usable,
and Silabs have very good ToolStick level development choices.

The Cypress Debug flows look to extend things, as they claim a
TraceBuffer
I have not seen volume PSoC3 prices, but their web prices are
comfortably under $10

-jg

Grant Edwards wrote:
> On 2009-09-23, ChrisQ <meru@devnull.com> wrote:
> 
>>> Who funds these open source programmers? They have to eat.
>> Some people are still altruistic, believe it or not and do it for fun or 
>> the intellectual challenge while keeping their day job. Others want to 
>> be remembered for contributing something for the common good, rather 
>> than merely for commercial gain. Any number of reasons. Not to say that 
>> there's not serious money involved now. IBM, Hp / Compaq and many others 
>> fund development and the likes of Redhat, Code Sourcery and Kpit Cummins 
>> package up the results to sell and provide support.
> 
> Some of the CPU vendors (Hitachi, Atmel, Altera) fund much of
> the initial gcc port and then provide support for the
> community. Unfortunately, others (like TI) appear to actively
> sabotage free tools.  They don't succeed in hindering the tool
> development much, but they do manage to annoy their customers.
> 

It will be interesting to see how that attitude will change at TI now 
that they have bought Luminary Micro and swallowed their Cortex M3 line. 
  Luminary Micro supported a broad range of compilers pretty much 
equally (Keil, IAR, Code Red and CodeSourcery) with their evaluation 
kits, libraries, and example software.  They also support FreeRTOS, uIP 
and lwIP (their ROM-based boot loader uses uIP, AFAIK).

I don't know how much of that attitude will spread from the Luminary 
Micro group at TI to other groups (you're probably thinking mainly of 
the msp430).  But for the Cortex M3 devices anyway, the idea is that the 
customer gets to choose which tools suit his needs, rather than which 
ones TI happens to like dealing with.

ChrisQ wrote:
> Chris H wrote:
> 
>>
>> If that were the case there would be a problem but so far most of the
>> open source compilers are no where near as good as the top commercial
>> ones.
>>
> 
> I'm sorry, but you need to be more specific in terms of *how* they are 
> better. You're not selling soap powder to the 19th c unwashed here. If 
> we are discussing Keil, it's not so much the compiler, but the linker, 
> which seems to do magic in terms of it's overlay analysis and ability to 
> make use of constrained ram and xdata space. A btter solution might have 
> been to do more work upfront in terms of design and cpu choice to avoid 
> the problem in the first place. Great for legacy hardware but not 
> necessarily relevant if you're starting from scratch.
> 

One point that is missing here is that the tools situation varies widely 
according to the processor architecture.  In particular, there is a huge 
difference between C-friendly architectures (>= 16-bit, plenty of 
registers and pointers) and C-unfriendly architectures (8-bit, few 
registers).

In the world of C-friendly processors, there is not a huge difference 
between major compilers for ordinary code generation.  I've looked at 
tools for the PPC and the ColdFire - there are not many percentage point 
differences in the code size or speed for ordinary code between tools 
like Green Hills, CodeWarrior, and gcc.  You certainly couldn't justify 
a purchasing decision based on the code quality.  One thing that /can/ 
vary is the support for generating code that takes advantage of 
additional features such as DSP-type processor extensions.  Libraries, 
debugger, profiler, IDE, wizards, etc. are other distinguishing 
features, as is language support (C and C++ standards and extensions). 
Much depends on how well the toolset fits the way you like to work.

For these sorts of processors, gcc is very much a realistic choice for 
professional users seeking the best tools.  CodeWarrior has compiler 
options to enable gcc language extensions - that's an indication of the 
relevance of gcc in that market.

You also see smaller players building toolchains around gcc - they have 
gcc as the compiler, but use their own library, debugger, and other 
tools (possibly their own IDE, or just using Eclipse like many others).

Anyone who still thinks gcc is "nowhere near as good as the top 
commercial compilers" for processors like ARM, PPC, ColdFire, MIPs, x86 
is either many years out of date, or has his head in the sand.  Argue 
about the benefits of commercial support, integrated solutions, 
certification, libraries, etc. if you want - that is where there are 
real distinctions in the tools.  But not the compiler.


For small cpus, the situation is very different.  Getting the best out 
of a processor like the 8051 or the COP8 is far from easy.  For the 
COP8, there are relatively few users, all of which are serious 
professionals.  Writing a good compiler for the device is a specialised 
job.  Whereas for larger devices, much of the compiler software can be 
shared across different targets, on something like the COP8 there will 
be a higher proportion of target-specific code.  This means that writing 
a COP8 compiler takes a lot of time and money for a very small user 
base, and that really boils down to commercial tools at a 
professional-only price point.

The 8051 is an oddity in this.  It is a C-unfriendly device and the 
professional-only compiler (and associated tools) from 8051-specialist 
Keil gives the best code.  On the other hand, it is very popular and 
there is a perfectly reasonable open source compiler.  The generated 
code might not be as compact (especially in data usage) as with Keil's 
compiler, but that's not a problem for all users.


One important thing to consider in this is how things will change in the 
future.  The trend is towards 32-bit micros - they are getting smaller, 
cheaper and lower power, and pushing out the 8-bit devices (16-bit is 
now almost non-existent, except for the msp430 which is squarely in the 
8-bit market).  Use of 8-bit devices will become less common for new 
designs (except for customers looking for huge volumes, of course), 
especially in the case of C-unfriendly architectures, making life 
difficult for the more specialist tool vendors.  I suspect we'll see 
more development tools based on gcc but with specialisation and 
differentiation in libraries, debuggers, other tools, and support (there 
are already half a dozen such tools for ARM variants).  How then will 
the big commercial developers react?  I hope they adapt and that we 
don't see acquisitions or bankruptcies - choice and competition is 
important for end users.

On Sep 23, 11:00=A0am, "Lodewicus Maas" <wicus.m...@gmail.com> wrote:

> OK. So Keil is NOT an option anymore
> .
> R 39,335.81 ( this is equal to 5,326.93 USD) - for a single user license

Which package is that? PK51 costs more, but if don't need their RTOS
and debugger, then check CA51.

Chris H wrote:
> In message <4ab9e8bc$0$26317$8404b019@news.wineasy.se>, David Brown
> <david@westcontrol.removethisbit.com> writes
>> Lodewicus Maas wrote:
>>> OK. So Keil is NOT an option anymore
>>> .
>>> The Demo/Eval version can only compile up to a max of 2K - which I
>>> reached already. I then requested a quote from the local suppliers of
>>> Keil software, and the quote is ...
>>> .
>>> .
>>> I hope you're sitting ...
>>> .
>>> .
>>> .
>>> R 39,335.81 ( this is equal to 5,326.93 USD) - for a single user license
>>> .
>>> .
>>> My whole outlook on life is "value for money", and I don't invest in
>>> anything if this requirement is not met, but unfortunately there is no
>>> way in which I can justify this as a hobbiest
>>> .
>>> I'm now busy looking at ImageCraft
>>> .
>>> The "doors" keep on closing, but eventually I'll get there.
>> ImageCraft does not make an 8051 compiler - the make (amongst others)
>> an AVR compiler.
>>
>> For hobby use, you have two options.  You can use SDCC for free, or you
>> can drop all thoughts about using the 8051.
> 
> Or use the 2K Keil or the 4K Keil if you can find one.  These can
> compile programs the SDCC can't. However for hobby use the Keil is
> expensive but then it is not aimed at hobby users.
> 

For hobby or small usage, you can typically just buy a device with more 
memory.  So what if it costs a dollar more - it is easier (and therefore 
faster and therefore cheaper) that trying to make sure your code is 
within such small size limits.  So what if SDCC takes 10 KB when Keil 
can put the same program in 6 KB - if you have a 16 KB device, it 
doesn't matter.  Code size is not always a big issue.

> for commercial use one of my customers worked out the SDCC cost them
> about 5K in time and resources.  So free to buy does not always mean
> completely free. Though for hobby use time is free.
> 

People are always working out figures like that.  Occasionally, they 
will actually come up with a figure that is realistic, but even then it 
is not applicable to anyone else.

To get true figures like that, you'd need to actually do the work in 
parallel with two different development teams, each of which being large 
enough to make valid statistical comparisons about the abilities and 
experiences of the two teams.  No one is going to do such a comparison - 
at least, not for a 5K cost or saving.

So the numbers are based on guestimates and figures pulled out the air. 
  You ask a developer to look briefly at the tools and he says it will 
take me a week to get up to speed with Keil, and two weeks for SDCC - 
the bean counter concludes that Keil will save a weeks worth of 
development time.

I don't mean to say that these numbers are wrong for the customer in 
question, just that for other potential users, the quote is barely worth 
the pixels its written on.

On 2009-09-24, David Brown <david@westcontrol.removethisbit.com> wrote:
> Grant Edwards wrote:
>
>> Some of the CPU vendors (Hitachi, Atmel, Altera) fund much of
>> the initial gcc port and then provide support for the
>> community. Unfortunately, others (like TI) appear to actively
>> sabotage free tools.  They don't succeed in hindering the tool
>> development much, but they do manage to annoy their customers.
>
> It will be interesting to see how that attitude will change at
> TI now that they have bought Luminary Micro and swallowed
> their Cortex M3 line.
>
> Luminary Micro supported a broad range of compilers pretty
> much equally (Keil, IAR, Code Red and CodeSourcery) with their
> evaluation kits, libraries, and example software.

Definitely.  I played with one of their M3 eval kits, and they
provided a pre-built linux-hosted gcc toolchain and they seemed
very friendly towards open-source toolchains and non-MSWindows
uses.

> They also support FreeRTOS, uIP and lwIP (their ROM-based boot
> loader uses uIP, AFAIK).
>
> I don't know how much of that attitude will spread from the
> Luminary Micro group at TI to other groups (you're probably
> thinking mainly of the msp430).

Yes, I was.  Their nasty attitude towards open-source JTAG
debugging in particular.  TI even went to the extent to plant
moles in the open source community (TI employees who didn't use
TI e-mail addresses when interacting with the public and
attempted to hide the fact that they were TI employees.)

> But for the Cortex M3 devices anyway, the idea is that the 
> customer gets to choose which tools suit his needs, rather
> than which ones TI happens to like dealing with.

The interesting thing about the MSP430 tools is that TI pushed
people pretty hard towards IAR -- even to the extent that the
FAEs would tell people not to use TIs CodeComposer tools but
rather to use IAR's.

The IAR tools themselves aren't bad, but their licensing terms
suck (the usual hassles with dongles, license managers), and
the only host they support is MS Windows.

-- 
Grant Edwards                   grante             Yow! NANCY!!  Why is
                                  at               everything RED?!
                               visi.com            

In message <h9fvhl$2lb$1@reader1.panix.com>, Grant Edwards
<invalid@invalid.invalid> writes
>Yes, I was.  Their nasty attitude towards open-source JTAG
>debugging in particular.  TI even went to the extent to plant
>moles in the open source community (TI employees who didn't use
>TI e-mail addresses when interacting with the public and
>attempted to hide the fact that they were TI employees.)


My god you are sad.  Most companies insist that  employees use private
email addresses and not company ones when  conversing on  newsgroups and
forum lest anything they say be taken as being said on behalf of the
company.

Your paranoid suggestion that TI was planting "moles" is a sad
reflection on you.

Then again what is your email address? invalid@invalid.invalid  Hmmm not
a TI mole by any chance?  OK so you do have another email address inthe
sig.

Tell me is Mike Sowada happy with you/visi making these accusations
about TI?



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 2009-09-24, Chris H <chris@phaedsys.org> wrote:

> My god you are sad.  Most companies insist that employees use
> private email addresses and not company ones when conversing
> on newsgroups and forum lest anything they say be taken as
> being said on behalf of the company.

We're supposed to believe that things TI employees say in
regards to TI products _aren't_ being said on behalf of the
company?

> Your paranoid suggestion that TI was planting "moles" is a sad
> reflection on you.
>
> Then again what is your email address? invalid@invalid.invalid
> Hmmm not a TI mole by any chance?  OK so you do have another
> email address inthe sig.

A futile attempt to avoid my e-mail address from being
harvested mechanically.

> Tell me is Mike Sowada happy with you/visi making these
> accusations about TI?

I don't think my ISP cares one way or the other about my
opinions on TI's interaction with their customers.  Neither
does the post office or the phone company, in case you're
curious about them.

-- 
Grant Edwards                   grante             Yow! I smell a RANCID
                                  at               CORN DOG!
                               visi.com