- This topic has 8 replies, 2 voices, and was last updated 7 years, 6 months ago by
.
-
Posts
-
Greetings.
I’m trying to import a sample, existing project into Visual Studio to take advantage of all the cool VisualGDB features. Specifically, this project:
https://github.com/kanflo/opendps
It’s a rather cool “Open Digital Power Supply” app. It compiles easily in Linux, just as described, and uses the libopencm3:
make -C libopencm3 make -C opendps
However I’ve not been able to get it to compile with VisualGDB. I’ve been able to manually resolve most all issues of conversion – that would have been nice if handled automagically, but for a nagging (hopefully last) one…
Here are the steps I take:
File – New Project – Embedded Project Wizard. (call the project OpenDPS-import; my default location is c:\workspace-git\)
(click ok)
Select “Import a project built with command-line tools”; select “Specify a build command line manually”
(click next)
Filter: stm32f100c8 (select the device) ; check “Provide default stubs for system calls”.
(click next)
for “Directory with imported sources”… browse to “c:\workspace-git\opendps” , where this was fetched from GitHub like this:
git clone –recursive https://github.com/gojimmypi/opendps.git
leave the “Import preserving directory structure” radio button selected.
(click next)
leave the defaults (in my case, Segger J-Link in C:\Program Files (x86)\SEGGER\JLink_V614b (which is not actually connected at the moment – as it is in use by VM)
(click Finish)
fwiw – the first time I started writing this, the initial reason was that Visual Studio would explode with an “unexpected error” at that last “Finish” press during processing and restart. It did that twice in a row. But alas this most recent import time it did not.
Additionally – note that the Toolchain is set to “ARM in C:\SysGCC\arm-eabi” (readonly) – however the makefile is using a PREFIX=arm-none-eabi (but I would not this this would cause this problem I am having, just fyi)
I manually edited the Preprocessor Macros:
DEBUG=1 FAMILY=STM31F1 STM32F1
The Include Directories:
libopencm3/include/ libopencm3/include/libopencm3 libopencm3/include/libopencm3/cm3
and the Library Directories:
libopencm3/lib libopencm3/lib/cm3
I also “removed from project” all of the HAL related and other files copied that were giving errors – as they did not belong in the project. I also unchecked the “referenced frameworks” (HAL, System Init, and Legacy).
So at the end, I am still stuck with a compile error in nvic.h for an include file that does not exist:
# include <libopencm3/stm32/f1/nvic.h>
(as it does not exist, yet recall this compiles fine from Linux prompt)
I tried changing this to either of the 3 explicit instances of “nvic.h” that do exist: no joy.
It would seem to be an issue with the STM32F1 declaration, yet without that – there are even *more* compile errors without it – as it needs to be defined elsewhere. So perhaps there’s some other DEFINE that I am missing and/or did not get imported properly?
This seems to be more of an issue with the conversion process than the libopencm3 app – so I thought I’d start here asking for help. I hope this is not too much of a program-specific issue, as it would be great if VisualGDB could actually convert existing apps well (e.g. not including HAL library, detecting defines, includes, etc). Hopefully this is an example of something that could be either enhanced in the conversion wizard, or at least some documentation as to how to address problematic conversion.
Any suggestions or observations will be appreciated 🙂
Thanks a bunch.
Hi,
Just to double-check: you imported the project using the “specify build command line manually” mode, correct? If yes, you should not need to adjust any include/library directories in VisualGDB Project Properties (VisualGDB should not even show them as it will simply treat the project as a black box and build it “as is” using the original command-line tools).
If you are not sure, could you please attach a screenshot of the include directory settings that you had to edit?
Hi.
back to that “initial reason” for this new thread… 🙂 … Visual Studio crashes before conversion completion:
http://gojimmypi.blogspot.com/2017/05/converting-opendps-to-visual-studio.html
I tried 3 times – crashed each time. Also tried a 4th time importing from local copy on C:\workspace\opendps rather than that Z:\ mapped to Ubuntu. Same result.
the actual conversion / makefile issues are duplicated in my other thread here:
https://sysprogs.com/w/forums/topic/visualgdb-and-externel-makefile/
Windows 10 Version 10.0.14393 Build 14393
Visual Studio Enterprise 2017 Version 15.1 (26403.0) Release
VisualGDB 5.2
edit: Note that this same result occurs on two different computers.
Hi,
Thanks, we have managed to reproduce this. Unfortunately this is caused by a bug in VS2017 that causes random crashes after programmatically adding files and folders to Visual C++ projects.
We have submitted a bugreport to Microsoft and are also investigating possible workarounds, but the best short-term solution would be to temporarily downgrade to VS2015.
Thanks for the verification. Hopefully Visual Studio 2017 will be fixed soon. In the meantime I tried your advice with Visual Studio 2015:
Microsoft Visual Studio Enterprise 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.6.01586It does not explode, but it also does not compile. I added a few new pics here:
https://gojimmypi.blogspot.com/2017/05/converting-opendps-to-visual-studio.html
The problem appears to be the config generated: “make: *** No targets specified and no makefile found. Stop”
The resultant build config was “win32″… so I tried both creating an “ARM” as well as “VisualGDB” config, but no luck. I then tried to “convert to stand alone project”. As expected, no change to the missing make target.
I am not familiar with VisualGDB on manually setting make targets (I would have hoped the wizard would have done that for me).
I also tried the “Project – Add VisualGDB configuration – new Windows configuration” – resulting in “Creating Windows Configuration is only supported for Windows, Linux, and native visual c++ projects”
I’ve not been able to find any documentation or perhaps a tutorial on converting existing projects… could you kindly point me in the right direction? thanks 🙂
Hi,
This would normally indicate a problem with the project’s Makefile and selecting a different VisualGDB configuration won’t affect this.
Please try checking if you can build the project on Windows via command line (by running make.exe manually). If not, the project’s build scripts may not be compatible with Windows and would need to be fixed before you can import the project into VisualGDB.
Hi.
That sounds like a good suggestion. Could you give a little more detail on just how to do that? I guess I’ve grown so used to Visual Studio IDE right-click builds, that I’ don’t know how to do it manually from command-line. I went back to a known-good VisualGDB project that works and compiles – and even there have not been able to figure out the command-line method. I tried simply “make” from the solution and project directories… that of course returned the same “make: *** No targets specified and no makefile found. Stop.” error.
Hi,
Sorry, if you want to import complex 3rd-party projects into VisualGDB, you do need to understand how to build them manually and locate/install the necessary build tools. VisualGDB can simplify a lot of the common tasks through features like automatic header discovery, but it requires understanding of the underlying build process if you want to go beyond creating & modifying basic samples that work out-of-the-box.
Our best advice would be to check with the project vendor for specific steps required to build the project under Windows.
actually, I do know how to build them: the project builds fine in Linux. 🙂 As for Windows, I’ve been programming in Visual Studio a long time, but I’ve never once have taken a solution developed there – and compiled it from command line. To take something like VisualGDB project in Visual Studio and compile that from command line, seems rather complex. Addicted to IDE’s I guess. 😉 (not always a great thing to not understand the whole process when insulated with an IDE, I know).
If I had the ability to build this project on manually on Windows before import, well, I kinda would not need to import to Visual Studio. I do agree that would be useful. But I was hoping to avoid the hassle of setting up the toolchain since I thought that’s what VisualGDB import wizard would do for me.
It would be cool if VisualGDB helped with that import process, and used the toolchain specified in the wizard. But ya, I understand given an arbitrary makefile, that’s probably not a trivial process to convert. Too bad, as that would be really awesome.
fwiw – I was able to get Windows-based debugging working from VSCode (of all places!). I compile on Linux, use OpenOCD there, but connect using the VSCode GDB. It is really quite awesome:
https://gojimmypi.blogspot.com/2017/05/vscode-remote-debugging-of-embedded.html
VSCode shockingly does many of the debugging things that Visual Studio does (single step, hover text for variable values, intellisense, peek definition, and more)
Cheers
- You must be logged in to reply to this topic.