How is NCS better than SDK17?

[myself]

Hi sir,

  I would like to know the advantages of NCS to illustrate customer adoption NCS.

  Thank you and best regards.

[daviddedwin]

It appears less risky to me to use the nRF5 SDK for the nRF52 series and these are my comments on it.

If the customer's needs are satisfied by the nRF5 SDK I would stick to the nRF5 SDK. (No, the nRF5 SDK is not deprecated). If I am using the nRF53 then NCS is the only choice.

The nRF5 SDK has been built over the years and has had multiple interoperability issues that have been solved for older iOS, Androids and other vendors, it has a degree of robsutness to handle older OSes.
Test coverage for the nRF5 SDK is far more as it has been developed and tested over almost 8 years as compared to the fledgling NCS.It appears more risky for me to use the NCS for nRF52 as compared to nRF5 SDK at this point.

I expect that eventually as more and more engineering effort is expended on NCS it will slowly get to a usable point on the nRF52 series.

[Nguyen Hoan Hoang]

I lost 2 big customers on the nRF9160 because they don't like NCS. They went with competitor for freedom of choice.  Leveraging existing code is one major decision choice.  So in fact it is Nordic that actually lost them.  They produced 100K units with Nordic competitor.

[niebert]

What exactly do you mean by "no freedom"?

[Nguyen Hoan Hoang]

Freedom means that you can use whatever IDE you want, compiler you want, any RTOS you want, bare metal or with RTOS, works with C++, easily integrated with or existing code base, any CMSIS-DAP compatible JTAG.  No freedom means you can't do the above.  With NCS, you're stuck with zephyr, you're stuck with SES, you're stuck with JLink, no C++ support, can't integrate with your existing code base.  So do you have any freedom ? 

[niebert]

NCS uses ZEPHYR allright, so you cannot use other RTOSes. But then, what did you have in mind and in which way would it be superiour to Zephyr? I have never seen an open source RTOS for microcontrollers that is so complete. That is the whole point of Zephyr. You would not say something similar of Linux.

But you are mistaken in several points and that may be due to Nordic communication:

- You are NOT stuck with SES. You can in fact use any IDE that understands well enough CMake. I for one am a happy VSCode user.

- You can use C++, it is just the core of Zephyr which is written in C. Openthread is implemented in C++ for instance.

- You are absolutely not stuck with JLink, any probe that works with Openocd or PyOCD is fine.

=========

As for "your existing codebase", it is based on some APIs, right? If it is based on SDK, then of course you cannot integrate it, you have to port it. But if you do, it will run on all sorts of platforms.

If Nordic took a risk in embracing Zephyr it is that the customers are less prisoners of their own code, since much of it will run on competitor products. But for IoT, there really is no choice about being open.

[niebert]

Concerning "depreciation", listen to the complete presentation at "Embedded World" this march :

https://webinars.nordicsemi.com/understand-the-nrf-connect-sdk-2

Especially after minute 35 there are statements to that end as well as after minute 52 up to the end, quite enlightening. I think it is pretty clear, even for Nrf52, there already exist production ready features that are present in NCS that will never be implemented in SDK. nRF5SDK is maintained for bug fixes, not for new features.

There is also an answer to bare metal in NCS near the end of the webinar, IMHO it is more theoretical, and threadless operation is now depreciated in Zephyr. But you can through out a lot and base yourself on nrfx for most part, if that is what you want to do.