Closed LinkHyrulian closed 2 months ago
sean-mcmanus
commented
2 months ago @LinkHyrulian If your includePath has
"${workspaceFolder}/CM4/Core/Inc",
"${workspaceFolder}/CM7/Core/Inc",Then IntelliSense will first try to use main.h in the CM4 folder. That is the same way a compiler would behave. How are you telling your compiler which directory to use. You could potentially configure using compile_commands.json or CMake/Makefile Tools extensions. I'm not sure what you're asking for.
Colengms
commented
2 months ago Hi @LinkHyrulian .
A base configuration in c_cpp_properties.json will apply that same configuration (as compiler args to the IntelliSense compiler front-end) to all files you open. It's a good way to configure a self-contained project, in which all files are built the same way, with the same include paths, etc.. If you have a scenario where you're opening a root level directory that contains various subprojects, that configuration is likely not right for all files.
The best way to configure any specific file for IntelliSense would be to use the same command line that was used to build the file. Since you mentioned using a Makefile, you might try using the Makefile Tools extension, as Sean suggested. That extension acts as a 'custom configuration provider' to the C/C++ Extension and provides IntelliSense configurations on a per-file basis, directly from the build system. If you have a root level Makefile that can build those subprojects, Makefile Tools may be able to configure everything correctly.
LinkHyrulian
commented
2 months ago Thank you for the responses.
Since this is a dual core setup, each core has its own Makefile. The Makefile for the CM4 core has the following:
C_INCLUDES = \ -I../../CM4/Core/Inc \ -I../../Drivers/STM32H7xx_HAL_Driver/Inc \ -I../../Drivers/STM32H7xx_HAL_Driver/Inc/Legacy \ -I../../Drivers/CMSIS/Device/ST/STM32H7xx/Include \ -I../../Drivers/CMSIS/Include
The Makefile for the CM7 core has the following:
C_INCLUDES = \ -I../../CM7/Core/Inc \ -I../../Drivers/STM32H7xx_HAL_Driver/Inc \ -I../../Drivers/STM32H7xx_HAL_Driver/Inc/Legacy \ -I../../Drivers/CMSIS/Device/ST/STM32H7xx/Include \ -I../../Drivers/CMSIS/Include
Each core is compiled separately, each with its own Makefile. Is there a way Makefile tools can be setup to handle a situation like this, which uses two makefiles in a single project folder?
Colengms
commented
2 months ago Hi @LinkHyrulian . There is a repo for Makefile Tools here: https://github.com/microsoft/vscode-makefile-tools . I'd suggesting opening an issue there, and describing your scenario.
LinkHyrulian
commented
2 months ago @Colengms Copy that, thanks for your help.
Environment
Bug Summary and Steps to Reproduce
Bug Summary: It is the exact same issue documented here, but I have some things to add: https://github.com/microsoft/vscode-cpptools/issues/12296
My scenario:
My company recently wants to begin development using the STM32H745IIK6 which is a dual core processor developed by STMicroelectronics. Using their STM32CubeMx tool, I can initialize the features on the MCU and generate a Makefile output which includes two main files, one for each core in the following folder structure where CM4 and CM7 are the two cores: Project/CM4/Core/Inc/main.h Project/CM4/Core/Src/main.c
Project/CM7/Core/Inc/main.h Project/CM7/Core/Src/main.c
The STM32CubeMx generator provides no option to rename the main files to a name of my choice so if I was to do so manually, every time I had to regenerate code from the MX tool in the future, I would have to then manually rename the main files as well as every reference to their headers in my code. Thus it would be a tedious headache to manually change them to allow Intellisense to work.
I tried both suggestions in the linked issue #12296 which suggests to #include <dir1/dummy.h> as well as reordering the includes in the c_cpp_properties.json include path, but neither of these suggestions works. The following is what my c_cpp_properties.json file looks like:
{ "configurations": [ { "name": "STM32", "includePath": [ "${workspaceFolder}/Drivers/STM32H7xx_HAL_Driver/Inc", "${workspaceFolder}/Drivers/CMSIS/Include", "${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32H7xx/Include", "${workspaceFolder}/CM4/Core/Inc", "${workspaceFolder}/CM7/Core/Inc", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/lib/gcc/arm-none-eabi/13.2.1/include", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/include/gdb", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/arm-none-eabi/include/c++/13.2.1", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/arm-none-eabi/include", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/arm-none-eabi/include/machine", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/arm-none-eabi/include/newlib-nano", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/arm-none-eabi/include/sys", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/arm-none-eabi/include/c++/13.2.1/arm-none-eabi", "${workspaceFolder}" ], "defines": [ "CORE_CM7", "USE_HAL_DRIVER", "STM32H745xx" ], "windowsSdkVersion": "10.0.19041.0", "compilerPath": "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/arm-none-eabi-gcc.exe", "cStandard": "c17", "cppStandard": "c++20", "intelliSenseMode": "gcc-arm", "browse": { "path": [ "${workspaceFolder}/**", "${workspaceFolder}/Drivers/STM32H7xx_HAL_Driver/Inc", "${workspaceFolder}/Drivers/CMSIS/Include", "${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32H7xx/Include", "${workspaceFolder}/CM4/Core/Inc", "${workspaceFolder}/CM7/Core/Inc", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/lib/gcc/arm-none-eabi/13.2.1/include", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/include/gdb", "C:/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/arm-none-eabi/include" ], "limitSymbolsToIncludedHeaders": true, "databaseFilename": "${workspaceRoot}/.vscode/browse.vc.db" } } ], "version": 4 }
My current workaround is to comment out the "${workspaceFolder}/CM4/Core/Inc" line if I'm working on the CM7 core, and to comment out the "${workspaceFolder}/CM7/Core/Inc" line if I'm working on the CM4 core but this is very inconvenient.
Is it possible that you could come up with an update to the Intellisense tool that allows same file names in different directories? Or if you have a better workaround for this issue that what I've come up with in commenting those lines, it would be appreciated.
Thanks for your time.
Steps to reproduce: See the link to the 12296 issue.
Expected behavior: Provide an update to the tool that allows same file names in different directories or at least provides a simple workaround for this issue.
Configuration and Logs
Other Extensions
No response
Additional context
No response