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.
Today we are proud to announce the release of VisualGDB 5.3 Release Candidate 1. This version introduces profiling and code coverage support for Linux projects, Linux Dynamic Analysis, advanced code annotation and a few other improvements. In this post I will give you an overview of the new features:
Today we are proud to announce the release of VisualGDB 5.3 Preview 8. This build mainly focuses on stability and usability improvements, such as better integration with Kinetis KSDK 2.x and support for importing Keil projects, however it also introduces a feature that greatly simplifies and reduces the overhead of analyzing precise timing of your embedded code – Chronometer.
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.
Today we announce the release of VisualGDB 5.3 Preview 6. It focuses on further improving the usability of the embedded and Linux projects. I will give you an overview of the highlights of this version in this post.
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”.
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
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.
Today we are excited to announce the second preview of VisualGDB 5.3 that introduces several improvements to the Clang IntelliSense engine. In this post I will show you the highlights of the new engine. Continue reading Clang IntelliSense Improvements in VisualGDB 5.3 Preview 2
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