ARM compiler recommendation

If you're a GUI addict, no. (But then, all current available IDEs for ARM aren't that good to justify the extra money :-)

I did not see any differences in code size compared to ARM SDT, ARM ADS, IAR and GH. But our programs where relatively small.

At our company we decided to go for gcc at first if possible.

The ARM compiler generates more warnings, but maybe I just did not find the right gcc switch :-)

Using it from version 3.0 (thumb and arm mode combined), and so far I am happy with it.

But again: I tried several IDEs for gcc, none seemed to fit my needs, so I stick to using perl and bash scripts + Makefiles for my projects.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !

You can try Codewarrior for ARM or AXD, even if you still want to compile with gcc, it's usefull to have a nice and practical debugger GUI... But I've been using Codwarrior for 1 year now with MX1 and I wouldn't exchange it for whatsoever.

Regards,

Oliver.

"Yu Hao" a écrit dans le message de news: snipped-for-privacy@posting.google.com...

What operating system are you intending to use on the ARM target? If you're intending to use ARM-Linux, for instance, it is unnecessary pain and anguish to use a compiler other than gcc. If you're trying to integrate some weird closed OS designed for mobile phones or something, then you should use the compiler the OS vendor recommends.

There are three issues that may affect you with gcc:

1. Buyware packages will have somewhat better integration with BDM hardware. TTBOMK the best BDM combo with the GNU toolchain is something like the Macraigor Raven.
2. gcc doesn't generate the fastest or smallest possible code, though it is of course always improving.
3. Your CPU or support chip vendor may not be willing or able to support you as assiduously if you are using gcc. Again, this issue is improving, but in the past I've encountered some difficulty with chip vendors who sell an EVB with instructions and assumptions centered around some buyware compiler/BDM package. (ITE is one company that comes to mind here).

1) ARM ADS v1.2 (CodeWarrior IDE, AXD debugger) Usable, provided you don't want to use modern language features (namespaces, sophisticated templates). I think this is a dead product now, superceeded by the RealView tools... but could be wrong. CodeWarrior doesn't use standard makefiles nor will it export standard makefiles, which makes it difficult to ever not use CodeWarrior once you fall for the trap. Also the ARM version is not supported and some things just don't work. There is source control integration... but it's rough. 2) GCC Better C++ language features than ADS... but you have to be a 70s fan (command-lines, makefiles). I've never got the GDB debugger to do anything after several attempts. 3) ARM RealView The RealView compilation tools are "the mutts nuts"; excellent modern C++ features and powerful embedded assembler (as well as inline assembler). However, you'll have to like hand-crafting makefiles... unless you lash out for the RealView debugger. For some bizarre reason, ARM include the project management features in the debugger; the basic IDE with project management isn't available without the debugger. The IDE itself is both awsome and frightening at the same time; it'll surely be the best IDE for embedded development ever (better featured than Microsoft Developer Studio 6)... once the rough spots are ironed out. It supports debugging multiple ARM CPUs at the same time (including those with DSP), has source control integration, board visualisation, seems a heck of a lot faster than AXD for downloads and watches. However, the UI really needs some work, particularly for menus and project management. I would love to switch over to it right now and say good ridance to CodeWarrior and ADS... but it's not quite there yet (IMHO).

Tim

Tim,

you seem to have some experience with RealView. Do you know if it is possible to integrate external tools (like code-generators) into the Debugger-IDE ?

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !

I think it's a bit unreasonable to classify gcc like this. (Note - I haven't used the ARM or tools for it, but I've used gcc and other compilers on a fair number of systems.) Gcc works like almost all compilers - it runs from the command-line. What it does not do, is pretend to be something else - the people who write gcc are experts in compiler technology, not in making some fancy gui ide. There are plenty of others out there who make editors and IDEs, along with build management programs. Choose what you like - most use makefiles, but you use ant, cmake, cook, rebuild, or a dozen other programs - or even write batch files or shell scripts. Choose the editor you like - many have nice syntax highlighting, and direct support for running compilers and interpreting the error outputs. If you are downloading these things for free, then you have to expect to put them together yourself - if you want a pre-packaged "click here to install" compiler/editor/debugger/printed manual/telephone support package based on gcc, then you can buy that too.

For those of us who work with many compiler toolchains, this is a far better way to work - nothing annoys be more than a commercial toolchain that forces me to use its editor or build system.

It's also worth noting that gcc has a lot more functionality than many commercial compilers. I use it along with commercial compilers to provide better lint-style checking, and to automatically generate makefiles - even for platforms that don't have a gcc port.

On the other hand, it is obviously faster and simpler to get going with a "click-to-install" toolchain, and some kits do have good, well-integrated tools.

And as for gdb - it could do with some changes to make it more appropriate for embedded debugging, but it works well enough on many targets. And don't forget that you have the advantage of a text-based interface (very quick to use when you get used to it, at least for simple things) or gui interfaces (you can choose between gvd or insight on windows, and several more on

*nix). However, it is no where near as polished as a good commercial embedded debugger.

I've only played with the evaluation version (v1.6) for a very short time, so don't take this as gospel, but it looks like the answer is no. In fact, the IDE's editor seems very basic at this stage (no macros or object model for plug-ins, can't change font, font-size, limited choice of colours for syntax coluring) although there is some support for using other editors. I hope there are plans to improve this; the debugger really has some nice features.

You can request an evaluation version of the RealView Tool Set from ARM. The latest version is v1.61 for the debugger/IDE and 2.01 for the compilation tools (assemlber, compilers and linker).

Tim

I'm regularly running GDB on embedded AT91's with a self-made stub at the target. It does work, even with the DDD graphic front-end. I'm sure that the TCL/TK modified GDB (Insight by Red Hat) will work as well - even with MS-Windows graphics.

Tauno Voipio tauno voipio @ iki fi

There-in lies the problem! I've seen some posts about problems with these tools being related to particular versions of the TCL-TK libraries (another massive and complex project in its own right). To me it simlpy looks like to much effort to build, fix and maintain the tools. The build tree for all of the components required to build the compiler was huge and incomprehensible last time I looked. I don't know about you, but I just don't have the time to get to know this seemingly archaic mass of trees, sources and scripts to have the confidence to switch to it.

It was the Insight GDB (Windows GUI) that I played with on a couple of occasions; I got nowhere and didn't have the time to persue the problem.

Regards

Tim

Dave,

Hi. Are you saying that the emulated Unix command-line she´ll is only necessary to build the tools (and the tools that build the tools), but NOT to use them. Does this mean that one can build a single executable (gcc.exe) that would run in any DOS environment or Win32 command-line?

P.S. I just had a look under the 'cygwin' directory on my machine; there are about 29,500 files and 1,257 folders; now that's actually from a company that supplies the GCC tool set PRE-BUILT!!!

Tim

As a matter of fact, it's not. Looks like you never bothered to look at other ports of GCC besides Cygwin32. MinGW32, e.g., or DJGPP, which are ports to native Win32 API (no cygwin DLL), and to 32-bit DOS, respectively.

Even Cygwin's GCC can be used quite nicely without using their port of Bash as the shell. The real reason that they decided not to deliver it that way is that Cygwin assumes a Unix-ish *environment*, rather than the mere superficial usage of a Unix-ish shell. That's how they got around the ton of problems caused by issues like backslashes instead of slashes used as directory separators, and drive letters.

But this means that most non-Cygwin tools wouldn't interact very well with the Cygwin port of GCC. E.g., command-line completion with the key works on Win2K and XP, but the command lines you get from that would be quite incompatible with the format expected by Cygwin GCC.

One important aspect of this is building GCC itself. For that, you ultimately need a complete Unix-ish toolchain like Cygwin, unless you're prepared to only ever cross-compile GCC from, say, Linux to Cygwin, instead of being able to build it natively.

But it has to *find* those files first. And that's already where the trouble starts. E.g. DOS/Windows style PATH or INCLUDE path settings would be utterly unusable to a Unix-born program like GCC without rather massive internal changes.

It's a bad idea to look at the Cygwin port of GCC as just an isolated effort: Cygwin is really a complete simulation of the Unix environment on Unix, including the GCC compiler as one among many building blocks. If a simulated Unix is not what you want, Cygwin may not be the right choice for you.

Because "they" do --- though for a different meaning of "they" than the one you currently seem to be presuming.

Not even the Cygwin ports are actually "stuck" to the Unix shell in that way.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Well gcc itself requires a few more files (it has a lib directory) and it wants to be able to invoke things like gas, but essentially yes, this works fine.

Routinely we (Ubicom's software team, apps team and our customers) invoke the GNU tools from pretty-much every version of Windows from Win98 using both DOS or Cygwin (bash) shells. We also invoke all of the tools from our Unity IDE (this is a pure Win32 app). The tools are built as a single configuration for all such uses.

Regards, Dave

gas?

Dave. I'm interested; any pointers (links)?

Tim

The GNU Assembler. One of lots of programs supporting GCC, known collectively as the GNU Binutils.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

gas is the GNU assembler - gcc invokes it when it generates its object code.

Nothing that I can think of off the top of my head, but a google search will probably find things quite quickly.

FWIW while I'm generally only concerned with developing gcc for our IP2000 and IP3000 series processors I do tend to cross-build gcc and the other tools for x86, MIPS and ARM so that I can compare code generation and code density. Right now I'm building with a snapshot of the FSF trunk imported from (I believe) sources.redhat.com, although I didn't do the last import so I'm not 100% certain that that's where it was from.

I have a full cygwin install (including gcc-3.2 rather than just Red Hat's 2.96 version) and building a cross compiler for one of our processors (the same strategy works for all of them) is just a case of taking the sources in a directory called say "src", creating another directory at the same level called say "build-ip2k" and from the build directory doing:

../src/configure --prefix=/usr/local/ip2k --target=ip2k-elf --enable-gdbmi

after this runs then I tend to build and install each of the major items one at a time:

make all-binutils make install-binutils make all-gas make install-gas make all-ld make install-ld make all-gcc make install-gcc make all-gdb make install-gdb

This creates a cross toolchain in /usr/local/ip2k. To build an ARM toolchain I'd do the same but replacing "ip2k" with "arm".

Regards, Dave

I really don't follow your problem - are you saying that it would be fine if gcc were a windows console program rather than a unix-style CLI program? If so, then what exactly is the issue? Do you think that gcc needs to be run from, say, a cygwin bash shell rather than a NT command prompt? This is, of course, completly wrong (*building* a gcc compiler is far easier when you have the full cygwin tools installed rather than a more "native" mingw toolkit, but that has nothing to do with *running* it). I run gcc (for many targets) either directly from an NT/W2K command prompt (normally via make), or via my editor (mostly jedit, but sometimes others). A command prompt is faster for doing less-common builds, while running via the editor gives me automatic highlighting of source code errors and the like.

For most popular targets, you can download ready-to-run gcc binaries for windows. Some even come packaged with nice installers, and other tools such as a debugger bundled together. It is also perfectly possible to download the source (gcc source, plus patches if needed), and build native windows versions of the compiler yourself. This is definitely easier using cygwin, since it gives you a *nix like environment under windows, and you can follow the same build instructions as under *nix. But the resulting binaries can run happily without any cygwin "polution" other than the odd dll. You can even build gcc with mingw - this is a bit more awkward (since it is less

*nix-like).

(gcc.exe)

Do you really mean DOS? Remember, the "DOS prompt" in 32-bit windows is not DOS - even when running DOS-based windows like Win9x and WinME.

are

If you're really addicted, you can use MS Visual Studio IDE with gcc as the compiler. The Game Boy Advance hackers seem to like to do it that way.

--
Grant Edwards                   grante             Yow!  Now that I have my
                                  at               "APPLE," I comprehend COST
                               visi.com            ACCOUNTING!!

You could try looking at the websites for some of the open-source OSs that are available for arm, such as ecos, uclinux and rtems - they might have pre-built tools somewhere.

ftp://ftp.oarcorp.com/pub/rtems/cd-working/tools/gcc3.2.3newlib1.11.0-4/cygw in/