Forum Replies Created
-
Posts
-
Hi,
We have looked into it and will be getting some ESP8266 boards to investigate the complexity of adding a BSP for it. Feel free to follow us on Twitter (@Sysprogs) to stay updated.
Update: here you go.
Hi,
The clang version we use has the c++1y, not c++14 syntax. We will add an alias to the final release, though.
The Include directories and Linker script are managed by GNU Make and do not have access to VisualGDB variables. You can simply use relative paths to specify something relatively to the project directory or create a per-user variable (Custom edition and higher) and select to propagate it to GNU Make.
This is true. Can you inspect the contents of View->Output->VisualGDB Launcher Output after an unsuccessful debugging session? It should normally show something like this:
VisualGDB: Executing predebug actions VisualGDB: Deploying e:\PROJECTS\TEMP\test\test/Debug/test to /tmp/vgtest/test on raspberrypi... VisualGDB: Launching gdbserver VisualGDB: Run "gdbserver :2000 "$(DeployPath)" " in directory "$(DeployDir)" on pi@raspberrypi (SSH) VisualGDB: Launching custom program console VisualGDB: Launching gdb VisualGDB: Executing postdebug actions
Then check that:
1) The file on the Windows machine exists and is readable under your account
2) The remote file does not exist, the remote directory does and the device has enough free space
If none of that provides clues, can you reproduce it with a “Hello, World” project? If yes, can you create an image of your SD card and send it to us so that we could reproduce it on our side?
Please run ‘dmesg | tail’ to see debug messages from the kernel. Are there any details regarding kgdboe issues? Have you tried following the manual kgdboe tutorial?
Hi,
Looks like VisualGDB cannot upload to the /tmp folder on your Raspberry Pi. Please double-check that the folder is writable from your user account and that you have enough free space on your Raspberry Pi.
Unless it contains assembly files that are incompatible with GCC, you can simply import it to VisualGDB. E.g. refer to the legacy project tutorial to see how to specify device-specific flags manually: http://visualgdb.com/tutorials/arm/legacy/
Normally C++ files should be handled as c++14 unless you have explicitly specified a different standard in your Makefile settings. Could you please double-check your CFLAGS/CXXFLAGS? You can see the effective IntelliSense flags via View->Clang IntelliSense Status->Project Status. Does the CXXFLAGS field specify -std=c++1y?
The handling of .h files depends on your project type. When you open a .h file, VisualGDB first checks if any of the source files includes it. If yes, it opens the .h file in the context of that source file. If no sources include the header file, it simply counts the C and C++ sources in the project. If there are 50% or more C++ sources, new .h files are treated as C++ includes. Can you please check how many C and C++ sources are in your project?
The command for switching between source and header files will be fixed in the final 5.0 release.
Yes, simply go to the IntelliSense Settings page of VisualGDB Project Properties and add “-include <forced include file>” to IntelliSense CFLAGS/CXXFLAGS.
You can change the syntax highlighting colors via Tools->Options->Environment->Fonts and colors->Text Editor. VisualGDB automatically uses the standard C/C++ colors from the normal Visual C++ package (if they are supported in your VS version) and adds a few elements of its own (e.g. “C++ Constructors and Destructors”).
Hi,
The easiest way to restore the broken Remote Console window would be to restore the .vgdbsettings file from your source control system. All debug settings are contained in that file and will be reverted by restoring it.
If that is not possible, please try creating a new project with the project wizard and see if remote console is broken there as well. If not, compare the settings in your project with the settings in the new project to see what can be causing the problem.
Hi,
VisualGDB currently does not support solution-wide variables. However, you can use 2 mechanisms to define things globally:
- Use SSH host aliases (see the SSH Host Manager window) to avoid hardcoding machine names in your projects.
- Reference environment variables using the same syntax as the per-project variables: $(VarName).
If this is insufficient, please let us know your scenario so that we could suggest a better solution.
Hi,
Can you attach a screenshot of the emmintrin.h file showing the error location and the color of tokens around it?
Does your project specify -std=xxx explicitly in compiler flags? Can you open View->Clang IntelliSense Status, switch to Project Status and share the value of CFLAGS and CXXFLAGS displayed there?
Please also confirm whether the problem happens while trying to edit a .c or .cpp file.
