Forum Replies Created
-
Posts
-
Good to know you got the regular SysprogsSync to work. This is the recommended way as it’s much faster than generating temporary scripts using command-line tools.
Either way, we have added another check for the “xargs -0” option, so if it’s not supported, VisualGDB will fall back to the regular xargs syntax.
Please feel free to try this build: VisualGDB-5.4.103.2811.msi
No worries. We usually schedule the BSP updates based on the popularity of the device families. Nordic devices are quite popular (and are, in our opinion, the best choice for Bluetooth LE), so our normal internal guideline is to have a BSP ready in 1-2 months after the official SDK release. However, unfortunately we did get a few interruptions along that path, so it took longer than we expected. It should be out fully tested and supported in 1-2 weeks based on what we see currently. Sorry for the wait.
Hi,
VisualGDB itself does not provide any global shortcuts, instead it registers commands with Visual Studio so that you can set shortcuts via the Visual Studio’s options dialog.
The Find Symbols in Solution command is available in the Edit menu, so you can set a shortcut for it. Method enumeration doesn’t have a global command yet, so will try to add it in one of the next builds.
Thanks for sharing this. Yes, our internal BSP build is somewhat usable, although a few example projects from Nordic use library settings that were not present in the previous SDKs, so we are making sure that VisualGDB can clone them properly. We also understand that it took us longer than usual to process this, so we will give a higher priority to supporting the next Nordic SDK so it won’t take that long.
Hi,
The Preview Changes dialog is actually rendered by Visual Studio based on the data VisualGDB reports to it, so the amount of tweaking we could do to it is limited.
That said, reference highlighting was indeed broken in the latest VisualGDB 5.4R2, so we have fixed it in this build: VisualGDB-5.4.103.2810.msi
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.
