Forum Replies Created
-
Posts
-
Hi,
Yes, we are currently running internal tests on it and expect to release it in a few next weeks (there have been non-trivial changes to the Nordic samples).
No problem and good to know it works. FYI: we are updating our installer to support VS2019, so we will try to improve the detection of multiple VS2017 installations as well.
Hi,
Please let us know whether the VisualGDB.pkgdef file mentioned in step 7 of the diagnostic instructions exists and whether the registry value mentioned in step 8 is set correctly.
Look like something on your computer is preventing VisualGDB from running the Arduino builder properly.
Please double-check that your antivirus is not blocking the following file:
C:\Program Files (x86)\Sysprogs\VisualGDB\Arduino\arduino-builder.exe
If it doesn’t help, please open View->Other Windows->VisualGDB Diagnostics Console, reproduce the problem and share the log from the console.
Hi,
The Makefile itself does not get overwritten (it is part of the VisualGDB’s design to do small and very focused edits to the Makefile itself so that our users can edit it to modify the build logic), however the auxiliary files (e.g. stm32.mak) do get overwritten. As long as you edit the files that do not have the “THE FILE WILL BE OVERWRITTEN” warning, you should be on the safe side.
Hi,
According to our records, your trial has started considerably earlier (see your previous forum account). We are happy to help users that have active VisualGDB licenses, or are evaluating VisualGDB (i.e. running the 30-day evaluation period to decide whether it could be useful in their environment), however we are not able to provide any help outside of these constraints. If you are looking for a free IDE/code editor that does not come with any limitations, please consider using Vim, Emacs or Eclipse.
According to our records, your trial has expired, so unfortunately we won’t be able to provide any further support unless you purchase a VisualGDB license. Sorry.
According to our records, your trial has expired, so unfortunately we won’t be able to provide any further support unless you purchase a VisualGDB license. Sorry.
Hi,
It looks like your system sets the %AS% environment variable to the default x86 assembler and the Makefile picks it up. Please try locating the following code in your Makefile:
ifeq ($(AS),) AS := $(CC) ASFLAGS := $(CFLAGS) $(ASFLAGS) endif
Once you locate it, simply make it unconditional (remove the ifeq and endif lines). This will override the incorrect value inherited from the environment.
Hi,
We were just going to suggest that option, but it looks like you were faster. In case anyone else searches for this, the option is called “Group sources by paths” and is available for CMake-based, ESP-IDF-based and Arduino-based projects.
Hi,
The automatic sysroot synchronization indeed can only download the files from the root of the target filesystem. The easiest way to work around it would be to synchronize the files manually using SmarTTY, or add custom project shortcuts (requires Custom edition or higher) for downloading the arbitrary directories from arbitrary machines into the toolchain’s sysroot. Once defined as a custom shortcut, you will be able to trigger synchronization via the Project menu.
Regarding the case sensitivity, such files will indeed override each other on the Windows side. You can try enabling the case-sensitive mode for a specific NTFS folder as described here, but this may not be handled correctly by the toolchain or Visual Studio itself. Generally, unless you are building custom kernels, this should not be a problem as this type of file name collisions is rare. If it does interfere with your projects, please consider creating an Advanced CMake-based project configured to directly access the remote filesystem via SSH. This mode will properly handle case-sensitive file names, although you would need a Linux machine to build the code.
Thanks for the update. Looks like the busybox version on your target is more limited than one we tested.
The problem happens because VisualGDB tries to run the following command line in order to list all files in a certain directory:
find . -maxdepth 1 -print0 | xargs -0 stat -c "StatEntryL:|%N|%Y|%d|%s|%f"
It uses the ‘-0’ option so that xargs won’t get confused if some of the file names have spaces. We have tested this on busybox 1.27.2 and it did work, so if possible, please try updating the busybox version on your target. If this is not possible, please try running ‘xargs –help’ on your target and share the output so that we can try to find a command line that will work on your target.
Hi,
Please double-check with Espressif (the vendor for ESP-IDF) whether there is an officially supported and stable way to do this. If yes, we will be happy to add a GUI setting for it.
Hi,
VisualGDB sets the optimization level to “none” for debug builds because this makes it easier to debug the project. Debugging optimized code could be very complicated as the compiler would often reuse common chunks of generated code (complicating stepping) or destroy the values of the variables once they are no longer needed (preventing you from evaluating most of them in the debugger).
If your project only works with some optimization levels, but not with others, it likely contains bugs triggered by a specific memory layout, or runs out of stack/heap space. Either way, we would advise investigating this as it might cause further trouble in production code.
Hi,
Yes, simply right-click on the project in Solution Explorer, select “Open ESP-IDF terminal here” and VisualGDB will launch the MinGW2 shell where you can run commands like “make monitor”.
If you are looking for something different, please let us know and we will try to provide a better suggestion.
