Difference between revisions of "CMSIS Pack remarks and criticism"

Revision as of 10:47, 18 June 2014

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.

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 certain package is present or not, and go no deeper, at component level.

TODO: add more detailed remarks