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 

Nguyen Hoan Hoang said:

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.

Please do report it if the problem persists. If it is a bug on our side we can then look to get it fixed. 

Nguyen Hoan Hoang said:

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.

Complaining is a big part of what we do in support, since we are among the first to play with new software and hardware releases

There was certainly a lot more to complain about 2 years ago as well...

Nguyen Hoan Hoang said:

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

I am not aware of this particular customer, no, but after many years in Nordic I have seen my share of designs get lost for various reasons. 

It's never a good feeling when it happens obviously, but you can't really do much about it except try to learn from your mistakes and move on. 

As a final word I realize that I lack the rhetorical skills to win you over to my way of thinking. As a long time member of support I face issues and problems every day, and I try to apply a positive and constructive attitude to these issues rather than getting too focused on the negatives (which I succeed to do most of the time, if not all...). If not I think I would have tired of this job a long time ago. As a piece of friendly advice I would urge you to do the same, and obviously keep us in the loop on any issues you do find so we can do our best to help out

Best regards
Torbjørn

[Nguyen Hoan Hoang]

It is bad that a silicon vendor force the software people to lock in to a particular RTOS.  In software, there are 1001 ways of doing the same thing.  Software engineers like freedom of choices.  People who have many projects developed over the years always have a library of code that are re-usable in new projects to save on dev costs and time.  What you did is to tie their hand in the back to develop with nRFConnect and make all their previous investment go down the drain.  The old SDK is easy integration into existing environment.  It is actually easy to support the nRF53 the old ways.  You just need to make a Softdevice alike running on the Net core and wrapper function over rpc communication.  Exactly the same as you did with S132 for nRF52832 and S140 for nRF52840 with wrapper through SVC calls. Easy and fast to do. I don't get what you are doing with a Linux want to be (Zephyr) on a MCU.  You should learn FreeRTOS way.  Simple, no mess, no scripts, no Linux junk and it works with almost any MCU.  Your old SDK too was like that. Just a compiler is needed. That is what needed for MCU.      

[brianreinhold]

What I like about the SDK is SoftDevice. It is basic GATT/GAP and avoids the crazy BTLE profiles dreamt up by BT SIG. Having worked on a few of those standards, BT SIG just can't seem to learn simplicity and consistency and each profile is created without much thought to any other profile. Many profiles (especially in the health sector) just collect dust.

What I like about the nRF51 is that it can only do basic BTLE  (4.2 maybe) and for those devices that need no more than that and are happy with the MTU of 23 that is good. Because it can only do 4.2 the memory footprint of the application is considerably smaller than the same application built using nRF52 devices. At least mine were. On the other hand if the nRF52 is now cheaper and takes less power running the same application then it would be hard to argue for starting a new project with the nRF51. The nRF52 DK was not cheaper than the nRF51 DK, but the nRF52840 dongle was cheaper than the nRF51 equivalent (if you can still find it).

I do not know what nRFConnect brings to my application compared to the SoftDevice only BTLE version of the application. I did hear that the SoftDevice equivalent here will be source thus allowing optimization by removing unused functions which is not present in the SoftDevice library of the SDK.

As an aside, Using SoftDevice only for BTLE makes porting to other MCUs easier - as all BTLE software (at minimum) has to handle these basic operations.

I not sure how hard it will be using an RTOS. An OS is supposed to make life easier at the same time more of what goes on becomes a black box. There is something to be said for the simplicity of a non-OS application on an embedded system.

Since I have no investment in any hardware yet (all my work has been for developing a generic standard for health devices) the only thing I loose by moving to nRFConnect is my time learning and implementing the new approach. For those who have units in the field the cost is probably much greater.

[ovrebekk]

Hi

Nguyen Hoan Hoang said:

It is bad that a silicon vendor force the software people to lock in to a particular RTOS.

Just to be clear, Nordic doesn't force you to do anything. Our devices use standard ARM Cortex M microcontrollers, and our datasheets document all the peripherals that are non standard (like the radio and the various interfaces). If you want to write all the software yourself, or use a third party software framework, that is entirely up to you. 

The only limitation in using a third party software framework is that the support responsibility falls on the developer of the software, not Nordic. I don't think you will find any silicon vendor that takes support responsibility for other peoples software, unless they have an established partnership with the software provider in question. 

Best regards
Torbjørn

[ovrebekk]

Hi Brian

brianreinhold said:

What I like about the SDK is SoftDevice. It is basic GATT/GAP and avoids the crazy BTLE profiles dreamt up by BT SIG. Having worked on a few of those standards, BT SIG just can't seem to learn simplicity and consistency and each profile is created without much thought to any other profile.

You will be happy to hear that you get a standard GAP and GATT API, then. Running standard services is entirely optional

Similar to the SoftDevice the API is grouped into groups such as GATT server, GATT client and GAP. 

Because the Zephyr Bluetooth API is vendor agnostic it is much more focused on Bluetooth only, and follows the naming conventions set out by the Bluetooth specification. 

The SoftDevice by comparison is more Nordic centric, and includes various features not technically Bluetooth related (such as the flash, clock, and power management functions). 

brianreinhold said:

What I like about the nRF51 is that it can only do basic BTLE  (4.2 maybe) and for those devices that need no more than that and are happy with the MTU of 23 that is good. Because it can only do 4.2 the memory footprint of the application is considerably smaller than the same application built using nRF52 devices. At least mine were. On the other hand if the nRF52 is now cheaper and takes less power running the same application then it would be hard to argue for starting a new project with the nRF51

You won't be able to build Bluetooth 4.2 stacks anymore, but as I mentioned earlier you can link out functions that you don't need. Also, if you don't need more than 23 byte MTU the RAM consumption is lower. 

As you say the nRF52 gives you more memory and performance for less cost, so there is really no good reason to use the nRF51 anymore. 

brianreinhold said:

I do not know what nRFConnect brings to my application compared to the SoftDevice only BTLE version of the application. I did hear that the SoftDevice equivalent here will be source thus allowing optimization by removing unused functions which is not present in the SoftDevice library of the SDK.

Ideally the Bluetooth part of the application should be relatively equivalent, the difference is more in the other libraries you have available as a part of the nRF Connect SDK. 

You might find some value in being able to run your application on non Nordic hardware as well, even if we hope you will chose to stick to Nordic devices

brianreinhold said:

I not sure how hard it will be using an RTOS. An OS is supposed to make life easier at the same time more of what goes on becomes a black box. There is something to be said for the simplicity of a non-OS application on an embedded system.

Using an RTOS should ideally be no harder than using a bare metal system. A bare metal implementation is easier to understand intuitively, since there are much less layers of software between the hardware and your main function, but once you start writing more complex applications then you need to put more complexity into the application to handle things that an RTOS can otherwise do for you. 

In a way having an RTOS moves some of the complexity from the application into the underlying RTOS, which makes it harder to learn the framework, but makes it easier to understand the various applications. This is especially useful when multiple people work together on a larger project, or when you have to work on many different projects rather than just maintaining a single one. 

The main challenge of adopting to the RTOS way of thinking is that you have to structure your programs a bit differently. As an example, in the nRF5 SDK good coding practice was to never use blocking function calls. With an RTOS you are now free to use blocking calls from threads, since other threads will be able to run while one thread is blocked (and if all threads are inactive you will automatically go to sleep). 

brianreinhold said:

Since I have no investment in any hardware yet (all my work has been for developing a generic standard for health devices) the only thing I loose by moving to nRFConnect is my time learning and implementing the new approach. For those who have units in the field the cost is probably much greater.

Fair point. We don't really recommend people porting existing nRF5 projects to the nRF Connect SDK, unless they really need features not available in the older SDK. It is usually better to adopt the new SDK when you have a new project, making it easier to make a clean break. 

Best regards
Torbjørn