Recommendations for ARM compilers

We've just released a product with an ARM920T (Atmel's AT91RM9200). We are not happy with the tools and tool vendor we used. The vendor is an ARM reseller, and the package we have includes the ADS 1.1 compiler/linker and the vendor's own debugger.

We have found that ADS 1.1 is buggy, and the vendor's debugger is really poor. ADS 1.2 did not fix these bugs.

Now that we've released the first model of the product, we have a little time before additional models, new accessories, etc., and we can investigate changing tools.

So I am interested in recommendations for commercial (not gcc, thank you) C compiler and tool packages.

A few more specifics:

  1. No ARM9 specific code is used, the binaries could run on an ARM7.

  1. No Thumb code, full 32-bit all the way.

  2. We own several Abatron BDI2000 Ethernet JTAG debuggers (and really like them!), so we need tools that support it and allow programming off-chip flash through the debugger.

I would appreciate any recommendations or experiences good or bad with tool sets, we can check out the debugger and flash support issues with the tool vendors.

Thanks,

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein
Loading thread data ...

My suggestion is Keil.

You also can use realtime OS of their production.

Visit

formatting link

Mickey

Reply to
Mickey

Have you tried the RVCT compilers? Specifically the latest versions?

-p

--
Paul Gotch
CoreSight Tools
 Click to see the full signature
Reply to
paul.gotch

What kind of bugs? ADS1.2 was at the time a big quality improvement over previous releases, and many people are still using it today despite its age... (interestingly it still beats the latest GCC!)

I would try out its successor RVCT2.2 which gives an easy upgrade path, especially if you're using any language extensions. It supports full C++ which is something ADS wasn't very good at.

Wilco

Reply to
Wilco Dijkstra

Last year I evaluated RVCT, ADS and a few other tool sets for a new project using an ARM966 based ASIC. I went with IAR Embedded Workbench for the ARM and I have been very happy with it. We use an ARM MultiICE that works ok and we also use the Segger J-Link that works very well. IAR has support for the Abatron BDI2000 using the RDI interface. They have a free trial version that you can download if you want to try it out.

Reply to
Mike Harvey

Using ADS 1.2 (from ARM) on a complex ARM7 right now. Combination of Multi-ice and BDI-2000's. Both worked fine until the hw engineers made some board changes :(

Otherwise works fine. I have used another companies version of ADS 1.1 and don't blame you for wanting to switch. You can buy the current ARM package (I think they call it RealView now) and it comes with ADS 1.2 on a separate CD.

Scott

Reply to
Not Really Me

Jack, you may want to give our $199 ARM compiler a test drive. It's fully functional for 45 days. As for debugger support, we emit Elf/Dwarf and the current release has been tested with Nohau, Lauterbach, ADS, etc. In our next update (probably next week), we will also have tested it against Ashling, GNU Elf/Insight, and CrossStudio. So really, any Elf/Dwarf debugger should work. Email me if you have any other questions.

--
// richard
http://www.imagecraft.com
 Click to see the full signature
Reply to
Richard M.

I am following up on my own post because several people who were kind enough to answer me asked about the problems we had with the ARM ADS

1.1 tools.

I haven't been working much on the ARM code in the product, I've been coding for a DSP on another board, but I do remember at least four specific problems, and I can describe three of them.

  1. We have a large application and as more of the features were added and the number of source files grew, we ran into a linker problem. At somewhere around (but not exactly) 256 files, somehow the linker garbled one file name and threw out an error about being unable to find the object file.

We fixed that one after I posted to these two groups and somebody suggested linking each set of related files into a library, and having a final link step that linked all the libraries. Since out multi-tasking system is composed of about 35 individual tasks, each in its own directory, we took that advice and it worked.

  1. We had a real nasty problem with pointers to members of structures. Our architecture, originally developed on a 32-bit x86 processor for a different RTOS, used message queues for inter task communication. I'll show some simplifier code...

Each task defines a message enum:

enum TASK_TYPE { TIMER_MSG, DATA_UPDATE_MSG /* etc. };

...then a structure for the data of each message type:

struct timer_data { uint32_t token; uint32_t time; }; struct update_data { int32_t x_pos; int32_t y_pos; }; /* etc. */

...and finally its overall message structure:

struct my_msg { enum TASK_TYPE msg_type; union { struct timer_data t_data; struct update_data u_data; }; };

A task blocks on a call to retrieve a pointer to a message structure from its queue. When it has a message and it is the highest priority task ready to run, that call returns, and it dispatches the message to the proper handler function:

for ( ; ; ) { struct my_msg *msg = rtos_get_message(queue_id); switch (my_msg->msg_type) { case TIMER_MSG: my_timer_handler(&my_msg->msg_data.t_data); break; case DATA_UPDATE_MSG: my_update_handler(&my_msg->msg_data.u_data); } }

In other words, the handler function is called with a pointer to data structure member of the union inside the message structure.

The ADS 1.1 compiler GOT THE ADDRESS WRONG. It was off by 4 or 8, I forget which. We walked through the code at the assembly level with the debugger. When it came to taking the address of a member of a structure from a pointer to the structure, IT JUST PLAIN ADDED THE WRONG OFFSET.

We did try ADS 1.2 on this one, and it had the same problem.

  1. We only bumped into this one a few weeks ago:

enum ( FALSE, TRUE } bool_t;

void some_func(void) { bool_t some_name = FALSE;

if (/* some condition */ && /* some other condition */) { some_name = TRUE; }

/* code */

if (bool_t) { /* code */ } }

If I remember correctly, the initialization of some_name to FALSE (0), did not happen. Unless the condition was true, setting it to TRUE (1), it remain uninitialized and had random garbage in it.

So we had to change all code like that to this:

if (/* some condition */ && /* some other condition */) { some_name = TRUE; } else { some_name = FALSE; }

We did not try ADS 1.2 on problems number 1 and 3, but it did not fix number 2. At that point we had lost enough time to be seriously behind schedule and decided we could live with the problems we knew and had workarounds for. We didn't have time to try out other tools and make a change without blowing the release data.

Now that version 1.0 went out the door on time, and we've got a little breathing space, we want to evaluate other tool sets.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

For reference from the compiler/linker point of view

ADS 1.1 -> ADS 1.2 -> RVCT 1.2 -> RVCT 2.0 -> RVCT 2.1 -> RVCT 2.2

So ADS 1.1 is 2 or 3 generations behind the current tools depending on how you cound. A large number of new features have been added since ADS 1.1 and lots of bugs have been fixed.

Did you report the problem to ARM? In any case this sounds as though it has long since been fixed.

Again did you report the problem? Incorrect code generation bugs are taken extremely seriously.

Again did you report the problem? This also sounds like it has long since been fixed.

It would be to your loss to write off the ARM compiler based on your experiences of ADS 1.1. Try RVCT 2.2 (part of RVDS 2.2) and report any problems to ARM support.

-p

--
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------
Reply to
paulg

On 18 Jun 2005 13:27:56 +0100 (BST), snipped-for-privacy@at-cantab-dot.net wrote in comp.sys.arm:

[snip]

We bought the tools through an ARM reselling third-party, and ARM will not support them directly when you do this. For a variety of reasons, including the total incompetence of their support, we have decided that we do not wish to continue dealing with this vendor.

ARM RVCT is quite expensive, and I am unsure about how well it will work with our BDI2000 JTAG debuggers, which we are quite happy with and not planning to replace.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

You could always try gcc and the GNU toolchain. Get the source and compile yourself (using either Cygnus libs or MingW on Windows), or visit

formatting link
for ready-to-go Windows binaries.

I'm using the Microcross tools, which came bundled with Netsilicon's Net+OS, and I've never had any problems with them.

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

I've had excellent luck with IAR... Although expensive, they have support beyond all others.

James Kosin

Reply to
James Kosin

Thanks for the explanation, see my responses below.

I agree with Paul that it's best to report any bugs you find. Bugs in compilers are generally very rare (MUCH rarer than the bugs in the code it is compiling, more like 1 in a million rather than 1 in 1000), but they do occur in all. Usually the first time I test a new compiler on my test suites I find several problems - and that's just the internal errors or crashes while compiling the code (not counting syntax errors as no 2 compilers accept identical syntax...).

Reporting bugs gives the vendor a chance to improve the quality of their product, which in the end benefits all customers. You would typically be given a workaround if there is any (which is safer and often less intrusive than inventing your own workarounds). Many vendors supply free patch releases which just contain bugfixes, so it is always recommended to upgrade to the latest available.

This sounds like you ran into the command-line length limit in Windows. The solution is to use via files which have no limit.

This sounds unlikely, if something as basic as taking the address of a structure field would be wrong, not a lot of code would work (ADS1.2 is used in many current mobiles, which do appear to work most of the time...). The particular circumstances are most likely a lot more complicated than you describe. Did you manage to narrow it down to a small example that demonstrates the problem? I am interested in seeing it (apply the obvious transformation to get my email address).

Again it sounds unlikely the circumstances are as trivial as you describe. Compilers don't remove initializations unless they are redundant. A far more likely scenario is that the variable got corrupted later. Do you have a small example for this one too?

Note there are several patch releases available for ADS1.1 and 1.2 on the ARM website, so it would have been worth trying out those. If all that failed and you couldn't get a satisfactory answer from your vendor, it would have been reasonable to tell ARM support about your issues - I'm sure they would be sympathetic.

Wilco

Reply to
Wilco Dijkstra

snip

I'd add a vote here for GNU and Microcross, I've been using their distribution of the GNU tools for the ARM (and also for the SH) for several releases (GNU 2.95.2 throgh 3.4) and their support has been excellent. I've only found one bug which they confirmed and found a workaround for within 24 hours and corrected on their next release.

I've also used the tools from

formatting link
as well without any problems (but no support).

Stan Katz

Reply to
Stan Katz

You may want to try AMPC at

formatting link
It's a C to Java Bytecode compiler that runs on JVM enabled devices (including ARM based systems).

Napi

Reply to
napi

I had a similar problem when a '_packed' qualifier was involved. The structure was declared as _packed and then a pointer to its member was passed to a function as a parameter. Since the function knew nothing about the _packed, it expected that 32-bit value to be aligned on a word boundary, which was not the case. Rewriting the function declaration as void func(_packed uint32_t *) solved the problem.

Reply to
tum_

structure

surely taking the address of a _packed member should yield a _packed pointer. passing that to a function requiring a non-packed pointer should surely report a warning at least.

Peter

Reply to
Peter Dickerson

There was no warning. And it's a good question to compiler writers whether it should have been there. AFAIK, this '_packed' thing is not properly standardized.

Reply to
tum_

Please can you ensure you don't remove the attribution lines ("xxx wrote:"), as it makes the posts difficult to follow.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
Reply to
druck

On 20 Jun 2005 02:56:30 -0700, snipped-for-privacy@axiomsol.com wrote in comp.sys.arm:

That's a very interesting idea, although completely impossible for my situation for several reasons. The first is that the application runs on our own real time kernel, and the effort to bring up a JVM is not practical. Then there's the fact that we peak at about 90% CPU usage with code written in compiled C with some assembly language in the ISRs and kernel, so we'd never meet our timing requirements with Java bytecode.

But I do appreciate your suggestion.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.