nRF Connect Install requires a huge amount of packages

[brianreinhold]

I have developed a set of applications using just SoftDevice for Bluetooth and flash read and writes in the framework of nFR51 and nRF52 SDKs. Now I was thinking of moving to nRF Connect. I already have Visual Studio Code installed for a project that is handled remotely from my Windows 64 10 PC  on a Linux Raspberry PI. So I installed the extensions for Nordic. However, I could not find the locations on my computer where they were installed. VS Code itself is installed on a second disk E.

However I was far from finished. It looks like I need to install a great number of third party programs I have never heard of including the nRF Command Line Tools. I do not intend to use the command line tools and have never used this tool to date. Why do I need this? Is it absolutely necessary to install all these third party packages like 'chocolately',  'west', python??? , Zephyr I can understand... This is probably gigabytes of junk. I cannot image all of this stuff ever getting cleaned up. Do I really need all this? Why Python? That's a whole SDK for building Python applications ... that is huge.

How many of these can I get rid of once nRF Connect is installed. What does 'chocolatey and west do? I realize that I can install even more stuff and get the manager to do all of this for me but that is just hiding all the junk getting downloaded and installed.

I went to the Nordic 'Seminar' in Boston (Waltham) about a month ago where I was introduced to nRF Connect.

So the actual goal here was to see if this project would have a smaller footprint using SoftDevice (used now) or the nRF Connect SDK and which was easier to implement. There is interest in this project (which is a generic health device model over a BTLE tunnel) primarily in China at the moment so It would be nice to have an answer. One thing the seminar did not reveal was the massive amount of support software needed to get off the ground.

[Nguyen Hoan Hoang]

Correct, the nRF53 is not currently supported.  That is because you forced people to use Zephyr.  

Port is in the work using the sdk_nrfxlib with support for nRF53 in the IOsonata.  App firmware on nrf52 can seamlessly compile for either old nRF5_SDK or nrfxlib.  It would be a great help if the BLE stack is added to the nrfxlib.  

[ovrebekk]

Hi

Making a big change like this is painful I know, but it is a change we would have to make at one point regardless. The nRF5 SDK was perfect back when we had a handful of single core devices, but got more and more complex to maintain as we added more and more devices with a wider and wider range of capabilities. 

Case in point, if I download the latest and greatest version of the nRF Connect SDK I can still build many of the Bluetooth samples for the nRF51, a device released 12 years ago!

For the nRF5 SDK you have to go all the way back to version 12.3.0 to get support for the nRF51. The later versions support the nRF52 only. 

(the nRF51 is not officially supported though in the nRF Connect SDK, but if you have some old kits laying around you can still use them) 

Once you move your own platform over to the new architecture it should make life easier for you as well, in regards to supporting new nRF devices as they are released. 

Nguyen Hoan Hoang said:

It would be a great help if the BLE stack is added to the nrfxlib.  

By this I assume you mean both the controller and the host? 

There are no plans for this unfortunately since we are using the Zephyr host, rather than our own host implementation. 

Best regards
Torbjørn

[Nguyen Hoan Hoang]

Firstly why would anyone wants to use nRF51 on new platform.  It is just a lame excuse.  nRFConnect does not make life easier but big pain.  Beside the examples don't work properly on nRF52832. Same examples work on nRF52840 only (not using coded phy of course).  A simple UART BLE example does not work properly.  After so many years you still unable to accomplished your goal.  All of my customers complain about the new SDK is a big pain and they don't want it.   While with IOsonata same code works across nRF51, 52 5 years ago and you can use it with any RTOS you like. 53 in the works,  

[ovrebekk]

Hi 

I am sorry to hear you are having so much pain with the nRF Connect SDK. 

Have you opened a ticket on the nRF52832 issue? 
Is this with the nRF52DK or a custom board/module?
I can't say I have experienced this myself, normal BLE examples should work fine on the nRF52DK. 

Nguyen Hoan Hoang said:

While with IOsonata same code works across nRF51, 52 5 years ago and you can use it with any RTOS you like. 53 in the works,  

Sounds like you have a good argument for providing your own solution then

There is definitely room for third party software frameworks for our devices, as long as people realize we can't support them directly since they are not developed by us. 

Best regards
Torbjørn

[Nguyen Hoan Hoang]

ovrebekk said:

Have you opened a ticket on the nRF52832 issue? 

No, I didn't have time to investigate further for creating a ticket. I just wanted to know how to use the sdk_nrfxlib.  It crashes on nRF52832 but works on nRF52840 so I used it instead.

ovrebekk said:

Is this with the nRF52DK or a custom board/module?

I don't recall but I believe both DK & custom board didn't work (using known working board with nRF5_SDK).

ovrebekk said:

I am sorry to hear you are having so much pain with the nRF Connect SDK. 

I am not the only who doesn't like Zephyr obviously.  About 2 years ago even one of your ex-support staff approached me with the same complains about Zephyr. 

Did you know that you have lost a customer that could have used 10K-50K nRF91 per year due to Zephyr & nRFConnect SDK ?!!