CMSIS Pack remarks and criticism

The good parts

CMSIS Pack is an important step forward towards the standardisation of ARM Cortex-M system software, hardware description and documentation.

It provides silicon vendors with a great method to describe their chips in a structured way, from the full list of part numbers down to register level. These are all very useful information, since they are the basis for advanced tools, like project creation wizards (requiring the actual list of available parts and their associated header files and build details) and debugger register viewers (requiring detailed knowledge on the actual peripherals available in a chip variant and their full register definitions, down to bit level).

The bad parts

The advantage of being a great tool for silicon vendors is probably its worse disadvantage, since (at least the current version, v1.3) CMSIS Pack seems intended mainly to silicon vendors, and not to general software distribution (like eCos CDL).

The second major disadvantage (partly understandable by its origins) is the deep bias towards µVision, a proprietary tool by Keil, which limits (and sometime even voids) its usefulness in open environments, like GCC and Eclipse.

Non-portable examples

Apart for µVision users, that does not use Eclipse anyway, with the current version of the CMSIS Packs, the many existing CMSIS examples are... useless, at large. :-(

The provided examples cannot be used to automatically create ready to build new C/C++ Eclipse projects, requiring many manual configuration changes, usually out of reach for beginners.

For this to be possible, the following (portable) details are required in the definition of an example:

• the list of source files
• the list of header files
• the list of include holders
• an optional list of preprocessor definitions

One possible solution would be to define the content of an example as one or more components, with full details regarding the files and include folders, and, instead of mandating the presence of a proprietary project definition, allow each tool to create the project required to build the example.

Hopefully future CMSIS Pack versions will be improved, to make the examples more portable and available for Eclipse/GCC based tools.

Simplistic repository index

The recommended method to access the packages from a web site is via a very simple index, plus the full package description. This method generates a lot of network traffic, and parsing the very large xml files, containing full device descriptions only to get a summary of the package is wasteful.

Low configurability features

Compared to eCos, CMSIS Pack addresses only a very limited range of configurability options, generating a single, fixed name, header file (RTE_Config.h) generally intended to inform the source code only if a package is present or not, and does not go deeper, at component level.

The CMSIS alternative is a mechanism to allow a controlled edit of header files, using additional definitions embedded as comments.

Although functional, these additional definitions may interfere with embedded documentation, like Doxygen, further reducing the files readability.

Fixed file naming schemes

CMSIS Pack requires the package files to follow a very rigid naming scheme: VENDOR.PACKNAME.VERSION.pack, and also requires the presence of a description file, named VENDOR.PACKNAME.pdsc to be present both inside the archive and on the server where the package is published.

Fixed object hierarchies

Actually the CMSIS components are not really organised hierarchically, they are just tagged with various attributes, like class, group, subgroup, variant, version, and referring to them requires all relevant attributes.

Also packages have a flat structure, there are no methods to define hierarchies of packages.

No package dependencies

Packages are currently fully independent, and there are no dependencies between them, so if a package requires another package, the second one also needs to be manually installed.

Windows only tools

The package validation tool, and all other provided tools are non portable, and run only on Windows.