Forum Replies Created
-
Posts
-
Hi,
The _WIN32 macro should not be defined with the Clang IntelliSense. If you believe it is, please double-check it with the following code:
#ifdef _WIN32 #error Oops #endif
If you get the error message, please try selecting ‘go to definition’ for the WIN32 macro. Perhaps it is defined on one of your header files?
The __clang__ macro is defined together with the __GNUC__ macro; as Clang is normally backwards compatible with GCC, this should not be causing any trouble.
Hi,
Sorry for the confusion. In VisualGDB terminology, Embedded projects are the ones without any OS (i.e. barebone) that run on hardware like STM32. Linux projects involve the same setup/build steps for both Desktop and Embedded Linux, so they use the same Linux project wizard.
The “Exec format error” error means that your binary is not compatible with the target machine. E.g. you could have selected the normal x86 Linux toolchain instead of the ARM one or are trying to deploy the ARM binary on a Desktop machine instead.
Please double-check the selected toolchain and the target machine in your VisualGDB Project Properties.
Hi,
The value in the VisualGDB Project Properties is set for all configurations and is stored in stm32.props:
<ItemDefinitionGroup> <ToolchainSettingsContainer> <ARMCPU>cortex-m4</ARMCPU> <InstructionSet>THUMB</InstructionSet> <FloatABI>soft</FloatABI> </ToolchainSettingsContainer> </ItemDefinitionGroup>
The corresponding VS property could override it for each configuration, but we do not recommend changing it manually to avoid confusion.
Hi,
If you are using the Custom edition or higher, you can click the “Convert to stand-alone project” button on the Embedded Project page of VisualGDB Project Properties.
This will automatically copy the relevant files under your project directory and update the references to them.
Hi,
We recommend installing the Windows build of Qt and then using Qt Designer from it to edit the .ui files. If you install the Qt VS add-in, it will automatically open the Qt designer once you click at a .ui file in Visual Studio.
Hi,
If the project relies on additional include directories, you need to specify them in your project properties (Project->VisualGDB Project Properties). With VisualGDB 5.2 it’s very simple, as it will search nearby directories for missing headers and suggest automatically adding discovered directories.
If this does not help, please let us know the errors you are encountering and we will suggest the related settings.
Hi,
The original ESP-IDF does not usually build out-of-the-box without adjusting several things manually. E.g. several different components inside it have include files with the same name and and hence expect different order of include directories.
We do have an open-source tool that converts the original ESP-IDF into a VisualGDB package, so you can try using it at your own risk: https://github.com/sysprogs/BSPTools/tree/master/generators/esp32
We have also just released an updated ESP32 toolchain that is based on the final ESP-IDF release (v1.0), so updating to it will automatically switch your projects to a newer ESP-IDF.
Hi,
VisualGDB normally does not prebuild the full IntelliSense information for all sources, as this takes a lot of space (a full uncompressed cache for the entire Linux Kernel is around 50GB) and normally if precompiled headers are detected properly, the delay you describe should not happen. It does build a highly optimized reference cache, but it’s only used in “Go to definition” and “Find all references” commands.
What we could offer is add a setting to forcibly precompile and include an arbitrary header file as if it was directly included from each source. Would that be helpful?
It also sounds like a good idea to measure how much time was spent compiling each header and offer such optimizations automatically, so we will experiment with this in v5.3.
Hi,
Sorry for the delayed reply.
The Digi tutorial is very old and does not reflect the new simplified project wizards.
Most likely you don’t need to use the Custom wizard at all – if your toolchain consists of the regular tools like gcc, ld and make, you can simply select it in the VisualGDB project wizard and VisualGDB will setup a basic project automatically including the necessary deployment steps (see this tutorial: http://visualgdb.com/tutorials/linux/3machine/).
If you want to configure manual build steps nonetheless, you can change the build machine (where gcc and other tools are located) globally on the Project Settings page.
If you encounter any further problems, please feel free to let us know and we will help.
Hi,
The error message should normally contain the gcc output. Does it show any details about the problem?
If not, please try running gcc manually with the flags shown in the error message. Sometimes gcc fails to start due to missing DLL files and only shows a meaningful error message if started manually from cmd.exe or Explorer.
Hi,
Sorry about that, looks like some MSBuild-related setting is preventing the .S files from being automatically recognized. If you encounter this problem again, please let us know and we will investigate.
Hi,
Sorry, perhaps the other debugger is handling some USB requests differently. VisualGDB relies on OpenOCD to handle low-level debugging and we can confirm that it does not work very fast on VMs. Hence our best advice is to use a physical VM instead (or at least run OpenOCD on a physical machine, however that would require a complex manual setup).
Hi,
Are you using a VM with USB virtualization? If yes, slow debugging is to be expected. Please try running VisualGDB directly to get the best performance.
Hi,
The remotetimeout should not affect the initial connection problems.
Could you try locating the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\edp.xml file and increasing GDBServerDelay to 5000 or even more? Perhaps OpenOCD initialization takes longer than the 2 seconds that VisualGDB waits normally?
