[support]

Good to know it works. The IntelliSense cache uses incremental snapshots, so it will normally only reparse the changed files (if you are editing a header file included from multiple source files, it will invalidate all of those source files).

If you believe too many files are re-cached, please try the following:

1. Open Clang IntelliSense Diagnostics Console and clear the log
2. Edit one file and trigger the cache rebuild
3. Let us know the file you edited and share the output shown in the Diagnostics Console. It should normally mention why the cache is being rebuilt, so we can help you understand what is going on.

[support]

Hi,

Thanks for the update. We can still help you get it to work – VisualGDB supports both Keil v5 and v6, so if there is a combination of tools that works with the uVision IDE, it should be possible to configure VisualGDB accordingly.

Please feel free to submit more details (project file, assembly file, exact error messages) via our support interface and we will help you get it to work.

[support]

Hi,

Sorry, this is showing the flags for the main source file, but not for the project itself. Please click at the project name and then copy the CXXFLAGS.

Also the diagnostics console shows that the Clang server process has terminated. Was this caused by reopening the project, or does this message seem to occur randomly?

[support]

Thanks, this looks like some of the Keil project variables are not recognized by our importing plugin. If you could share the .uvproj file (we don’t need the actual source files), we should be able to fix this.

Alternatively, simply try clicking “Ignore” and removing invalid options via VisualGDB Project Properties.

[support]

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.

[support]

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).

[support]

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.

[support]

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).

[support]

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.

[support]

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

• This reply was modified 6 years, 9 months ago by support.

[support]

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

• This reply was modified 6 years, 9 months ago by support. Reason: updated build link

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[Author]

Posts