C++/C# Sharing source code (struct)

Posted by: @inq

↑

I'm working on a project where I am using TCP to communicate between a Visual Studio C#.NET program running on a computer and a Sketch/C++ program running on an MPU... specifically an ESP8266.  I've set up a protocol using structs.  These only contain normal variable types that both environments recognize.  At the moment, it works totally fine where I can say... fill out a struct on the desktop and it comes out into the Sketch.  Here is an example of one message on both.

 

#pragma once

// CommonComms.h on the ESP8266.

struct VelocityChange
{
    const static char ID = 'V';
    float LeftVelocity;
    float RightVelocity;
};

using System;

// CommonComms.cs  on the Desktop

namespace Inq.Utils
{
    public struct VelocityChange
    {
        const char ID = 'V';
        float LeftVelocity;
        float RightVelocity;
    };
}

 

I would like to make one file that both projects can use.  Just so that as messages are added, I only put them in one place, and re-compile both sides.  I can get around issues of syntax... like hiding the using System; when used on the ESP8266.  What I'm having troubles with is... I can't include a *.h file in the C#.NET program and I can't include a *.cs file in the Arduino IDE.  I've done some searches on the Internet, but haven't found anything useful.  

Does anyone have any ideas how I might do this?

Thanks.

VBR,

Inq

Unless I misunderstand, something like the following should work

In each project, create a define unique to that part, maybe #define NETpart and #define SketchPart

Then in your common header file use #ifdef so that only the parts needed by each part is used.

Hi &inq,

  What you are trying to do is way beyond my experience, but I tried this....

I added this line to the Arduino .ino file

const int LED_BUILTIN = 2;

  And it compiled as usual.

Note, it didn't find it, if I just had #include "test.cs", eventhough the same file, in the same location, when it was named "test.h" was found.

-------------------------

I see Ron has also provided an answer. His solution may well be authentic.

I make absolutely no claims as to whether my suggestion is valid, except as I describe above.

Best wishes, Dave

@davee Keep in mind Dennis @inq wants all the include stuff in a single file to be used by both parts, the C# and the C++. Including the file isn't the problem, the problem is getting each compiler to only SEE the relevant lines in the include. What I suggested is common as dirt in virtually all open source projects. If you dig into the built in and board libraries for our Arduino environment you will see the same sorts of things. For example many examples test what hardware is the target as in AVR or SAMD. See pic for all the arduino hardware types there are.

@zander, @davee,

Thank you for your replies.  @zander, yes... I was planning on #deffing away for syntax issues like you suggest.  That, I knew how to handle.  The discovery @davee found was my problem.  As he illustrates if I simply tried to do 

#include "test.cs"

The Arduino IDE can not find the file even though it is clearly in the same folder as the INO file.  I mistakenly assumed it was because of the cs extension.   As soon as I used the absolute path, the problem went away!  For example, here is the same example using a single file that compiles in both IDE's.  Now, I can have one common place to put all the various messages (struct) that will communicate back/forth between apps.

Thanks!

VBR,

Inq

CommonComms.cs

#if ARDUINO
  #pragma once
  #define public
#endif

namespace InqSim
{
    struct VelocityChange
    {
        public char ID;
        public float LeftVelocity;
        public float RightVelocity;
    };
}

#if ARDUINO
  #undef public
#endif

InqEgg.ino

// The following include is shared in both the Arduino Sketch
// and the VS C#.NET project.  The Arduino IDE must use 
// an absolute path when the extension is "cs".   Also, must
// include the using namespace statement for visibility.

#include "X:\InqEgg\CommonComms.cs"
using namespace InqSim;

@inq AH, I did misunderstand, but @davvee saved the day yet again!

@davee Just a quick followup, since the full path is a maintenance problem and not very portable, did you try a few of the other possibilities like #include "./test.cs" or even whatever the environment variable name is for your home or current dir?

I did try a link/alias on my Mac but it failed because it actually read the link which is a binary file. I think that is a bug and I will report it to the arduino team.

I suspect Dennis may be using a subset command thus his example starting at X, OR maybe something else.

I am curious because I have a similar situation that I have not been able to solve probably due to a bug in the IDE as I said.

Hi Ron @zander,

  I only did a quick test as I described (before I saw your first message).

I started with "test.h",  with test.h alongside the .ino file, in the same directory. It worked as expected.

Renamed the file "test.cs" and similarly in the #include "test.cs".  Compiler said it couldn't find the file. This I took as a hint, that it was willing to look, but had different ideas as to where to look with a .cs filetype, albeit I didn't know where it was looking.

So I simply tried giving it an absolute filepath, hoping it would override any built-in search paths .. and it worked.

I realised it was not a particularly robust solution, but hopefully it is a useful start.

Sorry, that is my entire knowledge on the subject.

Best wishes, Dave

Posted by: @zander

↑

@davee Just a quick followup, since the full path is a maintenance problem and not very portable, did you try a few of the other possibilities like #include "./test.cs" or even whatever the environment variable name is for your home or current dir?

I did try a link/alias on my Mac but it failed because it actually read the link which is a binary file. I think that is a bug and I will report it to the arduino team.

I suspect Dennis may be using a subset command thus his example starting at X, OR maybe something else.

I am curious because I have a similar situation that I have not been able to solve probably due to a bug in the IDE as I said.

I would say this is an Arduino IDE bug.  Why should it allow other extensions, but only if they're on an absolute path.  I tried the "./test.cs" and it didn't work.  But... YMMV since you're on a Mac and I'm using Windows with IDE 1.8.19.  It sounds like an IDE bug to me, but maybe it's fixed in the 2.0+ version.

And yes... I do use a subst since I have several environments I have deal with. 👍 

Hi @inq & @zander,

  I was using Windows 10 and Arduino 2.1.1.

  And I just tried "./test.cs" without luck, although it was happy with the full pathname using / as well as \, for pathname separators. I am not clear if Windows can handle ./  form.

Linux might be a different story.

Best wishes, Dave

@inq I am using 2.x but I also tested with 1.x. If it is an IDE bug, it's an oldie. I just discovered there are 2 link/alias type facilities in MACOS, I will test again with the other. For WIN, subst is the best.

@davee Windows has understood *nix for quite a while now; I just opened a command prompt and did an ls (dir), cd ./ and all ok.

@inq The IDE documentation doesn't say one way or the other what is allowed for a #include filename. It only discusses the use of <> and "". If we look at the GCC documentation, it may be more revealing. As @davee has shown, it works with a full name.

Hi @zander,

@davee Windows has understood *nix for quite a while now; I just opened a command prompt and did an ls (dir), cd ./ and all ok.

  Interesting ... I previously tried to run a trivial "hi.bat" batch file as ./hi instead of the usual hi and it didn't like it.

ls doesn't work either.

cd ./  and cd .\  seem ok.

Best wishes, Dave

@davee Are you using cmd or PowerShell? cmd has very limited *nix support, but the newer command tool is PowerShell. I just tried ls and pwd.

Just type terminal into the search box and you will see 3 choices, powershell, (old) command and azure power shell. The default is Windows PowerShell.