How to setup NCS v2.0.0 for VS Code on Ubuntu 20.04?

[PopradiArpad]

Hi,

after the manual installation the Quick Setup of nRF Connect for VS Code says

that GNUARMEMB_TOOLCHAIN_PATH and ZEPHYR_TOOLCHAIN_VARIANT environment variables are missing

and

zephyr-sdk is not found in the PATH.

I am confused because nRF Connect SDK v2.0.0 Release Notes says that

"The Zephyr SDK toolchain replaces the GNU ARM Embedded toolchain".

In that case GNUARMEMB_TOOLCHAIN_PATH should be not needed.

And I installed the zephyr-sdk to one of the recommended place (~/.local/opt/zephyr-sdk-0.14.1)

I don't find help on the Zephyr site either

docs.zephyrproject.org/.../env_vars.html

So what is the easiest environment variable setup for NCS v2.0.0 for VS Code on Ubuntu 20.04?

With kind regards,

Árpád

[Elfving]

Hello Árpád, sorry about the delay

Have you tried the automatic installation using the toolchain manager? It should be available for NCS 2.0 on Ubuntu 20.04.

That would definitely be the easiest way.

Regards,

Elfving

[KRich]

I am not the original poster, but am very interested in this thread. While I appreciate that Nordic provides the automatic, all-in-one toolchain manger solution, this is not practical for many of us. At a minimum it does not easily enable automated builds, and it hides what is being done "under the covers" making it difficult to figure what needs to be done when using a manual installation.

In this case, toolchain manager is obviously manipulating some environment variables and/or VS Code settings before launching VS Code. Can you, or someone at Nordic, describe what exactly is being done and/or what needs to be done to configure VS Code (and the nRF Connect extension)? Additionally, please be aware of and/or consider the possibility that a developer may be using Python virtual environments to contain/control the large amount of python modules that need to be installed.

[PopradiArpad]

Hello Elfving,

thank you for your hint and sorry for the late answer. It worked, only I had to do it twice because it got stuck at a point.

I had a NCS 1.9.1 and that was not a problem either.

For me the question is answered but I don't set it to "Verified Answer" because maybe somebody answers KRich's more detailed question.

With kind regards,

Árpád

[Elfving]

Great! Glad to hear it. 

PopradiArpad said:

For me the question is answered but I don't set it to "Verified Answer" because maybe somebody answers KRich's more detailed question.

Good, I will get back to him on that eventually.

Regards,

Elfving

[Elfving]

Hi Keith,

KRich said:

At a minimum it does not easily enable automated builds, and it hides what is being done "under the covers" making it difficult to figure what needs to be done when using a manual installation.

When it comes to the installation I believe the Toolchain Manager essentially does the same as what is the described in the manual installation documentation. It is just easier to do it automatically, to be sure nothing is being missed in the process. 

KRich said:

In this case, toolchain manager is obviously manipulating some environment variables and/or VS Code settings before launching VS Code.

There isn't much of a difference between between launching Visual Studio Code directly and starting it from the Toolchain Manager. It does inherit preset environment like PATH and such, but it doesn't need it, since it has a better control of the toolchains and the SDKs anyway. This was not the case with SES, that's why it's still there.

KRich said:

Can you, or someone at Nordic, describe what exactly is being done and/or what needs to be done to configure VS Code (and the nRF Connect extension)?

I am not sure if I understand your question here. You can simply install the nRF Connect Extensions from VSC; you don't need to do it from the Toolchain Manager. TM does allow you to install all of the required extensions automatically though.

KRich said:

Additionally, please be aware of and/or consider the possibility that a developer may be using Python virtual environments to contain/control the large amount of python modules that need to be installed.

That is an interesting point. Could you expand a bit on a use-case you have where this is an issue?

Regards,

Elfving

[KRich]

Thank you Elfving,

Elfving said:

Could you expand a bit on a use-case you have where this is an issue?

I work across several different projects, each using a different MCU and a different toolchain and/or SDK. Attempting to keep the right versions of the right supporting tools installed on my machine and/or keeping my PATH ordered in such a way that everything works can be a real challenge. The Toolchain Manager does provide an interesting solution to the this issue, but there are 2 issues with this approach:

1. This does not lend itself to automated builds. Any instruction that involves "Open this tool, click here, then here, then here" doesn't work for automating a build.
2. Similarly, for my personal development, I really don't like to have to open a different program/window, just to launch a shell and compile. Again, I work with several different MCUs/toolchains, so it's really simpler if I can just open a shell and go.

Fortunately, both of these are minor issues for me because you also provide the zephyr/zephyr-env.sh/cmd scripts for getting things set up from a shell environment. This allows me both in my personal development and/or in the automated environment to simply open a shell, execute one script and get to work.

The larger issue is that most modern build systems use Python to some degree and, like NCS/Zephyr, have requirements around installed modules and even specific versions of specific modules. To manage this, Python provides virtual environments. So, for each project I create a virtual environment where I install the required versions of the required Python modules (i.e. requirements.txt). Any time I'm working on the NCS/Zephyr code, so, technically my process is open a shell, activate the Python virtual environment, execute the zephyr-env.sh/cmd script, start working. As I mentioned before, I suspect that Toolchain Manager is doing something similar behind the "Open bash" and/or "Open command prompt" options.

Sorry for the long-winded response, to the simple question about a specific use case, but this all leads up to this. When I want/need to use VSCode (typically only for debugging):

1. There does not appear to be a way to point it to a Python virtual environment to use when running a build, and
2. It's not obvious to me what setting/group of settings need to be set in VSCode to achieve the equivalent of executing zephyr-env.sh/cmd. Again, this seems to be something that Toolchain Manager does behind the scenes when launching VSCode.

Finally, I noticed one further thing while attempting to get VSCode configured. A couple of times I was close to having things configured correctly, but got warnings/errors about GN not being installed. In the setup/getting started instructions, GN is listed as optional and only required if using the Matter features. Since I am not using the Matter features I would prefer not to install the tool (as I mentioned I have enough tools installed, I don't need to install unnecessary tools), but it is discomforting to be told this is an error/warning when it is not.

Again, my apologies for the long reply. Please let me know if you have any other questions or need any other information. Thanks!!!