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

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

Children
Related