Intellisense configuration

[sb_st]

Hi, I am trying to transition from cubeIDE to the VSCode workflow, and am having trouble getting intellisense working. I'm relatively inexperienced with this (I appreciate that cubeIDE 'just worked' in this regard, and I never had to deal with figuring out how to configure this). 

I've tried starting from a relatively vanilla state - I only install the STM32CubeIDE VSCode extension pack. I *think* I need to also install the C/C++ extension from MS in order to get/enable intellisense for developing stm32 projects (?)

Within my project, some things seem to work - I can right-click on some functions and see/jump to definitions. In other cases, I see errors about undeclared variables/defines/macros or other miscellaneous "problems", none of which the compiler actually complains about. I'm confused why this seems spotty within the project. 

Then, I have an out-of-project shared code area. I've set this up relatively simply (there are no "library" CMakeLists.txt files in this area, just .c/.h files), and intellisense seems completely unable to make sense of this area. There are hundreds of problems reported, red squiggles everywhere, but again when I build, there are zero errors, so I'm pretty confident this is just intellisense not being configured properly. This, again, was not an issue I had to grapple with with cubeIDE, so I'm trying to come up to speed with how to manage it here. 

I'm curious if there's a resource offering some tips about how to be doing this?

[KnarfB]

The STM32CubeIDE VS Code extension does not rely on IntelliSense; instead, it uses clangd as its language server for code completion, syntax highlighting, and related features. Because IntelliSense and clangd conflict with each other, it’s best to disable IntelliSense when using this extension.

Clangd provides accurate results once the project has been built at least once. This is because clangd depends on the compile_commands.json file generated during the build process to deliver precise code analysis and enhancements.

hth

KnarfB

[sb_st]

This is fantastically helpful, thank you so much. 

To try to get myself into a better state, I've removed the C/C++ extension for the moment. And - with apologies that this may stray outside the bounds of what's appropriate to ask for support with here - I wonder if you can help me understand how I may best structure my code/workspace to work the way ST intends withVSCode. 

I mentioned previously that I have an STM32project (that was created by cubeMX using CMake), and I also have a code area outside this project that contains what I'll call "reusable code". So, like:

/dev
  /my_stm32_project
  /my_reusable_code
    /my_driver
      -my_driver.c
      -my_driver.h
    /my_math_library
      -my_math_library.c
      -my_math_library.h
    /my_useful_constants
      -my_useful_constant.h

I wouldn't call the "resuable code" area fancy - it's just my attempt to reduce redundancy in my repo. It *seems* like I am expected not to be doing this, and that all code for a given project is meant to live within the project folder itself (at a cost of potential redundancy, if the same code is used in a different project)? I'm honestly not quite sure. 

My my_driver.c uses some HAL functions...so my project needs to see/use my_driver, and my_driver needs to be able to understand how to 'see' the HAL library files when being used in a given project. Again, maybe this is terrible - this all 'just worked' with cubeIDE, but I'm unsure if this is considered a poor practice in the VSCode context. 

I initially tried following the design pattern I see inside the cubemx-generated cmake folder within my project -  which seems to refrain from splitting everything into CMake libraries, and instead just relies on large lists of .c files and include directories, and the target_sources() and target_include_directories() commands - to link my out-of-source files/folders. This compiles fine, but clangd seems to not be able to understand the relationship between these out-of-source files and my project files, and complains "'stm32f4xx_hal.h' file not found" about my my_driver.h file (with heaps of other errors about associated HAL functions as well). 

After bit of googling/AI chatting, I tried restructuring things slightly to include CMakeLists.txt files in each of my my_reusable_code subdirectories, to properly create CMake libraries from each of them, and then link them using add_subdirectory() and target_link_libraries() commands (instead of target_sources() and target_include_directories()). This also compiles fine, but still does not seem to resolve the clangd errors I'm seeing. 

Admittedly I am banging around clumsily here, because I don't fully understand what expectations clangd has that I am apparently violating. I'd love to better understand either what I'm doing wrong, or what I might try that would make clangd happier with my setup. 

Thank you!

[sb_st]

Hm, Gemini is sending me down the path of constructing an abstraction layer between my shared code and my application code, as a way to strictly remove HAL stuff from my shared code. I'm not an experienced enough embedded software engineer to know whether this is a good idea in this context - I recognize the benefit, but the cost seems to be a fair amount of added complexity, and I tend to like to prioritize simplicity where I can. It also seems particularly irksome to to all this just to satisfy clangd, because my project already compiles fine as-is, so I need to think a bit about whether the juice would be worth the squeeze with this approach...

[sb_st]

Still banging around on this trying to get it to work - this is quite demoralizing. 

The exercise of trying to solve this by writing an interface was a bit of a boondoggle. The crux of the issue here seems to be getting clangd to understand stuff that isn't located within the main stm32 project folder. 

Where I am at right now:

• I have started a fresh, empty vscode workspace
• I add one single stm32 project to the workspace
• I add my shared code folder to the workspace
• I can compile this code fine - zero errors/warnings
• clangd seems unhappy when browsing the code in the shared folder. 

I have tried including this shared code simply as extra files, and I've tried making cmake libraries in each...neither seems to help clangd (and I understand that cmake is separate from clangd). 

I tried modifying my workspace file to include an argument I found on clangd's website, which seems intended to solve this problem ("--compile-commands-dir"), but it too has no effect:

{
	"folders": [
		{
			"name": "my_components",
			"path": "../my_components"
		},
		{
			"name": "my_stm32_project",
			"path": "."
		}
	],
	"settings": {
		"stm32cube-ide-clangd.arguments": [
			"starm-clangd",
			"--query-driver=${env:CUBE_BUNDLE_PATH}/gnu-tools-for-stm32/13.3.1+st.9/bin/arm-none-eabi-gcc",
			"--query-driver=${env:CUBE_BUNDLE_PATH}/gnu-tools-for-stm32/13.3.1+st.9/bin/arm-none-eabi-g++",
			"--compile-commands-dir=${workspaceFolder:my_stm32_project}/build/Debug"
		],
		"stm32cube-ide-clangd.path": "cube"
	}
}

 I'm trying to be a good citizen and teach this to myself, but I sure would be grateful for any advice. 

[sb_st]

This seems to encourage better behavior from clangd:

{
	"folders": [
		{
			"name": "my_components",
			"path": "../my_components"
		},
		{
			"name": "my_stm32_project",
			"path": "."
		}
	],
	"settings": {
		"stm32cube-ide-clangd.arguments": [
			"starm-clangd",
			"--query-driver=${env:CUBE_BUNDLE_PATH}/gnu-tools-for-stm32/13.3.1+st.9/bin/arm-none-eabi-gcc",
			"--query-driver=${env:CUBE_BUNDLE_PATH}/gnu-tools-for-stm32/13.3.1+st.9/bin/arm-none-eabi-g++",
			"--compile-commands-dir=${workspaceFolder}/build/Debug"
		],
		"stm32cube-ide-clangd.path": "cube"
	}
}

(it seemed to be that ${workspaceFolder:my_stm32_project} was not being properly resolved, whereas ${workspaceFolder} does. I do not understand why). 

This also negates the requirement for an interface, which might be a fine thing to exist, but is not necessary nor directly related to clangd in this case. (talking to an AI chatbot about this is 20% helpful and 80% untangling all the stuff it conflates/gets wrong).