Are ARM CMSIS-Pack the Future of Software Components?

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.

CMSIS-PACK in Eclipse

CMSIS-Pack in Eclipse

Outline

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.

McuOnEclipse Components on SourceForge

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

Processor Expert Components

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:

Utility Component

Utility Component

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

Utility pdsc file

Utility pdsc file

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

Utility Package

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:

ARM Keil Package Manager

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.

💡 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:

List of PDSC

List of PDSC

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

💡 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:

Installed MDK5 Packs

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:

MDK Pack Device Selection

MDK Pack Device Selection

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

Keil Runtime Environment

Keil Runtime Environment

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

Manage Runtime Environment

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.

💡 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’. UPDATE: according to the information from an ARM engineer I was wrong about that: it does not require a dependency. It looks I was running into some refresh problem (known limitation of the GNU ARM Eclipse plugins), plus my XML file did not pass the Schema test: the RTE_Components.h section needs to be *inside* the component! See “XML Editor & Checker for CMSIS-Pack in Eclipse” about how to check the XML files.

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:

Installed GNU ARM Eclipse Packs Plugin

Installed GNU ARM Eclipse Packs Plugin

It adds new views for packs to Eclipse:

Packs Views

Packs Views

It extends Eclipse with a package manager:

CMSIS-PACK in Eclipse

CMSIS-Pack in Eclipse

I can specify where to install the packs:

Pack Installation Path

Pack Installation Path

And I can specify my repository paths:

CMSIS-PACK Repositories

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:

https://github.com/ErichStyger/McuOnEclipse_CMSIS-PACKS/raw/master/index.idx
https://github.com/ErichStyger/McuOnEclipse_CMSIS-PACKS/raw/master/arm.idx

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:

Pack Manager Button

Pack Manager Button

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

Refresh Button

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:

Eclipse Pack Manager

GNU ARM Eclipse Pack Manager

💡 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:

https://github.com/ARM-software/cmsis-pack-eclipse

Prebuilt binaries for installation into Eclipse are uploaded here:

https://github.com/ARM-software/cmsis-pack-eclipse-prebuilt

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:

Installed CMSIS Pack Plugins from Arm

Installed CMSIS Pack Plugins from Arm

This adds the following CMSIS views for Packs to Eclipse:

CMSIS Packs Views

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:

CMSIS Pack folder

CMSIS Pack folder

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

Installed CMSIS Packs

Installed CMSIS Packs

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

CMSIS Devices

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

New RTE Project in Eclipse

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:

CMSIS RTE Project

CMSIS RTE Project

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

Select Device

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:

RTE with Components View

RTE with Components View

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

Added RTE

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:

Device Settting in Build Settings

Device Setting 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:

Device Setup with CMSIS pack identifier

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:

Peripherals Register Details View

Peripherals Register Details View

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

Summary

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?

Happy Packaging 🙂

Links

 

Advertisements

38 thoughts on “Are ARM CMSIS-Pack the Future of Software Components?

  1. I’m convinced that the future of software components is based on some kind of packs, but, as you mentioned, the CMSIS Packs are now too MDK & ARM CC centric, which limits their use. And, as long as ARM/Keil will continue to use the Packs as a marketing tool to promote their MDK, things will not change very fast.

    Another component based technology is [yotta](http://yottadocs.mbed.com) from mbed, which comes with an interesting component [repository](http://yotta.mbed.com/#/module/ilg-arm-cmsis/4.5.0-7). Unfortunately, their design also has some characteristics that makes integration with IDEs difficult (see [#606](https://github.com/ARMmbed/yotta/issues/604)).

    For GNU ARM Eclipse I’ll try to complement the CMSIS Packs with additional metadata (xPacks/XCDL metadata), and try to pack everything as yotta packages.

    The future GNU ARM Eclipse Packs Manager will be able to manage both CMSIS & XCDL packages, to download packs from any CMSIS Packs site, from yotta repository and from GitHub projects.

    Any help in this endeavour will be highly appreciated.

    Liviu

    Like

    • Hi Liviu,
      I agree that the future is some kind of package manager. Thanks for the links to yotta: it strikes me that ARM is (again?) doing one thing with mbed and another thing with CMSIS/MDK. I see the advantage of yotta to be less XML loaded and with the ability to use command line tools (which is great for build automation and testing). But as you say: it lacks good IDE integration.
      As for myself, I will get a bit deeper into CMIS-Pack and will port some of my modules and then see how it works out. But I already realized that building up my first two packs is a lot of efforts, and it will be even more to maintain them. At least with your plugins it is not an ARM MDK only thing anymore. It is the third time now that I invested a lot of time and efforts into a technology, and then the vendor decided to drop it. I don’t want to have that again. If mbed goes away, I’m sure that yotta will not last long. And if MDK goes away, not sure what will happen with CMSIS-Pack?

      Like

      • > yotta to be less XML loaded and with the ability to use command line tools

        I gave this subject a lot of thinking, and, to cut a long story short, the final decision is between XML and JSON (or derivative). Since now JSON also benefits from using schema validation tools, the distinction narrows to how convenient is to create/edit such files. Well, at first sight XML appears to win, there are lots of tools to manually create and maintain XML files, but… actually this is a wrong approach, a sign of poor tools design. The tools should not expect these files to be manually edited, but provide nice command line and GUIs to create and maintain the configuration. And in this respect JSON wins.

        So in xPacks/XCDL all metadata is stored in .json, and everything will be edited by tools (a command line tool, like yotta, and some Eclipse plug-ins), not manually.

        > At least with your plugins it is not an ARM MDK only thing anymore

        🙂

        Like

  2. Hi,
    We have for several years used the PEx to ease the configuration of various HC12 projects, and when we switched to ARM it was nice to find PEx also here. To my great surprise it seems that NXP is abandoning this now, and I honestly doesn’t understand what they are thinking.

    We are a small company and our products will last for 15-20 years, and we could not and will not jump to new technologies just because some vendor has a new idea. In my simple mind I thought that Freescale was delivering PEx and KSDK to make a competing edge against other ARM vendors, but now it seems that they are killing it all, and what remain then is price, so special strings will attach me to Freescale/NXP, so maybe the next project will be ST…

    As of your work, I have not dared to incorporate it in our projects, one reason is that there was competing beans from Freescale and McuOnEclipse.

    A wish for the future:
    Could you please now make your packages with a unique prefix, so that it will be easier to use packages from different sites.

    As a general idea, I’m very pleased with your thoughts regarding packages, and I will follow it with great interest, I totally agree that some kind of processor independent packages will be a very valuable contribution to the various projects.

    Thanks for your contribution.

    Liked by 2 people

    • Hi Ole,
      Thanks for your comments and thoughts! ‘Abandoning’ depends on how to look at it: I think it will be still around for some years, but not for new devices. Similar to what happened to CodeWarrior for Microcontrollers a few years ago. And some of the Processor Expert functionality will go into the Kinetis Expert concept (see https://community.freescale.com/message/611862#611862). So there is something replacing that, but it is not the same, so I need some way of migration, thus I’m looking into CMSIS-Pack.
      As for your point about using a unique prefix: You can distinguish Processor Expert components with different repositories (see https://mcuoneclipse.com/2015/07/06/processor-expert-component-repositories/). But if you are on S12, then this will not help you as Processor Expert has not been moved to Eclipse for S12/HC12.
      Otherwise, that problem is nicely solved with CMSIS-Pack too: there is a ‘vendor’ field in CMSIS-Packs allowing to easily distinguish packages. And it has version management built in. So from this perspective, CMSIS-Pack is a viable approach. But it is only a subset of the Processor Expert technology. CMSIS-Pack is only about packaging and dependencies, but has no intelligence (or I have not seen it) to configure software and drivers.

      Like

    • I agree with Ole here. We have a long (and sometime turbulent) history designing products around Freescale MCUs and using their dev tools. For our latest generation of products we had decided on ARM cores, but given the choice between the various ARM vendors ST and NXP (LPC-series) were also high on our list. After much deliberation, the Freescale Kinetis parts were chosen largely due to the SDK and the Processor Expert tools. We later discovered that the SDK doesn’t support the MKE0x series parts, and now processor expert is deprecated. So much for our choice…
      -Mike

      Liked by 1 person

  3. to spin the whell a bit further…. wouldn’t it be nice to have a standardized HAL for different microcontrollers?

    There is a bit of a mess when it comes to such things like APIs across vendors or even their product families. In my understanding CMSIS was a good idea, but does not cover enough to make software easily portable.

    I have stumbled across some projects trying to unify the programming of microcontrollers at a HAL-Level.
    one of it is stm32plus which tries to ease the programming of stm32parts with a unified API
    https://github.com/andysworkshop/stm32plus

    some time was thinking about the arduino platform as a good reference. there exist ports for nearly any kind of processor. The support varies and highly special features like DMA-Triggering and fancy timer chaining are not seen at all.

    If i was a bit more certain which way would be the right one, I would have little trouble to find good arguments to put some of my work into supporting such a project.

    this would also ease the creation of a “ARM Cortex-M Software Repository”…

    what other HALs do you know which ease the support of writing embedded software as chip-vendor independent as possible?

    thank you!

    Like

    • Hi Peter,
      very good thoughts! What comes to my mind is AUTOSAR (http://www.autosar.org/) which basically does what you are proposing (and which you might know already?): a unified vendor neutral API for programming automotive applications.
      I don’t expect ARM or any of the ARM vendors to come up with something like this, because every vendor tries to separate and keep things under their control, with the way they want it.
      In the AUTOSAR case the ‘customers’ (BMW, BOSCH, Continental, Daimler, Ford, GM, PSA, Toyota, VW) have forced the silicon vendors to get together and define a common API and standard. Along the line “if your silicon and software does not conform to the AUTOSAR, we won’t buy from you anymore”. In this case the group of customers was big and strong enough to get AUTOSAR established. ARM in my option is doing similar with CMSIS in my view, but has a much weaker position: ARM can suggest the standard, but not enforce it because the silicon vendors are the customers of ARM. Putting all the CMSIS together gives a good marekting story, but falls short if still everyone is doing its own thing to protect its business? On the other end I think that big companies like Google and others are big enough to make their own HAL and to control their own destiny, because it is strategic for them and they can affort it.
      Moving things even to a higher level (my university point of view): development, quality of software support for Intel parts are better than for ARM, to the point that I see software development for Intel easier than for ARM (see as well http://appleinsider.com/articles/15/01/16/five-barriers-that-might-hold-apple-back-from-moving-intel-macs-to-custom-arm-chips). From my own engineering perspective I love the ARM core, but I have to admit that the development for Intel parts (again in my personal view) is easier and better. I’m not a Microsoft fan, but I have to admit that their Visual Studio environment is a different class of tools, with a GDB for Visual Studio here: http://visualgdb.com. My 1 cent is that I think such a unified API or HAL needs to come from the bottom, and won’t be able to come from the top in the case of ARM. Or that simply engough customers demand standard X (which could be from ARM).

      Like

  4. Hi Erich,

    highly appreciate all your work around PEx, it’s pretty amazing!
    Regarding the article:

    I think CMSIS aim is different from the PEx one significantly, although some principles (packaging) used on both might look very similar.

    Within design of PEx at the start I intended not to give user just control over the SW “BOM” capable to be build using different environments, but to have intelligent set of components interacting with the MCU knowledge system and helping user with the MCU/board resources management and configuration under RAD principles.

    Regarding the HAL, we came with PEx components API and inheritance capability several years before Autosar. I totally support idea to HAL should come from the bottom – as mentioned on the previous reply. But, why to build something new from scratch, better to reuse proven APIs on many MCU architectures…..

    Like

    • Hi Milroad,
      My view is that the intention is a good one, and would play well with CMSIS-Pack concept. But given the vast majority of different ways to implement an API, and given the passion (or disputes) about APIs I think this one will be even harder to get a common standard than CMSIS-Pack. I think overall it could work for ARM, but not for the individual silicon vendors. It *might* work for the middleware vendors. But I see the middleware (RTOS, stacks, etc) provided for free mostly by the silicon vendors, so I think they have no interest in making that part common. I think CMSIS-Driver could be technically the ‘AUTOSAR’ for ARM. But as long there are no big OEMs demanding it, the future of CMSIS-Driver is unknown to me. It would be interesting to hear why ARM is doing CMSIS-Driver, and the same time using something completely different with mbed.

      Like

      • Yes, ARM is pushing this (and mbed is part of ARM). I’m not convinced yet that CMSIS-Driver will succeed if not more are adopting it. Only the future will tell 🙂

        Like

      • I switched to CMSIS Drivers for USART and USB, and, at least for F4/F7, they’re fine. I even wrote a USB CDC driver that behaves like a USART driver.

        The only design problem that I encountered is that callbacks are non-reentrant, if you have multiple devices you need to write a callback for each one, you cannot reuse callbacks with a parameter.

        Given some time, they’ll probably succeed.

        Like

  5. On the topic of HAL unification and “abstraction”, how about the opposite approach? I mean the “inversion of control” applied to this domain? I would say that the chip vendor should provide the “framework” part of the event-driven, inverted control logic, while application programmers plug in their product-specific extensions to form “the app”. For example, the framework provides “onInitDone()” event (callback, extension point) where one could call some APIs to enable and configure the UART, later “OnUartDataReceived()” event (callback) gets fired by the framework and our MODBUS driver (for example) gets busy. In this context my MODBUS protocol engine (middleware, component) become totally platform independent (including ARM vs MIPS vs xxx). This is often associated with “node.js” style where one could implement complex applications in a single threaded environment … Sure this needs some more work to be hard real time proof, but there comes the active objects and “event service threads”.
    The main point is to avoid “forwarding” configuration and connection information through multiple layers (e.g. to avoid the situation where HMI component needs “COM port number” configuration field, which is passed to the MODBUS component’s “COM Port number” input, which is passed to some kind of “resource manager” that could resolve the “COM1” name to precise handle and so on. This style (the “forward control”) leads to exploding dependencies between components that bring more and more abstractions. While this (“forward”) approach might be useful for general-purpose operating systems (Windows, Linux, Arduino) because of simplicity where one expects that anyone could build new applications (so called “web programmers”), it does not fit in embedded world where product quality and availability (up time) is important as well. How often one needs to change the index of the UART (or SPI, or I2C) port where the EEPROM is soldered, after the point when the firmware get compiled and linked?
    My point is that if we learn how to create SW components that strictly perform only the direct work they are designed for, and find a way to simplify connections between those “self-sufficient” components, that we don’t need abstractions and common interfaces.
    As we see from the comment of Ole Asbjorn Fadum, depending too much on technology from given vendor always bring the risk of getting dissapointed. So we need approach that could “interconnect” different technologies. This could be based on simple, plain ANSI C – in the form of “glue logic” at places that don’t stick together naturally.
    Another example could be a protocol middleware – in case of inverted control, this one would be separated in independent serialization functions and transport functions. Whenever one uses it he/she needs to make the “glue” – to call the serializations and to use the result as argument for second call to the transport layer (for example, Eclipse mqtt Paho embedded C source base). The “forward” approach would give one function that will make both (serialization and sending) and would require some kind of handle to the transport channel. Maybe TCP based at first. To switch to another interface (e.g. Serial) one needs to develop another class that implements exactly the same interface. And this “abstraction” might be not usable for serial transport (for example, because TCP defined IPv4 addressing information while Serial needs 4096 byte long string to be able to resolve “\\\\.\\xxxxx\iiiii\COM245”).
    If we want to do the same in “inverted control” style, we would not touch the serialization routines, we just call the serial access functions (and not some particular style or interface, we can easily call any available API being it Linux, Windows, ChibiOS, mbed, arduino…).

    Like

  6. Hi Erich,

    You are writing ” … 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’”.

    That is incorrect, a component can be entirely generic (no “condition” attribute is provided) or define only software dependencies in its condition. I have specially tested that it works in uVision and in CMSIS-Pack Eclipse plug-in.

    Like

    • Hi Evgueni,
      thanks for that input. I’ll have to check what exactly happened, as I was changing the file back and forward. It could be that I have indeed made a mistake somehow, or it was a refresh issue.
      I will try to reproduce it (but won’t be able probably before the weekend) and report back. But what I remember is that I have run the .pdsc through the normal batch file (which includes the checker?), but I have not seen a warning or error? Maybe I missed it?
      Many thanks!

      Like

    • Hi Evgueni,
      Yes, you are indeed correct and I was wrong. I guess I was on the wrong path due other issues, plus as you pointed out on GitHub my XML file was not according to the schemata. I updated the article and files.
      Thanks!
      Erich

      Like

  7. Hello

    I’ve just installed the CMSIS Pack plugin and I’ve downloaded the packs. Also I’ve configured both paths to point to where the packs are installed and the “Installed CMSIS Packs” and “CMSIS Devices” views are empty. How can I populate them? I can’t find the option to refresh the view 😦

    Thanks!!

    Like

    • Hi Manuel,
      I assume that you have used GNU ARM Eclipse pack manager from gnuarmeclipse to install the packs. That plug-in is independent from CMSIS-Pack Plug-in from ARM.
      Those plug-ins do not share the same preferences snd should be configure separately.
      You need to set “Window->Preferences->CMSIS Packs -> CMSIS Pack root folder” to the location where packs are installed to make CMSIS-Pack plug-in work.

      Like

      • Thank you for helping! Nevertheless, the “package folder” configuration from the GNU ARM eclipse and the “CMSIS pack root folder” configuration from the ARM CMSIS-Pack plugins are pointing at the same path as explained in the post but I still can’t see the ARM CMSIS-Pack Plugins views populated.

        Like

    • Have you tried to restart Eclipse?
      If it does not help, please check if packs are correctly installed:
      ${CMSIS_PACK_ROOT}/Vendor/Name/Version
      Please note that you cannot install packs to a hidden directory or directory starting with ‘.’ or directory that already contains a *.pdsc file.

      Like

      • I checked the installation path and I didn’t have any folder, then I realized that I had just hit the yellow refresh arrows but I had’t actually installed any package. I right-clicked all the packages I need and now I can see them.

        But thanks anyway for helping since your suggestion helped me to realize this!! 🙂

        Like

  8. Hello,

    So, is it time for a guide for an eclipse based DIY development environment without PEx?
    I tried, but the KSDK plugin installation fails. It looks like there is a PEx dependency.

    Iñigo

    Like

  9. Pingback: XML Editor & Checker for CMSIS-Pack in Eclipse | MCU on Eclipse

  10. Hi Erich,

    Thank you for your updating article. It has raised my already growth concern regarding Kinetis family. I have been using KL15s, KL16s and K10s always with PE and IAR. I have used your PE components very often so thank you very much for making my live easier. PE seems to be reaching its EOL and it looks like it won’t be supporting any new processors. I was hoping I would be able to keep using the IAR Embeeded Wrokbench with this new CMSIS package approach to reuse code have some kind of trusted HAL that allows me to jump into new processors within a short time. Have you done some research about IAR supporting CMSIS package? Do you know if that will even be possible in future? I know the is no “the best compiler + IDE” since each one has its ups and downs; but if I had to move from IAR in order to use CMSIS packages what tool would you recommend me to used?

    William

    Like

    • Hi William,
      I don’t know about plans of IAR, but my guess is that if CMSIS-Pack takes off and gets the industry attention, they problably have to support it in one way or the other. Unfortunately I cannot be at the Embedded World in Nürnberg next week, otherwise I would have asked them there.
      As to which IDE to use otherwise: There is an Eclipse version of IAR (see https://mcuoneclipse.com/2013/11/03/tutorial-replacing-iar-ew-with-eclipse-ide/), but I have not used that recently, but should still be a valid option. If you don’t want to use Eclipse, of course there is the Keil MDK. What you could use in any case is to install the Keil MDK (you don’t need to buy a license) and then use the CMSIS-Pack package manager: that way you get the packs independent of the IDE. Then use the pack files with your IAR. You won’t have the RTE (as shown in this post), but that might not be that much of a deal. And you can continue to use the IAR tools/compiler.
      I hope this helps,
      Erich

      Erich

      Like

      • Hi Erich,

        Thank you very much for your reply. I will explore the IAR plugin for eclipse option, I was using PE + IAR anyway so I guess this won’t be much of a change for me. Thank you again for your help and keep up with your blog, it is awesome.

        William

        Like

  11. What is the difference between creating the project as “CMSIS RTE” and creating the project with the “KSDK V2.0 project wizard”? I mean, what should I use?

    I’m just starting to work on this MCUs and I’m confused with all the ways a project can be created.

    I think it would be very beneficial if you could create a new post in the blog highlighting the differences.

    Thanks!

    Like

    • Hi Manuel,
      The CMSIS RTE project wizard is provided by ARM and is a wizard on its own. It creates CMSIS compliant projects using CMSIS-Pack using RTE. The KSDK v2.x project wizard creates NXP projects using the Kinetis SDK driver library.

      Like

  12. Hello Erich
    I was taking a look into the CMSIS-pack approach and I have a question. I was able to create the CMSIS RTE project but I see that there is no peripheral driver added and nowhere to add one right? I can only add the startup code, the CMSIS Core, and the CMSIS DSP.

    I was reading at the CMSIS website in the CMSIS-Driver documentation that the CMSIS-Driver specification is just a software API comprised just by header files. These header files are the reference for the implementation of the standardized peripheral driver interfaces and that these implementations are published typically in the Device Family Pack of a related microcontroller family under the Component Class CMSIS Driver.

    Then at the “Reference Implementation” in the same site I read that the CMSIS installation contain some implementation templates that have empty functions that match the API specification.

    This means that, for instance freescale (NXP) should provide the drivers implementation in such a way that can be used with this CMSIS-Driver API specification right?

    Or maybe at this stage of the project I should write my own CMSIS-Driver implementations based on the KSDK drivers to be able to use them with CMSIS-Driver API.

    Is this correct?

    Thanks!!

    Like

    • Hi Manuel,

      The CMSIS RTE is only a manager of CMSIS-Packs, regardless what is in the packs. And you see some CMSIS-Core and CMSIS-DSP because you have these packs installed on your machine.

      The CMSIS-Driver is an API, so you are correct, it provides the interface. The silicon vendors have to provide the driver implementation, and this is missing in this case. You are free to implement that, but I would think that’s not a simple task, depending on how many drivers you need.

      Erich

      Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s