STM32 ARM toolset advice?

In my experinece IAR compilers are good products. Except for the licensing. I avoid dongles and license servers if at all possible.

I prefer GCC, since it doesn't require dongles or license servers, and it's available for something besides MS-Windows. It's free too, but that's a minor factor compared to be chained to MS-Windows and a dongle.

Grant,

Are your comments general or specific to the STM32 on GCC.

I am looking for a jtag emulator to use with STM32, but the GCC development environments seems to not support any of the jtag emulators.

Getting a complete development suite from IAR or Keil seems the way to go. ( sorry but I am a windoze user. )

Are there any complete development suites using GCC ( free or paid) that have a jtag interface that work out of the box ?

donald

Recently, I've used GCC for Cortex-M3, ARM7, NIOS2, H8, MSP430, AVR. The only IAR target I've used in the past couple years is AVR. The IAR toolchain itself worked fine, but it was a PITA to use since I had to find a Windows machine on which to run it

-- then there were odd problems with network drives when ssh'ing into the Windows machine to do builds.

I've used gcc/gdb with three different JTAG interfaces for the ARM7, as well as JTAG interfaces for the NIOS2, AVR, and two for the MSP430. I'm afraid I don't have any experience with JTAG and the M3. As far as JTAG interfaces go, I can vouch for the fact that the Abatron BDI-2000 works nicely with gcc/gdb. I haven't used it with the M3, but Abatron says it works and I believe them.

I've also read that the $10-$20 prallel-port interfaces work with Cortex-M3, but haven't tried that route.

Then being "chained to windows" isn't as big a problem for you. :)

I've heard nothing but good things (from both Windows and Linux users) about Crossworks from Rowley:

For some targets, Rowley has their own compilers, but for ARM, they use GCC. The IDE and debugger are Rowley products.

Codesourcery also supplies an eclipse/gcc/gdb IDE for Cortex-M3:

I can vouch for the toolchain, but haven't used their IDE stuff.

IAR have dongles OR server OR node locked.

You buy a compiler based on the method of locking it to a machine? I tend to look at it's primary purpose and see how good it is.

Is that relevant?

Myth.

Religious bias noted.

Sticking to the STM32 subject,

I will look at these links and see if they work for me.

Thanks

donald ( chained to my windoze box :-)

Forgive me, there are 3 annoying choices instead of just 2. :)

It's one consideration.

If the compiler refuses to run after you replace a hard-drive or an Ethernet card, everything else is sort of moot.

It is to some people, yes.

Really?

I don't see how it's "religious".

Oh come on Grant,

Bashing windozes is bashing windozes !!

I for one would like to move past windoze, but noone will pay me to re-learn how to develop code.

I can figure out how to run most any compiler/development suite under windoze.

I have never run a linux machine. It would not take too long, however every time I try to get a job without linux/unix experience on my resume, I am told I do not qualify.

So I stay in the windoze world.

Lets call a spade a spade and leave it at that.

donald

Keil has been bought by ARM, and AFAIK they now use the compiler from ARM. Apparently this compiler generates the best code for ARM's CPUs. GCC Generates quite good code for the ARM these days. The biggest drawback is the use of newlib. Rowley provides a nice IDE with GCC, and their own library, which removes the one disadvantage of using GCC. Their product is also available for Windows and Linux.

Regards Anton Erasmus

I didn't think I was bashing windows. I don't use Windows, so when I choose products, those that run exclusively on Windows are ranked lower than those that support other host OSes. I also find dongles, node-locking, and license servers a hassle to deal with (I've used all three on several occasions), so vendors that don't think I'm a thief are ranked above those that do.

I've tried developing code on Windows a few times, and I found it to be clumsy and inefficient. Windows didn't exist when I started developing embedded software. I learned under Unix, VMS, CP/M, and ISIS. I've tried Windows at varios points in its history (3.1, WfW, 95, 98, NT-4, NT-5, W2K, XP, Vista), and I didn't much like it.

I'd have to second that opinion on newlib. It's fine if your codespace in measured in MB (or even in hundreds of KB). But newlib seems to put more emphasis on portability and completeness than on small code size.

I second that. We use it with the Olimex ARM-USB-OCD

Heinz

In message , Anton Erasmus writes

Well other compilers claim to be as good. Being a RISC HW designer does not make you a good compiler writer.

There are other equally good compilers.

But not as good, out of the box as the commercial ones out of the box.

There are other drawbacks.

The gcc Dhrystone benchmarks published by someone on the ST Forums are not really impressive. IIRC, 32 Dhrystone MIPS when running with a fairly late gcc compiler at 72 Mhz. There was a discussion with an ST employee, and he promised to come back but never did.

If I were you, I would get some 30 day free licenses, from ARM & IAR and compare the code size/execution time with gcc, before I goahed.

I can vouch for that this can be an issue. Upgraded my hard disk drive this summer, and since the IAR licensing scheme then needs another key. You can transfer a key from the old system, to the new system, but BOTH have to be running.

You would want to Start a transfer on HDD#1 and store the transfer information to file #1. Reboot on HDD#2 and use file #1 to start accepting the transfer generating file #2 Reboot again on HDD #1 and complete the transfer, generating file # 3 Reboot again on HDD #2 and complete the transfer using file #3

Since the transfer on both machines cannot be handled temporarily for reboots, you CANNOT transfer a license to a new hard disk, unless you have another Windows machine handy, - and then you have to do the license transfer twice!

Finally, IAR provided fresh license keys but the same week, my motherboard fried and both the CPU and the motherboard was replaced by HP, so I could not even install the new licenses. Only running size limited compilers at the moment.

Don't have any working licenses right now. I am sure that this will be sorted out, but If I was on a hard timeschedule this would be frustrating.

Then perhaps the USB dongle licensing would work better for you. I've used the IAR ARM toolset with usb dongle on three different computers without problems.

No---just a bias. I have no particular problem with dongles, since most often I use them all on the same computer that has lots of free USB ports in the back.

Almost all my analysis tools, as well as IAR ARM and ICC430 run under WinXP, so getting running GCC-ARM, that I was forced to use for another project, means either running GCC-ARM in a VirtualBox Ubuntu emulator, or toting a separate Linux laptop on business trips. I've managed to get the code development done, but I'm still cursing the day I was told to use Linux in a hard real-time system! Only the fact that it runs on a 300MHz StrongArm chip makes it feasible!

I may soon see if the Dell Mini-9 running Ubuntu will handle the GCC-ARM toolset and my source files. That would give me a bit of hardware redundancy in the field.

Mark Borgerson

One of the biggest problems I ran into with GCC-ARM when using the linux libraries for the TRITON boards, is that floating point operations are executed as kernel interrupts (Undefined Instruction generating jumps to a floating point emulator, I think.) I think it turned out to be several times slower than the IAR floating point library that runs in user mode.

I suppose it makes a big difference whether your ARM code is going to run under Linux or on the bare silicon. All my IAR experience is on ARM7TDMI without an OS, and all my GCC experience is on a StrongArm chip under linux. I'd love to transition to an RTOS with either system, but haven't found the free time to get either MicroC/OSII or FreeRtos running with either set of hardware.

Mark Borgerson

I had been running the IAR demo version under Win2K on a virtual machine using Qemu, but I was unable to get the USB dongle to work with Win2K/Qemu. AFAICT from the documentation, it should have worked, but it just wouldn't. So then I had to go in search of a "real" windows machine into which I could plug the dongle. I ended up using the company printer/scanner server.

All my other tools run on Linux, so being forced to find a Windows machine to run IAR was a similar hassle for me. If the "powers that be" had chosen something like Rowley that wasn't windows-specfic, I wouldn't have had to do so.

Windows would have been a better choice?

The ARM/gcc developers kits we ship with our products work on either Windows or Linux hosts (though I must admit they work better on Linux hosts) -- but we're not using Linux as the target OS.

And given that the IAR floating point library is one of the slowest available, that is quite slow indeed.

Wilco

For the flight control system??? Not likely. ;-)

I've learned to work with Linux as the host for the compiler and libraries. I don't like it as the target OS for the embedded system. Before I got the GCC-ARM system running in the VirtualBox emulator, I would edit the source on a shared directory using Codewarrior on the PC. I would then open a telnet session to run the make file to compile the code.

Having to carry two laptops on trips was a true PITA, since both were fairly low-end HP systems and were not exactly slim and lightweight! Before my next trip I hope to get the GCC-ARM and VirtualBox working on the WinXP laptop and have a $350 Dell Mini-9 as GCC backup and internet appliance.

Mark Borgerson