[Sherlock]

 

Hi, OK thanks, I did used to do a great deal of Win32 C development on Windows but that stopped around nine years ago so I am rusty.

Anyway I did get what seeking to do, two projects each referring to to “libraries” – these are in an unrelated sub folder and the projects are referring to these source by relative paths and also have additional include paths specified at the MS project level, so that they can see the header for these libraries.

The code is all being developed on Nucleo F446RE boards.

You can see how I did this:

• The libraries are here.
• A transmitter project is here.
• A receiver project is here 

(The receiver is at this point, more or less a clone of the transmitter, I’ve not really started working on that yet).

This seems to be sufficient for what I wanted being able to share library code easily, but if you have any suggestions or ways to do this better, please do shout!

 

Thanks

 

 

 

• This reply was modified 1 year, 5 months ago by Sherlock.
• This reply was modified 1 year, 5 months ago by Sherlock.
• This reply was modified 1 year, 5 months ago by Sherlock.

[Sherlock]

OK I see, so that’s not something I can do.

Well my core question is then, how can I have two distinct projects, in different folders, be able to “see” source and headers in some other folder?

Is there any way to adjust a project’s setting to tell it to include some source folder and some header folder, when compiling?

I can see that the Visual Studio project settings offer an “Additional Include Directories”, is that the only way to do this? and can that also contain .c files, not only .h?

I want to work on two distinct projects where each one must include some support headers and source files, I do not want to duplicate these as copies within each project’s folder so how can I do this?

Thanks.

 

 

 

 

 

[Sherlock]

I should have mentioned that, the problem is that when I do that the only buttons I see on the dialog is “Add” and “Cancel” I do not see the small arrow that usually appears. If I I try the same thing on some other non Visual GDB project I do see the small arrow. The dialog should show a button that looks like this:

But I see no arrow, just a plain “Add” button.

 

 

 

 

[Sherlock]

Yes, you’re right! “refactoring suggestion” my apologies, many thanks!

 

 

[Sherlock]

Just FYI too, I’m using VS 2022 version 17.3.6 and have the Color Theme set to Dark+ which is what I use for .Net and other projects and languages.

This might help you reproduce it.

 

[Sherlock]

Hi, OK I looked at that (and I’ve used this a lot in the past for my C# .Net work) but I do not know which specific C++ entry to adjust.

If I simply begin to edit an existing name, this odd highlighting kicks in, so it is the act of editing an existing name that seems to trigger this, and I have no idea what specific C++ entry this pertains to!

If I edit a C# file in a C# project it doesn’t do this, it does kind of select the name being edited but highlights it differently, the name gets surrounded in a dotted rectangle but the word is readable, slightly shaded but readable.

 

Thanks

 

 

 

• This reply was modified 1 year, 6 months ago by Sherlock.

[Sherlock]

Hi, thanks this is helpful, for my immediate purposes I’m using MSBuild projects and nothing more.

I created a new repo and used the Github Visual Studio ignore, then added this:

# VisualGDB MSBuild Projects
.vs/
.visualgdb/
VisualGDB/

 

Does this seem OK? might there be anything additional to consider?

Thanks

 

 

 

 

 

 

 

[Sherlock]

Beautiful !

All good, thanks for a prompt and precise response, much appreciated.

 

 

[Sherlock]

OK installing now…

[Sherlock]

Interestingly that when I choose “Program and Start Without Debugging” this succeeds, I see the “The device has been programmed successfully” dialog and the board seems to reset and the code gets loaded (I can see expected activity on my DSO).

 

 

 

[Sherlock]

I can’t see the “Edit” option here any more so I can’t add to my original post.

Anyway I just ran a repair of Visual GDB but this seems to have had no effect on this behavior.

 

[Sherlock]

If I try to start without debugging (from VS debug menu) I see a console window that soon vanishes, no app seems to load into the board and VS doesn’t crash, here’s what I captured from the console window:

 

Attachments:

You must be logged in to view attached files.

[Sherlock]

Hi, OK that helps me actually, so the contents of Device-specific files folders are never intended to be manipulated by the developer.

So there’s never a situation where I’d need to include some additional STM32 header in my source file and that include file would not already be present in the Device-specific files header section?

Every include file I’d ever need to leverage any aspect of HAL should already be present in the Device-specific folders?

Thanks

 

[Sherlock]

This is resolved, it was caused by me assuming I could freely leverage the std periph library within a project initially created for HAL.

[Sherlock]

OK understood, I have now posted this as a question on the STM forum site along with details of a public GitHub repo that contains the (unbuildable) project.

https://community.st.com/s/group/0F90X000000AXsASAW/stm32-mcus

Thanks.

 

• This reply was modified 4 years, 3 months ago by Sherlock.

[Author]

Posts