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

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

crzyrndm — Tue, 02 May 2023 20:46:20 GMT

New ticket here devzone.nordicsemi.com/.../high-idle-cpu-usage-with-vscode-and-more-streamline-vscode-actions

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

Øyvind — Tue, 02 May 2023 12:22:17 GMT

Hi! Thanks for confirming that the issue is resolved. I have forwarded the feature request to improve "Actions" buttons.

As the CPU idle time is not related to the out-of-tree driver. Could you please open a new ticket with your issue to keep this ticket on topic?

Thanks!

Kind regards,
Øyvind

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

crzyrndm — Mon, 01 May 2023 21:26:34 GMT

Can confirm that the issues mentioned previously now appear to be resolved

Out of tree driver is now not showing random errors on includes
mbedtls source is correctly highlighted

The next major issue on my list would be the idle CPU usage and general lack of responsiveness of the extension

The above was captured after ~5 minutes of no code changes (project has been open for a long time) on an i7-12700. I'm also seeing noticable lag in the on-hover tooltips (lots of "Loading..." before displaying the content)

^^ Is taken from the C/C++ log view (log level turned to Debug). This is occurring with no files currently open and never seems to complete

Speaking of inconveniences, Actions has a few edges that could be smoother

It would be good to be able to configure a few defaults for the actions buttons

"Erase and Flash" is *much* faster than the default "Flash" action and I generally do not need to use the slower option. Would be great to be able to swap the default here
- Also would like to use this for "Debug" as well
"Flash" action does a build first, "Debug" doesn't. While I do get the reasoning to allow this, making it the default is frustrating. An easy way to change this default would be greatly appreciated
- There is the "preLaunch" launch config option, but a) not sure how to refer to the build action and b) it hardcodes the build folder and again not sure how to get around that

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

Øyvind — Tue, 11 Apr 2023 14:11:18 GMT

Thanks for reporting. The VS code team have the following answer to this:

That's a proper bug in the extension - actually, it's two:

On Windows, the TF-M build system appears to be writing source files with a capital letter for the drive in the source file path (C:\), but the Microsoft C++ extension converts all drive letters to lower case. Windows paths are case insensitive, but our source file lookup wasn't, so we ended up using the includes for the wrong file in TF-M on Windows.

MBED uses #include MBEDTLS_CONFIG_FILE to link in the configuration, but cmake inserts an extra escape character before the quotes in defines, which we don't properly un-escape. This breaks this include statement, and defines like MBEDTLS_SSL_CLI_C are lost.

Both issues will be fixed in the next release, which is scheduled for the end of next week. I believe the NRFX_CHECK define issue is a different problem originating from the Microsoft C++ extension, similar to https://github.com/microsoft/vscode-cpptools/issues/3109. The go to definition call works just fine if I copy it out of the NRFX_CHECK macro to the line above, so it's being evaluated differently when passed to the macro, for some reason. I can't seem to reproduce it in a reportable manner, but I'll try to make an issue for the C++ extension all the same. It'll likely take a bit longer before it's fixed though.

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

crzyrndm — Sat, 08 Apr 2023 23:35:07 GMT

I think the C++ extension may be having issues with any Zephyr "module", not just one added through ZEPHYR_EXTRA_MODULES or just include directories (also what I thought was a fix before didn't continue working. I have no idea how I got it to work for a little while, but it's definitely not the problem I initially thought it was)

mbedtls is a very obvious example as all of it's source files are wrapped in

#if defined(MBEDTLS_FEATURE)
and no matter what the options are enabled, the code is always highlighted as
if the option was not defined. Using ssl_cli.c as an example, opened by
clicking on the file in the "nRF Connect SDK/modules/crypto/mbedtls/library"
folder (note that the debugger has no issues stepping through these files)
files under "zephyr", "nrf", and "nrfxlib" seem to work fine, it's just
modules that are sketchy (including hal/nordic/nrfx)

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

Øyvind — Wed, 29 Mar 2023 07:10:48 GMT

Hello, our VS Code teams appreciates the feedback and provide the following feedback:

As they point out, the DeviceTree issue comes from the usage of ZEPHYR_EXTRA_MODULES. We're not currently including that in the search path for devicetree (and some other parts), but we should be.

The suggestion about driver configuration files is something we hadn't considered or gotten feedback about before, but it makes a lot of sense. We have an upcoming task to clean up the input file section already, as it's a bit messy. We'll make sure to take this into consideration.

The custom include paths issue is surprising, as I'd expect the C++ extension to be able to pull this out of cmake. I'll go through it and see if there's anything that's not working as intended there. It'd be interesting to know whether their build directory contains a compileCommands.json file. If they built their app with the extension, it should, but if it was build manually, it might be missing. Without it, we make a best effort guess at the compilation flags, and I'm not sure we'd be able to pick up things like this in that case.

The CMake extension was marked as a conflict pretty early on, as it had some fundamental compatiblity issues with Zephyr, as discussed in this issue in their extension repo: https://github.com/microsoft/vscode-cmake-tools/issues/915 (also see issue #1120 and #1374). They released a version that attempts to solve these issues in January though (v1.13.40), and we plan to do a re-evaluation of this conflict, as it's a pretty useful extension

Kind regards,

Øyvind

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

Øyvind — Mon, 27 Mar 2023 09:28:58 GMT

Hello,

Thanks for providing this feedback. I will forward it to our VS Code extension team and get back to you.

Kind regards,
Øyvind