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]

Maybe you did it already, but you should be able to zoom in on the pictures if you click on them?

kw_martin said:

again I can't make out the details, but I'm guessing the window that is opened is a search and replace window

Correct. It's taken from the Notepad++ editor which I don't think is available on Linux. But most code editor should support this.

Let me know if you are not able to zoom in on the pictures. Then I can make new ones an upload them in a zip file instead.

[kw_martin]

Got stuck before I got going at 2)

"Open project files you just copied in SES and add a new project macro that points to your SDK copy. "

I don't know how to "add a new project macro". Is this a macro that makes a new project.

I went back to the user manual for Segger Embedded Studio and on pg 88 under Project Macros is :

Project macros
To define a project macro:
To set the project macros:
1. Select the appropriate solution/project in the Project Explorer.
2. Use Project > Options to show the project options dialog.
3. In the Project Options dialog's General Options group, select the Macros option.
4. Click the ellipsis button on the right.
5. Set the macro using the syntax name = replacement text.

I selected the Solution line of my copied solution/project, then under the Menu Project, I selected Options. I was careful in the upper left where the configurations can be chosen to select : Private Configurations: Common. I can see on the left a line with General, and when I click that, I can see (I tried pasting in a screen shot; didn't work):

General

    Environment Variables                                                 ...

I think I can use this to add an environment variable which I'm guessing is what you are instructing when you say "add a new project macro that points to your SDK copy". Is an environment variable a macro? I'm guessing yes. But I don't know the name I should choose for the environment variable and do I point it at my new copied project or the original place I copied it from, and I don't know how to use it. When I figure all this out, I really think I will need to write a Getting Started Guide.

Still, I have my SDK in .../SDK. Under SDK, I made a new directory called Workspace. Under this I put a new directory called ble_peripheral/. In this directory, I copied the original project (ble_app_blinky). I then changed everywhere the original project name was to ble_blink_pca10056_s140... including in the project file.

This leaves all the relative paths in the project file (now called ble_blink_pca10056_s140.emProject) pointing to same location and I can successfully build the project. This gives me a copy I can start to modify. I also found that I think I can see the settings for all of the Segger Environment Variables (again, are these also called macros?) by  right-click solutions line, choosing Options, and then under Code->Build left-click in the line called Project Directory, and then left click on the three dots that appear, and then in the window that pops up, left-click on the round circle at the right of where it says Macros (I really wish I could copy in a screen shot). This might be useful in the future.

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.

[kw_martin]

P.S. the workspace.zip file contained a complete SDK hierarchy; I think this is the same as what I already have and I'm not sure if I should replace my current SDK; for now, I'm assuming I don't need the new downloaded SDK.

[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!