- This topic has 5 replies, 3 voices, and was last updated 3 years, 5 months ago by
.
-
Posts
-
Hello, my task is to port a large project to STM32H743 MCU in VS with VisualGDB . This topic could be of value to many so I assume this is a good place to get such answer. I believe STM32H743 is well supported in VGDB. The code is done in another MCU vendor also based on the same Cortex-M7 . The project should be easily re-configurable in STM32CubeMX tool. Eventually, later on, it will be converted to a stand alone project to preserve customized libraries (but not at this stage of porting code). I would be ecstatic if the project structure and it’s handling were somewhat similar to the Atmel Studio which is also built on the top of Visual Studio.
This site has tutorials on different methods to do that by
- Starting a new STM32CubeMX project in VGDB and then gradually adding code. Creates a CMake project. This has advantages of all the bells N whistles of VS plus easy re-configuration by invoking CubeMX from inside IDE.
- Importing STM32CubeMX (GPDSC format) project. Can choose MSBuild version. Re-configuration of project can be done externally in CubeMX . Still easy configuration.
- Importing STM32CubeIDE which was built using .ioc configuration file. I guess this is similar to the previous method also with re-configuration possible by a stand alone CubeMX but never got through this method project creation.
Unfortunately all those methods had problems for me so far but for this post to be useful to others I’d prefer to focus on the topic here.
Please give advice on the best recommended approach and the reason why.
Thanks in advance for any useful input.
Vlad
I would never build any sort of serious project with VGDB/STM32CubeMX. I use STM32CubeMX for configuring only. The code STM32CubeMX produces is messy, IMHO, and I can’t stand the /* USER CODE BEGIN /ENDs all over the place.
I use objects for maintainability where I can. I’ll first create a STM32CubeMX stand alone project(not VGDB) for just configuring the hardware. I then create my VGDB project and create a, ie. CHardware(.h/.cpp) class, where I’ll copy/paste the hardware configuration from STM32CubeMX into. Everything I need from STM32CubeMX, except the IRQ routines, will go in this class. I keep the handles global and pass a reference to my hardware methods, ie:
bool CHardware::InitUsart1(UART_HandleTypeDef &huart1)True, a bit of pain if making many changes in STM32CubeMX to copy/paste into your project. Maybe there’s better way, but this seems to be a pretty good trade off to write clean/maintainable code while also using the advantages of STM32CubeMX.
Thank you arrow201 for sharing. I used to do something similar to your way about 2 years ago when we used STM32F4 MCU. I am still annoyed today with their “tradition” of re-configuration of user’s files and putting guards USER CODE STARTS HERE … ENDS THERE … nonsense … as if it is too hard to separate users’s only files from system configurable files and also allow users to use files comparison before commit…
As for the topic: back then I did part of development in VGDB and manually pasted CubeMX re-configured updates into the VGDB project. It was fine until project became large requiring more peripherals and managing their configuration became time consuming. Even re-allocating resources between shrinking choices of available pins became time consuming. To focus on application I need simple and easy tool for reconfiguration and I need IDE which simplifies toolchain-related tasks.
Tools like IAR and Keil are out of question for many reasons besides the price tag: when using subcontractors – those all have GCC/Eclipse environment in whatever OS and we are ready for a simple integration…
As for IDE – Visual Studio with GCC is the sweetest combination and VisualGDB strikes the best niche … As for the simple way to (re)configure ARM peripherals, the STM32CubeMX is one of the three best tools on the market today… got to tolerate some nuisances in it (all of them have )…
Thanks again for your input.
Vlad
Hi,
@arrow201, thanks for your input! The STM32CubeMX indeed makes it easier to quickly explore STM32-specific functionality, but makes it harder to maintain the projects in the long term.
@Vlad, the importing methods you mentioned should all work for the scenario you described. VisualGDB can automatically import basic project settings (list of files, include directories, preprocessor macros, linker script), however STM32CubeMX sometimes generates buggy project files (e.g. references non-existing sources or headers), and also some advanced settings (e.g. optimization) would need to be imported manually.Most of the errors with imported STM32 projects come from duplication between the files provided by VisualGDB and the files imported from the project. We have a very detailed documentation page here that explains the typical STM32 project structure and gives an overview of different project subtypes (it does not mention the new STM32CubeMX Wizard yet).
Hello, @support thank you for your input. Only one case in your provided link relates to the CubeMX created project – the Imported STM32CubeMX Project that is probably similar project structure to the scratch-built STM32CubeMX project. According to that tutorial:
The only VisualGDB-managed file will be the startup_stm32xxxx.c file containing the interrupt vector table
No HAL , neither middleware packages are used from VisualGDB in these cases. Only startup file. Is that duplication the most often reason for the problems you mentioned? If so happens, can one file be simply deleted?
Built from scratch STM32CubeMX project been CMake project has quite different structure (and probably handling) from MSBuild … I’d better consider for the start importing a STM32CubeMX (GPDSC) or STM32CubeIDE project (configured with .ioc file) which is MSBuild and then keep adding to it and use CubeMX for re-configuration… so, only to make sure to have only one startup file ?
Vlad.
- You must be logged in to reply to this topic.