STM32 ARM toolset advice?

Bocote wrote:
> Yes I might be able to find a contractor who would be willing to tell me
> they can easily fix a thorny compiler bug - but having been burnt by over
> confident coders, I would not risk my business or the jobs of people who
> are employed by it on the basis of a contract who thought they knew how
> compilers work better than a compiler vendor.

The only difference to the proprietary closed-source compiler here is
that the closed-source company won't tell you "unfortunately, our guru
retired, and we don't know how it works" even if that's the truth. Or
they tell you they're restructuring and are no longer interested in
supporting this product.

> I recently worked with another company who used a "free compiler" with all
> the library sources provided for the embedded chip they put on one of the
> boards in the system – wow they had problems, lots and lots of problems. 
> They ended up re-writing library functions, after of course working out how
> they were supposed to work and how they actually worked, and several
> abortive attempts to fix them themselves. etc.  their "free tool" added
> months to the project, now that I don't call free.

I still don't see how that task had been easier for you if you didn't
have source. The whole point is about having source, not about free. And
I don't think the open-source libraries have worse quality than the
proprietary ones. I have also fixed numerous bugs in the commercial
libraries we bought. Including some the vendors refused to fix. Even
trivial ones such as using 'char' instead of 'unsigned char' for
marshalling, which happens to work on PCs, but not on our target.

That aside, guess what you see when you look into a commercial system? I
found a NetBSD VFS, NetBSD IP stack, expat, gzip, Spencer's regexp.c,
etc. in that we bought. So it cannot be that bad.

> I guess my objection to open source is the way it is always portrayed as
> "free" and "better than software you pay for".   The trouble is the real
> costs are ignored.

The points where I think OSS is "better" are:
- you can evaluate it easier. No need to sign advance NDAs or hand out
  money. You do not even need to wait for the mail package to arrive
  next week, and you can usually get honest opinions on it on mailing
  lists.
- you can look into it. Some commercial software also allows that, but
  by far not all. I haven't seen a commercial compiler that ships the
  source for its 'printf' yet.
- you can still modify it, even if its original author no longer wants
  to. Yes, this may be expensive, but at least it's possible.

I haven't found anything where closed-source software is fundamentally
better. Warranties? Nobody guarantees you anymore than his software
takes up disk space, and maybe gives you free replacement if the shipped
CDs get unreadable within six weeks. Support? Commercial support can be
had for OSS, too. Otherwise, support is simply structured differently
than for classic closed-source SW. The big company you can sue if
something goes wrong? Did anyone *ever* sue MS or IBM when their
software failed?


  Stefan

In article <gd07af.1dk.1@stefan.msgid.phost.de>, stefan.news@arcor.de=20
says...
> Bocote wrote:
> > Yes I might be able to find a contractor who would be willing to tell m=
e
> > they can easily fix a thorny compiler bug - but having been burnt by ov=
er
> > confident coders, I would not risk my business or the jobs of people wh=
o
> > are employed by it on the basis of a contract who thought they knew how
> > compilers work better than a compiler vendor.
>=20
> The only difference to the proprietary closed-source compiler here is
> that the closed-source company won't tell you "unfortunately, our guru
> retired, and we don't know how it works" even if that's the truth. Or
> they tell you they're restructuring and are no longer interested in
> supporting this product.
>=20
> > I recently worked with another company who used a "free compiler" with =
all
> > the library sources provided for the embedded chip they put on one of t=
he
> > boards in the system =E2=A4=3D3F wow they had problems, lots and lots o=
f problems.=20
> > They ended up re-writing library functions, after of course working out=
 how
> > they were supposed to work and how they actually worked, and several
> > abortive attempts to fix them themselves. etc.  their "free tool" added
> > months to the project, now that I don't call free.
>=20
> I still don't see how that task had been easier for you if you didn't
> have source. The whole point is about having source, not about free. And
> I don't think the open-source libraries have worse quality than the
> proprietary ones. I have also fixed numerous bugs in the commercial
> libraries we bought. Including some the vendors refused to fix. Even
> trivial ones such as using 'char' instead of 'unsigned char' for
> marshalling, which happens to work on PCs, but not on our target.
>=20
> That aside, guess what you see when you look into a commercial system? I
> found a NetBSD VFS, NetBSD IP stack, expat, gzip, Spencer's regexp.c,
> etc. in that we bought. So it cannot be that bad.
>=20
> > I guess my objection to open source is the way it is always portrayed a=
s
> > "free" and "better than software you pay for".   The trouble is the rea=
l
> > costs are ignored.
>=20
> The points where I think OSS is "better" are:
> - you can evaluate it easier. No need to sign advance NDAs or hand out
>   money. You do not even need to wait for the mail package to arrive
>   next week, and you can usually get honest opinions on it on mailing
>   lists.
> - you can look into it. Some commercial software also allows that, but
>   by far not all. I haven't seen a commercial compiler that ships the
>   source for its 'printf' yet.

The first IAR EWARM version that I got (3.2)  arrived with the full=20
source and make files for the libraries.


> - you can still modify it, even if its original author no longer wants
>   to. Yes, this may be expensive, but at least it's possible.

I've never had to recompile the IAR ARM libraries.  I did find one
bug,  verified it in the source, and wrote my own version of the
function, which the linker loaded instead of the library version.
The bug was fixed in the next release.
>=20
> I haven't found anything where closed-source software is fundamentally
> better. Warranties? Nobody guarantees you anymore than his software
> takes up disk space, and maybe gives you free replacement if the shipped
> CDs get unreadable within six weeks. Support? Commercial support can be
> had for OSS, too. Otherwise, support is simply structured differently
> than for classic closed-source SW. The big company you can sue if
> something goes wrong? Did anyone *ever* sue MS or IBM when their
> software failed?

Mark Borgerson

Stefan Reuther wrote:

[...]

>- you can look into it. Some commercial software also allows that, but
>  by far not all. I haven't seen a commercial compiler that ships the
>  source for its 'printf' yet.

Which commercial "embedded" cross compiler comes without library
sources? By "library" I mean not only the standard C libraries (printf
etc.) but also the machine library, basic math functions (+-*/).

Today I use mainly the commercial "closed source" Cosmic compiler for
the HC(S)12 and HC(S)08 - it comes with full library sources. When I
found an error, it was always fixed extremly fast and the
communication was very efficient. The same applies to suggestions for
improvements.

The old (1992) HI-TECH C Compiler for the 68HC11 also came whith
library sources.

IIRC, HIWARE (later Metrowerks, then Freescale) also supplied library
sources for the HC(S)12 compilers. Can't say whether that's still
true.


When I had a look at GCC for Coldfire some time ago, I wasn't even
able to _find_ quickly these sources (wanted to check math
implementation) in the bloat of files and directories GCC consists of.
BTW: Any hints welcome.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

Oliver Betz wrote:

> Stefan Reuther wrote:
> >- you can look into it. Some commercial software also allows that, but
> >  by far not all. I haven't seen a commercial compiler that ships the
> >  source for its 'printf' yet.
>
> Which commercial "embedded" cross compiler comes without library
> sources? By "library" I mean not only the standard C libraries (printf
> etc.) but also the machine library, basic math functions (+-*/).
>
> Today I use mainly the commercial "closed source" Cosmic compiler for
> the HC(S)12 and HC(S)08 - it comes with full library sources. When I
> found an error, it was always fixed extremly fast and the
> communication was very efficient. The same applies to suggestions for
> improvements.

Most if not all embedded system commercial compilers are shipped with
full library sources.

Byte Craft ships library sources so that our customers have full application
sources for their projects.

Regards


--
 Walter Banks
 Byte Craft Limited
 http://www.bytecraft.com
 walter@bytecraft.com

Oliver Betz wrote:
> Stefan Reuther wrote:
> [...]
>>- you can look into it. Some commercial software also allows that, but
>> by far not all. I haven't seen a commercial compiler that ships the
>> source for its 'printf' yet.
> 
> Which commercial "embedded" cross compiler comes without library
> sources? By "library" I mean not only the standard C libraries (printf
> etc.) but also the machine library, basic math functions (+-*/).

Green Hills, for example. They're shipping the source code to 'open', so
you can implement your own (which I did). But I haven't found yet the
source code to 'fopen' or 'std::fstream', telling how they invoke it.
Which means, when debugging my file system stack, I always have a bunch
of assembly-only routines on my stack. Things like '__div32' are also
missing, but for those I normally don't need source when I have a
disassembler :-)

I don't know if this source can be had by moving a few more bucks over
the counter. Maybe not, the header files have a Dinkumware copyright.

> When I had a look at GCC for Coldfire some time ago, I wasn't even
> able to _find_ quickly these sources (wanted to check math
> implementation) in the bloat of files and directories GCC consists of.
> BTW: Any hints welcome.

Normally, the keyword is libgcc, leading to the source file
gcc/libgcc2.c; I'm not a gcc expert so I don't know whether that's
everything gcc needs.


  Stefan

On 2008-10-14, Stefan Reuther <stefan.news@arcor.de> wrote:
> Oliver Betz wrote:
>> Stefan Reuther wrote:
>> [...]
>>>- you can look into it. Some commercial software also allows that, but
>>> by far not all. I haven't seen a commercial compiler that ships the
>>> source for its 'printf' yet.
>> 
>> Which commercial "embedded" cross compiler comes without
>> library sources? By "library" I mean not only the standard C
>> libraries (printf etc.) but also the machine library, basic
>> math functions (+-*/).
>
> Green Hills, for example. They're shipping the source code to
> 'open', so you can implement your own (which I did). But I
> haven't found yet the source code to 'fopen' or
> 'std::fstream', telling how they invoke it. Which means, when
> debugging my file system stack, I always have a bunch of
> assembly-only routines on my stack. Things like '__div32' are
> also missing, but for those I normally don't need source when
> I have a disassembler :-)
>
> I don't know if this source can be had by moving a few more
> bucks over the counter. Maybe not, the header files have a
> Dinkumware copyright.
>
>> When I had a look at GCC for Coldfire some time ago, I wasn't
>> even able to _find_ quickly these sources (wanted to check
>> math implementation) in the bloat of files and directories GCC
>> consists of. BTW: Any hints welcome.
>
> Normally, the keyword is libgcc, leading to the source file
> gcc/libgcc2.c; I'm not a gcc expert so I don't know whether that's
> everything gcc needs.

Yes, that's everything gcc needs.  It's not libc though it's
just the internal functions to which gcc generates calls to do
operations that aren't supported directly by machine
instructions (multiple precision arithmetic, floating point,
etc.).

If you're looking for sources for libc stuff, that's not gcc.
That's glibc, newlib, uclibc, diet-libc, or whatever libc
you've chosen.

-- 
Grant Edwards                   grante             Yow! I always have fun
                                  at               because I'm out of my
                               visi.com            mind!!!

Stefan Reuther wrote:

[...]

>>>- you can look into it. Some commercial software also allows that, but
>>> by far not all. I haven't seen a commercial compiler that ships the
>>> source for its 'printf' yet.
>> 
>> Which commercial "embedded" cross compiler comes without library
>> sources? By "library" I mean not only the standard C libraries (printf
>> etc.) but also the machine library, basic math functions (+-*/).
>
>Green Hills, for example.

ha - the company which didn't respond to my first inquiry, and when I
called them again, they told me that I have to buy at least three
licenses to get a valuable customer.

>They're shipping the source code to 'open', so

I didn't understand this.

[...]

>> When I had a look at GCC for Coldfire some time ago, I wasn't even
>> able to _find_ quickly these sources (wanted to check math
>> implementation) in the bloat of files and directories GCC consists of.
>> BTW: Any hints welcome.
>
>Normally, the keyword is libgcc, leading to the source file
>gcc/libgcc2.c; I'm not a gcc expert so I don't know whether that's

Thanks!

Oliver
-- 
Oliver Betz, Muenchen (oliverbetz.de)

Stefan Reuther wrote:

[...]

>> When I had a look at GCC for Coldfire some time ago, I wasn't even
>> able to _find_ quickly these sources (wanted to check math
>> implementation) in the bloat of files and directories GCC consists of.
>> BTW: Any hints welcome.
>
>Normally, the keyword is libgcc, leading to the source file
>gcc/libgcc2.c; I'm not a gcc expert so I don't know whether that's

and huge #defines with inline assembler (or C) in .h files, e.g.
longlong.h. Extensive dependencies... I guess that's the price one has
to pay for having one copmpiler for so many targets, but who cares if
the result is fine.

I will have a close look at the generated code when I start using GCC
for the Coldfire. What I have seen so far is quite promising.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

On Wed, 15 Oct 2008 09:35:19 +0200, Oliver Betz <obetz@despammed.com>
wrote:

>Stefan Reuther wrote:
>
>[...]
>
>>> When I had a look at GCC for Coldfire some time ago, I wasn't even
>>> able to _find_ quickly these sources (wanted to check math
>>> implementation) in the bloat of files and directories GCC consists of.
>>> BTW: Any hints welcome.
>>
>>Normally, the keyword is libgcc, leading to the source file
>>gcc/libgcc2.c; I'm not a gcc expert so I don't know whether that's
>
>and huge #defines with inline assembler (or C) in .h files, e.g.
>longlong.h. Extensive dependencies... I guess that's the price one has
>to pay for having one copmpiler for so many targets, but who cares if
>the result is fine.
>
>I will have a close look at the generated code when I start using GCC
>for the Coldfire. What I have seen so far is quite promising.
>
>Oliver

We ported all our 68K Code from commercial compilers to GCC for 68k.
This is the same GCC used for Coldfire. The code was significantly
faster using GCC.  

Regards
  Anton Erasmus

Anton Erasmus wrote:

> We ported all our 68K Code from commercial compilers to GCC for 68k.
> This is the same GCC used for Coldfire. The code was significantly
> faster using GCC.
>

Anton,

Did you find out where the GCC was faster?

Which compilers?

w..