ARM toolchain mini comparison - Page 1
Forum section: electronics / general

author: Laurynas
author_rank: Contributor
timestamp: September 06, 2013, 04:53:33 pm
content: 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=noneFlash used: 10256 of 32768 bytes (31,3%).SRAM used: 308 of 4096 bytes (7,5%).Sourcery 4.4.1 optimize=sizeFlash used: 7352 of 32768 bytes (22,4%).SRAM used:300of 4096 bytes (7,3%).Sourcery 4.4.1 optimize=speedFlash used: 7656 of 32768 bytes (23,4%).SRAM used:300of 4096 bytes (7,3%).GNU GCC 4.7 generic --specs=nano.specs optimize=noneFlash used: 10622 of 32768 bytes (32,4%).SRAM used: 428 of 4096 bytes (10,4%).GNU GCC 4.7 generic --specs=nano.specs optimize=sizeFlash used: 7646 of 32768 bytes (23,3%).SRAM used: 420 of 4096 bytes (10,3%).GNU GCC 4.7 generic --specs=nano.specs optimize=speedFlash used: 8014 of 32768 bytes (24,5%).SRAM used: 428 of 4096 bytes (10,4%).Keil MDK 4.72 optimize=noneFlash used: 6264 of 32768 bytes (19,1%).SRAM used: 1564 of 4096 bytes (38,2%).Keil MDK 4.72 optimize=sizeFlash used: 5424 of 32768 bytes (16,6%).SRAM used: 1552 of 4096 bytes (37,9%).Keil MDK 4.72 optimize=speedFlash used: 5436 of 32768 bytes (16,6%).SRAM used: 1552 of 4096 bytes (37,9%).Keil MDK 4.72 --library_type=microlib optimize=noneFlash used: 5508 of 32768 bytes (16,8%).SRAM used: 1564 of 4096 bytes (38,2%).Keil MDK 4.72 --library_type=microlib optimize=sizeFlash used:4668of 32768 bytes (14,2%).SRAM used: 1552 of 4096 bytes (37,9%).Keil MDK 4.72 --library_type=microlib optimize=speedFlash 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 librariesspeed was not tested since it's not an issue for all my current projectsso the conclusion would be - get MDK and switch to it when you want to trade flash for RAMedit: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=sizeFlash used: 3318 of 32768 bytes (10,1%).SRAM used: 1628 of 4096 bytes (39,7%).Keil MDK 4.72 --library_type=microlib optimize=sizeFlash used: 3140 of 32768 bytes (9,6%).SRAM used: 1572 of 4096 bytes (38,4%).

author: nctnico
author_rank: Super Contributor
timestamp: September 06, 2013, 05:30:46 pm
content: 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.

author: Laurynas
author_rank: Contributor
timestamp: September 06, 2013, 05:46:55 pm
content: let it be beginner's conclusion thenthis 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

author: nctnico
author_rank: Super Contributor
timestamp: September 06, 2013, 06:57:23 pm
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 08, 2013, 10:41:41 pm
content: 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.

author: bingo600
author_rank: Super Contributor
timestamp: September 09, 2013, 04:14:10 pm
content: 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

author: Laurynas
author_rank: Contributor
timestamp: September 09, 2013, 06:02:18 pm
content: I was under impression that Launchpad GCC = generic GCCLaunchpad GCC is used in my tests above.my bad, I'll have to try the REAL generic now

author: bingo600
author_rank: Super Contributor
timestamp: September 09, 2013, 06:14:57 pm
content: Quote from: Laurynas on September 09, 2013, 06:02:18 pmWhy 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

author: Laurynas
author_rank: Contributor
timestamp: September 09, 2013, 06:43:35 pm
content: no practical reason for surenctnico 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?

author: andersm
author_rank: Super Contributor
timestamp: September 09, 2013, 06:50:00 pm
content: Those Launchpad releases look like mostly vanilla releases with a few backported patches. The "leading" development happens on GCC mainline as usual.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 09, 2013, 08:15:25 pm
content: Quote from: bingo600 on September 09, 2013, 04:14:10 pmIAR do free code-size limited versions - 32K for ARM.

author: dannyf
author_rank: Super Contributor
timestamp: September 10, 2013, 12:14:19 am
content: "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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 10, 2013, 12:25:03 am
content: Quote from: dannyf on September 10, 2013, 12:14:19 amIAR 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.

author: dannyf
author_rank: Super Contributor
timestamp: September 10, 2013, 12:32:54 am
content: "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.

author: Laurynas
author_rank: Contributor
timestamp: September 10, 2013, 06:22:56 am
content: 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

author: nctnico
author_rank: Super Contributor
timestamp: September 10, 2013, 09:56:45 am
content: Quote from: mikeselectricstuff on September 10, 2013, 12:25:03 amEclipse does that including a whole lot of other stuff IAR probably won't do.

author: dannyf
author_rank: Super Contributor
timestamp: September 10, 2013, 10:58:18 am
content: 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.