Tag Archives: VisualGDB 5.3 Features

Explaining project format changes in VisualGDB 5.3

The latest VisualGDB 5.3 release introduces a few improvements in the project format that avoid hardcoding of the paths and settings in the project files and make toolchain management on different machines easier. However some of those changes are not backward compatible with VisualGDB 5.2 and earlier, making it harder to update to v5.3 if some of the developers in your organization are still using v5.2. In this post I will show you the project file format differences between VisualGDB 5.3 and 5.2 and will provide examples on making v5.3 projects compatible with the older VisualGDB versions.

Continue reading Explaining project format changes in VisualGDB 5.3

Introducing Embedded Integration Tests

VisualGDB started supporting unit tests in version 5.2. Having out-of-the-box support for CppUTest, GoogleTest and TinyEmbeddedTest, VisualGDB made it easy to check whether every separable component of your system works. However the size overhead and the necessity to create a separate test project makes it hard to use them for testing the behavior of the entire embedded system.

So in VisualGDB 5.3 Preview 7 we introduced a new mechanism called Embedded Integration Tests that does exactly that – lets you conveniently verify the behavior of your firmware without any significant overhead.

progress

Continue reading Introducing Embedded Integration Tests

The Updated VisualGDB Embedded Debugging Experience

VisualGDB has a history of supporting embedded devices that has gone through several steps of evolution. The very first VisualGDB version released 5 years ago expected you to know the gdb and OpenOCD command lines, one of the next versions provided convenient GUI for locating OpenOCD scripts and settings that eventually morphed into detecting the settings for common devices and debug adapters, still requiring to go into script editing to support choosing a specific ST-Link instance or turning on the “Connect under reset”.

VisualGDB 5.3 Preview 5 replaces this experience with a much more streamlined (and powerful) UI and I will show you its main highlights in this post.intro

Continue reading The Updated VisualGDB Embedded Debugging Experience

Introducing the new Team Settings Engine

Since we released the first version of VisualGDB, it has evolved from a basic debugging plugin to a comprehensive extension that helps manage numerous toolchains, packages, build machines, project templates and more. VisualGDB offers GUI for managing those artifacts on the developer machines, however setting up a new development machine from scratch could be annoying due to necessity to setup remote host connections, toolchains, aliases etc.

VisualGDB 5.3 Preview 4 introduces a new mechanism that allows instantly sharing various common settings with other team members – VisualGDB Team Settings. Continue reading Introducing the new Team Settings Engine

Introducing the New Toolchain Engine

Today we are proud to announce the release of VisualGDB 5.3 Preview 3 that introduces a new improved engine for toolchains and BSPs. The new engine completely decouples project settings from toolchain settings, letting you easily switch between different toolchain options and seamlessly open projects on machines that have different toolchain/BSP installation directories.

tc

Continue reading Introducing the New Toolchain Engine

Introducing the new Advanced CMake Project Subsystem

CMake has been getting increasingly popular over the past years due to its simplicity and integration with the modern IDEs. The recently added CMake Server mode made it even more usable, allowing it to share the precise project structure with different IDEs, but if you wanted to actively edit a large project, you would still inevitably have to edit the CMakeLists.txt files manually, making it less intuitive than working with regular Visual Studio projects.

So we decided to bridge this gap and designed a new VisualGDB CMake Project subsystem that lets Visual Studio open Linux CMake projects and treat them just like the normal Visual C++ projects. Continue reading Introducing the new Advanced CMake Project Subsystem