Hi there

Does anyone know, generally speaking, how the Visual Micro extension works to compile and upload a sketch to the Arduino? I've heard that Visual Studio can only use the VS compiler, so what mechanism does it access the Arduino one instead and compile the hex file? What options in the IDE make it do this?

The reason I'm asking is because I'd like a single solution to be able to compile and upload for Arduino, and then in a different build configuration, build something different like a native Windows program. This is because I want to use Visual Studio's unit test suite for my Arduino projects, within the same Solution as the project itself. I imagine this would involve creating a new build configuration (called e.g. "unit test"), excluding the main .ino file from the build, using preprocessor directives to compile some bits of the code differently (e.g. not #include'ing Arduino.h, I'd imagine, and exporting the methods and properties under test in the same way as you would with a .dll), and changing the project properties. And some other stuff too I'm guessing. I managed to hack an Arduino project into something that's unit test-able by doing the above, so I guess it's possible, but I would definitely like to do it properly by understanding what I'm doing. If anyone has any info, in particular on what Visual Micro makes Visual Studio do to compile for Arduino, and what options/buttons/project properties/etc inside the environment make it do that?

Thanks!

Dan

Great, thanks for this - it's useful to know about point 1) in particular. I've actually recently noticed that Ctrl->F5 and F5 aren't automatically making the Micro compiler compile, it tries to use the c++ compiler instead (error list includes errors like "macro name '__cplusplus' is reserved, '#define' ignored" and so on). Could this be the reason? (I'm on VM version 1606.17.10). I've also noticed that the "assembly location" option gives the location of a .dll - is this what makes it assemble, i.e. the compiler is the same for an Arduino build compared with a Windows Native one, but the assembler different?

I'll have a play with option 2. As long as it lets me switch between the two using build configurations, in the same solution, I don't mind. If option 1) isn't working then this would be a good workaround, although it would be more direct to do it that way instead. (Are any legacy versions available?) Nice to know about 3) as well.

This has given me something to go on and I'm determined to get this set up! I'm making a how-to as part of this for my own use so I'd be happy to provide this to you when I'm done if you're happy to provide support? I'd appreciate that!

Many thanks

Dan

Ah ok. With the "code being active in the editor, then F5 to build" feature, this isn't working. I think I broke it when I was playing with all the properties for everything. Do you know how I might fix it? Also, do you mind pointing me towards the settings you mentioned anyway, in case they come in useful?

I guess that the compiler errors I was seeing was because the visual studio compiler was trying to compile the above file. Which was because of the above "F5" error.

Dan

Hi Tim

Thanks for that. The F5 button press doesn't work either when this is true or when the arduino code is the startup project. I'm not sure what I've done.

I did however get unit testing working. I did it by excluding certain bits (including the .ino file) from the build, building it as a .dll, and exporting the methods I wanted to test. Here are the instructions. I would point out to anyone wanting to do this that the work doesn't stop there: if you're testing any code that uses Arduino core functions, you'll need to mock these functions up when testing it. It'd be prudent to take this into account as well when judging whether unit testing will be an overall investment in time.

Anyway, here it is, I've just dumped my own notes in here so they're a bit rough but hopefully still useful.

To add unit testing to an existing Arduino project:

1) Create a build configuration called "UnitTest". Copy settings from "release" and create new project configurations.
(I did this for a Win32 configuration. Does it work just as well for x64?)

2) For the project properties of the original arduino project:
- exclude .ino and [projname].arduino.h from build in the project properties (and change "content" to 0 in the same place?)
- in the project properties:
  - change configuration type to a .dll
  - C/C++ Preprocessor definitions: (delete all arduino-related ones if they exist), add "UNIT_TEST" and "_VSARDUINO_H_"
  - C/C++ Additional include directories: (delete references to all arduino-related folder locations if they exist)
  - note that the above two are overwritten when compiling for Arduino, so you'll have to go back and do this every time you switch
    back to unit test after compiling for Arduino. In fact the include directories are overwritten when you switch over.

3) Create a native unit test C++ project in the same solution and:
- add a reference to the other project
- #include the header files in the unit test c++ file for the classes containing the methods you want to test. May need to
  specify e.g. "../[filename]", or the full path, or maybe fiddle around with the include directories in the properties
- add the same preprocessor definitions as the arduino project. (could you do this in the solution properties then?)

3) In the classes you want to test:
- add "_declspec(dllexport)" between "class" and the classname in the header file where the class is being declared.
- set up a macro (called "[CLASSNAME]_API" or similar to compile the above storage class specifier for the UnitTest
configuration but not for the main Arduino build


4) As you write the tests/code:
- Need to keep going into Arduino.h and #including the files and writing the #defines and typedefs that are used in your code
and putting this into a section #if defined(UNIT_TEST) in the header files.


Notes
- make sure they're all set to the same platform in the solution properties -> configuration
- this turns the arduino project into a .dll. is this the best way to do it? Suppose it's as good as any.

Enjoy!

Dan