VSCode: Feedback/issues with developing an out-of-tree driver

I'm writing an out of tree modem cell modem driver and have some feedback that could help in making this endeavour smoother in the nRF Connect VSCode Environment

I have got to the point where the driver is compiling, is recognised by devicetree/Kconfig and can be included in the build without a problem. The majority of the issues I have remaining are around the development environment not being quite as helpful as it could be. The Zephyr module is being shared in several applications so is being added from a parent directory using the following as the first thing in CMakeLists.txt

Fullscreen
1
2
3
4
set(REPOSITORY_ROOT_DIR ${CMAKE_CURRENT_LIST_DIR}/../../) # changes beased on project location in repository
list(APPEND ZEPHYR_EXTRA_MODULES
${REPOSITORY_ROOT_DIR}/zephyr_extra_modules
)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

To summarise the issues (all inside VSCode and not evident in the build)

  • Devicetree files continue to show "Unknown node for type" warnings on the compatible code and errors when added as a child node of a compatible peripheral
  • All driver files except the source file (Devicetree, Kconfig, and CMake) are not visible in the nRF Connect extension view.
  • Zephyr private includes show "cannot open source file"
  • Conflict with CMake Tools extension

Devicetree error on driver node

Driver configuration files not visible in extension view

When writing a Zephyr driver, a significant part of it is the non-source configuration files. It would be really nice if I didn't have to switch views to find them. The source files are listed under "External", could something similar be done under "Input files" for these configuration files?

Whatever way you think is best, reducing reasons to switch tabs makes the VSC development experience much smoother

Includes from the private Zephyr tree

Zephyr has a number of useful utilities for various drivers in the `<zephyr>/drivers/modem` folder and my driver uses some of those files.

This fails inside VSCode but is fine for the build

Fullscreen
1
2
3
4
5
6
zephyr_library_include_directories(
$ENV{ZEPHYR_BASE}/drivers/modem
)
# in source
#include "modem_context.h"
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This works for both

Fullscreen
1
2
3
4
5
6
zephyr_library_include_directories(
$ENV{ZEPHYR_BASE}/drivers
)
# in source
#include "modem/modem_context.h"
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

While I prefer the latter anyway, there is no reason the former should fail (as evidenced by there being no issue building the driver) and include issues are a real drag on the development experience

Extension conflicts with CMake Tools extension (and not auto-disabled in a non-zephyr folder)

The VSCode Cmake tools extension is tries to configure a normal CMake project when a folder with `CMakeLists.txt` is opened (every Zephyr project...). This doesn't work very well with Zephyr projects where west is the build system. As of right now, it would be great if the nRF extension could "claim" the folder or indicate a potential conflict (not sure if this is possible)

Along the same lines, it would be greatly appreciated if the nRF extension didn't try and run on folders that are clearly not nRF firmware projects (currently just generates spurious errors).

My ideal solution to the above would be for the nRF extension to act through CMake tools somehow (particularly for highlighting / suggestions / etc). The CMake Tools extension provides very accurate errors / highlighting / etc and also removes the current conflicting "claims" on the folder