Difficult to use nRF5x SDK from scratch!

[sgetz]

Whose idea was it to make creating a new project from scratch so difficult (if not impossible)????

I have created numerous projects using the nRF5x, but have always used an example project as the starting point.  However, when I want to do something that is in 2 different example projects, I have had a lot of trouble combining them.  And starting from scratch is impossible.  I am using it with IAR.

Why:

1. Mainly because of the sdk_config.h.  Trying to figure out what to enable or disable is very difficult.  Just for the UART/UARTE there are numerous enables.  All the color stuff makes no sense.  I never was able to make use of colors.

2. In order to move a project to a different directory either requires the entire sdk be brought with it, or redefining 1000's of includes paths in IAR's preprocessor options.  This is ridiculous.

3. There are a bunch of Define Symbols in IAR that don't make sense.  Having to recreate this for a scratch project is ridiculous.

4. TI does the above also, and I stopped using their sdk.

5. I have worked with numerous large software development companies that have written nRF5x projects.  They have all used example projects to get started because they say they can't figure it out either.

The API docs are OK, allowing me to do an include and start using the sdk calls, they are OK.  But having to read 25 documents and take 3 classes to create a scratch built project enviroment is not acceptable.

[Nguyen Hoan Hoang]

I second Mojo on that and also add this.  The much older SDK has all the includes files in 1 place with few folders underneath for grouping.  It was supper easy to add includes path.  Now it is all over the places and have to search for them and add a bunch of paths.  This is also bad programming practice as well.

[Billy-IV]

Simon,

I am relatively new to developing with Nordic Semiconductor.  Therefore, I cannot reference early SDK versions.  As such I have the perspective of someone who is constantly trying to learn from scratch how the SDK works and how to get the stack and hardware to do what I need it to do. In this process I have found a number of things difficult when using the NRF5 and the NRF Mesh SDK's.  

First, the documentation of lower layers and configuration files lack all the needed information to quickly use them.  Often comments for variables, type def's, and functions say "X is X."  The infocenter usually says the same thing as in the code. Therefore, connections between different configure variables are not apparent.  For instance, my colleague set the max value for an element but did not realize that there was a max value for the whole node as well.  When provisioning the node failed he spent nearly a week troubleshooting the provisioner and element instances.  It's instances like this that reveal the weak points in the documentation.

The config.h file is exceptionally long as previously mentioned. The steps provided by Simon see quote can be quite labor intensive, and speaks to the reality that there is not an easy way to start a project from scratch without having to use an example as a base.  Finally, I am not sure if I saw any explanation of the <e> to </e> before reading this post.

Simon said:

• Look into drivers/sub drivers, ...
• Search for the config in the sdk_config.h of ...
• Copy this config, and the associated configs into the sdk_config.h file of the ble_app_uart project
  • E.g. if SPI_ENABLED is the config you are looking for, then include all the configs that are "caught" between <e> and  </e> 
    • // <e> SPI_ENABLED ...
      

To address my statement of bloat within the code, I use abstraction to make development easier and so does the SDK code.  However, there are points that have unnecessary levels of abstraction.  There are declarations like this "typedef struct __generic_onoff_server_t generic_onoff_server_t;" where the __generic_onoff_server_t is only used to define generic_onoff_server_t.  It is a typedef that just references a different typedef.  These are all over the place function definitions that only reference other function definitions.  This makes it difficult to track what is happening or what is defined as what when diving into the code.  I do not understand why this is being done.  It adds extra lines of code and hurts the readability of the code.

Respectfully,
Billy Ivy

[Simon]

Thanks for the feedback from everybody, it is appreciated. I will get in touch with the developers responsible for creating the nRF5 SDK, who also has more insight about this.

Best regards,

Simon

[Duy]

I created a base project from scratch and I store it in the master branch of gitlab, whenever I have new project, I will create a new branch from master. If you want the use it, I can share the gitlab repository with you, it is already be updated to 16.0.0 There are both advantages and disadvantages of creating a project from scratch:

Advantages:

1. You will understand the SDK + peripehral better and deeper.

2. You can manage and develope your programme better.

3. You learn to be more patient.

4. Your reading skill and coding management skill is improved.

Disadvantages:

1. Time consuming.

2. Hard to start for a newbie. I started using Nordic in July 2017 when I was a senior year student working on my thesis and I almost went crazy. But now I love Nordic Semi.

3. You gonna go crazy when there is a new update comming.

Just a small sharing with you. Hope you enjoy it.

Best regards,

    Duy

[sgetz]

I would be interested in you "base project".

Recently, I have been writing my own simplified version of many of the libraries to avoid using the overly complex ones in the SDK.  For instance, I can turn on the LFCLK and configure it with a few register writes.  The SDK way involves multiple libraries and effect a number of other things that are not known unless you reverse engineer the SDK.

The libraries provided by mBed and Arduino may not cover everything, but they are infinitely easier to use and configure!