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.

[ovrebekk]

Hi Brian

However, I could not find the locations on my computer where they were installed. VS Code itself is installed on a second disk E.

VSCode extensions should be installed in the %USERPROFILE%\.vscode\extensions folder. Typically something like c:\Users\USERNAME\.vscode\extensions. I confirmed this on my own machine, and can see 5 folders with the nordic-semiconductor prefix for the various Nordic extensions.

I do not intend to use the command line tools and have never used this tool to date. Why do I need this?

That is odd to hear you have never use this before, the nRF Command Line tools contains the base drivers to interface with the debug chip on the various nRF52 DK's, and is used for flashing and debugging the DK's. I would expect you to have used this when working with the nRF5 SDK and the SoftDevices. 

These tools are listed in the Tools and downloads section of the nRF52 series DK's, based on the 'old' platform (nRF5 SDK and SoftDevice). 

Is it absolutely necessary to install all these third party packages like 'chocolately',  'west', python???

Chocolatey should no longer be necessary. This is a packet manager that was used to install the various toolchain components in the first releases of the nRF Connect SDK, but has now been replaced by the Toolchain Manager (TCM) application in nRF Connect for Desktop. 

When using the TCM it is basically a one click operation to install a specific version of the SDK, and this includes the various toolchain components such as West and Python. 

You define the install directory for any new SDK versions. Then the SDK's will be installed in a subfolder named v2.1.0 for instance, while the toolchain will be installed in the /toolchain/v2.1.0 folder. 

At the moment each SDK install comes with its own version of the toolchain which does contribute to the bloat definitely, but greatly reduces the chance of build errors caused by incorrect toolchain components. 

Do I really need all this? Why Python? That's a whole SDK for building Python applications ... that is huge.

Python is used by a lot of the build scripts in the toolchain and as such is critical, with West being the most important of these Python scripts. West is the meta tool that handles the download and update of the various repositories included under the nRF Connect SDK umbrella, and can also be used to start build, flash and other operations from the command line. 

I doubt the whole Python SDK should be downloaded though. The entire toolchain comes in at about 1GB, and I think the Python binaries are a relatively small portion of this. 

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 doubt there is much you can get rid of since most of these tools are used for building applications. Possibly you could get rid of chocolatey and leave the scripts in place, but I am not sure. 

Frankly you will be much better of using the Toolchain Manager. As I mentioned earlier all the resulting junk can be found in the [SDK_FOLDER]/toolchain/v2.x.x folder, so using the TCM should not make it any harder to find compared to chocolatey

You can uninstall the TCM and nRF Connect for Desktop once everything is installed, these are not used for building or developing applications. That said there are a lot of useful apps within nRF Connect for Desktop, such as the Bluetooth application and the Power Profiler (for owners of a Power Profiler Kit), so I think this is an application worth keeping. 

If you really want to keep your system as un-affected as possible the best option is probably to install everything in a virtual machine. If you want to go down this route though it is recommended to run a virtual Linux installation, since the build performance is generally faster in Linux than on Windows. 

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

I remember, I was there!

I think we had a chat at the end, regarding the work you have been doing with the SoftDevice

I didn't represent nRF Connect though, so any promises made about it I will put on Karl's shoulders

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.

Are you talking about memory footprint on the device, or the size of the toolchain?

What is more easy to implement is a complicated question to answer. The toolchain and build system is definitely more complicated, but making applications is typically not because of the advantages the build system offers. As an example the Bluetooth heart rate example in Zephyr is about 130 lines of code i main.c, compared to a much more complex example in the nRF5 SDK. And exactly the same main file can run fine on the nRF51, nRF52 or nRF53 devices by only changing the board file in the build, which is something the nRF5 SDK could only dream off...

Your development model is a bit different than most customers though, as you don't really use any of the libraries in the SDK and just program for the SoftDevice directly. I am not sure this will work as well in the new SDK, since we don't really have a SoftDevice anymore, but have split the BLE controller and host into two separate pieces of software. 

One thing the seminar did not reveal was the massive amount of support software needed to get off the ground.

To be fair, I think we mentioned most of these tools in the seminar, but it is true that Python isn't mentioned in the slides. This I can take as feedback to future iterations of the slides. Chocolatey is not mentioned either, but as I said we recommend using the TCM instead, rather than having to install all the tools manually. 

Finally I hope you have taken the time to go through the DevAcademy? 
It really makes a big difference in getting started with the nRF Connect SDK

Best regards
Torbjørn

[Nguyen Hoan Hoang]

And exactly the same main file can run fine on the nRF51, nRF52 or nRF53 devices by only changing the board file in the build, which is something the nRF5 SDK could only dream off...

Wrong, it exists 5 years ago without any scripting software only gcc compiler. It has been posted on this forum since.  

https://embeddedsoftdev.blogspot.com/2017/12/bluetooth-le-with-nordic-nrf51-nrf52.html

https://embeddedsoftdev.blogspot.com/2018/02/bluetooth-le-with-nordic-nrf51-nrf52.html

With only a few line of code, no RTOS, no 10K line of defines.

Original source code here

https://github.com/I-SYST/EHAL

new version moved here

https://github.com/IOsonata/IOsonata

[ovrebekk]

Hi

Nguyen Hoan Hoang said:

Wrong, it exists 5 years ago without any scripting software only gcc compiler. It has been posted on this forum since.

Not for the nRF53 I assume

Being multi core the nRF53 is more challenging to support with the same code base, which is something the nRF5 SDK wasn't really ideal for. 

T.

[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