Today we have released VisualGDB 5.2 Beta 4. Among various small improvements and optimizations it now allows automatically browsing and experimenting with over 3000 detailed code samples for the STM32 microcontrollers included in the STM32 CubeMX software libraries.
Continue reading Exploring advanced STM32 code samples with VisualGDB
Today we are proud to release VisualGDB 5.2 Beta 1. Aside from seamless unit test support for Embedded, Linux and Android projects, better Clang IntelliSense engine, Real-time Watch and a new MSBuild backend, it includes numerous usability improvements that make the development experience more streamlined and removes some annoying distractions. Let’s have a quick look through the main changes.
We have just released VisualGDB 5.2 Preview 3 that comes with out-of-the-box MSBuild support for Embedded and Linux projects (using both remote toolchains and Windows cross-toolchains). It is a lucrative alternative to the GNU Make and CMake build systems that VisualGDB supports as well, so let’s go through the main 10 reasons why it’s worth checking out.
Continue reading 10 Reasons to Try Out MSBuild for your VisualGDB Projects
One of the features most wanted from VisualGDB before version 5.2 was to detect stack overflows on embedded devices. On a typical ARM Cortex microcontroller where every byte counts, running out of stack space is not something out of the ordinary, and it can have catastrophic consequences and be hard to debug. So VisualGDB 5.2 Preview 2 comes with a feature that makes the stack usage analysis completely automatic and tracks the overflow event when it happens:
Continue reading Introducing Dynamic Stack Verifier
The new Visual Watch feature in VisualGDB 5.2 helps quickly visualize the timings of RTOS threads and functions, but what should you do if you want to track something more fine-grain? Thankfully the answer is really simple and I will show you why in just a moment.
Continue reading Extending Real-time Watch with Custom Events
One of the toughest types of problems faced by embedded software developers is timing problems. Seeing what exactly happened before a problem popped up and being able to put multiple events on one scale could save hours of time. The previous version of VisualGDB included an embedded profiler that could collect statistics on the runtime of various functions. VisualGDB 5.2 takes this even further and introduces Real-time watch – a framework for convenient recording and visualization of various real-time events in your program that works out-of-the-box with FreeRTOS and supports non-RTOS environments as well:
The upcoming VisualGDB 5.2 comes with several improvements to the Clang IntelliSense engine that make the development experience easier and save time on common tasks. Let’s look at those in detail.
Continue reading Clang IntelliSense improvements in VisualGDB 5.2
Embedded Memory Explorer is one of the most loved Embedded features of VisualGDB. It helps you keep track of the FLASH and RAM used by your embedded project so you can be sure that your program fits into your device memory:
The new VisualGDB 5.2 comes with a feature that makes this window even more efficient at finding out why is your program bigger than you wanted it to be. Continue reading The New Dependency View in Embedded Memory Explorer
One of the topics that got us a lot of feedback recently was the poor performance of the Visual Studio Memory window with embedded VisualGDB projects. Two main problems reported by our users were lack of memory view when the program is running and the fact that it tried reading a wider memory area that was actually displayed, sometimes causing the underlying tools to crash. We have solved that in VisualGDB 5.2 with a brand new Advanced Memory Window specifically designed for maximum usability with VisualGDB projects.
Continue reading The New Advanced Memory Window in VisualGDB 5.2
The new system for running C++ Unit Tests added to VisualGDB 5.2 has out-of-the-box support for CppUTest and GoogleTest framework. But it’s also designed to be easily extendable to support any other test framework through a flexible set of rules defined in XML files. This post will describe how the test frameworks are defined and what can be customized in the framework definitions to support more frameworks.