[support]

Sorry, if a project does not build outside VisualGDB, there is no way to generate a meaningful VisualGDB-based project that would somehow fix the build.

You can generate a project that will show the source files in Solution Explorer using the “import” mode of the wizard (it will simply add all files from the specified directory), however it will still invoke QMake when building, and hence will not resolve the build issues.

[support]

Hi,

Thanks for reporting this. Turns out, multiple instances of Visual Studio sometimes reuse the same external process for MSBuild-based builds, causing invalid values to be cached on the VisualGDB level.

Please try this build, it fully resolves the problem: VisualGDB-5.5.2.3397.msi

[support]

Hi,

Just to double-check, are you able to successfully build that project using the command-line tools (i.e. qmake) on the Windows machine using the same toolchain/target combination that you intend to use with VisualGDB?

[support]

Unfortunately, the internal structure of the latest QMake has changed in a way that does not allow VisualGDB to patch it to work with the Raspberry Pi cross-toolchain.

Simply replacing the QMake executable with a newer version will not work (you can verify this by downloading QMake from any other Qt package). As Qt is now fully compatible with CMake without any special patching, we recommend using CMake for all new targets that are not compatible with the old QMake that could be easily patched.

[support]

According to our best knowledge, there is no version of QMake that will work with the latest Raspberry Pi cross-toolchain. If such a version is ever released, we should be able to integrate it into VisualGDB promptly.

VisualGDB still supports QMake, as long as it is compatible with your toolchain/target combination. We do not release any special versions of QMake and do not control its compatibility with various platforms and targets.

[support]

Hi,

Generally, we are not able to resolve compatibility issues between 3rd-party components as a part of VisualGDB. However, we are happy to support the tool/platform combinations that do work reliably and provide convenient interface for developing projects for those configurations.

If you would like to get a time/cost estimate on customizing 3rd-party products beyond the supported configurations, please contact our sales, as the estimates are made on a case-by-case basis.

• This reply was modified 5 years, 8 months ago by support.

[support]

Hi,

Yes, please try using the older toolchain based on the Raspbian Stretch distribution (you would also need the older SD card image). It is compatible with QMake and will work out-of-the-box.

Unfortunately, we are not able to provide guidance on porting a 3rd-party framework to an unsupported 3rd-party platform as a part of our regular product support, however we might be able to create a port for you as a part of our paid consulting services. Please feel free to reach out to our sales if you would like a quote.

[support]

Thanks for clarifying this. Normally, VisualGDB should automatically detect the /usr/include/c++/8 directory after querying your toolchain, so you wouldn’t need to specify this directory manually. If you ever find the manual setup too annoying, feel free to get back to us and we will help you get the fully automatic setup to work correctly.

[support]

Hi,

Please make sure you use the VisualGDB 5.5 Preview 1, not v5.4.

Also you need to install the IAR compiler separately, and make sure you have a valid license for it (see this tutorial). We are not affiliated with IAR Systems, so VisualGDB can integrate with an existing IAR installation, but cannot redistribute it independently.

[support]

Hi,

Sorry, the latest Raspberry Pi toolchain is not compatible with QMake anymore. Please try using VisualGDB 5.5 Preview 1 and create a CMake-based Qt project as shown here: https://visualgdb.com/tutorials/linux/qt/cmake/. This should work out-of-the-box.

[support]

Hi,

You might be able to build one yourself, however in our experience, building Linux cross-toolchains almost always involves troubleshooting weird problems specific to a particular combination of target settings. You are welcome to try it, however we won’t be able to offer any support for this outside of our paid toolchain building service.

[support]

Hi,

This should be possible as long as you have a cross-toolchain specifically built for your target (with matching ABI, CPU/FPU settings and system library versions). If the board vendor provides such a toolchain, you can import it into VisualGDB as shown in his tutorial: https://visualgdb.com/tutorials/linux/edison/

If there is no ready-to-use toolchain, we can build one for you. Please contact our sales with details about your board and target OS version to get a quote.

[support]

Hi,

Sorry, the Keil component view requires the Custom edition or higher. If you are using a lower edition, you can always upgrade here: https://sysprogs.com/splm/mykey

[support]

Hi,

Good to know it works.

Not sure what you meant by mapping all #includes. Normally, this could happen automatically. If you believe it doesn’t, feel free to describe the repro steps starting from creating a project and we will investigate this further.

[support]

Hi,

Sorry, our AVR debugging support is based on an open-source tool called AVaRICE, that has somewhat limited support for debug probes. As the AVR devices use undocumented proprietary debugging protocols and are generally much less popular than ARM-based devices, the debugging experience is indeed much less straight-forward.

Our best advice would be to check the AVaRICE forums/mailing lists regarding support for new debugging probes.

[Author]

Posts