Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
Some environment variables are defined differently for different user accounts (also once the process is started, its environment won’t be automatically updated once you change the Windows environment settings), so we would advise checking where the variables are defined and also confirming that the build agent process inherits them properly (e.g. by running “cmd /c echo %VARNAME%” as a part of the build).
If this doesn’t help, please give us an example of a variable that doesn’t get resolved (i.e. where is it defined and what value you are observing) and we will try to help you get it to work.
support
KeymasterHi,
This is by design. Changing anything on the Embedded Frameworks page will automatically regenerate the file list.
If you want to exclude some of the files, please set the “Excluded from Build” flag via VS project properties. The file will then be still referenced from the .vcxproj file, but VisualGDB won’t try to compile it anymore.
support
KeymasterHi,
Good to know it works. Running TFS as the regular user is indeed the officially supported way. This scenario is included in our internal tests, so it should normally work out-of-the-box without any friction.
Let us know if you encounter any further issues and we will be happy to help.
support
KeymasterHi,
Welcome to the VisualGDB forum. You can definitely use VisualGDB to develop IoT-like applications for Raspberry Pi. VisualGDB supports a wide variety of different build systems (Make, QMake, CMake and MSBuild), so you should be able to quickly import existing code and samples into it and start experimenting with them.
The main advantages of VisualGDB is the deep integration with the underlying GNU tools. It comes with a special IntelliSense engine optimized for Linux codebase, advanced debugging engine that is capable of detecting common debugger problems and a powerful custom action engine that lets you customize various steps of your build/debug process. We also integrate many advanced tools (e.g. static/dynamic code analysis, memory leak detection and profiling with Valgrind). You can get an overview of the main VisualGDB highlights here: https://visualgdb.com/?features=linux
You could also browse our Linux and Raspberry Pi tutorials to get a quick overview of the VisualGDB workflow: https://visualgdb.com/tutorials/
The main disadvantage is that VisualGDB only supports C, C++ and Python. If you are planning to use a different programming language, VisualGDB won’t be able to offer much help.
June 25, 2018 at 04:04 in reply to: VisualKernel not listed as option under Project Templates #21182support
KeymasterHi,
This might be caused by corrupt VS package cache. Please try following the instructions on the following page: http://visualgdb.com/support/loadfail/
Please note that the instructions are for VisualGDB; the only difference for VisualKernel would be the package name.
support
KeymasterHi,
The easiest way to fix this is to run Visual Studio manually on the TFS build server (from the same user account that is used by TFS) and create a new project using the VisualGDB project wizard (importing the toolchain if needed). This should ensure that VisualGDB can find all the necessary components and will automatically fix TFS-based builds.
If this is not possible, let us know and we will provide alternate steps on diagnosing why the toolchain is not detected.
support
KeymasterHi,
Most likely you have created an MSBuild-based project. In most of the cases this type of project is better than Make-based, although the steps for integrating a bootloader would be different (we don’t have a detailed tutorial for this yet). If you would like to follow the tutorial, please try selecting Makefile on the first page of the wizard instead.
support
KeymasterHi,
This is by design. The MSBuild-based projects must be build by invoking either devenv.exe, or msbuild.exe (VisualGDB would internally run msbuild.exe if you try building the .vgdbsettings file, but it looks like something is preventing it from finding the correct .vcxproj file in your case). Please try using the following command line:
msbuild.exe <.vcxproj file> /property:Platform=VisualGDB /property:Configuration=Debug
support
KeymasterHi,
We could add an option to specify a list of “system” directory prefixes in the VisualGDB Project Properties and a button in the profiling report pane to hide symbols defined inside those directories. Would that work for you?
support
KeymasterHi,
Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2323.msi
It supports using clang-format instead of our regular code formatter (it also features a convenient GUI editor for the formatting styles with live preview). You can enable clang-format for VisualGDB projects via Tools->Options->Text Editor->C/C++ (VisualGDB)->Formatting Engine and then use the format icon in the upper right corner of the source editor to launch the interactive style editor.
support
KeymasterHi,
Good to know it works. BTW, you can avoid renaming the main.cpp file to main.c if you declare all functions that are called from Plain C code with extern “C” as shown in this tutorial: https://visualgdb.com/tutorials/tips/externc/
support
KeymasterHi,
Sorry, we still don’t have any plans for VSCode support. The biggest problem here is that VSCode is based on a different technology stack, so integrating VisualGDB with it would imply creating and maintaining another product from scratch with not much reuse from the current VisualGDB code base.
That said, Microsoft is working on bringing .Net to the web apps domain. Once the Blazor framework matures, we will reconsider supporting VS Code, as it might make it easier to port existing VisualGDB logic without a complete rewrite.
support
KeymasterHi,
Most likely you are missing the code responsible for redirecting stdout output to the UART.
Please see this tutorial for a detailed example (you will need to add a similar implemenation for _write() and other similar functions).
support
KeymasterHi,
You might be running a firewall on the Raspberry Pi side. You could try checking with Wireshark whether there’s any reply from Raspberry Pi when you try connecting to that port. Another option would be to try other ports or use netcat instead of OpenOCD to listen to incoming connections to see if the problem is caused by OpenOCD (it might be listening exclusively on the 127.0.0.1 socket).
support
KeymasterHi,
Sorry for the delay. We are still planning to add this in the near future, as soon as we complete finalizing the Arduino support. Please expect this to be available in the next 3-6 weeks.
-
AuthorPosts