Do folks just develop inside the SDK itself?

[Nick]

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

[Hein]

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.

[Nguyen Hoan Hoang]

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!

[tesc]

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

[SRA]

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.

[tesc]

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.