Hi,

Debug of local libs has been working for a long time (supposedly).

It's possible something broke with libs in the src\_micro-api\libraries folder if debug isn't working. I assume that's where your library is?

Recent versions of visual micro support shared c++ projects as arduino libraries so you can put the libs anywhere and still debug them. The way they work is much better and you still work with standard format arduino library code.

There is an initial doc here. http://www.visualmicro.com/post/2017/01/16/Arduino-Cross-Platform-Library-Develo...

There are many benefits to this new approach. For example

• the solution explorer is easier to use/organize because libraries show as projects
• multiple projects can use the same library
• your own or arduino libraries can be debugged
• allows arduino libraries to be used from any location and version
• integrates better with source control

I will test debug of old style local libs but I highly recommend this new way of working. It takes advantage of core visual studio functionality instead of jamming the files in a "special" folder below the project.

Can you create a zip with a solution you have saved along with a test empty master project and test library. So I can see the configuration and spot the issue.

If you can email to info[at]visualmicro.com along with a link to this post

Also confirm the library break-point is in a .cpp file?

Thanks

Hi Tim,

I did save the solution (CSense.sln), at least when I reopen Visual Studio my breakpoints are still there.

I've put one in CSense2.ino on line 35, one onf CSense.cpp line 37 and one on Sense.cpp line 19.

CSense2.ino::setup()  will call CSense::setup() which will call Sense::setup() so they all three should be reached.

I'm not with the hardware at the moment so I can't test any alternatives util tonight.

Thanks for sending the files. Sorry for the confusion. I think microsoft have moved the breakpoints to a file in the .vs sub folder.

What libraries have you installed and from which location?

Thanks

ps: the breakpoint in the .h will be ignored

Are you saying the TinyGPSSensor was installed with the IDE and that you didn't install it yourself?


It's not an issue because the breakpoint should be ignored but the last upload shows this break-point at line 24

It's also invalid because serial.print can not work in this location

 <BreakPoint Index="3" Name="CSense.h, line 24" Id="1d008f83-ca3e-4390-9a5b-04dbcdb8b8da" Enabled="1" Message="" MessageTextType="2" PreProcessedMessage="" Condition="" ConditionType="1" CurrentHits="0" File="d:\developme.................\csense2\csense.h" FileLine="24" FileColumn="1" FunctionName="" FunctionLineOffset="1" FunctionColumnOffset="1" HitCountTarget="1" HitCountType="1" Language="C++" LocationType="3" Tag="&lt;vmbp Id='bb2bb496-bdae-47ce-8f1e-830ae163fc72'/&gt;" Type="1" ToString="System.__ComObject" BreakWhenHit="1">
        <Source>17	#include &lt;ThermistorSensor.h&gt;
18	#include &lt;RealtimeClockSensor.h&gt;
19	//#include "TinyGPSSensor.h"
20
21	class CSense : public Sense {
22	public:
23
--&gt;24		ThermistorSensor fridgeTemp{ ..............
27
</Source>
      </BreakPoint> 

Tim@Visual Micro wrote on Feb 21^st, 2017 at 8:25pm:


TinyGPSSensor.cpp and .h are files I wrote, and are part of the SenseFrameWork local library

How about StandardCplusplus.h

Where should that be located?

I have found a few confusing things with shared lib compilation. Possibly not directly related to debug but made them hard to configure. I will write more in the release notes when we find this issue.

I'm having another problem, but maybe I should create a new thread for this ....

If I look at the file properties of the SenseFramework files that are in the "External Depencies" group of my master project, they are referenced by absolute path.

If I move the complete solution, including all subfolders and hidden folders somewhere else, it doesnt compile anymore because it cannot find the absolutely referenced files. How can I refresh the references to my own lib files in the Extrernal dependencies folder of my main project?

mailed the log!

Hi,

I think this just might be a whole load of confusion because of some conflict between new visual micro features and some lack of understanding about the quirks of arduino.

1)
First of all remove the "src\_micro-api-readonly" branch from your main project. That folder was added via "Micro>Toggle Hidden Files" and you are more advanced + want edit debug to the "src\_micro-api-readonly" section is causing a lot of confusion. The toggle hidden files has some cross over with using shared library projects which visual micro will work around more seamlessly in future versions. For your current test you do not want that code toggled in.

2)
Arduino does not have concept of local libraries. It has libraries supplied with the ide and libraries in the sketchBook\libraries folder that you install yourself manually or via the library manager .

Visual micro will use the sketchbook path that is configured in the arduino ide unless you override it in visual micro. It defaults to myDocuments\Arduino therefore "user libraries" are in myDocuments\Arduino\Libraries

It doesn't matter if libs are placed below id or sketchbook but it's best to use sketchBook for your user installed libs

3)

You can forget the term local libraries. Visual Micro docs will soon remove the words. With the addition of c++ shared projects (as you have used for your library) a library can be located anywhere. So that can be a parent folder to the project, sketchbook\libraries, ide\libraries. 

The libraries can be easily discovered/known because they are added as References to the project as you have done. That is why they can be located outside of the "known arduino" locations.

4)

I have just built your project with debug in the Sense.cpp. It's easy to see if debug commands are being added to the compiler source if you switch on verbose compile or the show build folder compiler property. In that case the build output will show the temp folder used for the build. Your library will be in a sub folder below and a copy of sensor.cpp in the \src folder below that. In sensor.cpp you should see an extra include for vm_dbg.h and some debug commands where you requested the breakpoint to be located.

If you are not seeing the debug command I suspect that visual micro has detected "toggle hidden files" containing the same library and assumed it is read-only and not a candidate for debug. This is why I suggested removing the src\_micro-api folder for now.


5)

I found a bug that you have worked around and actually its caused you to improve compile speed. With the new shared library system you had to switch off "vMicro>Compiler>Deep Search" unless the header that has the same name as the shared library was #included above other headers from the same library. So #include <SenseFramework.h> would have need to be before the first include which is <TinyGPSSensor.h>

6)

With a paid license you can switch on "vMicro>Compiler>parallel build". This will improve compile time when lots of files have to be rebuilt.

I will try to explain but your libs can still be in normal Arduino locations in which case the shared project simply provides something that visual studio can use in the solution explorer and to provide intrllisense.


Creating from scratch is simply a matter of using the standard visual studio file,new,project , shared project.


Sounds like the tutorial needs to explain about Arduino too

Sketch book doesn't matter if you have a reference to a shared project.

The link I gave to the shared lib doc shows how to create a project from a lib (see below) 

However as I said, your project worked find for me and I could see the debug commands in the output. So I suggest you switch on the verbose option I mentioned so you can then go have a look at sensor.cpp in the build folder and see if it contains the debug commands where the breakpoint should be. Also to ensure you removed the breakpoint in the .h.

http://www.visualmicro.com/post/2017/01/16/Arduino-Cross-Platform-Library-Develo...

1)

Quote:


This is how both the arduino ide and visual micro works. SketchBook\Libraries is where user libs are installed


2)
File>New>Project>C++>Misc>Shared Project t

Shared projects are a standard part of visual studio and unrelated to visual micro. You can google them if you need help

3)

Why not resend a zip with your solution so I can see what you have done.

4)

Because your project is so big I suggest a new simple test project using a small shared lib such as EEPROM so you can easily see what is happening and how things work.

Ignore my email asking for a link

I have seen this if you define and use code from a header without a .cpp. With arduino and gcc only .cpp files are compiled into .o files and then linked. 

If this is the case then you have defined prototypes in your header file(s) so the cpp files are compiled but the linker fails to find the actual code.

......

Unrelated but also important is to use #pragma once at the top of header files of an #if condition.

#pragma once 

Ok . I've solved the linker error.

It was caused by the fact that my main .ino file was called CSense.ino and that I used another .cpp/.h combination that was also called CSense.cpp and CSense.h

When I renamed the .cpp and .h the linker error vanished.

I never had this problem when compiling through a batch file which called arduino-builder directly but apparently the Visual Studio / Visual Micro toolchain has some other ideas about this

Well, I had both and it worked

But I can understand that it wasnt such a wise descision to use equal names there
I would suggest not allowing it, but then generating an explicit error message... would save a few hours of taking your project apart