Hi,

Yes this makes sense as a temporary solution however it is perfectly normal to have these source codes locally and does not require full path qualification of includes.

You do not need to use any of the c++ settings and as you found this would not work anyway.

The source files should be directly in the sketch folder with the arduino source code then you can add a standard #include "filename.h" without full path.

If you do this you should remove the library from the arduino library folder otherwise this might cause the confusion you encountered.

Hello,

It would help if you could update us as to if you have normal <filename> includes or still using full path qualifications.

Please confirm the following:-

1)

First off please set (Micro Debug) = false and do not use the debugger until VS works the same as the Arduino IDE. This will allow us to compare apples with apples 

With (Micro Debug) = False breakpoints are ignored so will not need to be considered in our discussion.


2)

May I see the full compiler output please. Can you confirm that project property (Validation Skip = False)?

...

Once we have established these answers I will have a couple more questions that will help us understand why you have this problem.

Thanks

Hi thanks for all of the info, I am starting to see some reasons for the problems, hopefully the following info starts to help.

1 - VS C++ Settings (should not be altered unless to tweak intellisense/editor/ui controls)

When working in an Arduino projects you must ignore all the VS C++ settings. The   'Additional Include Directories' is automatically maintained by Visual Micro, this is how we make intellisense work correctly for Arduino core and libraries. So you will see erratic results if you are changing this yourself. Further more Visual Micro entirely re-routes the VS compile process. This means that VS C++ warning levels, include directories and everything in VS is ignored when we compile. This is important because Arduino does not compile the same way a VS C++ project compiles and we are 100% compatible with Arduino.

Therefore any changes you have been making to the C++ project settings will only have confused or altered the VS intellisense and will not affect compile.

2 - Compiler Warnings

Should you want to see Arduino warnings there is an option under Tools>Options>Visual Micro>Compiler to enable warnings in all of your Arduino projects. I suggest that you leave warnings off simply because the Arduino core throws quite a few warnings all of which can be ignored.

3 - You have confirmed that if you disable debugging (or remove all breakpoints) Visual Micro compiles the same as the Arduino Ide. Great! and none of the C++ project properties affect this. 

The Arduino Ide does not have such as thing as a "project". When you compile with the Arduino Ide it looks at the files in the sketch folder and performs a compilation based on every valid source file. When you compile Arduino in Visual Studio it does the same. 

This is also why, when you re-open an Arduino project in Visual Studio, the sketch directory is scanned and any new or missing sources are added/removed from the VS solution explorer. This ensures that your VS projects are always Arduino compatible, removes possible confusion associated to using VS project files and allows the sketch/projects to be compiled in either Ide at any time.

4) I asked about the debugger setting "Validation Skip" because the compiler output you posted shows only a debug compile. The standard config for Visual Micro performs two compiles (Release and Debug) when you start debug. 

The reason being that to work the debugger has to inject code into a temp copy of your program. If your Arduino program has an error in it then the injected code will confuse the error messages so for this reason, for newer users, the default is to attempt a release compile and only perform a debug compile if that is successful.

I suggest switching back to default "Validation Skip=False" if you encounter any future issues. Whilst you did check that the program compiled in the Arduino which proves that your program would have validated correctly I thought it might help in the future to explain this.

5)

I think the problem was that a break point pointed to an old source file in a different location. I suspect you might have had a break point on some source or library code with the same name as a source file in the current sketch. That the debugger thought it was safe to process the file when it should have ignored it. Visual Micro does protect for this problem because it has to support multiple projects in a single VS solution.  As you know breakpoints are stored in the VS solution and not with each project. This means that it is possible to have a list of invalid breakpoints but again Visual Micro should have ignored them. I will look at the Visual Micro break point management system to see how that could happen.

Summary

I think/hope this makes sense and that now your project has become stable in terms of libraries and source code locations that the problem isn't a problem any more.

The wiki on the main visual micro web site does contains some documents that might help but needs improving.

Hi Don,

Sounds like you might have the wrong version of the debugger installed.

Please uninstall the debugger using Control panel>add/remove features

To see which version of vm you have installed, "Tools>Options>Visual Micro>Version" and install the matching debugger from the beta page.

Does that fix it? What version of vm are you running?

Thanks

Hi, the versions sound fine. I'll try a {String} over the weekend but it was used in initials tests. However the data type handling has been extended since then so maybe String objects are now a problem.

Hi Don,

I have now tested the debugger with various data types and find it works fine. So something else is going on here.

Would you please zip and email your sketch and try to also include the solution with breakpoints in the places that you have set them. info[at]visualmicro.com

Please also tell me the version of VS and also which version of Arduino you are using.

Thanks

Hi Don,

Okay the problem is that you have a syntax error in your breakpoint at line 42.

Your solution didn't contain any breakpoints when it arrived so I used the log files in the "Visual Micro" folder to manually add your breakpoints one at a time. So thanks for including the sub folders in the zip they are always useful 

The project compiled fine for debug until I added the Breakpoint at line 42. I think for long breakpoint "when hit expressions" it is a good idea to make sure the "When Hit" column of the BreakPoints list is wide enough to see the code/expression. 

You can see the problem that strlen(buff is missing the closing bracket...

calling showSprintfFailure(), {status} {strlen(buff} 

Syntax errors in breakpoints are not reported very clearly which is why the default plugin performs both a "Release" and a "Debug" compile. 

As stated previously the default project property setting of "Validation Skip" is False, this means that you will see two complitaions in the output below when you perform a debug/upload compilation.

Notice below that first we get a successful release compile in under half a second with size 9390 bytes. Then we see the debug compile fails.

Compiling 'tst' for 'Arduino Uno'
Binary sketch size: 9390 bytes (of a 32256 byte maximum) (0.453 secs)
Compiling debug version of 'tst' for 'Arduino Uno'
tst.ino : : In function 'void loop()':
tst.ino : expected `)' before ';' token
Error compiling 

Visual Micro performs these two compilations so that you can know that an error in the "debug" compile is a result of a break point invalid Breakpoint "placement", "when hit" and/or "condition".

I hope this makes sense and that you find everything is working well.

Look forward to hearing your thoughts

Thanks

ps: I noticed you have a VS temp folder called ipch below your sketch. VS creates these automatically which is a pain because they are difficult to delete. This article tells you how to stop ipch folders from being created below C++ projects

pps: I've cleaned up the thread a bit so it is helpful to others. Hope that is okay

Hi,

In the background Visual Micro uses programs such as avr-gcc to compile in the same way as the Arduino IDE so for a non-debug compile I would not expect to see any difference.

Can you confirm if the sprintf is working okay in non-debug mode?

Thanks

Good to hear the debug is working well.

The plugin doesn't have any control over how sprintf is compiled. When you compile, in the background, the plugin uses exactly the same programs and syntax to compile as the Arduino IDE.

Therefore this must be something else. If you get time to try it again it will be appreciated. Thanks

BTW, the Arduino forum has reported this issue; apparently there is no floating point support for the sprintf / printf library calls.

Don