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

CW vs KDS

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

CodeWarrior

Kinetis Design Studio

Kinetis Design Studio

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.

CodeWarrior Build Panels

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.

πŸ’‘ See “Solving the 8192 Character Command Line Limit on Windows” how to overcome the 8196 character limit on Windows.

KDS Build Panels

KDS Build Panels

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.

CodeWarrior Register Details

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.

πŸ’‘ 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.
Eclipse Kepler

Eclipse Kepler

Happy Comparing πŸ™‚

29 thoughts on “Comparing CodeWarrior with Kinetis Design Studio

  1. Hi Erick,
    This is a pretty good post!
    Just a note on Codewarrior Special Edition code limit. For Kinetis E, L and M Series is 64 KB and
    128 KB for K Series.

    Like

  2. Hi Erick,
    Thanks for the analysis — it is very helpful.
    Beyond image sizes, do you have any feel for the execution time differences between CW and KDS?

    Like

    • Hi Dave,
      you mean execution of the IDE/Eclipse, or the code execution on the target? I feel (not measured) Eclipse is somewhat faster. I have not noticed that the code producec by gcc is slower than the one of CodeWarrior.

      Like

        • I have not done that measurement yet. As for code size, this heavily depends on the application. All what I can say is that I have not observed any performance degradation.

          Like

  3. Hi Erick,

    i’m porting some FRDM K64 projects from CW 10.6 to KDS 1.1.1
    The FRDM K64 board is connected to PC via PE Multilink Universal device.
    Using CW 10.6 the ‘Run’ and ‘Debug’ configurations allow me to ‘program and start’ or ‘program and debug’ the target board.
    Using KDS 1.1.1 only the ‘Debug configuration’ and ‘Flash from file…’ are executed correctly (sometime PE Multilink is not recognized), in all cases i cannot create a working ‘Run Configuration’ (similar to CW 10.6).
    Please can You explain the KDS 1.1.1 ‘Run configurations’ tipical usage ? IF its possible can You post some ‘Run configuration’ example ?
    Thanks in advance for Your fundamental support.

    Like

    • Hi Fabio,
      You are right, ‘Run’ does not exist (or better: does not work). What is the problem with the ‘Debug’ configuration? Or what would be the advantage of using a ‘Run’ configuration? The ‘debug’ is exactly the same as ‘run’, with the difference that you can debug. Is the problem that you need to do the extra start command?
      Thanks,
      Erich

      Like

      • Thanks Erich, my question was just to understand any differences between the two environments development and / or my probable misunderstandings. In the meantime, I tried typing in ‘Run Configuration’ field ‘C / C ++ Application reference to a generic executable file (exe) … and this is started on command’ Run ‘. It might be useful in the future. Thanks again

        Like

        • Hi Fabio,
          yes, you always can run a batch file or executable that way. The basic difference between a ‘run’ and a ‘debug’ configuration for an embedded target is that it does not set breakpoints and halts/runs the target. This can be emulated pretty much with a normal debug configuration. I see if I can come up with a quick description of how to do this, as you are not the first one asking that question πŸ˜‰

          Like

  4. Pingback: Emulating Eclipse ‘Run’ with ‘Debug’ Configuration | MCU on Eclipse

  5. “Processor Expert the differenciation and the key factor why we are using Freescale devices”
    After spending 2 days trying to map pins on a PIC32MZ I ran across your site and have never looked back, after 15 years of PIC. I tried STM32Cube, it’s a move in the right direction but lack of support for GNU stopped me (that and their web site), Microchip has MPLAB Code Configurator but is reluctant (as in does not) to support any device that are currently produced and of course only support it’s partners tool chains.
    I picked up a K64F and got the Ethernet working, found connectors for KL46Z and have been working with the touch feature.
    Great site!

    Like

    • Hi all!
      Just overheard this: “I picked up a K64F and got the Ethernet working”

      Kevin, please can you share how you did that?
      Thank you!
      Cristian

      Like

  6. Pingback: Tutorial: FreeRTOS with the Kinetis SDK and Processor Expert | MCU on Eclipse

  7. Can I just confirm that all your PEx extensions for CW will work with KDS? If so, having an IDE that a) has no code limit and b) works on Linux almost sounds too good to be true!

    Like

    • I am delighted to advise that, since I overcame the OpenSDA bootloader issue (disable auto-mounting of MSD on OSX, so that Windows VM gets proper access,) I have successfully programmed boards using the latest CodeWarrior with a Windows XP VM (KL46Z,) and also did a quick LED blinker using KDS, programming a firmware-upgraded FRDM-KL25Z (rev D) using a Linux VM – all on a Mac laptop.

      The Linux driver support (OpenSDA) seems to be MUCH better than it was last time I tried, back when there was the Linux beta version of CodeWarrior. Ran installer, restarted udev, plugged in, everything just worked.

      There are certainly some differences in creating a new project on KDS – I didn’t get asked about a connection/debug system, and had to set that manually through Debug Configurations, but everything behaved otherwise.

      Since I have no current need to use the Kinetis SDK, I will continue to use your PEx components under KDS, because I am still using your CodeWarrior projects as examples.

      Like

  8. It’s nice that KDS3 now supports Mac OSX. I abandoned Freescale hardware for new designs when they killed off Codewarrior for Linux after version 10.2. Now that they have a native OS X tool suite I might evaluate Kinetis for my next design.

    Like

  9. Pingback: Automatic Variable, Expression and Memory Display with GDB and Eclipse | MCU on Eclipse

  10. Hi Erich,

    Will installing KDS overwrite any CodeWarrior and/or Processor Expert resources? I ask because I have a project developed on CodeWarrior that will end in a few weeks but at the same time I just started working on a new project and this is a good opportunity try out KDS from the ground up.

    Thank you.

    Like

    • KDS is installed separately and will not overwrite each other (as long as you don’t try to install them into the same folder). I have them working side-by-side on my machine for a long time, so I can use either KDS or CW dependinig on the projects. The only thing shared are some of the USB debug drivers (P&E and Segger), but this has not been an issue for me.

      Like

  11. Pingback: P&E ARM Cortex-M Debugging with FreeRTOS Thread Awareness and Real Time Expressions for GDB and Eclipse | MCU on Eclipse

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.