Forum Replies Created
-
Posts
-
Hi,
Sorry, the fully automatic renaming of the ESP-IDF projects is not yet supported. Hence, you would need to edit the Makefile (or CMakeLists.txt file if your are using CMake) in your project directory manually in order to rename the project. Simply search for the project name in that file, replace it and save the file. VisualGDB should automatically reload the project structure and show the new name.
Hi,
For Arduino projects please use the first page of VisualGDB Project Properties to manage preprocessor definitions and other global options.
For ESP-IDF projects please use the VS Project Properties of a specific ESP-IDF component to define exported preprocessor macros (those macros will apply to all components in a project, not just the selected component). You can access the properties of the main component via the Properties command for the project node itself.
Hi,
ESP-IDF projects do not use automatic library discovery like Arduino ones and require the libraries to be wrapped as ESP-IDF components. You can read more about the components in the ESP-IDF documentation. Once you get an understanding of the component structure you need for your project, simply use VisualGDB’s Add New Item command in the component list to create the necessary components.
Hi,
It is still on the roadmap, however it is hard to give any estimates currently, we are prioritizing a few other features over it, sorry.
Thanks for the repro. We have added this to our investigation queue, however due to the current amount of investigated issues and their priorities, it may take 2-4 weeks to fully process this.
Hi,
The .axf extension is used by the Keil compiler for the ELF files. VisualGDB follows the Linux naming convention for the built files, hence the ELF files it produces have no extension. I.e. you can find an equivalent of the AXF file for your project under the following path:<Project Directory>\VisualGDB\Debug\EmBGM13P22F512GA_Test01.
The .rsp files are used to pass the command lines of the tools, avoiding the Windows command line length limitation of 8192 characters. They do not contain any code or symbols on their own.
Sorry, it looks like you did not add “VERBOSE=1” to the GNU Make command-line arguments (see our previous reply), hence Make did not dump the gcc command lines.
Please try adding it as suggested and share the updated log that should include the exact gcc command lines used to build the code.
Hi,
Yes, simply use the Advanced Mbed Project Subsystem and you should be able to use the latest mbed version out-of-the-box.
Unfortunately, it’s hard to suggest anything specific without knowing the exact steps to reproduce the problem.
Please describe the steps required to reproduce it, starting from creating a new project (see this page) and we should be able to suggest what is going on.
Hi,
The easiest way to achieve this would be to use the CMake-based projects and add the following constructs to the CMakeLists.txt files:
if (CMAKE_BUILD_TYPE EQUAL "DEBUG") set(CONFIG_SPECIFIC_MACROS CONTROL2) endif()
and then simply add ${CONFIG_SPECIFIC_MACROS} to the regular list of preprocessor macros via VS Project Properties. This will affect both build and IntelliSense.
If it doesn’t work, please let us know and we will help you configure everything.
Strange. Please try enabling verbose build (add “-v” to Ninja command-line arguments or “VERBOSE=1” to GNU Make command line arguments via VisualGDB Project Properties -> CMake Proejct Settings -> Ninja/Make command) and then build the project again.
It will show the exact command lines used by the build system for each file. Please locate the command line for any file from that library and check what is going on (e.g. ${CMAKE_SYSROOT} got expanded incorrectly, or the path is not present in the command line at all).
If you are not sure, please post the corresponding command line from the build log and your updated target_include_directories() statement and we will help you understand it.
P.S. You can also try using our CMake Debugger to quickly understand what is going on. It allows stepping through CMake statements and will evaluate variables like ${CMAKE_SYSROOT}.
Hi,
No problem. The “Exclude the startup file from project” should exclude the startup_xxx.c file from the project (you can change it later via the first of page VisualGDB Project Properties, save the project and compare the .vcxproj and .props files against the versions checked in the sourec control to see what exactly the setting does).
The “Advanced Low-Level Driver Functions” sets the USE_FULL_LL_DRIVER preprocessor macro that in turn enables some advanced functionality in the STM32 SDK. You can search the STM32 low-level drivers for USE_FULL_LL_DRIVER to see what exact functionality gets affected by this setting.
If you are planning to stay up-to-date with the STM32 SDK, we advise NOT converting the project to a stand-alone one. Then simply updating the BSP via Tools->VisualGDB->Manage VisualGDB Packages will automatically affect all projects targeting STM32 devices. That said, you may need to apply minor edits to the projects; although the STM32 SDKs are usually backwards-compatible, sometimes small changes (e.g. adding new macros to the configuration headers) might be required.
Hi,
Sorry for the confusion. Although most of VisualGDB’s tutorials indeed show one project per solution, VisualGDB fully supports having multiple projects in the same solution.
Please simply right-click on the Solution item in Solution Explorer and select Add->New Project to add a new VisualGDB project (e.g. a unit test project) to the existing solution.
If it doesn’t work, please let us know and we will help you further.
Sorry, the settings in both cases look equivalent. To be fully sure, please consider reverting them back and forth 2-3 times and checking if the problem reoccurs consistently.
As a long-term workaround, please consider setting the GNUToolchainExtraPath MSBuild variable in the .vxcproj file. It is used internally by VisualGDB to propagate path directories exported by the selected toolchain, so you can edit it to inject the Python path into the environment as well.
Also, as the variable is lost between Visual Studio and MSBuild, it could be worthwhile verifying if the problem can be reproduced with the regular Exec task on a regular non-VisualGDB project and checking with the Visual Studio support whether it’s a bug that could be fixed on the VS side or if there is a setting controlling this behavior.
Sorry, not sure what exactly you meant. Please try describing the problem using the first 2 steps of the 3-step format shown here and we will suggest the best solution.
