Since you love the nRF52840, we are sure you will love both the nRF54H and the nRF54L Series.

The NRF Connect SDK is based on Zephyr which is vendor agnostic, so at least if you switch to NRF connect SDK now, you don't have to worry as much about vendor lock-in. The old SDK was only simple when doing simple things. In my experience Zephyr makes simple things a bit more complex, but makes complex things much simpler. I felt that it was a bit hard to get started with it a while back, but now it keeps getting easier as the ecosystem around it improves.

The nRF Connect SDK brings a new structure and higher level of abstraction that decouples your application from the underlying hardware, allowing for highly scalable applications that can be deployed to various hardware platforms with minimal to no code changes. The benefits brought by nRF Connect SDK ensure the cost of migrating from nRF5 SDK to nRF Connect SDK will be recouped in the long run. We have also made significant investments to smoothen up the migration journey. In the DevAcademy you can find courses that help you get up to speed with the SDK and some of the wireless technology (Bluetooth LE, cellular IoT, and more to come). Additionally, we have created our own nRF Connect extension for VSCode that brings unique tools (Devicetree visual editor, memory report, nRF Debug), supporting developers to accelerate their development and decrease time-to-market. To learn more about nRF Connect SDK and the benefits it brings to your application development we recommend watching this webinar: ukposts.info/have/v-deo/l32qra6acGpysYU.html&pp=ygUoZnV0dXJlIHByb29maW5nIGlvdCBlbWJlZGRlZCBkZXZlbG9wbWVudA%3D%3D

​@@NordicSemi I understand where you are coming from, an OS is indeed a much more modularized and neat way of doing things. But this feels like its becoming a bit like the JS ecosystem. Yes, Zephyr is better, shinier and cool, but this pattern of not being careful with breaking changes started long time ago (with every other SDK update). First was the nrf_drv and nrfx confusion, with random #define flags enabling competing libraries within the SDK, and now the nrfx standalone vs. the old SDK way vs. NCS. From what I read online, our whole app needs to be re-written again when switching to NCS. All the suffering of getting everything to work together, i2c, spi, usb, sleep, cellular, ota, factory test jigs, etc etc is kinda wasted.. And then there is the question of if the units in the field can even benefit from this... Can a unit with a secure USB/BLE DFU bootloader handle binaries from the new Connect SDK? Or shall we start shipping J-Links to customers to keep under their pillows? 😂😂

important distinction (I say the same thing about Arduino) @@auspiciouslywild

For details on the nRF54L15 SoC please reach out to your local Nordic sales representative.

Love to hear your are interested in that t-shirt, but currently it is only for Nordic employees. We might give out a few through webinars etc after the launch.

​@@NordicSemiexpectation

It is currently only for Nordic employees, but we might give out a few through webinars etc after the launch.

The main processor is a 128 MHz Arm Cortex-M33, but the nRF54L15 also has a RISC-V coprocessor.

I see! Thanks for the clarification.@@NordicSemi