Visual Code issues

[Evluma]

While using Visual Code I have noticed that:

• First compile always generates errors, which is fine. The error notifications are persistent even after they have been fixed. The only thing that clears these errors is exiting Visual Code and restarting the program.
• Adding a second build within the same project consistently cause all builds to fail with missing file errors
• While creating custom applications, such as the Hello World App from the DevAcademy, the printk function does not output to any terminal. Also the DevAcademy still references the NRF Terminal, which has been removed
• Many of the sample applications or examples do not copy over correctly into target directories with several files having hard coded directory paths which are not valid due to the path move

These are annoyances and can be worked around but having to close and reopen VC to clear errors is troublesome and not being able to reliably create multiple builds in the same project without bricking the original build is limiting the versatility of the system.

[runsiv]

Hi sorry for the delay. 

Thanks for the clarification. There is some background talk going around at our end regarding the samples. 

The response I have gotten on my end is that they should be viewed the following way: 

"

These samples are available to show how nrfx can be used instead of Zephyr drivers (or shims). They are designed to build using different frameworks including Zephyr and bare metal, which is why this build configuration in Zephyr has its flaws.

As nrfx is a set of drivers which are os-agnostic and focusing on individual peripherals. Therefor any Zephyr-specific frameworks such as pin control, power management, cache, will never be a part of nrfx. Given this, nrfx is not (and not ment) to be a direct replacement for Zephyr drivers.

Low Level is on the course of delivering features and functions within Zephyr APIs so hopefully nrfx will once become a hacker’s tool and internal low-level drivers in Low Level.

Please try use Zephyr drivers first, then nrfx, and unfortunately you will need to manually trigger all Zephyr frameworks such as pin control, power management, cache and any other framework that may be needed." 

Regards

Runar

[Evluma]

Hi

What you say about using the Zephyr drivers is true, but there are cases where we will want to have finer control over timing and utilize hardware specific to the nRF chips which is not a part of Zephyr. For my development this is not the case but I am sure others will require low level access to nrfx for such things as tight timing and utilization of DPPI/PPI. The DevAcademy courses also reference this particular requirement. 

In this thread I am just pointing out places where the supplied examples cause issues and hang up. I can work around these issues. As I come across new "hick-ups" I will post them.

Cheers