Why is the SDK fragmented into nRF5 and nRF Connect SDK?

[Andy]

The question is clear I believe. Why did support for the NRF5340 not make it to the nRF5 SDK? Is it something about the SoC specifically?

What's better about the nRF Connect SDK? Is the SDK for NRF52s going to move to Connect eventually?

Maybe an official blog post comparing SDKs would bring a bit of light into the issue.

[Thomas Page]

Hi Andy

A blog post is indeed a good idea.

We have noticed over time that the software we require to support our SoCs is growing in complexity. nRF Connect SDK is being introduced to provide a platform that allow us to address these complexities in an efficient and scalable way into the future.

The nRF91 and the new nRF53 families are complex devices and it made sense to introduce support for these new devices on the new nRF Connect SDK. Ultimately, as nRF Connect SDK matures, we will include support for the nRF52 family of devices. For the time being our nRF5 SDK remains the primary SDK for development on our nRF52 family.

[Andy]

Looking forward to that blog post :) I'm especially interested in understanding the technologies in the new "platform" that will allow the SDK to be more efficient and scalable in the future.

[Marciano-PL]

I look forward to the blog post. If I might add, I think another piece of content which would be very helpful in the blog post is a list of the available libraries/sdks for different aspects of the hardware and where to find them. The current state of the documentation for the nRF5340 makes it difficult to tell what is yet implemented and where it might be. Between Zephyr, nrfxlib, and the nRF Connect SDK it can become a headache to find what you are looking for. Especially considering the lack of detailed documentation and centralized information regarding the firmware for the mcu.

Thanks for being so responsive. I really appreciate the community support!