Developing/compiling software

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.

So what else is there and how about other vendors and architectures. 
What's so inferior about the gnu toolchain, for example ?.

> 
>> means a diminishing client base and less money for development. Unless
>> they can come up with a revised business model, they seem condemned to
>> niche markets and long term decline. If you want evidence, compare the
>> diversity of tool vendors a decade ago with the same now.
> 
> True... So eventually programmers will be expected to produce their own
> tools and RTOS on their own time at their own expense.

Some already do :-), but that's taking the argument to absurd limits. Of 
course, you write some tools over the years, but buy in the stuff that 
would be uneconomic to develop yourself. One of the great strengths of 
open source is that it shares the cost and time to develop complex 
applications among the many with the result available for all to use. It 
potentially brings together resources that would be not possible for 
individual companies.

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

The truth is that the marketplace for tools has changed forever. How 
will traditional tool vendors  like Keil and IAR survive in the long term ?.

> 
> The problem is the main users of the open source tools are not the ones
> who are producing them...
> 

How is this a problem ?...

Regards,

Chris

On 2009-09-23, Lodewicus Maas <wicus.maas@gmail.com> 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. 

Have you thought about using an AVR or MSP430 or something less
brain-dead (for which free/cheap tools are available)?

-- 
Grant Edwards                   grante             Yow! This PIZZA symbolizes
                                  at               my COMPLETE EMOTIONAL
                               visi.com            RECOVERY!!

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.

-- 
Grant Edwards                   grante             Yow! I just heard the
                                  at               SEVENTIES were over!!  And
                               visi.com            I was just getting in touch
                                                   with my LEISURE SUIT!!

Chris H wrote:


> Who funds these open source programmers? They have to eat.

There is a big difference in the philosophy of the self-employed and the 
employees: An employee hates his job and tries to do something beautiful 
on his own for the sake of it. Self-employed tries to make money of 
everything.

> The problem is the main users of the open source tools are not the ones
> who are producing them...

One of the main problems of any tools is that the one who makes them is 
not the one who uses them. The more sophisticated the tools are, the 
bigger is the problem.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On 2009-09-23, Vladimir Vassilevsky <nospam@nowhere.com> wrote:
>
>
> Chris H wrote:
>
>
>> Who funds these open source programmers? They have to eat.
>
> There is a big difference in the philosophy of the self-employed and the 
> employees: An employee hates his job and tries to do something beautiful 
> on his own for the sake of it. Self-employed tries to make money of 
> everything.
>
>> The problem is the main users of the open source tools are not
>> the ones who are producing them...

In my experience the producers of open-source tools _do_ use
them. It's just that not all of the users are producers.

> One of the main problems of any tools is that the one who
> makes them is not the one who uses them. The more
> sophisticated the tools are, the bigger is the problem.

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.

-- 
Grant Edwards                   grante             Yow! HUMAN REPLICAS are
                                  at               inserted into VATS of
                               visi.com            NUTRITIONAL YEAST ...

Grant Edwards wrote:

> 
> In my experience the producers of open-source tools _do_ use
> them. It's just that not all of the users are producers.
> 

The best example must be gcc, where each new generation will be compiled 
by the previous one.

> 
> 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. It's 
not the tools that are the problem, but sometimes the attitude of the 
vendors, imho.

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

Regards,

Chris

In message <OLWdnTbPU7jp2SfXnZ2dnUVZ_hKdnZ2d@giganews.com>, Vladimir
Vassilevsky <nospam@nowhere.com> writes
>
>
>Chris H wrote:
>
>
>> Who funds these open source programmers? They have to eat.
>
>There is a big difference in the philosophy of the self-employed and
>the employees: An employee hates his job and tries to do something
>beautiful on his own for the sake of it.

Then you are very sad. It is most certainly not true of all employees by
a long way

> Self-employed tries to make money of everything.

Again completely false.
Though it might be true for you? Arn't you self employed?

>> The problem is the main users of the open source tools are not the ones
>> who are producing them...
>
>One of the main problems of any tools is that the one who makes them is
>not the one who uses them. The more sophisticated the tools are, the
>bigger is the problem.

Very true.


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

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.

-- 
Grant Edwards                   grante             Yow! I'm changing the
                                  at               CHANNEL ... But all I get
                               visi.com            is commercials for "RONCO
                                                   MIRACLE BAMBOO STEAMERS"!

On Wed, 23 Sep 2009 10:00:17 +0200, "Lodewicus Maas"
<wicus.maas@gmail.com> 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.

Last I checked (April, this year) Keil limits itself to 0x800 bytes
(2k) without registration and to 0x1000 bytes (4k) after that.  So you
_may_ be able to boost this to 4k if you register with them.  (I don't
know their policies about registration in your country, though.  So
you will just have to find out about it, I suppose.)

But if you feel that you will also exceed 4k, then... well, perhaps
Keil is now off the table for you.

>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

That's more than I would have expected.  I'm very sorry the situation
is like that, for you.  I mean that very sincerely.

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

I still don't know what code size you expect in your project.  And you
still have a few commercial vendors to check out (like IAR.)  I don't
believe IAR offers more than Keil for a trial version, though I really
don't know about it.  But if it your project is likely to be larger
than 4k, it's possible that the price of the few serious commercial
alternatives may very well leave you with SDCC as the only viable
choice.  However, take a look at Dunfield:

http://www.dunfield.com/products/dks.htm

They are a commercial vendor for low cost c compilers.  They
apparently offer one for the 8031/2 core.  So that may be another
option for you to consider that is already known to be 'cheap.'  You
may look up some reviews that compare it with SDCC before deciding.

Keep finding out about other commercial options, of course, and ask
just as you have with Keil.  But if your project will become much
larger and you feel unable to afford the kinds of prices you find with
those commercial vendors, it's probably better to just invest your
time in SDCC before getting in too deep with the trial versions of
compilers you can ill afford.

So far, SDCC has just worked exactly as intended without difficulty
for the modest tasks I've thrown its way.  So I have no complaints,
yet.

Keil accepts 16-bit descriptions for SFRs that happen to actually be
16 bits wide.  To do the same with SDCC, I have to write two
statements in c, one for each byte.  The generated code in each is
different, but equally fast and occupying the same space.  Just by way
of example how your source code might differ a little.

Although I haven't heard specific details about IAR's pricing for the
8051, I have heard some numbers for IAR's offering for other
microcontrollers where Imagecraft, for example, also plays in the
commercial marketplace.  And there, IAR is not a low-cost compiler
tool, either.  Not by any stretch.  So although you may see a
difference by a factor of 2 (less?), or so, I wouldn't expect a whole
lot better than that.  It's still worth a moment for you to find out
an exact number from IAR and see where it falls relative to your own
willingness to spend for this.  Give them a shot.

Luckily, SDCC seems not a bad choice so far as I'm aware right now.
Don't be scared about SDCC just because Chris H works so energetically
to make it seem terrible.  He has always been quick to reply with
scare tactics regarding anything that he sees as 'threatening' to high
priced commercial products.  Last April, he and I talked a bit about
all this and he is very good at making highly veiled, while almost
seemingly definite claims about SDCC.  In the end, though, he refuses
to be literal and specific and I've taken the view that all of his
knowledge about SDCC is a decade old or more, if it has any value to
it at all.

For example, here is a snippet of our conversation:

>>But I'm not interested in hearing your opinion a second time, without
>>supporting facts.  Which is why I asked for you to provide specifics.
>>I see you still aren't doing that.
>
>Just try both and you will see the results.  I don't have the time.

In this thread, he once again made a semi-specific comment which seems
on its face to be accurate.  I took the time to look up what few words
he used that I might use in a search and found that there was indeed
something about it... but it is old news, back in 2000/2001, and
apparently long since gone as an issue.  And here in this thread, he
continues to avoid providing a recent reference or source or to
elaborate at all.  Which seems very true to form.

There may be good reasons.  Free and low cost c compilers that can do
a credible job threaten to topple high prices.  And with lower prices,
there is less money within those commercial business entities to fund
internal research/development of improved techniques.  So he may have
a holy grail he's pursuing.  I just can't say.  It's just that he
remains a reliable apologist for expensive commercial compilers and
dongles and a consistent attacker of anything that even 'looks'
somewhat different from the usual commercial business model operation.

My main point here isn't to attack Chris H, but to point out that you
shouldn't be frightened by him regarding alternatives like SDCC.  You
are definitely able to do serious projects with SDCC.  If you have any
question, google a few projects that have used it in the past with
good success.  For example, here is one I quickly found, just now:

http://www.arrickrobotics.com/robomenu/adam.html

You can get the SDCC manual here:

http://sdcc.sourceforge.net/doc/sdccman.pdf

Also, the author of the SDCC 8051 component was John Hartman and he
has a mildly interesting 8051 web site here:

http://www.noicedebugger.com/help/8051.htm

Besides some minor differences in the way the SDCC c compiler handles
some things in the source code from the way that Keil does, there are
substantial differences in the way the compilers may be invoked
through their option switches.  See this appnote for some thoughts:

https://www.silabs.com/Support%20Documents/TechnicalDocs/an198.pdf

On a final note, you may still want to revisit the idea of using an
8031/2 core, at all.  Though 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.

Best of luck.

Jon

In article <Hatum.359333$RV1.69792@newsfe26.ams2>, meru@devnull.com 
says...
> Grant Edwards wrote:
> 
> > 
> > In my experience the producers of open-source tools _do_ use
> > them. It's just that not all of the users are producers.
> > 
> 
> The best example must be gcc, where each new generation will be compiled 
> by the previous one.

That's not necessarily true for the GCC cross compilers.  Most of
the cross compilers are compiled on an X86 system.  The people who
build an ARM compiler may never actually use it to compile code
to run on an ARM system.
> 
> > 
> > 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. It's 
> not the tools that are the problem, but sometimes the attitude of the 
> vendors, imho.
> 
> 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...
> 

Mark Borgerson