March 25, 2021 at 04:07 #30233
I am currently switching from MSBuild projects to advanced cmake projects and I really like the options available to share code between different targets.
I have two questions:
- I have also a few libraries that are shared between several projects in one solution. Until now (with MSBuild) I managed it with static libraries that were referenced in the embedded projects. I could do this similarly in the advanced cmake projects by adding “Library From Existing Code” and not copying the files into the project folder. However, I like the framework feature very well. Would it also be possible to create custom stand-alone frameworks that could be added to the different projects? If yes, how could I do this? Currently I only found the way to add frameworks via the project properties, but therefor I would need a package that is imported by the VisualGDB packet manager, right?
- How can I define custom BSPs? I have my own peripheral library for the controllers I use that build on top of the manufacturer libraries to provide an abstraction layer. I would like to create my own board support package that includes the manufacturer libraries (core), my own library as a framework for example and further frameworks like FreeRTOS,… . What is the best practice to achieve this?
I hope you can help me here. Thank you!
EliasMarch 25, 2021 at 08:14 #30237
No problem, please refer to the following page for a very detailed overview of custom frameworks, BSPs and other ways of managing shared code: https://visualgdb.com/documentation/embedded/bsps/March 25, 2021 at 09:23 #30238
thanks for the fast reply. The link you provided does not answer all my questions. I do understand now how to create custom BSPs but I still haven’t found an easy way to create stand-alone frameworks, that than are in the framework library of VisualGDB. I managed to create an own simple framework by creating my own framework.cmake and added the framework to the project with import_framework() (for the controllers I use (Infineon XMC4XXX) there was no framework available that I could make stand-alone and adapt than). But I have not found a way to do that automatically (creating a new stand-alone framework with the framework.cmake). It would be also nice to have the possibility to add the own frameworks in the project settings or in the context menu (right click on the project > Add > New Item > “Framework” or something similar). Is something like that planned for the future?March 25, 2021 at 09:30 #30239
Indeed, the only way to create stand-alone frameworks currently is to clone an existing framework from the BSP. If you are using a device family that does not include any frameworks, please consider creating a temporary project for a different device, cloning one of the frameworks there and editing it manually. We will try to add support for creating the frameworks from scratch to one of the next VisualGDB releases.March 26, 2021 at 03:38 #30244
that would be great, if you could integrate this functionality into one of the next releases. In between it would massively help if you could provide us a detailed documentation about the structure of the efp.xml and the framework.cmake files (what are the options? what must be included?). If this information is provided it would be much easier to create stand-alone frameworks manually.
Thanks!March 26, 2021 at 08:22 #30246
No problem. The EFP.XML file is a reflection of the EmbeddedFrameworkPackage type from the BSPEngine assembly. You can try opening one of our open-source BSP generators and navigating to the definition of EmbeddedFrameworkPackage to see a full list of members.
You can find some basic documentation on the BSP and framework mechanism here: https://github.com/sysprogs/BSPTools/wiki
Generally, if you are planning to heavily invest into making multiple frameworks for your environment, we would advise cloning one of our open-source BSP generators and stepping through its logic of generating the BSP. E.g. the CC3220 generator relies on a relatively small SDK and produces a BSP with many frameworks. You can then make a similar generator for your own BSP, or modify it to just generate framework definitions (in BSP generators, the frameworks would end up inside the BoardSupportPackage object, while in framework packages they would be placed under EmbeddedFrameworkPackage).
If you are looking to create a relatively small and simple framework, the easiest way would be to download our advanced semihosting and profiler framework, and create your own one by modifying its EFP.XML file. The definition of the profiler framework uses most parts of the framework engine, so it could be used as a good starting point.March 26, 2021 at 12:08 #30247
Thank you for the information. I will get deeper into that.
Further exploring the features coming with advanced cmake projects I also tried the simulation feature.
There I came across the following problems:
Building with the MinGW toolchain I get the compiler error “crtdbg.h: No such file or directory”. This error is gone, if I build with the MinGW32 toolchain. But than I face an other problem: I can successfully build the project but debugging does not work. When I hit “Start debugging”/F5 I get the error “undefined reference to WinMain@16”, so it cannot find my main function. Are you familiar with these problems?
I have also started a completely new unit test project with advanced cmake (XMC4500 controller), same problems than.
Hope you can help me, I would really like the feature to test software without the need of the controller hardware.March 26, 2021 at 12:16 #30248
Most likely, your Windows port ended up missing some of the parts required by the Windows platform. We can gladly review your project and point out what is causing the issues as a part of our consulting services. Feel free to forward it to us and we will give you a quote.
Alternatively, please try following our simulation platform tutorial. Make sure you select the device, toolchain and other options exactly as shown in the tutorial, and you should be able to get a usable project that includes all the necessary parts. You can then use it as a reference to fix the errors in the current project that doesn’t build.March 28, 2021 at 04:18 #30261
thank you for your reply. I managed to fix the problem by using mingw32 or mingw64 instead of mingw. The problem with not finding the main function was gone as I started a new project in a new, clean solution.
I have now finished setting up my custom BSP. During exporting it to a regular BSP I am facing the following problem:
Everything works fine if I do not attach sample projects. But if I add at least one sample project, I get the following error during file copying: “Could not find a part of the path ‘D:\…\Custom.XMC4500BSP\samples\TestExecutable\TestExecutable/src/TestExecutable.cpp’. Note that “…” is a placeholder I put there, in the error message there is the full path. What seams a bit suspicious instead is that there are backslashes and forward slashes mixed in the path. The .cpp files are all added to the executable (Add > Existing Item > …). The folder “…\Custom.XMC4500BSP\samples\TestExecutable\” is empty. So neither the sub folder TestExecutable, src or TestExecutable.cpp exist there.
When I remove the TestExecutable.cpp from the executable there are no errors occurs and the BSP export is successful.
Is there any problem with having files in sub folders in a project to use it as a sample project?
Hope you can help me here as well.March 28, 2021 at 09:19 #30262
We would advise comparing the sample definitions with the existing BSP (where the examples work). E.g. you can copy a single sample project from the regular BSP, make sure it works, and then modify it, one step at a time, to match the custom example you would like to ship with the BSP. If you verify that the examples work after each step, you can easily find the step that causes the build errors.March 28, 2021 at 10:07 #30263
the problem does not occur during building but if I want to export my bsp as a regular bsp. In the file copying process the error I mentioned appears. Did you try this process if your source files are in sub-directories within the project? I only get the error in the case of having my sources in sub-directories…
An other (and hopefully the last problem) I came across. I use the regular XMC4500_F100x1024 BSP with the Fast Semihosting and Embedded Profiler framework. I am also using FreeRTOS, so I have defined the USE_FREERTOS preprocessor directive. The FreeRTOS is integrated into my custom stand-alone framework, which I have integrated into my project (and referenced at the executable). When I want to build the target I get the “FreeRTOS.h No such file or directory” of the ProfilerRTOS_FreeRTOS.c file. This file is part of the BSP and my FreeRTOS is inside an other framework (I can see the FreeRTOS.h file in my solution explorer, it is correctly added by the EFP.xml). What can I do to let the compiler find this file during building ProfilerRTOS_FreeRTOS.c?March 29, 2021 at 14:01 #30268
Thanks for pointing out the subdirectories. We have rechecked it and indeed, one of the cases with subdirectories in project samples was not handled correctly. Please try this build: VisualGDB-22.214.171.12474.msi
In order to use the Fast Semihosting and Profiler framework with FreeRTOS, please make sure that the BSP defines the USE_FREERTOS macro and adds the directory containing FreeRTOS.h to the include search path. The easiest working example of it would be the STM32 BSP (search for AdditionalIncludeDirs and AdditionalPreprocessorMacros in the BSP.XML file).March 29, 2021 at 23:48 #30270
thank you very much for checking it again and fixing it! I will try this build right away.
Of course, if I have the FreeRTOS as a part of the BSP eveything works fine. But I actually do not want that, because it would mean, that the FreeRTOS is not available for the Simulation platform. I currently use the FreeRTOS inside a standalone embedded framework included into the project. With this setting I can also use it during Simulation (with the FreeRTOS Windows port). As the BSP gets built as a seperate embedded library it of course does not find the header files of an other embedded framework in the project during build. Currently my work-around is to add the header files of FreeRTOS to the BSP too, so it can build and the linker finds the references inside the embedded framework of the FreeRTOS anyway. Maybe you have a more elegant way to achieve this?March 31, 2021 at 11:03 #30284
This would involve manually editing the CMakeLists.txt files created by VisualGDB. You can generally use the if (SIMULATION) syntax to make sure that a certain part of the CMake script will only be relevant to the simulation platform, or vice versa. E.g. you could define different versions of the same library for simulation vs. hardware, or 2 different versions of the statement that references common libraries.
That said, editing the project structure via Solution Explorer will ignore the parts of CMakeLists.txt that are currently inactive, that may lead to build errors later. We can only recommend this for users familiar with CMake semantics that are OK editing the generated scripts manually and troubleshooting possible errors later. If you would like to rely solely on GUI, please try using #ifdef SIMULATION in the code instead.
You must be logged in to reply to this topic.