Forum Replies Created
-
Posts
-
Hi,
Sorry, there is no special GUI or command to achieve this. You should be able to get this working by patching the Makefile to escape relevant internal variables and pass them to gcc as preprocessor macros, however it requires a good understanding of the inner workings of GNU Make and is unfortunately outside the scope of VisualGDB support.
Hi,
SSH performance should not be affected by updating VisualGDB. Please try installing the previous version and check if the problem persists. If it does, please try deploying the same executable using a different SSH client (e.g. using PuTTY SCP or SmarTTY).
If you can confirm that the problem only happens with VisualGDB, but not with other SCP software, we can help you narrow down the difference and make sure the VisualGDB performance matches the performance of other tools.
Hi,
According to our records, your trial period has expired. Hence, VisualGDB will not work and we will not be able to offer any technical support. If you are looking for a free alternative to VisualGDB, please consider using the Arduino IDE.
Sorry, no current plans. We will keep an eye on the popularity of Rust and will consider support it if it becomes more mainstream.
Hi,
No problem, we will try to help you.
VisualGDB loads the list of unit tests by scanning the binaries (either running them, or looking for specific symbols). Hence, in order for a newly added test to appear in the Test Explorer, you need to build the solution. If it doesn’t help, please let us know what happens after the solution build is complete. Does the Test Explorer window show the progress indicator? Does the View->Output->Test window show anything new?
Switching between the different platforms is necessary because VisualGDB (and CMake itself) defines the toolchain settings (i.e. the compiler to use for all targets) for the entire project. Hence, if you would like to run the tests on the Windows machine, you need to build the platform/configuration targeting the Windows machine. Building embedded code would require switching back to the platform/configuration that uses the ARM toolchain.
That said, you can work around it by having 1 solution with 2 VisualGDB projects around the same CMake codebase. The first project would load the top-level CMakeLists.txt file with the PLATFORM=Hardware macro, while the second project would load the same file with PLATFORM=Simulation (see CMake Command lines to understand what exactly gets passed to CMake). From Visual Studio and VisualGDB perspective, these will be 2 independent projects, one of them producing the ARM binaries, and another one producing Windows binaries. From CMake perspective, it will be the same set of CMake scripts reused between the builds.
Note that it will result in some cross-talk between the projects. E.g. adding a source file to a target within one project will not automatically refresh the same target shown in the other project until you manually refresh the second project via context menu.
Regarding the test frameworks, normally, VisualGDB would run the tests on the hardware. In this mode, it supports GoogleTest, CppUTest and TinyEmbeddedTest. As we have recently added support for simulation platforms (i.e. running tests on Windows), we have ported TinyEmbeddedTest and GoogleTest to support this configuration, but not CppUTest yet.
Ceedling looks interesting, however it appears to be very niche. We would be happy to fully integrate it with VisualGDB, however we would have to bill it as a custom paid feature unless sufficient number of our paid users shows interest in using it.
The regular CTest integration works by scanning the source files for test macros. This is less reliable than the binary-level analysis and does not work when running tests on the hardware (since it involves selecting specific test cases by modifying variables during program startup). That said, VisualGDB support for test frameworks is implemented via interchangeable plugins, so you can try tweaking it to support any case that is not supported directly.
You can add libraries to embedded projects via add_library(), however you would need to manually take care of all the fine details done by add_bsp_based_library(), such as automatic handling of code coverage, whole archive linking, handling of differences between GCC, IAR and Keil, and so on. A better approach would be to define a dummy implementation of add_bsp_based_library() to your Linux configuration and use it instead of the original one.
Hi,
No problem, we will help you get everything working. In order to get VisualGDB to edit the source files, you would need to import your project into VisualGDB and configure path mapping via the Linux Project Wizard (e.g. to first copy the entire Linux directory to Windows, and then upload modified files during build, or to access all files directly on Linux via SSH).
Files that are not covered by path mappings will be indeed downloaded to the AutoDownloadedSources folder, but will not be uploaded back.
If you have configured a path mapping, but the files are still downloaded to the temporary folder, please ensure that the Linux file paths reported by gdb match the paths specified in the mapping. You can find out the gdb-reported paths via a gdb log.
If nothing helps, please attach your gdb log along with the screenshots of your path mapping settings, and we will help you find the right settings.
Hi,
No problem, please follow this tutorial to troubleshoot symbol-related problems. If it doesn’t help, please attach your gdb log and we will help you understand what is going on.
Thanks for letting us know. If the file is missing from the gpdsc file, please feel free to report this bug to ST, as this needs to be fixed on their side.
No problem, we have fixed it in the following build: VisualGDB-5.5.103.3907.msi
Hi,
This is already supported via Custom Shortcuts (requires Custom edition or higher). If you are using a lower edition, you can always upgrade your key here.
Good to know it works. BTW, feel free to try out the new Advanced CMake Embedded Project Subsystem. It was specifically designed to address the shortcomings of MSBuild (including the duplication of settings between targets, platforms and configurations) and provides much more streamlined experience.
No problem, we can help you. Please double-check that you are building the correct configuration, since custom build steps are defined for debug/release configurations separately.
If it doesn’t help, please try enabling the verbose build mode and share the build log (from the regular VS Output window, not the VisualGDB Build window) and also the name of the .vgdbsettings file that contains the custom step.
Thanks for the input. Normally, VisualGDB would show the “this feature requires Custom edition” overlay on most Custom-only property pages during the trial. However, once the trial runs out, the extra pages will indeed be just hidden.
We will mention the Custom edition next time we update the custom step tutorial.
Hi,
Most likely, you have already installed the latest versions of the toolchains, so they will appear in the Installed view, but not in the Online view. Please try double-checking both views.
Hi,
The custom build/debug steps are supported starting from the Custom edition of VisualGDB (see our feature matrix). Most likely, you are using a lower edition that does not support them.
You can find out more about VisualGDB Custom Edition features here or upgrade your edition using the following page: https://sysprogs.com/splm/mykey
