March 11, 2018 at 01:55 #20355
Hello, I just downloaded to try VisualGDB. I’m Trying to import examples prepared in STM32CubeF4 folders for Workbench SW4TM32 IDE . Workbench is using the same toolchain as VisualGDB , importing suppose to be rather natural but I cannot find any ways to import/use those examples. I tried to import as a STM32CubeMX project but GPDSC files are not provided there. “Create a project from a custom template” did not find necessary files in the main sourcefiles folders. I didn’t find a user manual for VisualGDB yet – only tutorials. Tutorials are very good but not all topics are covered there…
Please helpMarch 11, 2018 at 02:39 #20356
As a workaround I tried to import from IAR project (also provided in STM32CubeF4 folders) . Import reported success but a followup clean build failed with many C related syntax errors such as “invalid conversion” , “aliased to undefined symbol”, etc…March 11, 2018 at 06:39 #20357
It’s hard to say why the projects didn’t get imported correctly, although our STM32 support package comes with pre-imported ST samples from the original SDK packages (we have tested that each of them builds out-of-the-box). Please follow this tutorial to see how to create projects based on those samples.March 11, 2018 at 14:27 #20359
Does VisualGDB import only those packages which VisualGDB possesses in “pre-imported” ST samples ? Now when I tried to import from newly downloaded STM32CubeF4 folders (copied to my workspace location), following those steps you pointed to , VGDB showed me only “HAL” directory in the examples for my target board (see attachment screenshot) , but there are 4 more directories in the downloaded packages which I need yet not shown in VGDB. After this step , my main goal will be to import a large project from ST which is made for STM32 Nucleo expansion board based on their Cube – I don’t expect VGDB to have that example….. how will I import that?
Is it possible to import a C++ project for STM32 from the user’s repository of the sample code? In other words how to build VS project from the user’s repository of the SMT32 sample code? Do you have tutorial on that? Or does VGDB allow only to import from VGDB provided examples and then user has to manually copy all the contents of the files/directories?
Please clarify and thanks in advance.
- This reply was modified 10 months, 2 weeks ago by Vlad.
Attachments:You must be logged in to view attached files.March 12, 2018 at 05:23 #20369
The examples shown in the VisualGDB project wizard are pre-imported. I.e. we imported them as a part of our BSP building process, verified that they build successfully and computed all the dependency information to ensure you can just pick it in the wizard and get it created. They won’t get changed if you download an SDK manually.
If you want to import a project from your own repository, we provide automatic importers for IAR, Keil and STM32CubeMX projects, e.g. see this tutorial. However projects imported this way might require some adjustments after importing (e.g. if the original project contained IAR-specific code).
Another option would be to use the generic importing logic – it will automatically discover and add the source files from your project directory to the VisualGDB project, but you would need to manually enter various compilation options like preprocessor macros and include directories.
Either way, the most common issue when importing projects is the conflict between the ST libraries shipped with VisualGDB and the ones that might come with the project. You can easily remove the references to VisualGDB-shipped ones via the Embedded Frameworks page of VisualGDB Project Properties, although we do recommend using the startup file that comes with VisualGDB.
If you still encounter strange errors, please feel free to attach the build log showing the exact error messages (and screenshots of the related files) and we can suggest what could be the reason behind them and how to fix it.March 12, 2018 at 16:59 #20372
Hi, thank you for reply. As I said before, we want to import STM32CubeF4 examples made either for SW4TM32 IDE or for Atollic (we’ll use that code for our own subsequent development), both are the same toolchain as VisualGDB, made with STM32CubeMX for Eclipse but VisualGDB required GPDSC files which are not included in STM32CubeF4 examples hence the import process failed. Can you show an example for importing code made for SW4TM32 workbench? I think it could be importing of STM32CubeMX generated project but how to do it without GPDSC file ? The compiler flags should be the same as if built with visualGDB, libraries to be used those which came with STM32CubeF4 distribution, my “unqualified” thinking suggests it should be easier than Keil or IAR, and could be less of manual file structure recreation as in “generic project import”, am I missing something?
March 12, 2018 at 19:30 #20375
- This reply was modified 10 months, 1 week ago by Vlad.
I should mention – the task is simplified by choosing a workspace for VS inside the copied version of all the STM32CubeF4 installation, within examples source code made for SW4TM32 Eclipse IDE, to build DEBUG and RELEASE executables in VS and run it. So there is no need to recreate file tree in another location, neither is needed the translation between different compilers and linkers as they are the same and the resulting VS project files should reference the same libraries and the same include files in the same locations as the original installed projects do. I believe there should be a VGDB tutorial for this scenario.
I believe this kind of tutorial could be the door opening for embedded ARM developers to the convenience of VS to develop their applications instead of spending most the time on developing basic configuration setups for eclipse IDE.March 13, 2018 at 02:27 #20377
Can you suggest the importing procedure for a STM32 code project prepared for any other GCC-toolchain based IDE ?March 13, 2018 at 04:21 #20379
The easiest way to import a generic project (based on a format that VisualGDB cannot parse directly) is to follow this tutorial. It will involve re-entering include directories and preprocessor macros manually, but will import the files automatically.
If you want to import multiple projects of the same format, please consider forking one of our open-source importing plugins. They are designed to be extremely lightweight – as long as the plugin builds the list of source files and options, VisualGDB will automatically manage the project structure and even merge the changes between the 2 projects when they are detected.
P.S. We might eventually support direct importing of SW4TM32 projects, although as the current combination of the pre-imported projects and IAR/Keil importers covers most of the scenarios, we don’t have any specific deadline for it yet.March 14, 2018 at 18:56 #20401
Thank you . I got a complete answer. Before trying that tutorial link you provided I will first try again import from IAR and Keil because those projects are prepared in all STM32Cube demos we need and VGDB has a direct automated import procedure for them. Whence it makes sense that you don’t see importing from SW4TM32 projects as a priority. Yet, taking into consideration that STM purchased Atollic and will use their IDE for a direct in-house support of their MCUs, it probably will make sense for VGDB to add Atollic as a choice for automated import to VGDB.
Hint: I saw a statement made by STM marketing rep that STM will eventually merge Atollic with SW4TM32 as they both based on the same toolchain and Eclipse components
Thank you again. Your help encourages us to have the convenience of VS for our STM32 based development
March 15, 2018 at 04:29 #20419
- This reply was modified 10 months, 1 week ago by Vlad.
No problem. Based on our communication with ST, they consider GPDSC to be the format used for exporting projects to 3rd-party tools and we fully support it (see our STM32CubeMX importer tutorial). Either way, we will continue monitoring the formats used by the ST project samples and will consider supporting more of them in case they change.
You must be logged in to reply to this topic.