Do folks just develop inside the SDK itself?

RE: Do folks just develop inside the SDK itself?

Nguyen Hoan Hoang — Tue, 06 Feb 2018 18:32:34 GMT

Never recommended to work inside the SDK. I put all the third party SDK/Libraries in external folder. It's easier to maintain and change version as needed. This link show how I organize my stuff, see the readme.

RE: Do folks just develop inside the SDK itself?

SRA — Tue, 06 Feb 2018 16:49:21 GMT

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.

RE: Do folks just develop inside the SDK itself?

SRA — Tue, 06 Feb 2018 16:46:13 GMT

Yea, I'll start my master build from that. I'm not sure what Nordic was thinking when they remove things from a config header. It doesn't make things any easier. A master/common file would be a way better idea.

RE: Do folks just develop inside the SDK itself?

Richard D. — Tue, 06 Feb 2018 16:37:27 GMT

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.

RE: Do folks just develop inside the SDK itself?

tesc — Tue, 06 Feb 2018 16:16:23 GMT

There is a base sdk_config.h at "<sdk folder>/config/sdk_config.h", although I see that for SDK 14 that file is missing a number of defines. Hopefully that will be fixed before too long.

RE: Do folks just develop inside the SDK itself?

SRA — Tue, 06 Feb 2018 15:26:04 GMT

I just posted something similar last night.

No, I don’t recommend working right from the SDK. I consider the SDK to be read-only so I’m certain it never gets messed up. I don’t want to be in a UART example and make a change to a peripheral driver that another application will use later.

So more or less I put the SDK in a folder and put my application near that. I made a SoftDevice template with the things I know I’ll need for my real application and a barebones no-sd template for testing external software and peripherals. I must manually adjust the paths at the start of a new project.

A little tip if you are using Keil, the project files are .XML and you can very effectively use Find and Replace on path names.

See my other post devzone.nordicsemi.com/.../properly-update-nrf-sdk-to-14-2-in-keilv5

Oh and yes, the sdk_config.h is terrible. Nordic has a master file somewhere I’m sure but they knock it down for each example so instead of dealing with one large constant file, you need to go find the parts you’ll need and integrate them into your file. It’s REALLY DUMB. I’m considering just making a master file, esp because in Keil you get a graphical config window for it.

RE: Do folks just develop inside the SDK itself?

tesc — Tue, 06 Feb 2018 12:48:24 GMT

I usually keep projects inside the SDK, but instead of having my own projects in an "<sdk folder>/examples/xx" folder I create a new path of folders from the <sdk folder> so that the project can be put "on the same level" as the example projects. Then I copy an example project into that location and start from there. E.g. from "<sdk folder>/examples/ble_peripheral/ble_app_hrs" to "<sdk folder>/my projects/project name/ble_app_hrs", and then also change the folder name from "ble_app_hrs" to whatever makes sense.

Do note however that my use case is fairly uncommon. I often have to quickly set up projects that I get from others, and which are usually based on SDK examples. Or I have to quickly test something based off of an SDK example. I rarely have to set up a "real" project that is supposed to grow big and fill a particular purpose, and I rarely need to migrate to a new SDK version.

I would love to hear more about what other people do, when setting up a custom project and when porting an existing one from one SDK to another. I also appreciate any feedback on what can be improved in the SDK when it comes to setting up and porting your projects.

Regards,
Terje

RE: Do folks just develop inside the SDK itself?

Nguyen Hoan Hoang — Sun, 04 Feb 2018 20:21:07 GMT

hahaha! welcome to the SDK pain. It wasn't like that in the early days. Then it got worst and worst with every updates. Lately the worst of the worst was introduced: the famous sdk_config.h. You need to enable or add 3-5 defines for each module to get it compiled. Cheers!

RE: Do folks just develop inside the SDK itself?

Hein — Sun, 04 Feb 2018 19:15:40 GMT

I copy the 'components', 'config' and 'external' folders from the SDK to my blank project, the contain everything you might want to include from the SDK (still over 100MB)

Then I set up my development environment project by looking at the make files for the example. They show you all the compiler flags, included folders and source files you need to add.

If you wanted to, you could then go through the SDK folders and delete all the unused source code after you complete the project.