Compiler opinions...

Hi all,

As I’m sure most know from my “HELP HELP HELP” messages on this board, I’m starting ARM development. I’ve currently been focused on PIC development, now its time for ARM…

I finally got openOCD working with the Yagardo toolchain.

I was looking at different IDE’s/compilers and would like some opinions from those who use it.

Some of my needs

#1. Time is money. I would rather spent $500 and get up and running then spending days. time is money.

#2. I want to code, not spend time setting pragma’s, chip settings etc. Let the compiler do that, thatss why I paid $$$!!!

#3. Same with debugger.

Now, I did see the following packages

#1. Crossroads

#2. ICC7

#3. noIce debugger/programmer

#4. IAC (?) —> wow, this costs alot!

#5. GCC toolchain

Now, I use CCS for the PIC development, and when I want to build a new program, I just create a new project and viola! It’s all setup. I can start progamming with little “startup” time on my end.

The GCC toolchain using eclipse, to start a new project, there seems to be alot of initial setup (makefile etc).

So, whats cheapish, supports ARM-USB-OCD, good debugger? Maybe a Crossroads+noICE setup? Just GCC?

Thoughts, anecdotes, stories about pickles and eggs…any advice would be greatly appriciated!

~Kam (^8*

The CrossWorks (not Crossroads) tools are excellent, they offer a low-cost personal option which is very good value. Their new USB CrossConnect is worth getting, as well. Their support is very good.

Leon

Leon,

thanks for the reply. Now crossworks is also a GCC toolchain? Or is it their own baby? I was told by their support, that they do support the olimex arm-usb-ocd in version 1.7x (they sent me a url to downlod it, still waiting for activation key)

Can I just say, “create a new project” and it will do the rest? The “rest” would be things like default chip setups etc. How about a wizard to help with different ARM support (serial, i2c, etc).

~Kam (^8*

leon_heller:
The CrossWorks (not Crossroads) tools are excellent, they offer a low-cost personal option which is very good value. Their new USB CrossConnect is worth getting, as well. Their support is very good.

Leon

Just to add to what Leon said, the NoICE debugger works well with BOTH the ARM-USB-OCD pod via OpenOCD and also with Olimex Wiggler via H-JTAG. Both H-JTAG and NoICE provide very quick and easy FLASH programming. OpenOCD also is good at supporting FLASH programming via ARM-USB-OCD. All those software tools are free except for NoICE, and they really do work well for FLASH programming and debugging. I think NoICE has a free evaluation period, if you want to give it a try? I prefer NoICE because it is so simple and easy to use, while still being very useful for my work style.

–Dave

Yes, the noIce does look good. One tech question about it, I’m using the Olimex’s at91sam7s256 proto board, and the only “target chip” selection for atmel is for the at91sam7s32 and the rest are for the philips brand. Any idea what I should select? I used the s32 as a quick test, and it worked…but is there a better choice?

~Kam (^8*

KamPutty:
Yes, the noIce does look good. One tech question about it, I’m using the Olimex’s at91sam7s256 proto board, and the only “target chip” selection for atmel is for the at91sam7s32 and the rest are for the philips brand. Any idea what I should select? I used the s32 as a quick test, and it worked…but is there a better choice?

~Kam (^8*

I can’t say with 100% certainty, but I think that the target chip selection that you are refering too will mainly affect the FLASH programming algorithm used. The Atmel selection is indicating that NoICE does not yet have built in support for FLASH programming of Atmel parts directly from NoICE. Even so, you can still program the Atmel part directly from OpenOCD, or with H-JTAG if you have an Olimex Wiggler type clone. H-JTAG provides an ARM Remote Debug Interface (RDI) , so you would use the RDI selection in NoICE.

– Dave

I just checked out quite a number of C code files into my ARM project. The code was originally written for an MSP430 target, which is shipping now in quantity. It was debugged using gdb.

The code compiled for ARM with only some minor tweaks in some include paths in the Makefile.

The compiler, of course is GCC. And I saved tons of time not having to rewrite a Makfile for scratch, learn what the compiler warns about, or learn a new debugger. In fact many of the gdb commands in my .gdbinit file work for either platcorm.

You may think that you’re saving money/time when you purchase an IDE that supposedly sets up the hardware for you and doesn’t require a Makefile per se. What you’ve done, though, is add more layers between you and the product you’re building. You don’t know what’s in those layers and WHEN, (not if), something breaks in a layer, you’re going to spend more time finding it and working around it than the time you would have spent initially to learn the underlying hardware and how to set it up exactly the way you want.

If you’re writing code for embedded systems and that code is expected to run for years without rebooting, you need to peel away all the layers between your code and the hardware as possible.

KamPutty:
Leon,

thanks for the reply. Now crossworks is also a GCC toolchain? Or is it their own baby? I was told by their support, that they do support the olimex arm-usb-ocd in version 1.7x (they sent me a url to downlod it, still waiting for activation key)

Can I just say, “create a new project” and it will do the rest? The “rest” would be things like default chip setups etc. How about a wizard to help with different ARM support (serial, i2c, etc).

~Kam (^8*

CrossWorks for ARM uses the gcc compiler with their own IDE, debugger, simulator, etc.

It does most of the work for you nwhen creating a project. There are lots of library functions for using serial I/O etc.

Leon

Leon,

I was trying to figure out how to use the serial IO librarys with Crossworks and I couldn’t figure it out. I tried to use printf() after setting up the USART, but didn’t have any luck.

The help file says that it it sends the string to the “standard output stream” but I have not been able to figure out how to set up or use the standard output stream.

Hopefully you can help.

Thanks

Michael Moore

james4546:
Leon,

I was trying to figure out how to use the serial IO librarys with Crossworks and I couldn’t figure it out. I tried to use printf() after setting up the USART, but didn’t have any luck.

The help file says that it it sends the string to the “standard output stream” but I have not been able to figure out how to set up or use the standard output stream.

Hopefully you can help.

Thanks

Michael Moore

Have a look at Customizing putchar and getchar in the Standard C Library Reference documentation.

Leon

Thanks so much that should work. I can’t believe I didn’t come up with that in my searches.

Sorry for hijacking your thread Kam.

I use CrossWorks with the Jlink. I bought a hobby/student license for $150. So far I like it pretty well and it works well with the Jlink. IAR was the best price I could find for the Jlink at $250.

Thanks

Michael Moore

Michael, et. al.,

thanks for the info. Still some questions:

In regards to this

Have a look at Customizing putchar and getchar in the Standard C Library Reference documentation.

You know, I really think I am blind and could not locate the information since I want to do that too! Is there a URL to this doc since I must have a different doc! :oops:

Okay, JLink. How does that differ from the ARM-USB-OCD by Olimex?

How about Image Craft, anyone using them?

Thanks again!

~Kam (^8*