Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Do folks just develop inside the SDK itself?

I've been playing around with the SDK these past few days using both Keil and ARM GCC options. 

When people develop a product using this SDK, do they just clone one of the examples, keeping it inside the examples/xx directory and then develop directly inside the SDK?  It feels like with the way the SDK is laid out, references all over the place, creating a blank solution outside of the SDK examples directory leads to a lot of frustration.  

Is there a clean way to create a project outside of the SDK that references includes and libraries?  The Espressif IoT Development Framework (ESP IDF) does this beautifully with just a couple environment variables.

Nick

Parents
  • Our projects are kept outside the SDK because it provides a clear separation between our code and Nordic's code.
    - makes source control easier to keep Nordic code out of our SCM
    - clear separation makes it easier for the lawyers
    - our own code doesn't move when we update to a new SDK

    In creating one's own application outside the SDK, it seems logical to use one of the SDK examples as a starting point. The biggest problem with this approach is that the example project files reference SDK with relative paths; i.e. project files assume that application code is in the same directory as the SDK. I found the easiest way to fix the project files was to edit them manually with a text editor ; a real nuisance, but only has to be done once.

  • Pretty much my point too.

    I had an issue where I had an outside contractor set up our first Nordic product. He gave me code that worked but it was rooted inside an SDK example for some reason. It made sharing around to my team annoying because everyone had to make their directory structure match.

    Now I have it in a separate folder included in my GIT repo for this project. Now if I need him to log on or my at a different machine or a team member, just clone the repo and start working. I can check to make sure the SDK files aren't changed. And I could roll us up to a new SDK version, get it working, and everyone would also be automatically upgraded at next pull.

    Working inside the SDK could be the same effect, but it doesn't look good and isn't obvious.

Reply
  • Pretty much my point too.

    I had an issue where I had an outside contractor set up our first Nordic product. He gave me code that worked but it was rooted inside an SDK example for some reason. It made sharing around to my team annoying because everyone had to make their directory structure match.

    Now I have it in a separate folder included in my GIT repo for this project. Now if I need him to log on or my at a different machine or a team member, just clone the repo and start working. I can check to make sure the SDK files aren't changed. And I could roll us up to a new SDK version, get it working, and everyone would also be automatically upgraded at next pull.

    Working inside the SDK could be the same effect, but it doesn't look good and isn't obvious.

Children
Related