ARM toolchain mini comparison

[Laurynas]

Hi,

Since I was unable to find a comparison of different ARM tool-chains I did my own test and decided to share the results here.

I am playing with PSoC 4 Pioneer kit and I love it - it's like having half of breadboard inside the chip. But 4100/4200 family is limited to 32k flash 4k RAM chips, and my little project was already at 1/3 of that.

PSoC Creator is using and older version of Sourcery compiler so i downloaded generic GCC 4.7 and MDK 4.72 lite version (limited to 32k, which is fine).

Here are the results of my small CapSense+PWM+UART+Frequency divider project:


Sourcery 4.4.1 (default) optimize=none
Flash used: 10256 of 32768 bytes (31,3%).
SRAM used: 308 of 4096 bytes (7,5%).

Sourcery 4.4.1 optimize=size
Flash used: 7352 of 32768 bytes (22,4%).
SRAM used: 300 of 4096 bytes (7,3%).

Sourcery 4.4.1 optimize=speed
Flash used: 7656 of 32768 bytes (23,4%).
SRAM used: 300 of 4096 bytes (7,3%).


GNU GCC 4.7 generic --specs=nano.specs optimize=none
Flash used: 10622 of 32768 bytes (32,4%).
SRAM used: 428 of 4096 bytes (10,4%).

GNU GCC 4.7 generic --specs=nano.specs optimize=size
Flash used: 7646 of 32768 bytes (23,3%).
SRAM used: 420 of 4096 bytes (10,3%).

GNU GCC 4.7 generic --specs=nano.specs optimize=speed
Flash used: 8014 of 32768 bytes (24,5%).
SRAM used: 428 of 4096 bytes (10,4%).


Keil MDK 4.72 optimize=none
Flash used: 6264 of 32768 bytes (19,1%).
SRAM used: 1564 of 4096 bytes (38,2%).

Keil MDK 4.72 optimize=size
Flash used: 5424 of 32768 bytes (16,6%).
SRAM used: 1552 of 4096 bytes (37,9%).

Keil MDK 4.72 optimize=speed
Flash used: 5436 of 32768 bytes (16,6%).
SRAM used: 1552 of 4096 bytes (37,9%).


Keil MDK 4.72 --library_type=microlib optimize=none
Flash used: 5508 of 32768 bytes (16,8%).
SRAM used: 1564 of 4096 bytes (38,2%).

Keil MDK 4.72 --library_type=microlib optimize=size
Flash used: 4668 of 32768 bytes (14,2%).
SRAM used: 1552 of 4096 bytes (37,9%).

Keil MDK 4.72 --library_type=microlib optimize=speed
Flash used: 4680 of 32768 bytes (14,3%).
SRAM used: 1552 of 4096 bytes (37,9%).

note that generic gcc was used with --specs=nano.specs linker option to use small MCU optimized libraries

speed was not tested since it's not an issue for all my current projects

so the conclusion would be - get MDK and switch to it when you want to trade flash for RAM

edit:
I haven't found the reason of high memory usage for KEIL MDK yet.
While digging MDK notes, I read that MDK likes 32 bit variables and was able to reduce flash footprint a little by changing all 16bit vars to 32bit. However the same changes increased flash usage substantially when compiled by GCC.

note:
this is not a practical problem solving thread, I'm doing this just for curiosity and i hope the results might be useful/interesting for somebody like me.

edit [2013-10-01]:
It looks like there was a bug in PSoC creator 2.x versions and RAM used was not reported correctly. This means that results above are NOT correct.
They fixed this bug in v3.0 and i ran a couple of quick tests on default PSoC4 CapSense project:
GNU GCC 4.7.3 (default in v3.0) --specs=nano.specs optimize=size
Flash used: 3318 of 32768 bytes (10,1%).
SRAM used: 1628 of 4096 bytes (39,7%).

Keil MDK 4.72 --library_type=microlib optimize=size
Flash used: 3140 of 32768 bytes (9,6%).
SRAM used: 1572 of 4096 bytes (38,4%).

[nctnico]

Wrong conclusion. First check the size of imported libraries. Chances are the difference in flash usage is due to the library and not due to the compiler creating shorter code. Besides that shorter code doesn't means it is faster. By using loop unrolling (making code longer) one can get significant speed improvements because the loop overhead is reduced. BTW Sourcery's compiler is GCC.

[Laurynas]

let it be beginner's conclusion then
this is my first arm chip so I'm just trying to graduate from arduino.

i could probably play with their libraries to get smaller size (like i said, speed was not a question here and was not tested), but i was hoping they would do that for me like generic GCC did by providing linker flag enabling smaller libraries.
if there are such flags or other simple methods to compile the same code with less flash or RAM taken - i would be grateful if you could point them out.

p.s. added MDK with microlib

[nctnico]

There are not many open source minimal C libraries out there. For my ARM projects I use the mini C library which comes with MSPGCC. I have altered the makefiles and made some minor modifications to the library itself to make it compile for ARM instead of MSP430.

To start I wouldn't stare myself blind on ram or flash usage. Better get a project going first and optimise for a smaller part later if necessary. Besides that a part with more flash may be cheaper because they sell more of them. For the project I currently work on the 32kB version of the controller is actually cheaper (in single quantities) than the 16kB version.

[mikeselectricstuff]

My guess is that much variation in RAM usage is down to different default settings for stack ( & maybe heap) sizes. Or maybe the compiler doing something stupid like copying CONST data to RAM.
Unless there is something dumb going on, you shouldn't see huge differences in RAM usage for the same program under different compilers.

As toolchains can target a wide range of processors, it is not uncommon to find default settings that don't make sense for smaller parts.

[bingo600]

Well i hope you don't suggest Keil MDK for a project larger than the "Free Size" ...
Then you are out of the hobbyist league , and should also check IAR ... And be prepared to pay SERIOUS $$$$

Who recently changed from Sourcery to "Launchpad GCC" , as Mentor sucked Sourcery up.

Now the Launchpad GCC is supported directly by ARM , as was previously with CodeSourcery.
https://launchpad.net/gcc-arm-embedded

/Bingo

[Laurynas]

I was under impression that Launchpad GCC = generic GCC
Launchpad GCC is used in my tests above.

my bad, I'll have to try the REAL generic now

[bingo600]

I was under impression that Launchpad GCC = generic GCC
Launchpad GCC is used in my tests above.

my bad, I'll have to try the REAL generic now

Why on earth would you do that ??

Launchpad arm-gcc is "leading" as ARM develop patches for it , and it's FREE.
They (patches) will eventually go upstream to GCC , and "stock gcc" will be able to do the same.

But if you insist on being "behind" .... go ahead 

/Bingo

[Laurynas]

no practical reason for sure
nctnico said the simple truth - it's usually much more simple to get bigger chip, not to mention that the one I have is big enough for my needs. so this thread is here purely out of curiosity.

As for Launchpad <-> gnutoolchains.com how does that river flow?
gnu is at 4.8 gcc -> launchpad is at 4.7 internally trying to get 4.8 ready -> gnu 4.9 will be built with launchpad's 4.8 improvements?

[andersm]

Those Launchpad releases look like mostly vanilla releases with a few backported patches. The "leading" development happens on GCC mainline as usual.

[mikeselectricstuff]

Well i hope you don't suggest Keil MDK for a project larger than the "Free Size" ...
Then you are out of the hobbyist league , and should also check IAR ... And be prepared to pay SERIOUS $$$$

IAR do free code-size limited versions - 32K for ARM.

[dannyf]

"And be prepared to pay SERIOUS $$$$"

I think the most valuable thing you get out of the commercial packages is their support. With the "free" ones, you are pretty much on your own. But in terms of speed / size, GCC is largely comparable to IAR / Keil.

If you are going down the gcc route, you may check out CoIDE as well - fully functional and totally free. However support for new chips is limited and not terribly user-friendly.

[mikeselectricstuff]

"And be prepared to pay SERIOUS $$$$"

I think the most valuable thing you get out of the commercial packages is their support. With the "free" ones, you are pretty much on your own. But in terms of speed / size, GCC is largely comparable to IAR / Keil.

If you are going down the gcc route, you may check out CoIDE as well - fully functional and totally free. However support for new chips is limited and not terribly user-friendly.

IAR is the best IDE I've used - very good integration between compiler, environment and debugger. A useful feature I've not seen elsewhere is it automatically pulls all included files into the project tree - saves a lot of hunting for register names in manufacturer-specific include files buried in install directories.

[dannyf]

"IAR is the best IDE I've used "

What's good is highly subjective. I like IAR for its utilitarian interface and consistency among the various platforms.

In terms of features, dedicated editors (SI or Sublime, etc.) are light years ahead of IAR.

[Laurynas]

As far as IDE goes I'm happy with Cypress Creator. It's about as good as any other popular IDE, but it has ability to play with PSoC components, which is a must have when using PSoC.
In theory you could set the universal logic using creator and then move to whatever IDE you like to write the code, but it's more convenient to have it all in one.

The only real drawback is it's windows only, which my Linux friends find irritating

[nctnico]

"And be prepared to pay SERIOUS $$$$"

I think the most valuable thing you get out of the commercial packages is their support. With the "free" ones, you are pretty much on your own. But in terms of speed / size, GCC is largely comparable to IAR / Keil.

If you are going down the gcc route, you may check out CoIDE as well - fully functional and totally free. However support for new chips is limited and not terribly user-friendly.

IAR is the best IDE I've used - very good integration between compiler, environment and debugger. A useful feature I've not seen elsewhere is it automatically pulls all included files into the project tree - saves a lot of hunting for register names in manufacturer-specific include files buried in install directories.

Eclipse does that including a whole lot of other stuff IAR probably won't do.

[dannyf]

TI has a set of benchmark routines (mostly math related) that can be easily ported to other platforms - they were written in C.

Look for slaa205 on their website and they are onto revision C.