At FTF 2014, Freescale made the announcement that CodeWarrior won’t support all the new ARM Kinetis devices coming out in the future: they will be supported with the free-of-charge Kinetis Design Studio (KDS) instead. As for myself, this is a big shift from a well established CodeWarrior toolchain to something new. A question which came up recently several times in the forums and in other posts is: how do CodeWarrior and KDS compare with each other?

IDE

Both CodeWarrior V10.6 and KDS V1.1.1 are using Eclipse as IDE, and have Processor Expert integrated.

💡 As of May 6th, there is the version 3.0.0 of KDS available

CodeWarrior is using Eclipse 4.2 (Juno), while KDS is using 4.3 (Kepler).

💡 Update: KDS v3.0.0 is using Eclipse 4.4 (Luna)

The KDS Eclipse is stock Eclipse Kepler, while the CodeWarrior version has many small Freescale extensions, such as it is possible to open a project location in the Explorer window, or to import projects with drag & drop. Because KDS is stock Eclipse, that makes it easier to have it on other platforms, and KDS has a version for Linux. Because KDS only supports Kinetis, the installer/download size is smaller too: 512 MByte vs. 740 MByte with CodeWarrior.

💡 Update: Installer size of KDS v3.0.0 is 671 MByte.

And I feel KDS feels ‘snappier’ and runs faster, probably because it is not as ‘heavy’ as CodeWarrior and because Eclipse Kepler is performing better than Eclipse Juno.

CodeWarrior has a free code size edition (128 KByte for Kinetis K, 64 KByte for all other ARM families), while KDS has no code size limitation at all.

In summary, the KDS IDE is the winner for me as it is using a newer Eclipse IDE, and is unlimited and free of charge: two points for KDS.

Build System Integration

The build system (that are the compiler panels and how the compiler/linker is called) is in CodeWarrior a specific version built by Freescale. It has the cool ability that it allows to build large projects because it passes the options to the compiler using an external file. And I can directly produce a preprocessor listing or a disassembly on source file, without the need to setup special build options.

The KDS build tool integration is open source and are the GNU ARM Eclipse plugins maintained by Liviu. They are newer, and have better support built-in to create e.g. S19 files. However, the plugin does not support building large projects and hits the 8196 character limit on the command line at least on Windows.

💡 See “Solving the 8192 Character Command Line Limit on Windows” how to overcome the 8196 character limit on Windows.

In summary, each is about equal: one point for each.

Debugger

CodeWarrior is using a proprietary debugger engine, while KDS is using gdb. CodeWarrior comes with P&E and Segger support. KDS has this too, but adds the open source OpenOCD debug connection. Both KDS and CodeWarrior work as well with USBDM, another open source implementation.

The KDS debugger panels are provided by the GNU ARM Eclipse plugins. These plugins are easier to use than the CodeWarrior ones. KDS is using the GNU (gdb) debugger, and makes scripting easier. Additionally, because it is gdb, there is a FreeRTOS plugin for gdb available. But on the other side CodeWarrior has working support for typical embedded things like resetting a target, attaching to a running device or running specific ‘target tasks’ to download, compare memory or even write your own flash algorithm. CodeWarrior comes with very good register level detail viewer.

On the other side, KDS only shows CPU registers. It is possible to add an extra plugin (EmbSysReg Viewer), but even with this plugin it is not possible to inspect the ARM core registers (e.g. NVIC) because this is lacking in the SVD files available.

💡 Update: KDS v3.0.0 has EmbSysReg viewer included and supports CMSIS-SVD files with core periopherals.

CodeWarrior comes with a built-in trace viewer and support for hardware trace, while something like this is not present in KDS.

CodeWarrior offers a ‘Run’ configuration, while KDS does not. But there is a workaround, see “Emulating Eclipse ‘Run’ with ‘Debug’ Configuration“.

Another thing is ‘Live View‘: With CodeWarrior I can watch varables while the target is running. This is a CodeWarrior specific extension of CDT, and not available in KDS.

UPDATE: P&E has released a new plugin for Eclipse (and KDS) which supports ‘Realtime Expressions’ which is the same as ‘Live View’. See “P&E ARM Cortex-M Debugging with FreeRTOS Thread Awareness and Real Time Expressions for GDB and Eclipse“.

In summary, CodeWarrior has much better and more robust debugging support compared to KDS. KDS on the other side comes with the bonus of open source, but the winner to me is still CodeWarrior: one point for CodeWarrior.

💡 Update: with KDS V3.0.0 each get one point.

Compiler

CodeWarrior supports multiple architectures (S08, RS08, S12, S12X, S12Z, DSC, ColdFire, PowerPC and Kinetis), while KDS ‘only’ has Kinetis support. Both KDS and CodeWarrior include GNU gcc as the default compiler for the ARM cores. CodeWarrior comes with gcc 4.7.3, while KDS has the newer version 4.8.0. The KDS GNU toolchain however is not the standard GNU ARM Embedded (launchpad) toolchain from ARM, but a custom one built by Somnium.

CodeWarrior comes with its own proprietary ANSI and runtime library named EWL (Embedded Warrior Library) which is optimized for embedded usage. KDS comes with the open source newlib and newlib-nano.

To compare CodeWarrior and KDS, have compiled and built three projects, and I’m comparing the code and data size (see “text, data and bss: Code and Data Size Explained“). To compare the KDS gcc, I used the launchpad GNU ARM Embedded (4.8.4 update 2 release). The projects are compiled without optimization (-O0) and with -O3.

FRDM Touch

The first application a touch demo for the FRDM-KL25Z board (see “Tutorial: Touching the Freedom KL25Z Board“). This application does not use much or anything of the ANSI library:

		-O0			-O3
FRDM Touch	Linker Options	text	data	bss	text	data	bss
CW 10.6, EWL		19552	36	1340	16696	36	1336
KDS 1.1.1, nano	-nanolibc	18384	44	1372	15564	44	1368
KDS 1.1.1, newlib		18384	44	1372	15564	44	1368
KDS 1.1.1, lauchpad, nano	-specs=nosys.specs -specs=nano.specs	18288	44	1376	15464	44	1372
KDS 1.1.1, lauchpad, newlib		18576	1116	1376	15752	1116	1372

The observation is that both KDS and launchpad are producing smaller code than CodeWarrior. There is too much overhead with newlib, so usage of newlib is not a good thing, and newlib-nano is preferred instead. Code and Data size are comparable between KDS and launchpad, with the launchpad slightly better. Here CW, KDS and Launchpad are all about equal, so one point for each.

Printf() and Scanf()

The next application is using printf() and scanf() (see “printf() and scanf() with GNU ARM Libraries“):

		-O0			-O3
FRDM printf()/scanf()	Linker Options	text	data	bss	text	data	bss
CW 10.6, EWL		7432	228	2268	7000	228	2268
KDS 1.1.1, nano	-nanolibc	9884	704	1304	9020	704	1304
KDS 1.1.1, newlib		39340	2284	1608	38476	2284	1608
KDS 1.1.1, lauchpad, nano	-specs=nosys.specs -specs=nano.specs	9948	136	1136	9084	136	1136
KDS 1.1.1, lauchpad, newlib		54052	2248	1180	53188	2248	1180

Here again it makes it clear that the plain newlib library is not good for embedded applications, and using printf() and scanf() blows up the code (see “Why I don’t like printf()“). CodeWarrior and its EWL does a very good job, and KDS even using newlib-nano does not look good at all. The GNU launchpad withe newlib-nano has comparable code size with KDS, but needs much less RAM. What stands out is the excessive usage of RAM in KDS using the newlib-nano option.

Between KDS and launchpad tools, the launchpad tool is the winner, but CodeWarrior still has smaller code size. One point for CodeWarrior and one point for the launchpad tools.

💡 Update: KDS v3.0.0 comes with the launchpad tools and libraries.

K22 Robot

So far the two benchmark applications above don’t do much. So here is a more realistic application running on a Kinetis K22 robot system (see “Zumo Robot with WiFi and GPS“):

		-O0			-O3
K22 Robot	Linker Options	text	data	bss	text	data	bss
CW 10.6, EWL		147172	20352	16332	101784	20332	16332
KDS 1.1.1, nano	-nanolibc	138736	20360	16384	103396	20340	16384
KDS 1.1.1, newlib		138736	20360	16384	103396	20340	16384
KDS 1.1.1, lauchpad, nano	-specs=nosys.specs -specs=nano.specs	123520	20360	16384	96792	20340	16384
KDS 1.1.1, lauchpad, newlib		124996	21432	16384	98268	21408	16384

This application (of course! ;-)) does not use printf() or scanf(), so we do not see that big difference between newlib and newlib-nano, and the data size is comparable among all. What this example shows is that the launchpad compiler produces much smaller code than KDS and CodeWarrior. The winner here is clear: one point for the launchpad tools and compiler.

Summary

Both KDS and CW do their job: CodeWarrior performs better in typical embedded tasks, and its overall debugging support is better. On the other side KDS benefits (and gets hurt) by the fact that it is using mostly open source components. I expect KDS to mature more on the embedded side, or hopefully the GNU tools get better too so KDS can benefit, e.g. from better or more plugins for embedded users. What my data shows is that KDS is comparable to CodeWarrior, but can be even better with using the launchpad tools. For sure the EWL library of CodeWarrior is very good, but if your application depends on it, then probably you are doing anyway something wrong (using printf()?). Anyway, for newer Kinetis devices there is only KDS which is free, and for free tools this is very usable for my projects. But if you have money to spend, then there are plenty of commercial options out there. That’s the benefit of the ARM ecosystem: there is always someone who is willing to take your money ;-).

💡 If you are willing to invest some time instead of money, then there is a good alternative: you can build your own ARM IDE and toolchain, see the start of the “DIY Free Toolchain for Kinetis: Part 1 – GNU ARM Build Tools” series.

As for my projects, I’m running this strategy:

1. I still use CodeWarrior to support my ‘legacy’ projects built with it. No reason to get rid of CodeWarrior, or to migrate the projects to a new tool chain.
2. For new projects, I’m running a dual strategy: I’m using both KDS and my DIY Kepler toolchain. I can easily switch projects between KDS and stock Kepler (because same Eclipse same tool chain integration), but it allows me to use the launchpad tools instead of using the KDS toolchain. In parallel, using the DIY solution gives me the ability to be vendor independent and picking and choosing the best of the two (or any) worlds.
3. Processor Expert is key, and it is supported in CW, KDS and Eclipse Kepler, so I have the freedom of choice. Processor Expert the differenciation and the key factor why we are using Freescale devices for teaching and research, because it is such a productivity tool.

Happy Comparing 🙂