Forum Replies Created
-
Posts
-
Hi,
Yes, the Makefile looks like it can be built with VisualGDB. Simply install our ARM toolchain, add it to PATH and replace arm-none-eabi- with arm-eabi- in your Makefile so that it matches the arm-eabi-gcc.exe executable. However if the project is made to be built on Linux, it might rely on other Linux tools and simply not build under Windows. In that case we would suggest getting a Linux cross-toolchain, getting it to build on a Linux VM and then importing it into Visual Studio as described in this tutorial.
Either way, VisualGDB is flexible enough to build/debug any project that can be built using command-line tools, so you should be able to develop it with Visual Studio and VisualGDB even if it needs to be built remotely under Linux. If you encounter strange error messages, feel free to post them here so that we could try to help you.
Are you creating a normal VisualGDB proejct using the VisualGDB wizard, or importing some existing code? Are you selecting “FLASH” as the primary memory in the wizard?
Hi,
Thanks for letting us know. Our Jessie toolchain image was indeed missing some DLLs. We have updated the installer. Please re-download and re-install it.
Hi,
This is a known limitation caused by the way signals are implemented in Linux. You read more about it on StackOverflow: http://stackoverflow.com/questions/1717991/throwing-an-exception-from-within-a-signal-handler
Hi,
Yes, we usually update the BSPs quarterly. There are 3 ways to get the updated library:
- You can build and run our STM32 BSP generator against the new archive from ST.
- You can simply copy the new code from ST to %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\<…>stm32\<your family> replacing the old code
- You can convert the project to a stand-alone project and import the code from ST manually.
Hi,
For embedded projects VisualGDB always uses the GDB that comes with your toolchain. The easiest way to override it would be by copying the toolchain to a different directory and adding a GDBExecutable element to toolchain.xml:
<Toolchain ...> <GDBExecutable>other-gdb.exe</GDBExecutable>
Hi,
We are currently planning to release the first beta around the end of November – beginning of December.
You can include resources like image files by modifying the Makefile. See this tutorial for an example of including a .png file.
Hi,
It’s hard to answer that question from just looking at the project source page. What hardware is the project targeting? What toolchain is it using?
Hi,
Good to know the workaround works. It’s surprising that the cc1plus requires more than 2 gigabytes of RAM, how large is your source file and the included headers (you can find it out by preprocessing it to a file using -E instead of -c)?
Hi,
Please try viewing the Android log (run adb.exe logcat) or launch debugging with VisualGDB and check for errors in the GDB Session/logcat windows.
Hi,
The problem with Eclipse is that every version stores the settings a little bit differently, so there is no consistent way of importing them automatically.
We have received a lot of feedback recently about debugging embedded projects built elsewhere and will be extending our Quick Debug feature with Embedded Quick Debug in the next version. Until then the suggested workaround is to import your projects.
Hi,
You can try following our tutorial on importing projects from CooCox IDE: http://visualgdb.com/tutorials/arm/coocox/
Let us know if that works.
Hi,
What exactly do you mean by “crashed”? Do you get some specific message? Can you attach a screenshot? Does it also crash when you run the debug APK without debugging?
Hi,
Thanks for your feedback. We have extensively tested our IntelliSense engine with the auto variables, nested classes and template classes and could not reproduce the problems you are reporting. Furthermore, many of our users reported that they are successfully using the Clang IntelliSense engine with complex C++11 code. Hence it looks like the problem on your side is caused by some configuration issue (e.g. incompatible CFLAGS, missing include directory, or some very specific statement that breaks IntelliSense). We will be happy to help you solve it, but we would need more information on reproducing it.
Could you reproduce it on a stand-alone project and send it to us? If not, could you send us a screenshot of the problem along with the CFLAGS/CXXFLAGS from the project view in the Clang IntelliSense Diagnostics console?
Hi,
We have provided a solution in this post.
