- This topic has 4 replies, 2 voices, and was last updated 4 years, 5 months ago by
.
-
Posts
-
I’m building a project for a Silabs EFR32MG12 and need to convert this to a standalone project because the BSP is old; deprecated em_* files, old linker, and old startup files. So I’d like to convert to a standalone project WITHOUT copying the BSP. There is some weirdness though.
- The old peripheral register definition .xml is referenced but because I chose NOT to copy the BSP it doesn’t reference the correct location. As a result debugging doesn’t work.
- In the Project Properties there is a relationship between the Embedded Project tab and the Makefile Settings tab that is very confusing. I think the Embedded Project tab applies to both the Debug and Release builds but all of the options aren’t available in that tab. For instance, the Embedded Project tab doesn’t include the Library Directories, Library Names, or CXXFlags fields, etc. Presumably the only thing you really want to change between the Debug and Release builds is the optimization, but to get the same build in both you’d have to manually add the same options to both builds. Why aren’t all of the options available in the Embedded Project tab?
- It’s easy to get the options on the Embedded Project tab and Makefile Settings tab out of sync. If you forget to add an include path and you do it through the IDE it adds it to the options in the Makefile Settings tab, not the Embedded Project tab. That means the change will only apply to whichever build configuration you’re current in (Debug or Release). That doesn’t seem right
Thanks for confirming your license. We will try to explain what is going on.
When you convert the project to a stand-alone one without copying the BSP files, it removes the references to all files from the BSP (including the linker script, register definition file, common preprocessor macros, etc). This option is intended for advanced users that would like to manually re-create the minimum necessary subset of files from scratch. It indeed will not result in a buildable project and will require some manual tweaking before you can get it to work. We have confirmed that this option left the reference to the register definition file (but did not copy it) and updated VisualGDB internally to remove the reference.
If this behavior is not intended, please try copying the BSP instead, and then remove the unnecessary files. This way you will start with a usable project and will be able to verify that it still builds after each step.
Also, depending on your requirements, you may not need a stand-alone project after all. If you want to remove the standard driver files, but keep the linker script and peripheral register definitions, you can simply unreference them on the the Embedded Frameworks page instead.
Regarding the out-of-sync Makefiles, this is a known limitation of the GNU Make build subsystem (see this page for a list of known limitations). For all new projects we advise using MSBuild instead. It does not require duplicating the settings between Visual Studio and the actual build subsystem (i.e. GNU Make) and hence eliminates many possible failure points.
If you would like to build the project outside Visual Studio, you can try out our experimental Embedded CMake integration. It combines the advantages of both GNU Make and MSBuild:
- The build is entirely managed by CMake scripts, that you can easily edit and build outside VisualGDB.
- Solution Explorer contents is rendered based on the exact CMake code model, so it’s always up-to-date.
- It also does not have multiple sets of settings for debug/release, avoiding the issue you mentioned.
The Embedded CMake projects are currently still very experimental and cannot be created using the wizard yet, but if you would like to try them out, we can share the instructions here.
Thank you for the explanation. I was not aware I could unreference the efm32 EMLib files on the Embedded Frameworks page. I think that may be part of what I’m looking for.
If I decide a standalone project is what I need how do I reference the correct peripheral definitions file? Just copy the .xml somewhere and change the settings to point to it? If this is the case do I need the .xml or the zipped .xml.gz?
I’d love to use MSBuild but it doesn’t have many of the exposed options I need. No CXXFLAGS, no COMMON FLAGS, no LINKER FLAGS. Am I missing something there?
I might have to check out the CMake experimental stuff. Thanks for the tip.
No problem. MSBuild does support common flags and linker flags via Configuration Properties -> C/C++ -> Command Line. If you need separate C/C++ flags, you can set them via C/C++->Advanced.
We do advise reading our documentation on MSBuild and STM32 project structure. It’s a long read, but it gives an extensive overview of all common settings types, and will save you considerable time long-term once you learn how to use it efficiently.
You will also get much faster build times, fewer rebuilds, single-file building, precompiled header support, and many other usability features that are not supported for Make projects.
- You must be logged in to reply to this topic.