Best Practices for Starting a New Project in SES Based on Example Application

[kw_martin]

I am about to start a new project for the nRF52840DK using SES in Ubuntu 18.04. I would like to start with an existing application but I don't want to change the original example application that comes with SES in case I get things wrong and need to start a second time. I have been reading the chapter in the SES manual on projects, but it is not clear to me what best practices are:

1) I am guessing I need to start a new "Workspace", and copy an existing example into this workspace. Is there a recommended location relative to $(StudioDir) that this new workspace should be located (aside: where is $(StudioDir) defined? I can't find it in Tools->Options or Project->ContxtMnu->Options). The PrjName.emProject files all use relative addressing for everything needed to build the project. Such as:

      c_user_include_directories="../../../config;../../../../../../components;../../../../../../components/ble/ble_advertising;../../../../../../components/ble/ble_dtm;../../../../../../components/ble/ble_racp;../../../../../../components/ble/ble_services/ble_ancs_c;../../../../../../components/ble/ble_services/ble_ans_c;../../../../../../components/ble/ble_services/ble_bas;../../../../../../components/ble/ble_services/ble_bas_c;../../../../../../components/ble/ble_services/

... for many many lines

Do we need to modify all of these by hand using an editor, or is there some automated way we can copy an example project to a new Workspace, and have the PrjName.emProject file updated automatically? Should we place the new workspace somewhere in $(StudioDir) to make this process easier?

My previous experience had under the File menu, a choice "New->Project->From Existing Project" choice that looked after almost all of the necessary changes of the configuration files. Does SES have something like this? Or is there a recommended best practices way to simplify this task? Sort of related, is there an automated way of making the PrjName.emProject file based on a template, and say a value for $(StudioDir) that will look after most of the boiler plate, compilation flags, etc.?

Finally, is there a link to a tutorial that starts a new project based on an existing project, or should I write one (I need it for future projects for student groups).

[Vidar Berg]

Hello,

It seems like the most commonly used approach is to make a copy of the example project and simply keep it in the same SDK directory as the original one. But as I've tried to illustrate by the screenshots below,  it's possible with relatively few steps to move an example outside of the SDK tree if you can edit the xml formatted project file with a text editor that supports "search&replace".

Moving SDK example to a different location.

1. Pick an example project that best fits the requirements and copy it to your workspace.

2. Open project files you just copied in SES and add a new project macro that points to your SDK copy. To make sure the setting is applied globally for all configurations, open the project settings at the top level ('Solution') and add the macro under the 'Common' configuration. 

3. Now we can replace the relative source paths with the macro we added in step 2.

4. That's it. Now you only need to update the SDK_ROOT macro if you want to move the project.

Example:

workspace.zip

Should we place the new workspace somewhere in $(StudioDir) to make this process easier?

StudiDir can be used if you want to add source files that have been installed through the package Manager in SES.

[kw_martin]

Vidar, thank you; I will give this a try. It is very difficult for me to see the details of the embedded pictures on my machine (my eyesight is not great). I'm guessing, I download the attached zip file, unzip, and add it as a global macro in step 2; I can't make out exactly where to add it from the picture, but I think I might be able to figure it out from the text. Regarding step 3, again I can't make out the details, but I'm guessing the window that is opened is a search and replace window. I'm not used to using a "macro" in a search and replace window; I'm guessing this might be an option specific to SES? Anyways, I will give it a try. Your e-mail has been useful in telling me: 1) there is no automated way, but by: 2) carefully choosing where to copy a project to, and 3) using some of the existing tools with the down-loaded macron, it shouldn't be too difficult.

[Vidar Berg]

kw_martin said:

Anyways, thank you for your help. Due to my inexperience, I can not follow your directions, but I think that just by copying to the carefully chosen location that didn't break relative paths, I can continue on.

It should be correct as long as you don't get any build errors. You don't have to use the project macro as I suggested, I guess my main point was that it can be both quick and easy to update source and include paths if you work directly with the project file in a code editor rather than doing it manually in SES.

Attached below are the screenshots I took earlier in a .zip file in case you're interested. Hopefully they are easier to read.

screenshots.zip

[kw_martin]

Thank you Vidar, being able to see the screen shots made all the difference. I now realize that the "Macro" was simply setting a value for the environment variable SDK_ROOT which could then be used in the search and replace window. For some reason, clicking on the screen shots did not enlarge them previously, it does now and it makes it completely clear.

[Vidar Berg]

Thanks for the update. Glad to hear that it worked.

[Don]

Hi,

Unless I missed something, this leaves you still pointed at all the original source code.  If you need to edit something in the example, say main.c or sdk_config.h, you would be editing the original example source files in the SDK.

Now if you want to back up your work, you need to back up these files, which may be scattered throughout the SDK.  Unless you have better tools than I do, you now need to back up the entire SDK folder.  Not only that, but now the SDK isn't pristine for the next project (or programmer).

My philosophy has been that to back up the project, should require 3 pieces: the compiler, the SDK, and the project.  In this case I would archive the SES installer, which as I recall includes the gcc compiler I'm using. Since the project directory is small relative to the other two, it is much easier to back up regularly.  The compiler and SDK only need to be backed up once not only for this project, but for all others that use the same versions.

This requires that any file you EVER edit gets put in the project directory, and should be referenced relative to the project directory.  In the example above, I would copy main.c and sdk_config.h from the SDK to the project directory, re-reference them in the project, then commence editing.

This way, after I retire and my computer is destroyed in a freak accident, the only things needed to resurrect the project are the 3 archived parts, and the only configuration that needs to be done is to tell the project where the SDK and the compiler are located on the new computer.  In other IDE's I've used this is easy, but appears a bit more work in SES.

Does this make sense, or am I (being new to SES) missing something vital to the structure?

[Vidar Berg]

Hi,

With the approach I tried to describe above, main.c and sdk_config.h will both be kept in the project directory outside of the SDK tree. Maybe I am missing something, but it seems to me like we have the same idea of how it should be done.

Don said:

Now if you want to back up your work, you need to back up these files, which may be scattered throughout the SDK.  Unless you have better tools than I do, you now need to back up the entire SDK folder.  Not only that, but now the SDK isn't pristine for the next project (or programmer).

If there other SDK source files you need to modify, then you can make a copy of those and import them to your project directory, instead of altering the sources in the original SDK.

Don said:

My philosophy has been that to back up the project, should require 3 pieces: the compiler, the SDK, and the project.  In this case I would archive the SES installer, which as I recall includes the gcc compiler I'm using. Since the project directory is small relative to the other two, it is much easier to back up regularly.  The compiler and SDK only need to be backed up once not only for this project, but for all others that use the same versions.

I agree with this approach. And I can confirm that SES uses GCC.

Don said:

This requires that any file you EVER edit gets put in the project directory, and should be referenced relative to the project directory.  In the example above, I would copy main.c and sdk_config.h from the SDK to the project directory, re-reference them in the project, then commence editing.

Yes, but usually you don't have to edit SDK sources (?), and if you do, you can import them to your project first.

Don said:

In other IDE's I've used this is easy, but appears a bit more work in SES.

I think this may have more to do with how we set up our projects and the way our SDK is structured. We support Keil uvision and IAR as well, but they are set up in the same way.

[Don]

Thanks.  Glad to hear we're on the same page.  I managed to copy the example project and getting it to compile!