- This topic has 7 replies, 2 voices, and was last updated 1 year, 1 month ago by
.
-
Posts
-
Hi Support,
I have created a STM32CubeMx project (in this case for the Nucleo-F429ZI board) and generated a STM32CubeIDE project. When I import that project into VS using the Embedded Project Wizard, I end up with incorrect filters and allocated files.
The “Header files” filter contains other sub-filters (including source folders), but no actual files. The “Source files” contains sub-filters (including header folders), plus source and header files. If attached a screen shot of it.
Is that expected behaviour or is there something wrong with my configuration?
Cheers
David
Hi,
This should not normally happen, however it’s hard to determine the exact cause of it from the screenshot. Normally, we would advise using Advanced CMake – it is fully controlled by VisualGDB and should work better in most cases.
If you specifically would like to use MSBuild and it’s not working, feel free to attach the sample project that you are importing, and we can recheck if we can reproduce the issue.
Hi Support,
Importing an STM32CubeIDE project with MSBuild or GNU Make populates the filters incorrectly. Using the CMake method imports correctly (although it still creates unnecessary empty filters e.g. an “Inc” directory will create an empty “Inc” filter under the Source Code filter – no bid deal).
I have attached an example STM32Cube project for you to try.
I have been resisting the move to CMake because it has more out-of project dependencies than GNU Make, but it looks like I will need to make that leap. Is there a tutorial on how to setup up a build server with a CMake build? installations, command lines, etc. If not, I will ask my questions on a separate log.
Cheers
David
Sorry the file is too big. I’ve removed most of the source files so it wont compile, but it should still show you how the import works.
Hi Support,
I’m starting a new STM32Cube project and will be using CMake to build for the first time. I’ve noticed some issues with the generation of the filters in VS:
- I create STM32Cube project and import it into VS. I then build the project successfully. Later, I add a new middleware module (e.g FreeRTOS) in STM32Cube and re-generate the stm32Cube project and code. The next time I open the VS project, it detects the STM32Cube project has changed. I hit the resolve button. It imports the new files ok, but they are not under any filters. When using GNU Make, this process worked correctly. Btw, the filters are created correctly if I had included FreeRTOS in the initial project creation. It is only adding it later is a problem.
2. When I add a folder recursively (Add -> Import Folder Recursively) it doesn’t add them under any filter (like above) even though that option is selected in the dialog. I don’t think this process worked with GNU Make either.
3. I’m not sure if this next issue is by design or a defect. When it initially imports the STMCube project, and it comes across a folder (say “Inc” containing *.h files), it creates two filters called Inc under the Source Files and Header Files. However they are not independent. The one under Source Files is empty and if you delete it, the one under Header Files (which contains actual files) is also deleted. I can see this might be advantageous if you have a folder containing both source and headers files, but when they are already separated, it is confusing having an empty Inc filter under Source Files.
I can fix all the problems manually, but regenerating a project or dragging in existing code with complex directory structures will be time consuming.
Can you let me know if I’m doing something wrong or if there is a workaround?
Cheers
David
Hi,
OK, we have investigated the issue with MSBuild projects. Turns out, it was a combination of the Visual Studio bug we reported in May, and a change in the STM32IDE project structure, that referenced the headers in a different way, that interfered with one of the workarounds used for older projects.
We have fixed it in this build: VisualGDB-6.0.2.4922.msi
With CMake, VisualGDB would normally group the source files by their physical paths, hence the source/header filters would indeed be linked to each other. If you wish, you can disable the splitting into sources/headers entirely, or disable grouping by paths and group by virtual folders instead (similar to MSBuild). See this page for more details.
In general, CMake projects support multiple targets (applications/libraries) within the same project. If you are importing a large external library with a non-trivial folder structure, we would advise putting it into a separate static library (see this tutorial). It will appear under a separate node in Solution Explorer (side-by-side with the application node, but within the CMake project node). If you have multiple such libraries, you can organize them arbitrarily by creating virtual target folders (target grouping is separate from source file grouping, so you can group targets by their function, and keep path-based grouping for files).
The best of organizing the code this way is that the library-specific settings will be stored in the library’s CMakeLists.txt file, separate from the rest of the project. E.g. if the library has some public include directories and expects certain preprocessor macros, you will only need to specify it once, and can then reference that library from any other embedded project, and VisualGDB will automatically combine the project-level settings (e.g. target device) with library-level settings (which sources to build and which include directories to use).
- You must be logged in to reply to this topic.