Recommended
Related

Deprecating support for CMSIS Pack in nRF5 SDK

Pär H

Some news I wanted to highlight from the SDK team.

What

With the release of nRF51 SDK v7.0.1 in Oct 2014, we introduced support for CMSIS pack. The main motivation was to have an easy to use dependency manager, which defines an open standard defined and driven by KEIL/ ARM. With the release of nRF5 SDK v11.0, we have decided to deprecate support for CMSIS-Pack.

Why

As we were early in the game, we had to accept some initial issues with the setup. Now, one year later, we are in a situation where SDK users that have started with CMSIS-Pack are still reporting issues. We see various issues reported, both for users in development phase and in/ or while updating to a newer version of the SDK. Actually, the feedback is that CMSIS-Pack cause more pain than pleasure to you as users. Most customers report that all issues are gone after migrating to *.zip-based SDK setup. Some of the root causes of the problems are out of our control, and we do not see these being fixed in short time. With this in mind, we have decided to stop supporting CMSIS-Pack in nRF5 SDK’s.

Now what

Customers using CMSIS-Pack should move to *.zip-based SDK releases. Don’t hesitate to contact technical support if you need help to migrate from CMSIS to .zip-based release. Feel free to share your experience on dev-zone as well. We at Nordic SDK team cannot wait to show you our plans for upcoming releases, and are at the same time understanding and humble for the inconvenience caused.

  • I am a long time Embedded C programmer however I'm New to Nordic. The Nordic Nrf52 Hardware solution was so far ahead of other options that I felt I needed to use the Nordic Nrf52 as the base for this new BLE project. However my initial evaluation of the Keil software was when Nordic was using the CMSIS packs (Version 11.x) the demo went really smoothly I was able to clone the keyboard example add/remove some peripherals and compile the project with the changes. so I was very confident that the Dev environment was similar to what I was used to. I purchased the Keil software and started the hardware design. In June of this year I started the software having the hardware prototypes done and tested. But I was very disappointed that CMSIS packs where not supported anymore. It may not be a big deal for someone seasoned in Nordic Nrf52 but for me on my first project it has left me with a development environment that is Killing me with a huge learning curve this solution does nothing to help be integrate new peripherals I must learn every detail about each module to do the very smallest thing its tedious to me and not a good uese of my time. In My view what you have here is worse than what I started on in the 1980 at least in the 1982 they used environment variables to set path definitions to all common headers and libs so you did not need to know or ever edit the paths except maybe to add new libaries. The rigid Path structures as found in this ZIP Version of the sdk is fine for running an example but falls flat on its face when you want to clone an example to your on project working directory. Moving an Example project to a development folder creates a complete disaster. as all the sources have relative addresses to the libraries/headers making every include in the project a likely compile error needing to be tweaked. if I had known this is what you were going to do I would not have designed with Nordic no matter how efficient your hardware design is. Anyway I am stuck at this point I have working hardware and a spent hardware budget. The software has become a major expense both time and $$$ to me that I was not expecting. I would would like to see you guys bring back the CMSIS Packs at the very least until you come up with a reasonably comparable Alternative.
    something that at least does project cloning without tons of massaging of the code. and it would be nice if there was a simple way to add/remove/configure peripherals. Maybe this is too much to ask but it is pretty much the norm these days for a dev enviroment and it is what makes development faster and less error prone especial if you are talking about someone like me who is trying to tackle their first Nrf52 project.

  • I'm a little disappointed at this as well and would like to see them come back. But at the same time I do understand that if there are issues really outside of your control that's another matter.

    I'd rather have more frequent SDK updates over CMSIS packs - but ideally we would have both.

  • Par H i found one solution for coverting 51422 project to 51822.