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.

[brianreinhold]

The non-blocking restriction does make life more difficult but most non-OS based embedded systems run in that manner (at least that is what I am led to believe). In my project I have a situation where the characteristic value can be longer than the MTU. So it has to be sent fragmented. So when notifying, one would send 6 notifications but then one needs to wait for the ack event before one can send more. So I would exit the send routine and basically wait on sd_app_evt_wait() and handle the events myself when it woke.

I have never really fully understood that call, but I assumed it could only be called in one place in your program and your entire program ran around this call. When it would exit, you would check everything you might need to do and return to the sd_app_evt_wait().  Anything else, like a sleep, is just a busy loop and a horrible way to wait for something to happen before continuing,

So that's what I have done. When I used the pc-driver-btle library on the PC, I could use mutexes and semahores which DID dramatically simplify the program - but at the cost of having a multi-tasking OS which diminishes real time implementations.

[Nguyen Hoan Hoang]

ovrebekk said:

Just to be clear, Nordic doesn't force you to do anything

It has been said time over by Nordic people that if you want to use the nRF53 or nRF91 you have use Zephyr!!!  SDK not available otherwise.  DUH !!!

[ovrebekk]

Nguyen Hoan Hoang said:

It has been said time over by Nordic people that if you want to use the nRF53 or nRF91 you have use Zephyr!!!  SDK not available otherwise.  DUH !!!

Then I am glad I could clear up that misunderstanding

[Brian]

ovrebekk said:

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!

Hi Torbjørn, I am a teacher and I have a bunch of nRF51822s that I want to use to set up a lab for my students to use. If I can get help using the latest nRF Connect SDK to build apps on the older chips, I would certainly make sure my students get an extra positive review of Nordic Semi. 

[ovrebekk]

Hi Brian

Please open a new ticket if you have a question not directly related to an older case, the devzone is not really designed do handle long running cases with multiple different questions. 

The short answer is that the nRF51 series is not officially supported in the new SDK, but many samples will still work by using the nrf51dk_nrf51422 board definition, including many of the Bluetooth samples. 

In other words it should be possible to put together a lab session based on the nRF51 boards and the new SDK, if you find a set of features and libraries in the SDK that work fine on the older boards. 

Best regards
Torbjørn