GNUPro Development, v850

Actually you don't generally use a "debian" gcc for embedded development. You use a cross compiler (or more accurately a complete cross- toolchain) which is stand-alone and lives in its own directory structure.

You don't *need* to ever rebuild the toolchain. Although you can if you want to since the source code is available. I have used pure FSF gcc, as well as "packaged" cross-gcc's like gnuarm, and "modified" gcc's like code sourcery. In all cases you can get the complete sources needed to rebuild the binaries, or you can just download the binaries for your architecture (i.e. linux or win32).

And there is nothing to stop you putting the binaries under the same revision control as your own source code.

I don't understand why you are going on about this - you just make sure you keep the compiler binaries for your project in a different location for each compiler you need to use. Generally this does not change, but if it does there is no problem. What do you do for different versions of a commercial compiler? The precedures required are not really any different except that the gcc toolchain will probably still work 10 years later and the commercial one probably won't.

Here are some subfolders in my /opt folder:

arm-2007q3 arm-2008q1 avr-4.1 avr-elf-3.3.2 avr-elf-3.4.3 c167 gnuarm-3.4.3

Each folder contains a complete toolchain (gcc, binutils, libraries, debugger etc). In the project makefile there is a statement like

GNUBASE := /opt/arm-2007q3

So the project always uses that one.

What do you do with commercial compilers when there are multiple versions of it installed?

I would also emphasise that the native gcc is not that relevant for embedded development. Unless you are developing a linux "appliance" with a compiler hosted on that appliance, perhaps.

On Thu, 04 Dec 2008 12:26:11 GMT, snipped-for-privacy@mpeforth.com (Stephen Pelc) wrote:

The support have definitely improved since sanctions were dropped and being able to contact companies directly using the internet. Many of the local companies got things through the sanctions, hence operated almost like a mafia underground. You paid your money, and you took what they could get you. The local agents were slow to change their attitude - having markups of a few 100% without having to provide support is much better than having a markup of 50% or lower and having to provide support. We switched to gcc, and smaller compiler companies. Initially it was difficult to get going with gcc, but once one get going with one variant, it is actually less trouble than getting going with another compiler. The quality of gcc has increased dramatically over the years, so for 32-bit processors that we use the results are more than adequate. Where we had to qualify our software by compiling with 2 totally different compilers, and then do a full functional check on the 2 resultant binaries to ensure correctness, we have actually used gcc as the main compiler and the commercial one's as the check compiler. The one place where gcc still suck big time compared with the commercial compiler suites are the debuggers. gdb and insight is a pain to use. gcc has allowed us to consider processor families, which would have been out of the question, if we had to buy tools before being able to use them. Once evaluated, and found to be worthwhile using, it ended up most of the time, that we'd rather spend the allocated compiler budget on other tools, since gcc was and is adequate for our needs. The gcc extent ions are actually quite nice to have as well. Being able to use 64 integers on an 8-bit MCU with avr-gcc is quite nice. I do not know if any commercial avr compilers provides long long support. These days we would probably switch processor families to a family with better gcc support, than switch compilers if gcc does not generate adequate code.

Regards Anton Erasmus

Much of what you write regarding commercial compilers would only be true in an ideal world.

We are not dealing in absolutes here - you claim that the same gcc version for the same target have "wildly different behaviour and efficiency". I don't claim they will be identical, merely that they will normally be very similar. In an ideal world they'd be identical - in the real world, they are merely very similar.

I use various gcc versions for a wide range of targets - sometimes pre-packaged gcc's from serious suppliers, sometimes from purely voluntary projects, and sometimes built from source. Do you actually have any experience with gcc other than third-hand rumours and outdated complaints?

Everyone involved if they've been part of the apps team other than the library authors. It's *really* good for them, far better than any of that "team building" stuff.

No, no. Not if you need a 3000 PSI water jet, compressed air and a diesel generator to run it. The bomb casings are 12mm steel. What we were doing was for unexploded ordnance. The really scary part is that even now, about 10..20% of "air-dropped munitions" don't go off when dropped. Hence the dreadful legacy all over Asia and Africa. Let alone the landmines, which were the original target of what we were working on.

Stephen

No it is what actually happens and that is the difference. I often supply old version of compilers with the dongle protection removed. We can replace and swap parallel and USB dongles.

Most of the things claimed you can't do with commercial compilers we can do with most of the ones we supply.

There is an important point here. It depends who you are dealing with. One FOSS devotee on here has problems with just about every commercial tools company he deals with... The common denominator is him. It is the way he deals with these companies and support people.

Same version numbers from different distributors. The wildly different behaviour and efficiency was a quote from a support person at a GCC/Linux maintainer. He maintained that not only was the behaviour very different between versions theirs were also different to anyone else's with the same version numbers

I was talking to some one on Monday who had been into a company where the major problem was the incompatibilities between four GCC-ARM compilers the team were using.

GCC is a very wide family of loosely connected compilers from many suppliers.

I have a wide range of experience with commercial compilers. A lot less with GCC but I talk, daily to those with GCC.

Why would I need to? Most of those arguing against the commercial compilers can cite one incident some years ago and that was enough for them. After that ALL commercial compilers are bad.

If they don't need any real experience of commercial compilers why do I need real working experience of GCC?

As it is I come across gcc users daily and see some of the problems they are reporting. Also I talk to others who have problems directly dealing with and testing GCC tools

Then we are talking about different items of kit. We should probably carry on this discussion off the Newsgroup.

I agree that is a very scary statistic. This is the thing that is rarely published. What is worse it is usually civilians who are caught by the munitions that don't go off on impact. Often children playing in the ruins.

It always worries me when the USA (the main culprit) resorts air dropped munitions as the first and main weapon. They did this in Iraq and Afghanistan. It makes good TV when the bomb goes off ( killing real people, often civilians) they never show the film where they don't go off.

I have often sat in a pub looking at the slot machines or a motorway service station with the large games machines and thought "what a waste of human ingenuity and time. There must be better things we can do with the technology" . You are one of those who is doing good things with the technology.

The trouble is there always seems more resources available for the destructive and frivolous than useful or good things.

Good Luck.

In message , Anton Erasmus writes

That is a local cultural problem.

However I have asked you to contact me direct to sort out the problems but you have not.

I haven't made *any* claims about what cannot be done with commercial compilers regarding old versions, undongled versions, or alternative copy protection mechanisms. I *have* said that it is much easier to archive old software versions and run them on different machines if they are open source software (thus no legal restrictions, even if you don't believe having the source code helps) and have no locking mechanisms in the first place. I have *not* said that it is impossible to do with commercial software - only that it can often be harder, and never easier. Some suppliers - such as ByteCraft and ImageCraft - are happy to help any customer with these issues. Others seem to go out of their way to avoid anything other collecting license fees from users. I expect most suppliers are somewhere in between, and a good distributor will be able to help too.

Actually, I think you'll be hard pushed to find a long-term embedded developer who has not had some problems with licensing or locking with commercial tools. I have certainly had such problems with commercial tools, and I know several of our customers have had problems. Of course, there are always going to be problems, bugs, incompatibilities and other issues with development tools - they are complex software with a small market. And gcc and other open source tools are no exception. The point is merely that paying a substantial price for the commercial software is no guarantee for hassle-free use, and that dongle and locking issues are particularly irritating. After all, these are problems in parts of the software that no customer asks for or needs.

Pick any four commercial ARM compilers and there will be far more incompatibilities between them.

Perhaps people expect a little too much from different gcc suppliers, and assume they will be identical instead of just very close. It is also very easy to forget the other parts of the toolchain - in particular, libraries can be significantly different, as can debugging support and support for different physical devices.

It's a bit like assuming that ARM devices from different manufacturers are the same.

To re-cap, I don't claim that gcc from different suppliers will be the same (after all, they want to differentiate their products) - just that they are not "wildly different".

It's worth remembering the bias of your position - people come to you to buy commercial embedded tools. If someone tries gcc for the ARM and is happy with it, they'll use it. If they have problems with it, they come to you and ask for alternatives. So your samples will naturally be skewed.

I use a number of commercial compilers, and a number of gcc versions. I've recommended and supported (for customers and colleagues) commercial compilers even when I am happy using gcc for the same target, and vice versa. I am a "best tool for the job" advocate, not a FOSS "fanatic". But I don't like to see people making exaggerated and unsubstantiated negative claims about gcc (or any other software I know about, FOSS or not).

These statistics *are* well known in many parts of the world. That's why the civilised world has just signed the Convention on Cluster Munitions, and has already signed a convention against anti-personnel land mines (these are not the only munitions that don't go off and pose a danger to civilians, but they are the biggest causes). It's a pity the USA and the UK failed to sign (no one expected Russia or China to sign unless the USA also signed).

That makes no sense, why would they not just use the same version? They can just copy the directory containing gcc to each developer machine.

Yes - it's great. Although I would not say "loosely". The same gcc source code can be configured for many different target processors (and can run on many platforms). And once you have learnt how to use the toolchain for one target, the knowledge can be used again and again for each different target processor.

When one has had experience with not being able to use a software tool because of devices and code specifically added to make use of the tool difficult, then one easily comes to the conculsion that ALL specific measures that prevent one from using the tools are bad. NOT that the compilers themselves are bad. Dongles are BAD, Node locking is bad. One can live with an activation key which does not require authentication from outside.

IMHO of course.

Regards Anton Erasmus

AFAIK UK was going to sign until pressure from the USA.

However it does put the USA on the moral same level as Russia and China for all their human rights posturing.

debuggers from debugger companies are most times better than debuggers from compiler manufacturers.

I also don't understand why compiler manufacturers try to provide an own "IDE" or static code checking tools.

I had to do tests with definitely stationary (200m long) machines.

Gladly I didn't need to change code there, but it might happen some day.

Oliver

Simulators, debuggers or emulators?

Because most customers want that. For most customers time == money and an out of the box IDE and compiler system is what is needed.

This should not be done by the compiler company. Similar technology but you want it done independently by some one who specialises in static analysis

Sounds like fun.

I don't know the details in this case, but that would not surprise me in the least.

The USA has always been big on talk but hypocritical in action regarding human rights. At least Russia and China have never claimed to place much weight on human rights!

Exactly. It is they hypocrisy.

However the US might live to regret it judging by the state of the US economy.

I fundamentally agree with this comment. We provide an IDE because there is a subset of our customers that don't have their own favourite development environment. Providing an IDE gives our customers a baseline of tools.

At the same time we provide tools that can be integrated into other environments and do everything we can to make this a seamless integration. There are accepted standards for error formats and error return codes that make mixing tools easy.

Debugger companies have generally done a good job in this industry. If there is debugging support for processor family we prefer to partner with them to develop markets rather than compete with them.

All the best of the Season,

-- Walter Banks Byte Craft Limited

I have emailed you directly using the above email address. My message was reported as delivered, but i have not received any response from you. Obviously you have not gotten it, so what email address should I use ?

Regards Anton Erasmus

Try again on the same address snipped-for-privacy@phaedsys.org