meanwhile we are stuck with the old SDKs and its quite hard to access new features since you moved to NRF connect SDK.. The old sdk was so simple and great, and we invested heavily on OTA and other features. Now the cost of migrating is as high as going with another vendor.
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: ua-cam.com/video/_Myyxc94APQ/v-deo.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? 😂😂
For details regarding the nRF54 Series prior to launch, please reach out to your local Nordic sales representative. If you do not have a direct contact, please use our contact form: www.nordicsemi.com/About-us/Contact-Us
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.
I’m very interested in BLE mesh capabilities for SoC. LOVE the 52840 series btw. Looking forward to the new H & L series. 👍
Since you love the nRF52840, we are sure you will love both the nRF54H and the nRF54L Series.
meanwhile we are stuck with the old SDKs and its quite hard to access new features since you moved to NRF connect SDK.. The old sdk was so simple and great, and we invested heavily on OTA and other features. Now the cost of migrating is as high as going with another vendor.
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: ua-cam.com/video/_Myyxc94APQ/v-deo.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
Where do I get that shirt :3
It is currently only for Nordic employees, but we might give out a few through webinars etc after the launch.
Does nRF54 support LLPM, in which connection interval can be lowered to 1 ms?
For details regarding the nRF54 Series prior to launch, please reach out to your local Nordic sales representative. If you do not have a direct contact, please use our contact form: www.nordicsemi.com/About-us/Contact-Us
I'm very interested in that T-shirt... Where can I obtain one? Luv the Chips.😛👍
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
Does it have a built in voltage regulator like the 840?
For details on the nRF54L15 SoC please reach out to your local Nordic sales representative.
Why does it say RISC-V on the image but he clearly says ARM based?
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