Are ARM CMSIS-Packs the Future of Software Components?

DZone 's Guide to

Are ARM CMSIS-Packs the Future of Software Components?

How to create a vendor-neutral way to build and distribute software packages for ARM devices using CMSIS-Pack in Eclipse.

· IoT Zone ·
Free Resource

I’m using Processor Expert components for nearly every Freescale (now NXP) projects: for S08, S12, ColdFire, DSC and especially all the different NXP Kinetis devices. Not only because it makes software development fast and easy and allows re-use of software, but as well because Processor Expert has a good way to pack and distribute software components. Unfortunately Processor Expert is not any more included for the new Kinetis devices (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“) :-(. So I have looked into an alternative and hopefully vendor neutral way to build and distribute software packages using CMSIS-Pack.

Image titleCMSIS-Pack in Eclipse


I’m looking at new ways to offer, install and distribute the McuOnEclipse software and components. They are now provided as .PEupd files on SourceForge.

Image titleMcuOnEclipse Components on SourceForge

In this post I give my thoughts and experience with adopting CMSIS-Pack instead.

Processor Expert Components

Processor Expert packs the software components into *.PEupd files, a special archive format: The files can contain one or more software components. See “McuOnEclipse Releases on SourceForge” how they can be loaded into an Eclipse or CodeWarrior environment.

Image title

Processor Expert Components

But with the acquisition of that technology a few years ago by Freescale (now NXP) that technology turned into a vendor specific solution and was only available for Freescale parts. It is used in many university labs, research and personal projects, but as noted above: it is now time to move a vendor neutral way.

ARM CMSIS-Pack Component

Two years ago ARM announced a new member of their CMSIS standard, the CMSIS-Pack: a way to package software components, device information, example projects and code templates into an open format. Since then, the standard has been evolved, but seems not be widely used (yet?). There are several points noted in this wiki about its current limitations.

In a nutshell, CMSIS-Packs are (zip) archive files with an XML description file. That XML (.pdsc, Packet Description) file describes the files and defines other attributes:

  1. Components: Describe software components with taxonomy (class, group, subgroup) and list of files
  2. Conditions: dependency on device, compiler and/or other components.
  3. Devices: describe the device (family, sub-family, device) with properties like processor architecture, memory, debug interface.
  4. Boards: describes development boards and links to information (e.g. web links).
  5. Examples: project examples which can be used to demonstrate usage of components.

I recommend reading through https://www.keil.com/pack/doc/CMSIS/Pack/html/index.html which includes nice training and tutorial material.

Main features of the CMSIS-Pack approach for the McuOnEclipse components:

  • Compressed normal archive files as package file which can reduce download bandwidth. In Processor Expert the packs were using a special (encrypted?) format.
  • The packs are hosted on a server used with a package manager. With Processor Expert users had to download the packs manually from a server.
  • Built-in version numbering (1.0.0, 1.0.1, etc). In project is it possible to ‘lock’ the version used which is important to keep things stable from a project perspective. Processor Expert had added lately multiple repositories to deal with versions, but that did not work well.
  • Building and publishing packs could be automated (that’s not the case with Processor Expert).
  • Dependency management: I can describe that a component needs another one. That actually is better in Processor Expert (it automatically add dependent components). For both approaches it is not possible to automatically download and resolve components: I need to download them manually.
  • Vendor independence: With Processor Expert I’m locked down to NXP/Freescale, and for new Kinetis there is no Processor Expert any more. With CMSIS-Pack I hopefully there is a vendor neutral standard (at least in the ARM Cortex-M land).

Experimental Pack: Utility Component

In my research, I was working on getting the Utility Processor Expert component into a CMSIS-Pack format. The utility component is a pure software component providing many utility functions including safe string functions:

Image title

Utility Component

I have created a CMSIS-Pack .pdsc file to describe the component:

Image title

Utility pdsc file

With the CMSIS-Pack utilities a zip archive with all the files gets built:

Image title

Utility Package

Then an index file referenced by a package manager lists all the packages. Below is the experimental index file for the McuOnEclipse packages:

<?xml version="1.0" encoding="UTF-8" ?>
<pdsc url="https://github.com/ErichStyger/McuOnEclipse_CMSIS-PACKS/raw/master/Utility/" name="McuOnEclipse.Utility.pdsc"  version="1.0.0"/>

See https://github.com/ErichStyger/McuOnEclipse_CMSIS-PACKS for all the files and packs.

Keil MDK Tools

The ARM Keil MDK IDE comes with a CMSIS package manager, a separate executable:

Image title

ARM Keil Package Manager

As shown in above screenshot, the CMSIS-Pack manager is focused around ‘Devices’ and ‘Boards’. Software is listed under ‘Generic’ buried in the ‘Packs’ view on the side.

Idea: What is a nice extension is that it is possible to provide ‘Examples’ which I have not explored yet.

The Pack installer connects to a (hard-coded?) package site (http://www.keil.com/pack/index.idx). I have not found a way to direct the package manager to a different site. It seems to me that this Keil site wants to be the central point listing all packages from all vendors. The index.idx file lists packages from multiple vendor sites, extract below:

Image title

List of PDSC

Because it lists so many and different sites it takes a while to get information from all packages.

Idea: The GNU ARM Eclipse package manager is much more flexible: it allows to specify multiple sites and dedicated package installation folder.

It is possible to load ‘local’ packages with the ‘import’ (menu File > Import) function which is a good thing.

It seems not be possible to configure where the packs get installed. In my MDK v5 they all get installed into \ARM\Pack:

Image title

Installed MDK5 Packs

Basically the pack archive content gets extracted to that folder.

When creating a project with MDK, it uses the device and board information from the packs for the project creation:

Image title

MDK Pack Device Selection

Then I can use the ‘Manage Run-Time Environment’ to add remove components to my project:

Image title

Keil Runtime Environment

If here is a dependency between the components, this is detected so I can fix it:

Image title

Manage Runtime Environment

That’s pretty cool, and to some level I can configure the components with a ‘variant’ setting. Additionally it provides a link to the documentation (if available). On the other side it is kind of mysterious which software components show up as everything seems to be very much board and silicon oriented, but not towards pure software or middleware components.

Idea: I lost more than one day until I have found out that even if a software components does not depend on a device or a given compiler, you *have* to restrict it with a dependency to a device or compiler, otherwise it does not show up in the ‘Runtime Environment’.

MDK then links then from the project to the source files present in the package, so the packages are shared between projects. I wish there would be a way to make ‘portable’ projects with a way to copy the files into the project so I don’t have to depend on the package manager. Overall things are working pretty good, but everything is tight around the Keil MDK environment.

CMSIS-Pack and Eclipse

Liviu Ionescu has realized the potential of CMSIS-Pack early on and has developed an experimental pack manager, see http://gnuarmeclipse.github.io/articles/arm-com-2014-07/, see http://gnuarmeclipse.github.io/plugins/packs-manager/ how to install it into Eclipse.

It is part of the GNU ARM Eclipse suite of tools which are installed with Help > Install New Software in Eclipse:

Image title

Installed GNU ARM Eclipse Packs Plugin

It adds new views for packs to Eclipse:

Image title

Packs Views

It extends Eclipse with a package manager:

Image title

CMSIS-Pack in Eclipse

I can specify where to install the packs:

Image title

Pack Installation Path

And I can specify my repository paths:

Image title

CMSIS-Pack Repositories

I have defined my repository index files to avoid long waiting time, as the ARM Keil site includes (to) many sites I’m not interested in. I have setup two index/repository files here:


The first URL is for the McuOnEclipse (experimental) packs, and the second URL is a reduced set of ARM packages.

The plugin adds a ‘Package Manager’ perspective and button:

Image title

Pack Manager Button

Use the ‘Refresh’ button to refresh the packs with the content in the repositories:

Image title

Refresh Button

In the Packs manager I can browse, install, remove packages or inspect the properties. And as a bonus I can click on the items in the Outline view on the right and it will open the file for me:

Image title

GNU ARM Eclipse Pack Manager

Idea: After installing/changing packs, I recommend for now to exit Eclipse and restart it. I have seen cases where somehow the new information was not propagated quickly. But things like newly installed components were properly shown after a restart of Eclipse.

ARM CMSIS-Pack Plugins

For a better integration into Eclipse, ARM has published on GitHub additional plugins. The sources can be found here:


Prebuilt binaries for installation into Eclipse are uploaded here:


The following slides are a good read about how the plugins integrate into CDT: Enhanced Project Management for Embedded C/C++ Programming using Software Components

Download the zip file from https://github.com/ARM-software/cmsis-pack-eclipse-prebuilt (I’m using the version 1.0). Make sure you use the ‘raw’ download (https://github.com/ARM-software/cmsis-pack-eclipse-prebuilt/raw/master/1.0/CmsisPackPlugIn_1.0.0.zip)

Then use the Eclipse menu Help > Install New Software using the downloaded archive file:

Image title

Installed CMSIS Pack Plugins from ARM

This adds the following CMSIS views for Packs to Eclipse:

Image title

CMSIS Packs Views

There is a preference setting to specify where the packs are installed: I use the same place as used by the GNU ARM Eclipse package manager. If using the Keil Package manager, then specify where it has downloaded the packs:

Image title

CMSIS Pack folder

The ‘Installed CMSIS Packs’ view allows me to inspect the attributes of the installed packs:

Image title

Installed CMSIS Packs

The ‘CMSIS Devices‘ view shows me the installed devices:

Image title

CMSIS Devices

I very much like these two views as they give me a lot of details about the installed packs. But of course I need first to understand the CMSIS Pack attributes from the standards description.

Creating Projects With CMSIS-Pack

The ARM plugin adds an interesting approach to creating projects in Eclipse: based on the information in the packs, the project wizard can use that information for the project :-).

If I create a new project in Eclipse with File > New C project (or C++ project), I’m offered a new wizard for CMSIS RTE (RunTime Environment):

Image title

New RTE Project in Eclipse

In the next dialog I can select the tool chain (GNU ARM Eclipse GCC only supported for now, or ARM DS5:

Image title


Next I select the device from the list of installed devices:

Image title

Select Device

The next dialogs are for setting up Release/Debug configurations and to select the tool chain, and then it creates the project. That project includes a .rteconfig XML file which has a cool viewer for it to configure the components used for that project:

Image title

RTE With Components View

With building that project, it will add the selected components to the project:

Image title

Added RTE

In my case the linker complained about missing _exit() function, so I had to add

void _exit(int a) {for(;;);}

to my source code in main().

The GNU ARM Eclipse plugin is using the device setting in the build settings too:

Image title

Device Settting in Build Settings

As noted in the dialog, the memory map is not yet used for the build to generate the linker script (which would be cool!).

But the device selection *is* used for the debug configuration (e.g. Segger J-Link) when creating a debug configuration for that project:

Image title

Device Setup with CMSIS pack identifier

And best of all: the device setting (and register detail/SVD information) is used in the GNU ARM Eclipse Peripherals view: so with the information in the device packs I have a very nice peripheral register viewer:

Image title

Peripherals Register Details View

Alone this feature makes it worthwhile to use CMSIS Packs and using the GNU ARM Eclipse plugins :-).


We have developed over 160 Processor Expert components at the university which are successfully used in projects. To move to a different component and distribution model will not be a small and simple task. The CMSIS-Pack approach seems encouraging, but it is still somewhat early in its evolution. Thanks to the GNU ARM Eclipse project there is hope and maybe this leads to a broader adoption of CMSIS-Pack for the Eclipse and ARM world. CMSIS-Pack could have the potential as general standard, but for now it is ARM Cortex-M only, very board, silicon and Keil MDK as well Windows focused, but that might improve for in the future. If you are developing for ARM Cortex-M and happy to be in the ‘ARM golden cage’, at least it has the potential to be neutral for the ARM Cortex-M eco system which is better than nothing. The CMSIS-Pack concept cannot replace the power of Processor Expert, but at least it can fill the gap with distribution and dependency management of components. But CMSIS-Pack does not even comes close to the versatility and ability to configure software with Processor Expert. The GNU ARM Eclipse project shows the potential of CMSIS-Pack to simplify our developers life.

So is CMSIS-Pack the future of software components? Maybe, but not if it does not get out of the ARM MDK cage. ARM has realized that and provides a proof of concept with their Eclipse plugins. Well done with that way to create projects based on Packs. What is really cool is the extension with RTE (RunTime Environment) to the project: the packs are able to contribute to the project and I have a simple user interface to turn on/off components for the project. The GNU ARM Eclipse package manager is promising thanks to the excellent contributions of Liviu.

I will continue to explore the technology and continue to find out how to transform the McuOnEclipse components into CMSIS-Pack. But to make CMSIS-PACK a success, it needs the contributions of many (more), not only of Keil and ARM. And it will be interesting to see what other silicon and tool vendors will do with CMSIS-Pack.

Or what do you think about CMSIS-Pack?

arm, connected devices, eclipse, iot, java

Published at DZone with permission of Erich Styger , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}