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.

[Simon]

I am sorry that you feel this way and I am thankful for the feedback. I will try to present to you my approach for developing a project and give a collection of links that may help you as well.

My approach:

• I always start with an existing project, most similar to the end goal and build on that
• I always use a BLE example (if your solution uses BLE, which I assume) as the base project and merge functionality from other projects into that. From my experience that is the easiest approach, not the other way around.
  • E.g. if I want to develop a solution with SPI and BLE, then I start with a BLE project (e.g. examples\ble_app_uart) and use an SPI example (e.g. examples\peripheral\spi) as a guideline of what to add into it
• Then I add the specific functions into the BLE example, for example, the function nrf_drv_spi_init(..) from examples\peripheral\spi.
• Then I go through these steps:
  • Put the function into main() and build the example
  • Get error messages
  • Go into main.c of examples\peripheral\spi right click on the function nrf_drv_spi_init(..) and go to the definition (source file) and declaration (header file) of the function
  • include the header file at the top of main.c of examples\ble_app_uart
  • Add the path of the header file as explained here and the source file as explained here into examples\ble_app_uart
  • Build the example (examples\ble_app_uart)
    • If no errors appear, you have successfully implemented the function
    • If an error appears, follow the steps below
  • Look into drivers/sub drivers, and check if the called function is grayed out, and check for the specific config that causes this (in examples\ble_app_uart)
  • Search for the config in the sdk_config.h of the SPI example (e.g. inside examples\peripheral\spi\pca10040\blank\config)
  • 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 - nrf_drv_spi - SPI/SPIM peripheral driver - legacy layer
        //==========================================================
        #ifndef SPI_ENABLED
        #define SPI_ENABLED 1
        #endif
• Repeat these steps for all the functions you wish to implement
  • Be aware that most of the other SPI functions will work fine after completing this once, and you don't need to do it again

Following this approach has worked fine for me, and I have never really had any problems merging two projects. If you encounter any specific problems, please create a Devzone ticket and explain it in detail, and someone will help you. I also recommend you to read this and this thread regarding NRFX vs. legacy configurations.

Some links you may find helpful:

• https://devzone.nordicsemi.com/f/nordic-q-a/30862/create-a-new-project-in-segger-embedded-stuido/129639#129639
• https://devzone.nordicsemi.com/f/nordic-q-a/28196/graduating-from-example-to-production-project-file-structure
• https://devzone.nordicsemi.com/f/nordic-q-a/39240/starting-a-new-project-from-scratch
• https://devzone.nordicsemi.com/f/nordic-q-a/20093/what-is-the-best-way-to-merge-two-existing-examples-with-segger-embedded-studio
• https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/merging-two-ble-examples-together
• https://devzone.nordicsemi.com/f/nordic-q-a/38054/how-to-combine-two-sdk_config-h-file
• https://www.youtube.com/watch?v=YZouRE_Ol8g&list=PLx_tBuQ_KSqGHmzdEL2GWEOeix-S5rgTV&index=1

Best regards,

Simon

[Mojo]

Thanks for the link.  Another how-to I'd like to see is how to eliminate sdk_config.h completely please and all other config.h as well nrfx, mesh,..... 

[Simon]

sgetz said:

I know the SDK can not be changed quickly, but please bring the concern to the right people in hopes an easier method is found in the future.

Do you have any specific suggestions on how to improve the nRF5 SDK? If so, I would appreciate if you could share it with us.

Mojo said:

Another how-to I'd like to see is how to eliminate sdk_config.h completely please and all other config.h as well nrfx, mesh

I think configurations can be quite useful when developing an application. It enables the developer to pick and choose specific features and libraries, and to configure the pins and parameters of a particluar peripheral (e.g. baudrate and CTS pin of the UART peripheral). I might be wrong, and it may exist other ways of doing it. Do you have any suggestions?

---

One of our newest products, the nRF9160, supports the nRF Connect SDK. This is a framework based on the Zephyr Project, and is quite different from the nRF5 SDK. Check out the nRF Connect SDK documentation for more information.

Best regards,

Simon

[RSA]

i Would say that thorough tutorials, about which elements need to be in a standard project, and when to change the cinfig.h (i know that the team is capable of this, since the BLE tutorials were pretty good.). IF i remember correctly it's rarely mentioned when you need to set a flag when reading in the infocenter. apart from that it's also often hard to figure out which headerfile to use when looking at functions. I always end up using Atom to search the directory.

After exploring the SDK for a while i notice alot of the things i spend time trying to figure out in the beginning, are written in the infocenter. Problem is that it's a labyrinth to navigate.

[Mojo]

It is not at all useful, instead it is a useless jungle.  The older SDK didn't have and it was super great and simple.  To configure a UART we just need to fill a config data structure with pins, baud rate and call init by passing it as parameter. The same for initializing the Softdevice, we can configure crystal/rc at will.  It was simple no mess and nothing was hardcoded. Since the introduction somewhere along the line of SDK10 I think, things got a lot messier with sdk_config.h, everything is hardcoded in it.  Due to that, it is not possible to compile the SDK into a lib and reuse in multiple projects. Now we have to add SDK source files to each project and every time we need to add one there is a min of 3  to 20 defines to add to the sdk_config.h.  The sdk_config.h ended up with over 300KB near 10000 lines of defines.  Isn't it ridiculous ? Thanks to the new scheme of the SDK I was able to teach the interns a great examples of what a bad programming practice is about.  

[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