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]

I think you are not right about nRF5 SDK being deprecated, please point at your sources. NCS is just not ready for production use on the nRF52 series.

[myself]

OK，Thanks！

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