Forum Replies Created
-
Posts
-
Hi,
Yes, this narrows down the scope.
Please try switching Clang IntelliSense to the “Projects” and “Remote VS” views and attach:
- A screenshot from the “Remote FS” view (please resize the window so that it shows all fetched directories at the bottom of the console).
- The entire text from Projects -> <project name> -> CXXFLAGS. If the text is missing, please share a screenshot of the “Projects” view instead.
This should explain what is going on.
Hi,
Thanks, looks like you are using a single-byte encoding for international characters that is not properly supported by the Clang engine. Please consider saving your source files in the UTF-8 encoding instead (via File->Save As).
Hi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2594.msi
If the problem persists, please let us know if it could be reproduced with publicly available Arduino platforms and libraries. If not, we will provide more detailed steps to diagnose it.
Hi,
No problem, we can help you. Please let us know whether it’s a cross toolchain-based project, or if it’s compiled on the Raspberry Pi directly.
In the latter case, what source transfer mode are you using? (e.g. automatic uploading, direct SSH access or shared folders).
Hi,
Thanks for clarifying it. Importing of existing uVision projects was indeed broken. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2594.msi
Please note that the import process won’t automatically convert the references to Keil packs, although you should be able to easily add them via VisualGDB Project Properties -> Keil Components.
Hi,
Sorry about that, it indeed looks like our bug introduced by a recent optimization in the code model reconstruction logic. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2594.msi
Hi,
No problem and thanks for the detailed description. We have reproduced the problem on our side and fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2594.msi
Hi,
Thanks for sharing details about the library; we will try to clarify what is going on.
VisualGDB gets the list of Arduino source files to show in Solution Explorer directly from the Arduino tools – it is exactly the same files that participate in the build. As header files do not participate in the build directly, VisualGDB simply scans the source directories for headers and shows them in Solution Explorer as well.
Specifically for the TFT_eSPI library, the TFT_eSPI.cpp file is the only source file that actually participates in the build of the sketch. You can double-check this by searching for .o files in the Output\SparkFun_ESP32_Thing\Debug\libraries\TFT_eSPI directory. The Extensions/smooth_font.cpp file is actually not compiled directly, instead it’s #included-d from the main source file:
#ifdef SMOOTH_FONT #include "Extensions/Smooth_font.cpp" #endif
We might eventually be able to show the included files in Solution Explorer as well (they could be queried using our Clang IntelliSense engine), although we won’t promise any specific deadlines for this as it would require a fairly large change on our side.
Hope this explains. Let us know if you have any further questions.
Hi,
The easiest way to accomplish this would be using a custom post-build action (requires the Custom edition). If you are using a lower edition, adding a custom msbuild action should have a similar effect.
Hi,
Thanks for the detailed screenshots. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2591.msi
Before starting the wizard, please open the View->Other Windows->VisualGDB Diagnostics Console, then open the VisualGDB Package Manager to trigger a full reload of the toolchain list (producing the diagnostic messages in the console). Finally, open the wizard again, reproduce the problem and attach the log from the diagnostic console. This should be sufficient for us to fix this.
Please also let us know if you are creating a new embedded binary project from scratch, or using project templates or any other advanced options.
Hi,
No problem. We should be able to include the device sharing tool in the next major VisualGDB release (please allow 3-6 months until we will have a preview build with this).
If you would like to get it earlier, we could offer it as a paid custom feature (typically 5 takes business days), but if your timing allows, we would advise simply waiting until we deliver it as a part of our regular release schedule.
Regarding the test frameworks, TinyEmbeddedTest is actually designed by us as a minimalistic test framework with minimum possible overhead on embedded devices, so we will more than appreciate your feedback on the issues you encountered and will be happy to make it better. We would appreciate it if you do start a separate thread about that, as it would make it easier for other users to find that discussion.
Hi,
This could be caused by some leftovers from the previous VisualGDB build that could not compute the IntelliSense settings correctly.
Please try deleting the VisualGDBCache and CodeDB directories and reopening the project. If it doesn’t help, please check if the problem persists in a freshly created project (we have quickly checked it with NUCLEO_L432KC and could not find any issues).
Hi,
This could be caused by your library not using the “src” folder format. Please refer to the Arduino library specification for details.
No problem, we can help you figure this out. Please attach the following screenshots:
- Registry editor showing the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Keil\Products\MDK key contents
- The contents of the Keil folder referenced via the registry
- The VisualGDB toolchain selector with the drop-down list open showing the available toolchains
This should help us narrow it down and suggest a fix.
Hi,
You don’t actually need to create a dummy project – simply install our regular ESP32 toolchain and point the hardware register viewer to the registers.xml file from it.
