Forum Replies Created
-
AuthorPosts
-
November 27, 2019 at 00:13 in reply to: Cross-compile toolchain error with Qtt5 on Raspberry Pi #26577
support
KeymasterAccording 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.
November 26, 2019 at 23:54 in reply to: Cross-compile toolchain error with Qtt5 on Raspberry Pi #26573support
KeymasterHi,
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 6 years, 1 month ago by
support.
November 26, 2019 at 23:43 in reply to: Cross-compile toolchain error with Qtt5 on Raspberry Pi #26569support
KeymasterHi,
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
KeymasterThanks 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
KeymasterHi,
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.
November 26, 2019 at 16:16 in reply to: Cross-compile toolchain error with Qtt5 on Raspberry Pi #26564support
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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.
support
KeymasterHi,
No problem. We have reproduced and fixed the problem. Please try this build: VisualGDB-5.5.2.3395.msi
November 22, 2019 at 19:30 in reply to: Cancel install/update AVR Boards package won't affect fully #26540support
KeymasterThanks for the repro steps. We have reproduced the problem, however it looks like it’s limited to showing incorrect value in the status bar. Indeed, canceling an Arduino package installation will immediately stop the download, but the Visual Studio’s status bar will only get updated when another component uses it to display the progress.
Due to the relatively low impact of the issue, we will fix it during the next update of the progress-related logic.
November 22, 2019 at 18:30 in reply to: Generating bin file for extra memories is slow for large projects #26539support
KeymasterThanks for the link. We have reproduced the problem. Indeed, when using Internet Explorer (not Edge) to download the temporary builds that don’t go through our CDN system, the extension changes to .man. it should be indeed trivial to fix it, however due to relatively low impact, we will delay it until the upcoming upgrade of our server framework, so that we could fully test it as a part of the post-upgrade tests. If this becomes more annoying, feel free to ping us and we will consider raising the priority for this.
support
KeymasterThe chronometer does show the time since the last event, even if it was of another type. You can double-check it by setting 2 breakpoints inside the LEDBlink loop. If it doesn’t work as expected, please share the repro steps along with the relevant screenshots per our problem reporting guidelines and we will investigate it.
You can also switch the chronometer to show the absolute timestamps (i.e. from the beginning of the session) to minimize confusion.
P.S. If the absolute timestamps don’t make sense, some code inside your project might be resetting the ARM cycle counter that is used by the chronometer. E.g. VisualGDB’s profiler does that to avoid overflows.
-
This reply was modified 6 years, 1 month ago by
-
AuthorPosts