So far we have been using nRF5 SDK v17.1, but we ended up using nRF connect SDK v1.9.1.
However, this compiles too slowly.
I modified main.c and it seems to compile everything.
Are there any options?
So far we have been using nRF5 SDK v17.1, but we ended up using nRF connect SDK v1.9.1.
However, this compiles too slowly.
I modified main.c and it seems to compile everything.
Are there any options?
You may use the "--pristine" option.
This will remove all the object files that you built previously.
Try with the removed "--pristine" option.
Thanks for the comment.
I am doing a sample build without changing anything in SES of "nRF connect SDK v1.9.1".
I don't use West.
I know that gcc is used when using the SDK's ses. Is the "--pristine option" valid even in this case?
Hi Kim
However, this compiles too slowly.
The nRF Connect SDK is a bigger SDK than the nRF5 SDK, so it will unfortunately build slower.
Building with the nRF Connect SDK is reported to be faster for Linux then for Windows though.
So if you want this, you could try to build either using a Linux PC or with Windows Subsystem for Linux(WSL).
ch0ry said:I know that gcc is used when using the SDK's ses. Is the "--pristine option" valid even in this case?
In Segger Embedded Studio, you acheive "pristine" build if you select the "Clean Build Directory" when you open a new nRF Connect SDK project.
ch0ry said:using the SDK's ses.
From the nRF Connect SDK 1.9.1 Release Notes:
"
nRF Connect SDK v1.9.1 is supported by both nRF Connect extensions for Visual Studio Code and SEGGER Embedded Studio Nordic Edition. In future releases, documentation on the setup and usage of Segger Embedded Studio Nordic Edition will no longer be available and all references to IDE support will instruct users with nRF Connect extensions for Visual Studio Code. In future releases, Segger Embedded Studio will no longer be tested with the build system and it is not recommended for new projects.
nRF Connect extensions for Visual Studio Code will be under continued active development and supported and tested with future nRF Connect SDK releases. It is recommended for all new projects.
"
So I recommend that you use VS Code for developing with the nRF Connect SDK.
See the nRF Connect for VS Code video tutorials for how to get started quickly.
I do not know if this will compile faster than Segger Embedded Studio(SES) or not though.
But it might be worth a try, maybe it is faster?
Regards,
Sigurd Hellesvik
Hi Kim
However, this compiles too slowly.
The nRF Connect SDK is a bigger SDK than the nRF5 SDK, so it will unfortunately build slower.
Building with the nRF Connect SDK is reported to be faster for Linux then for Windows though.
So if you want this, you could try to build either using a Linux PC or with Windows Subsystem for Linux(WSL).
ch0ry said:I know that gcc is used when using the SDK's ses. Is the "--pristine option" valid even in this case?
In Segger Embedded Studio, you acheive "pristine" build if you select the "Clean Build Directory" when you open a new nRF Connect SDK project.
ch0ry said:using the SDK's ses.
From the nRF Connect SDK 1.9.1 Release Notes:
"
nRF Connect SDK v1.9.1 is supported by both nRF Connect extensions for Visual Studio Code and SEGGER Embedded Studio Nordic Edition. In future releases, documentation on the setup and usage of Segger Embedded Studio Nordic Edition will no longer be available and all references to IDE support will instruct users with nRF Connect extensions for Visual Studio Code. In future releases, Segger Embedded Studio will no longer be tested with the build system and it is not recommended for new projects.
nRF Connect extensions for Visual Studio Code will be under continued active development and supported and tested with future nRF Connect SDK releases. It is recommended for all new projects.
"
So I recommend that you use VS Code for developing with the nRF Connect SDK.
See the nRF Connect for VS Code video tutorials for how to get started quickly.
I do not know if this will compile faster than Segger Embedded Studio(SES) or not though.
But it might be worth a try, maybe it is faster?
Regards,
Sigurd Hellesvik
