Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Difficult to use nRF5x SDK from scratch!

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.

Parents
  • 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:

    Best regards,

    Simon

  • 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,..... 

  • 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.

    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

  • 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.

  • 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.  

Reply
  • 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.  

Children
Related