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. 2. No Thumb code, full 32-bit all the way. 3. 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 FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Recommendations for ARM compilers
Started by ●June 17, 2005
Reply by ●June 17, 20052005-06-17
Reply by ●June 17, 20052005-06-17
Jack Klein wrote:> 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.Just curious what's wrong with ADS 1.2? We have used it for a while for quite a complex project and haven't seen any bugs. Were we just lucky?
Reply by ●June 17, 20052005-06-17
In comp.sys.arm Jack Klein <jackklein@spamcop.net> wrote:> 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.Have you tried the RVCT compilers? Specifically the latest versions? -p -- Paul Gotch CoreSight Tools Development Systems ARM Limited. This message is intended for the addressee(s) only and may contain information that is the property of, and/or subject to a confidentiality agreement between the intended recipient(s), their organisation and/or the ARM Group of Companies. If you are not an intended recipient of this message, you should not read, copy, forward or otherwise distribute or further disclose the information in it; misuse of the contents of this message may violate various laws in your state, jurisdiction or country. If you have received this message in error, please contact the originator of this message via email and delete all copies of this message from your computer or network, thank you. ---------------------------------------------------------------------
Reply by ●June 17, 20052005-06-17
"Jack Klein" <jackklein@spamcop.net> wrote in message news:tcg4b192ra8slhau7sulmq0j00u6ujofsr@4ax.com...> 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.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 by ●June 17, 20052005-06-17
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 by ●June 17, 20052005-06-17
"Jack Klein" <jackklein@spamcop.net> wrote in message news:tcg4b192ra8slhau7sulmq0j00u6ujofsr@4ax.com...> 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. > > 2. No Thumb code, full 32-bit all the way. > > 3. 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 > FAQs for > comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html > comp.lang.c++ http://www.parashift.com/c++-faq-lite/ > alt.comp.lang.learn.c-c++ > http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html >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 by ●June 17, 20052005-06-17
Jack Klein wrote:>.... > >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. > >2. No Thumb code, full 32-bit all the way. > >3. 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. > >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
Reply by ●June 18, 20052005-06-18
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. 2. 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. 3. 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 FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply by ●June 18, 20052005-06-18
In comp.sys.arm Jack Klein <jackklein@spamcop.net> wrote:> 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.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.> 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 havingDid you report the problem to ARM? In any case this sounds as though it has long since been fixed.> 2. 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...Again did you report the problem? Incorrect code generation bugs are taken extremely seriously.> 3. We only bumped into this one a few weeks ago: > 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.Again did you report the problem? This also sounds like it has long since been fixed.> 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.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" --------------------------------------------------------------------