Comparing CodeWarrior with Kinetis Design Studio

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?

cw vs kds

ide

both codewarrior v10.6 and kds v1.1.1 are using eclipse as ide, and have processor expert integrated.

codewarrior

kinetis design studio

codewarrior is using eclipse 4.2 (juno), while kds is using 4.3 (kepler). 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. 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.

codewarrior build panels

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.

kds build panels

in summary, each is about equal: 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.

codewarrior register details

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.

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 “.

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 .

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:

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 “):

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 .

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 “):

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 ;-).

:idea: 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.

eclipse kepler

happy comparing :-)