Feedback on KDS

[pgo]

Just some comments on KDS

• I quite like the light touch approach taken in KDS compared to Codewarrior 10.  I hope this will make it easier to add extensions to the environment.

• I've done some comparisons between the GCC included in KDS and my 'preferred' GCC from  https://launchpad.net/gcc-arm-embedded

They seem pretty comparable except that the RAM usage (suspect for newlib?) (even with -nanolibc) still seems excessive c.f. above.  I may not be using the options correctly of course. 

There may be some option to tune the allocated space.

.data.impure_data  KDS=0x298 bytes, GNU-ARM=0x60

For a minimal project created using the KDS compiler:

text   data  bss   dec   hex   filename
3800   692  65580 70072 111b8 zzzz.elf

For a minimal project created using GNU-ARM

text  data  bss   dec   hex   filename
3188  120  65584 68892 10d1c zzzz.elf

• I am interested in the choice of using a customised GCC.  Is there some expectation that there might be Kinetis specific optimizations that can be applied to the actual compiler?  I would have thought this unlikely since the ARM core is standard.

• The KDS setup adds the KDS toolchain path to the eclipse environment.  I suspect it is using the hack described here: http://www.eclipse.org/forums/index.php/t/679056/feed.php?mode=m&th=679056&basic=1

  The advantage is that the path is present in everything in the environment.  The disadvantage is that there is no mechanism to change this - so you are stuck with the toolchain in KDS.   Changing the toolchain in the project setup has no real affect.

It would be preferable to use the recommended tool-chain-specific method using IConfigurationEnvironmentVariableSupplier.

bye

[joeseymour · Accepted solution]

Hi pgo,

Thanks for trying and providing some feedback on KDS. Hopefully I can answer the questions you pose...

I am interested in the choice of using a customised GCC.  Is there some expectation that there might be Kinetis specific optimizations that can be applied to the actual compiler?  I would have thought this unlikely since the ARM core is standard.

I wouldn't go so far as to say KDS uses "customized" GCC. The intent of KDS is to stay as close as possible to upstream sources. Building the compiler, as opposed to using a pre-built compiler, gives us more control, making it easier to address issues that might manifest in the tools and it allows us to make different design decisions (for example the interface to newlib-nano is a real GCC option in KDS, while it is simply a .specs file in GAE). We elected to track the upstream FSF mainline branches instead of the GNU ARM Embedded branch primarily because we expect it to be easier to apply local patches from the GNU ARM Embedded branch to mainline than visa versa, which allows the KDS compiler to be built on the very best that the open source community has to offer.

Obviously KDS is in a beta state at the moment, and feedback on the compiler will be taken into consideration for future releases.

• I've done some comparisons between the GCC included in KDS and my 'preferred' GCC from  https://launchpad.net/gcc-arm-embedded

They seem pretty comparable except that the RAM usage (suspect for newlib?) (even with -nanolibc) still seems excessive c.f. above.  I may not be using the options correctly of course. 

There may be some option to tune the allocated space.

.data.impure_data  KDS=0x298 bytes, GNU-ARM=0x60

For a minimal project created using the KDS compiler:

text   data  bss   dec   hex   filename
3800   692  65580 70072 111b8 zzzz.elf

For a minimal project created using GNU-ARM

text  data  bss   dec   hex   filename
3188  120  65584 68892 10d1c zzzz.elf

Of course, it's difficult to reproduce your results without more details of exactly what zzzz.elf is. You are quite right though, they should be very comparable. The following results are a comparison of the GCC ARM Embedded toolchain and KDS for an empty-main program and for "Hello World", both were linked against the CMSIS-Core files provided by KSDK-1.0.0Beta, using the KSDK-provided linker script. The target device is a K64F. With the exception of flags required to make programs link, exactly the same options were passed to both compilers (notably -mthumb -mcpu=cortex-m4).

		GCC ARM Embedded (4_8-2014q1-20140314)			KDS 1.0.1			% delta	% delta	byte delta
Flags	filename	text	data	bss	text	data	bss	text	data	bss
none	empty	3308	1092	28	4980	1088	204	50.54	-0.37	176
	hello	10240	2132	88	10368	2128	260	1.25	-0.19	172
Os	empty	2776	1092	28	4168	1088	204	50.14	-0.37	176
	hello	9716	2132	88	9560	2128	260	-1.61	-0.19	172
Os gc-sections	empty	2776	1088	28	2736	1084	28	-1.44	-0.37	0
	hello	9160	2132	88	8544	2128	260	-6.72	-0.19	172
Os gc-sections Dprintf=iprintf	empty	2776	1088	28	2736	1084	28	-1.44	-0.37	0
	hello	14504	2172	88	11032	2168	260	-23.94	-0.18	172

Comparing two different versions or builds of GCC isn't straight forward, they can be configured in a large number of ways, as can newlib. At the very least, hopefully these numbers suggest to you that the KDS tools can generate competitively small code. Note that the above experiment doesn't include newlib-nano, but the pattern should be similar.

In this version there is a small overhead ~172 bytes in .bss introduced by the KDS C library. If that turns out to be the biggest issue with this beta version of the tools, then I'll be pretty happy.

• The KDS setup adds the KDS toolchain path to the eclipse environment.  I suspect it is using the hack described here: http://www.eclipse.org/forums/index.php/t/679056/feed.php?mode=m&th=679056&basic=1

  The advantage is that the path is present in everything in the environment.  The disadvantage is that there is no mechanism to change this - so you are stuck with the toolchain in KDS.   Changing the toolchain in the project setup has no real affect.

It would be preferable to use the recommended tool-chain-specific method using IConfigurationEnvironmentVariableSupplier.

I believe IConfigurationEnvironmentVariableSupplier was considered before the solution described in the thread you mention. I'm not familiar with the technical pros and cons between the two, but such a discussion seems better placed on that thread. I encourage you to add your thoughts there, if it turns out to be a better way of doing it future version of KDS may well do it that way, if not then at least the rationale is there for the next person who wants to achieve something similar.

Unfortunately it seems that because KDS pre-appends to PATH it is difficult to slip in a toolchain earlier on path. Pre-appending, as opposed to appending, might have been overzealous. The rationale was that the first users of KDS seemed to have a lot of trouble finding the right tools, by ensuring the KDS tools are at the start of PATH we avoid those problems. We might re-consider the approach for future versions (although it would first be interesting to see how the eclipse.org thread develops with your input).

If you want to use the GAE tools then you can replace the "toolchain" directory in your KDS installation with a GAE directory, the important thing is that toolchain/bin includes arm-none-eabi-gcc and friends. (In fact you could just delete, or rename, the toolchain directory to subvert the path setting, then set your PATH as you like.)

Hope that helps,

Joe

[BlackNight]

Hi pgo,

thanks for for your feedback, appreciated!

Yes, the Eclipse in KDS is pretty much stock Eclipse Kepler. That way it it shall be easy to catch up with newer Eclipse releases (in the past it took about a year with CodeWarrior to get to a new Eclipse release). So things like USBDM are now very easy to integrate and use :-).

That compiler was the choice of the vendor providing that Eclipse distribution and installer to Freescale. I have passed your data to them to get information what is causing that increase in RAM usage. I suspect it is due the libraries they build and include automatically which have semihosting enabled by default, and that might cause what you see. You are doing the right thing with -nanolibc option.

About the environment variables: my thinking is that as a workaround it should be possible to use the launchpad GNU ARM toolchain if you would put it into the PATH on your environment at the system level, so it finds the ARM toolchain first in the path?

Erich

[pgo]

Hi Erich,

Thank you for forwarding my comments.

I'm unsure what you mean by "PATH on your environment at the system level".

If you mean in the window's environment I don't believe this will work (I haven't tried it).

If you open a project settings as shown it appears the method used pre-pends the paths to the tool directories to the PATH environment:

This would apply to all projects and is ahead of any system paths.

Even modifying the path in the project settings (where it should be set) is defeated:

The only method I know of that works would be to use the same hack and create a new plugin that load AFTER the KDS one and modifies the path i.e. hack the hack :smileyhappy:.

Not really elegant.

bye

[BlackNight]

How to use GNU gcc ARM Embedded with KDS: Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio | MCU on Eclipse.

Still not as elegant as choosing the tool chain in Eclipse, as it means swapping/renaming folders, and it would be effective for all projects. But at least works and I can use that way the latest and greatest ARM launchpad tools with KDS.