Deprecating support for CMSIS Pack in nRF5 SDK

RE: Deprecating support for CMSIS Pack in nRF5 SDK

JanKap — Tue, 14 Jan 2025 15:52:40 GMT

I am highly confused. All major silicon vendors adapted to CMSIS-pack (because it really makes sense) and Nordic is ditching it and instead of offering a ready-to-use solution for package management you're offering a zip file? Is this information still correct?

How to do configuration management with your SDKs? I'm completely migrating to CMSIS-Toolbox for various projects (ST, NXP), but Nordic can't.

Is this still accurate in 2025?
Thanks.

RE: Deprecating support for CMSIS Pack in nRF5 SDK

Steph van Schalkwyk — Sat, 10 Feb 2018 00:09:34 GMT

is a nightmare for users new to your API.

RE: Deprecating support for CMSIS Pack in nRF5 SDK

Steph van Schalkwyk — Sat, 10 Feb 2018 00:09:17 GMT

Definitely a step backward.

RE: Deprecating support for CMSIS Pack in nRF5 SDK

Herb W. — Fri, 15 Sep 2017 03:47:25 GMT

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.

RE: Deprecating support for CMSIS Pack in nRF5 SDK

SRA — Fri, 20 May 2016 22:46:21 GMT

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.

RE: Deprecating support for CMSIS Pack in nRF5 SDK

jayesh — Wed, 06 Apr 2016 09:35:23 GMT

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

RE: Deprecating support for CMSIS Pack in nRF5 SDK

Pär H — Tue, 05 Apr 2016 06:27:39 GMT

Jayesh, if you have not. Post your question in the forum!

RE: Deprecating support for CMSIS Pack in nRF5 SDK

jayesh — Tue, 29 Mar 2016 10:22:07 GMT

In Keil 5 environment packs why cant i find any Template example for nRF51822 series or is their any way where i can migrate from 51422 to 51822

RE: Deprecating support for CMSIS Pack in nRF5 SDK

ddkumar — Sat, 19 Mar 2016 17:55:37 GMT

This is disappointing news. I agree with the previous response that, despite the issues, there were still version control benefits to using the packs. Is this decision limited to the SDK or all pack usage? Specifically, will the ARM Devices Family Pack still be supported? Nordic seems to moving away from supporting CMSIS standards. The device drivers do not even attempt to emulate the API syntax of the CMSIS-Driver specification, which makes it a hassle to integrate with Keil/ARM Middleware.

RE: Deprecating support for CMSIS Pack in nRF5 SDK

Pär H — Fri, 18 Mar 2016 19:33:09 GMT

Yes, that is what we previously have done. This is not a "forever" decision...we are always looking to improve the ease of use of our products.

RE: Deprecating support for CMSIS Pack in nRF5 SDK

Tien — Fri, 18 Mar 2016 10:20:57 GMT

I understand the reason you said, but you have alternative choice to release two formats.

Just like before, one for the users who need CMSIS-PACK and the other for ZIP-PACK users.

Is it right?

RE: Deprecating support for CMSIS Pack in nRF5 SDK

Pär H — Fri, 18 Mar 2016 08:20:12 GMT

Thanks for the feedback!

RE: Deprecating support for CMSIS Pack in nRF5 SDK

syntroniks — Thu, 17 Mar 2016 15:13:13 GMT

I actually liked the CMSIS packs and felt it lent additional value to both the SDK and the Keil IDE.

Yes, I did experience minor issues, but they were workable. Either way, that is in the past now. Thanks for the reasoning behind your decision.