STM32 ARM toolset advice?

Indeed. There is no shortage of vendors willing to sell you the support you want for most open-source products, including Linux and GCC. That way you get the comfort of having someone to yell at, *and* the advantage of being able to examine how things really work if you need to or want to. I don't understand why this is always seen as an either-or proposition when you can have both.

-Anders

That I have found generally the case.

No. However some open source is very expensive (see other email in this thread from Eden

Some closed source is very good and FREE

You seem to have the stupid idea that all closed source is expensive and all open source is free.

The last time I reported a gnu toolchain bug, it was fixed within a few hours. :) I've also been ignored by commercial toolchain vendors when I reported a bug.

You can get commercial support for open-source if you want.

Having been doing tech support for may years I can tell you that giving most programers the source to fix a compiler is not a good idea. Most don't understand compilers. They also go on about "ANSI-C" !!!

The other disadvantage is that it is old technology and is not as good at is primary purpose and the commercial tools.

Perhaps it is your approach. :-)

So they are not free.. Where is the advantage?

This is just the same old arguments that have been put pro and anti open source for years. Some open source code is good and well supported, some bad. Some closed source code is good and well supported, some bad. Etc, etc. Some open source comes with commercial support, some doesn't. Blah, blah, blah. As with everything in life generalisations are usually misguided.

I wonder how many anti-open source people use Firefox?

Usually being able to look and understand the implementation is enough. For instance, working on OS X having access to the IOKit sources has saved my bacon several times - either by clarifying vague or incomplete documentation, or by being able to show that some particularly tricky bug was in the operating system and helping us implement a workaround until the vendor released a fix.

There you go again, confusing "commercial" and "open-source". Though I suspect in your case it's intentional.

-Anders

The advantage is (and this is not at all a new argument): if the commercial vendor tells you "I won't fix this bug, buy our upgrade instead", "You are using a non-standard product which is not covered by our support contract", or "We won't fix this problem, implement your own workaround", that's it. Maybe you can go to court and solve the issue, so you get a fix six months later. With an open-source tool-chain, you can always hire someone to do it for you (if you don't want to do it yourself).

The open-source people will also not ship broken dongle drivers that crash your development machine, nor will they tell you "of course we delivered you the CDs and dongles, but we will not give you the license files until you sign this contract expansion which limits your rights".

None of the above has been made up, everything experienced during my (still short) life as embedded developer. I would prefer open-source by far. Actually, aside from the Windows and the toolchain on my development computer, all programs I use regularly are open-source. Unfortunately, the GCC for our target is pretty bad.

Maybe my experience also comes from the fact that we're a medium-sized European company, which doesn't have high priority for glorious American companies. If we were AT&T or the DoD in the United States, our live might be easier. That aside, our company policy is to buy source licenses for everything where we can get them. This has saved our lives, nay, projects, more than once in a while. If there were a source license for the compiler, we'd probably get it.

Compulsory car comparison: would you buy a car where the motor block is cast in concrete, which only the vendor can fix, and only if you buy a support contract? Or would you buy one which every backyard mechanic (or you yourself using a self-help book) can fix?

Stefan

I take it you have adjusted the mixture on a car that has moved from Boston to Denver to accommodate the 5000ft altitude change.

My point just as tools become more specific so has the examples. Just a simple screwdriver used to adjust carburetors it now requires engine controller code to be re-flashed to account for change of address.

Regards,

-- Walter Banks Byte Craft Limited

I've not seen that happen with my IAR ARM toolset.

Bad example. Backyard car engine diagnosis and repair pretty much went away with computerized engine controls, emission controls, etc.

I actually prefer to have my engine block cast in steel.

Mark Borgerson

... snip ...

In other words you disapprove of having code developed for one project usable unchanged on another? BTW, the standard is ISO. ANSI applies to the US.

Unless you have a car from the 70s or earlier. :-)

Or you spend a bunch for the proper diagnostic tools.

Mostly cast iron or cast aluminum, I think. :-)

No. That is not what I said.

I know that. You know that.

However most programmers have no idea what they mean by "ANSI-C" and have never heard of 9899:1990 or 9899:1999

Please be careful who you attribute text to: that was not written by me.

Paul

Good luck. However, ARM is a mass-market, so there's serious competition. That's probably a good incentive to behave nicely.

Okay, the last car I owned is now old enough to get its own driving license. It did have a little electronics, but I never brought it to an official manufacturer-licensed mechanic. The "free" / "unlicensed" ones still got it fixed.

And even with today's fully-electronicised cars, backyard mechanics can change the spark plugs, fuel pumps, catalytic converters, etc. For a piece of proprietary binary-only software, only the manufacturer can do that.

Stefan

And I have never said that. However never let the facts get in the way of a good rant....

Actually he failed to attribute it to anyone, including me. Note that properly composed messages have attributions with one less quote markers than the associated quote.

One thing is for sure I would not risk my families life or spend my life in prison by driving a car that any "backyard mechanic", or someone having a go using a "self-help book" has tried to mend the braking system that they don't understand, who can't do the calculations to determine if the tubing can withstand the pressure involved in an emergency stop, or even worse thought they could make it so much better with just a little alteration here or there.

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.

you (if you don't want to do it yourself).

Yes but ! my engineers are paid to do the job my customers want done not playing "backyard mechanic" fixing other peoples software. I did look at the route you suggested of buying a supported Linux environment for a major project we have recently completed. Wow, you might hate Microsoft but the cost of using tools etc from a vendor offering what I needed packaged and supported, was not far off 10 times the amount of buying the Microsoft Tools.

Rather proves the point doesn't it.

The compilers we use knocks spots of the GCC equivalent compiler for every single one of the targets we use, and with several project the code and data bloating of the GCC compiler would have made the project too large for the target processor, but then opur tools are written by a vendor who really understand the needs of embedded targets, who specialises in that one market.

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. Unless of course you done get paid for your time, such as if you?re a student. Oh and our mutual customer has asked us to quote for replacing their software completely in the next upgrade to the product. A lost customer is a very high price to pay for using a "free tool".

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. Its almost as though open source is a religion that is fundamentally right for all situations and for all people ? "just because it is", and somehow people earning a living writing software are evil capitalists.

Bocote

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

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