Forums

STM32 ARM toolset advice?

Started by John Speth October 7, 2008
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..