Difficult to use nRF5x SDK from scratch!

RE: Difficult to use nRF5x SDK from scratch!

Simon — Sun, 24 May 2020 22:05:25 GMT

Thank you for the feedback. I have forwarded this ticket internally and hopefully we can use the feedback from you and the others to improve the nRF5 SDK.

Best regards,

Simon

RE: Difficult to use nRF5x SDK from scratch!

tim.hsu — Wed, 06 May 2020 06:09:00 GMT

Nguyen Hoan Hoang

As a experienced C++ developer, I can't stand myself using example project as starting point. Most SDK examples are not minimal, they use their higher level abstraction with app library. Many components uses app library. Final binary are bloated.

Yes, you don't have to change your makefile even it is compiling unused component. The evil sdk_config look fine at first, but it limits you from every customization. sdk_config is like a second build system inside GNU make. It will change the compiled logic in the SDK and your program. A single line of change in sdk_config.h will cause complete rebuild of whole project.

- "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?"

Pin configuration is okay, but we seldom use old project as starting point because they are too different. Sdk_config really has too many fatal drawback. And there indeed exists other solution, cmake. What should I turn on when enabling a UART? Which lines should I change when I want to use hfclk? The fastest way currently is googling instead of reading document...

There are too many multi line macro of macro that I should rely on good InteliSense system. I found some macro even insert a new section in silence(NRF_SDH_BLE_OBSERVER). It's not suppose to be used twice (even the function is not called.)

void BLE::services_init()
{
    // ...
    NRF_SDH_BLE_OBSERVER(m_qwr_obs, NRF_BLE_QWR_BLE_OBSERVER_PRIO, nullptr, &m_qwr);
    
}

void BLE::services_init2_notcalled()
{
    // ....
    NRF_SDH_BLE_OBSERVER(m_qwr_obs, NRF_BLE_QWR_BLE_OBSERVER_PRIO, nullptr, &m_qwr);
    
}

Writing a custom linker script is hard too. There are too many pre-defined symbol secretly used by SDK. I have two chips on my board. The bootloader example is pretty much useless too.

At first glance, I think SoftDevice occupying my 0x0 address is rude. But the experience of using sdk is even worse. I'd rather it behave like SoftDevice, a standalone library.

RE: Difficult to use nRF5x SDK from scratch!

jcondon — Thu, 13 Feb 2020 04:50:48 GMT

A couple tips to make the SDK better:

1) Use relative path structures for includes (e.g. #include "/components/ble/nrf_ble_gatt.h"). This way developers only need to include the base path in their project and not dozens.

2) Avoid preprocessor definitions buried in project definitions. This obfuscates functionality and makes setup difficult

3) Avoid multi-layer macros. For example, the NRF_SDH_STATE_OBSERVER could be replaced by allowing the user to register a function pointer during boot.

4) Limit/Avoid the huge multi-layer structures of structures of structures.

5) Update ALL examples and tutorials to use the latest, best practices when a new SDK is released e.g. v15->v16) and then test them. Yea, it's a lot of work, but so is digging through broken example code.

6) Include explicit examples of "best practices" for functionality not things buried in other examples. I shouldn't have to figure out that the hrs example handles advertising in a different way than the uart example.

Bonus Points: It's 2020. Release a C++ based SDK! It can create a clean, type-safe, well defined interface. Rather than littered globals, make private members. Rather than #defines, use const and constexpr. Hide members as private and provide clearly defined methods to initialize, set, and get the object.

RE: Difficult to use nRF5x SDK from scratch!

jcondon — Thu, 13 Feb 2020 04:27:31 GMT

100% Agree. I have worked with many SDKs from various manufacturers and this is close to the worst.

RE: Difficult to use nRF5x SDK from scratch!

Steven — Fri, 24 Jan 2020 14:12:52 GMT

Thanks both, will read and reflect :o)

RE: Difficult to use nRF5x SDK from scratch!

Nguyen Hoan Hoang — Fri, 24 Jan 2020 13:53:50 GMT

That is how this library https://github.com/IOsonata/IOsonata is implemented. No hardcoded compilation define, such thing as sdk_config. Although documentation are not yet avail. The code are self-explanatory and simple to use. See Blog how to write BLE firmware in a few lines of code

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/writing-ble-firmware-with-a-few-lines-of-code-part

many peripheral examples :

https://github.com/IOsonata/IOsonata/tree/master/exemples

BLE examples :

https://github.com/IOsonata/IOsonata/tree/master/ARM/Nordic/exemples

To use periph simply file out the config data structure with the pins to se, rate,.. Call Init function with it to initialize. Then use Tx/Rx ... No hassle.

Writing BLE firmware is the same configuration data structure to set service/chrac, ble type and call Init. Then just handle event callbacks. See blogs https://embeddedsoftdev.blogspot.com/2018/02/bluetooth-le-with-nordic-nrf51-nrf52.html

RE: Difficult to use nRF5x SDK from scratch!

Simon — Fri, 24 Jan 2020 13:33:36 GMT

Here are some snippets that might be of interest: https://github.com/andenore/NordicSnippets. It includes a set of examples showing how to use the different peripherals, using the registers directly and without any layers of abstractions.

Best regards,

Simon

RE: Difficult to use nRF5x SDK from scratch!

Steven — Fri, 24 Jan 2020 13:01:20 GMT

Agree completely with this. The SDK is a bloated mess, too many layers of abstraction. What I want from Nordic:

1. Driver files for each peripheral type eg adc, uart, i2c, spi, gpio, timers, counters etc. Helper functions/macros to initialise/configure the peripheral and read/write, enable/disable each. At a level that I can plainly follow the hardware datasheet and see the relationship between the code and the hardware, poke and prod and play around until I can get to grips with how it works.

2. I want to bring up custom hardware from scratch to basic functionality (eg GPIO configured, UART active) in 30 minutes. I am talking a basic blinky, "hello world" level of operation where I can validate that the hardware works/doesn't smoke.

3. I want to be able to add the features I need by doing a #include to ONE FILE for EACH feature/peripheral. No massively complex interdependencies with 13000 lines of macros just to setup a project.

4. I want to be able to bring up/code each peripheral in stages. So I can test each part of the board in isolation. Incremental development.

5. RTOS features to be OPTIONAL and MINIMAL, easily explained and understood and well documented with comprehensive examples. Often I don't need these features at all - a simple state machine is adequate. If I do I want RTOS features I want them to be simple and relate-able. INTERRUPT>EVENT>QUEUE>HANDLER>CALLBACK is sufficient.

6. I want to be able to sit and write code, to be creative, develop solutions and not spend all my time reading through pages and pages of documents just to get started. At present the sdk requires too much mental overhead and this I am sure makes for less reliable solutions.I have been working with the nrf52832 for 18 months now, with the sdk, mbed and now zephyr and all of these just feel brittle, with simple features (power management) not working predictably. I am convinced that it is because of the weakness of the sdk.

Rant over ;o)

RE: Difficult to use nRF5x SDK from scratch!

sgetz — Tue, 19 Nov 2019 18:10:39 GMT

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!

RE: Difficult to use nRF5x SDK from scratch!

Duy — Tue, 19 Nov 2019 17:45:34 GMT

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

RE: Difficult to use nRF5x SDK from scratch!

Simon — Tue, 12 Nov 2019 22:45:01 GMT

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

RE: Difficult to use nRF5x SDK from scratch!

Billy-IV — Tue, 12 Nov 2019 17:26:37 GMT

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.

[quote userid="72692" url="~/f/nordic-q-a/54157/difficult-to-use-nrf5x-sdk-from-scratch/219370"]

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

[/quote]

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

RE: Difficult to use nRF5x SDK from scratch!

Nguyen Hoan Hoang — Tue, 12 Nov 2019 16:29:25 GMT

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.

RE: Difficult to use nRF5x SDK from scratch!

Mojo — Tue, 12 Nov 2019 15:56:17 GMT

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.

RE: Difficult to use nRF5x SDK from scratch!

RSA — Tue, 12 Nov 2019 13:18:24 GMT

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.

RE: Difficult to use nRF5x SDK from scratch!

Simon — Tue, 12 Nov 2019 11:41:39 GMT

[quote userid="14934" url="~/f/nordic-q-a/54157/difficult-to-use-nrf5x-sdk-from-scratch/219516"]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.[/quote]

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.

[quote userid="74486" url="~/f/nordic-q-a/54157/difficult-to-use-nrf5x-sdk-from-scratch/219536"]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[/quote]

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

RE: Difficult to use nRF5x SDK from scratch!

Mojo — Mon, 11 Nov 2019 17:45:11 GMT

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

RE: Difficult to use nRF5x SDK from scratch!

sgetz — Mon, 11 Nov 2019 14:56:07 GMT

Thanks Simon. That is what I was attempting to do. Had some problems and got frustrated. I will check out the links you provided. I appreciate your help. 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. Thanks.

RE: Difficult to use nRF5x SDK from scratch!

Simon — Sun, 10 Nov 2019 22:15:37 GMT

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

RE: Difficult to use nRF5x SDK from scratch!

Nguyen Hoan Hoang — Thu, 07 Nov 2019 23:47:21 GMT

Yeah, the sdk_config jungle is absolutely ridiculous. Thousands of compilation definitions. Min of 3 per file to compile,

I use Eclipse with this library which bypass the low level driver and most of the sdk_config.h stuff. Creating new project with Eclipse is also pretty easy. The library also supports IAR.

https://github.com/IOsonata/IOsonata

RE: Difficult to use nRF5x SDK from scratch!

sgetz — Thu, 07 Nov 2019 22:03:12 GMT

I have only been able to do 1 simple one. I tried a complex one and gave up.

The only hints I can give are that the examples use an abbreviated sdk_config.h file. Using that wil not allow you to select peripherals that are not used in the example. However, there a full generic sdk_config.h for each chip under config/nrf52832/config. (pick the appropriate processor). That is suppose to have all the peripherals in it. You go in and enable periphs. (There is a java tool in external_tools/cmsisconfig/CMSIS_Configurations_Wizard.jar that helps a little. But you still need to know the names of the various thing you are enabling. (Not always easy) Also, the full generic config seems to lack certain things in the example configs. So when I tried to use the full config for an example project, I still could not get it going sometimes.

I edited the include path list in IAR->Options->preprocessor. But it takes a long time, and that assumes you understand all the includes needed for what you are doing.

Hope that helps, but I am still wandering in the wilderness too.

RE: Difficult to use nRF5x SDK from scratch!

Billy-IV — Thu, 07 Nov 2019 21:49:10 GMT

I agree the SDK examples are bloated. There are often layers of abstraction that are completely unnecessary. My team has based several aspects on example code only to spend exorbitant amounts of time after we truly understand how it works to write the code more simply. As a question to sgetz it seems as if you have figure out how to setup a project from scratch. Could you point me in the direction of th 25 documents and 3 classes?

RE: Difficult to use nRF5x SDK from scratch!

lobaro-theo — Thu, 07 Nov 2019 20:49:45 GMT

Agree in most points.

I was scared after creating a project from zero just using the softdevice calls how few pieces of software are actually needed to get a simple ble uart runnning...the sdk examples seemed very bloated to me, too.