VisualGDB 5.5 RC1 is Out

Today we are excited to announce the release of VisualGDB 5.5 RC1. Aside from numerous usability and stability improvements over the Preview builds, it introduces the new Embedded CMake Project Subsystem that delivers exceptional flexibility and usability for complex embedded projects. In this post I will show you the main highlights of the new subsystem.

Multi-Target Projects

One big limitation of the MSBuild-based Embedded project layout is the requirement to have only one target (e.g. application or static library) per project. Multiple targets would imply multiple projects, each one with its own copy of global settings, a separate project file, and various auxiliary files. If your project structure involves multiple applications and libraries relying on each other, managing it with MSBuild could quickly become quite bothersome.

The Embedded CMake Project Subsystem addresses this by decoupling project-level settings (e.g. toolchain, debug interface) from the target definitions (e.g. defining static libraries and references between them). A single project can now contain an arbitrary number of applications and libraries spanning across any number of directories:The definitions for these targets are stored in CMakeLists.txt files and are decoupled from the global settings, such as the specific toolchain:

add_bsp_based_executable(NAME EmbeddedCMakeDemo
	SOURCES
		EmbeddedCMakeDemo.cpp
	GENERATE_BIN
	GENERATE_MAP)
 
add_bsp_based_library(NAME EmbeddedStaticLibrary
	SOURCES EmbeddedStaticLibrary.cpp)
 
target_link_libraries(EmbeddedCMakeDemo PRIVATE EmbeddedStaticLibrary)

So if you have a single reusable library included from many projects built with different toolchains, you only need one reusable definition of it.

CMakeLists.txt can contain conditions, internal variables, custom macros, and everything you need to script your complex setups. VisualGDB even lets you step through them in the CMake debugger to quickly troubleshoot any unexpected behavior:

Multiple Platforms

Another limitation of MSBuild projects is that the .vcxproj file must explicitly list all relevant source files in order for them to appear in Solution Explorer. This makes it virtually impossible to target multiple devices from the same project. Embedded CMake projects don’t have this limitation. A single project can instantiate multiple BSPs, and have each target explicitly reference one of them. Or have multiple platforms, each one targeting a different device. Or even have a Simulation platform that will build the code using the MinGW toolchain:VisualGDB will automatically build and show the necessary files in Solution Explorer, as long as the CMakeLists.txt calls the high-level functions for referencing BSPs and test frameworks:

find_bsp(ID com.sysprogs.arm.stm32
	VERSION 2020.06
	MCU STM32F407VG
	FRAMEWORKS com.sysprogs.arm.stm32.hal com.sysprogs.arm.stm32.ll com.sysprogs.arm.stm32.usbdev
	HWREGISTER_LIST_FILE STM32F4xxxx/DeviceDefinitions/stm32f407xx.xml)

And don’t worry, you won’t need to edit them manually unless you want to. VisualGDB provides intuitive GUI for all of the common settings:

More Flexibility

Because VisualGDB now directly controls the contents of Solution Explorer, we added a few usability commands that will help you manage your BSPs better:

  1. You can now convert a specific BSP to a stand-alone one directly from Solution Explorer. It will make it fully editable, letting you customize specific files or build settings.
  2. Once you are done tweaking the stand-alone BSP, you can now easily export it into a regular BSP and share it with other team members. Only one copy of the shared BSP will be installed on each machine, reducing the duplication of source files.
  3. VisualGDB now lets you patch a specific framework (e.g. the STM32 USB driver), while keeping the rest of the BSP unchanged. Simply convert that framework to a stand-alone one, and VisualGDB will copy it into the project folder, making it fully editable:You can include the stand-alone frameworks when exporting stand-alone BSPs into shared BSPs, so you can easily share them with your team.

STM32CubeMX Project Type

Since VisualGDB now directly manages the Solution Explorer contents, we have added a separate project wizard for the STM32CubeMX projects. If you would like to use STM32CubeMX to generate the project layout, and keep editing it afterwards, you no longer need to install the STM32 BSP shipped with VisualGDB. Just launch the new STM32CubeMX Project Wizard and VisualGDB will automatically launch STM32CubeMX, let you configure the settings there, and will create a project around it.

You can relaunch STM32CubeMX at any time directly from Solution Explorer and VisualGDB will immediately pick up any changes it makes to the project structure:

The new STM32CubeMX integration works around known GPDSC generator bugs in the STM32CubeMX tool, so you can enjoy intuitive workflow without any interruptions.

Other VisualGDB 5.5 Improvements

VisualGDB 5.5 RC1 includes numerous other improvements across the board. Native support for editing ESP-IDF partitions (including SPIFFS), better integration with the latest VS 2019 16.7, completion popups in the GDB Session window, go-to-definition for CMake projects, and much more. You can get the new release from our download page.

If you have any feedback, don’t hesitate to reach us out via our support form or the VisualGDB forum.