Arduino Addon for Mac

[zitronen]

Damn and I thought it was going to be easy...

[Cydonian Monk]

Now that I'm awake and semi-coherent (ie: it's not 3AM), I would agree this does not look terribly promising. There might be an unconventional solution to this however, and I'm not yet out of ideas. Still, this is digging into a layer of C# that I have no experience with... I'm a Linux dev by trade and mostly work with C/etc... so it's at least been educational.

Uhm, you do have verified that the actual SerialPort-Library you are using is cross-platform?

The description seems to imply that it should be, and there are several discussions among Linux forums about using that same library, so I'm partially assuming it is. I'm not convinced, though, and all the read/write routines seemed to use entry points in core.dll or kernel32.dll, which is a no-go for us. (The kernel32 usage in Port.cs is avoidable, as it is only allocating/freeing a buffer we don't need.) I'll verify tonight if I get the chance. (Edit: It's clear to me now the "multiple OSes" they discuss are Windows and Windows CE. It does appear to be written in such a way that /other/ support could be bolted on, but that would also require some other deep changes, such as environment detection.)

Your not using the standard .net/mono lib, so mono-docs are most likely not very helpful.

No, but it made for a decent example of SerialPort usage in a non-Windows environment. (Plus that page links to the same lib we're talking about, even though they're using System.IO.Ports.)

Worst case might be creating such a library yourself from old Mono source or by back-porting the current version (ps: as already linked earlier).

Thanks, I overlooked that. I'll take a look at it.

Edited February 12, 2014 by Cydonian Monk

[Faark]

Okay, there isn't much we have to take from mono to successfully compile against Unity 3.5 .net full Base Class Libraries: ISerialStream, SerialPort, SerialPortStream, SerialSignal & WinSerialStream

WinSerialStream would actually be the windows stuff and depend on kernel32. SerialPortStream on the other hand depends on the native MonoPosixHelper (and libc). That's most likely the reason that class was cut from Unity-Mono and sth we would have to provide. I'm not very familiar with native code, but here is a VS project file that seems to be for what we want. It appears to compile few of the c files from this directory. So that might fit your expertise more than .NET stuff

Once you got the native library, we still have to make sure the PInvoke does work properly. Unfortunately, the default lookup path appears to not include the directory of our dll-assembly and placing it somewhere outside of our GameData directory seems like a ****ty move & would complicate installation. As mentioned in my first post, in another not yet released (but windows-only) project i am using LoadLibrary from kernel32 to load my library from wherever i want. Guess you can do sth similar on non-windows? Though this stackoverlow-question implies that there might be issues and recommends dynamic pinvoke instead... what would be an OS-specific task for you to solve, again.

Edited February 10, 2014 by Faark

[cyoung_mi]

Thanks everyone for working so hard on this.. I really hope we can come up with a solution.

Never thought it would be this hard.

[Faark]

Here is the necessary part ripped from Mono's System.IO.Ports including some preparations for dynamic pinvoke. The native dependency (as mentioned above, mostly from serial.c) and its loading code is still missing, i hope Monk can contribute it.

[Cydonian Monk]

Excellent. Thanks Faark!

The native dependency and its loading code is still missing, i hope Monk can contribute it.

I hope so too. If I don't get to it tonight it'll be sometime next week, as this weekend is rather booked. Not sure how much work it'll take yet, probably not much. Just a question of finding time....

I wouldn't be offended if someone else gets it done first.

[Cydonian Monk]

I've been exploring a few alternatives.

Namely this: http://sourceforge.net/projects/amserial/

... which in a round-about way led me to this: https://github.com/playwithmyled/Internet-to-Serial-Proxy/wiki

I'm able to build and use both, FWIW, I'm just trying to figure out if it's possible to integrate AMSerial with the C# script in Unity.... I know IP traffic from a KSP plugin is possible, so using that proxy app might be a work-around, though it's not terribly elegant. Think I might look at what plugins such as Telemachus are doing tomorrow night if I get the time. (And building a new app specifically for KSP that's a bit cleaner than what's at the second link wouldn't be difficult.) This would also solve the port discovery problem.

I'm also wondering if it's possible to access Python methods from our C# scripts, as it would seem trivial to use this instead (and be platform agnostic, which is the best solution): http://pyserial.sourceforge.net - Not much of use turns up on my searches except some discussion from 2011.... And I'm not sure if something like IronPython is an option here?

Outside of that, the default build environment for C/C++/GNU stuff on OS-X 10.9 is non-existent, and it makes things a PITA to set up. (Gentoo back in 2003 was easier to bootstrap.....) The weird thing is I had the entire toolchain set up 2 OS versions ago... it's just all disappeared. Don't recall if I did a full install/restore (maybe), or if the 10.9 install zapped it. Regardless, that's an obstacle I can get past with a large hammer and some time, or I can just relent and use llvm in X-Code (maybe).

Edited February 12, 2014 by Cydonian Monk

[Faark]

... which in a round-about way led me to this: https://github.com/playwithmyled/Internet-to-Serial-Proxy/wiki

Letting someone else do the OS specific stuff? That's actually a great idea, even more if that could would supports multiple platforms. I was kinda afraid we would have to deal with 32vs64 bit stuff

[Cydonian Monk]

I was kinda afraid we would have to deal with 32vs64 bit stuff

I'm not. Anything I build will be 64-bit.

(Assuming I can get past the "duplicate entries on x86_64" compiler nonsense I was running into last night..... I've got an unfriendly header somewhere.)

[cyoung_mi]

Just checking in... any luck with this yet?

[Cydonian Monk]

Haven't had much free time in the last few weeks, and what I've had free I didn't really have any energy for it.

[cyoung_mi]

Haven't had much free time in the last few weeks, and what I've had free I didn't really have any energy for it.

TOTALLY understand.. I've been pretty busy myself and haven't even had time to play KSP... crazy right?

I was just checking.

Thanks again for even working on it.

[cyoung_mi]

Just checking in...

Is this project dead?

[Cydonian Monk]

Not entirely. Not yet at least.

To give a bit of an update: I've not been able to get the gcc build environment set up right on my Mac, at least such that I could build the libs needed to hook into. That's something I was going to tackle two weeks back, as I /really/ need to build a couple plugins for Gimp (so I can stop using it in a VM), which in-turn needs GTK, which includes what I need to build the bits of serial code extracted from Unity. I'll try to get to that Saturday and see what I can see. I was having multilib issues last I tried, and it was doing weird things like mapping unsigned long ints wrong, among other weird 32-bit vs 64-bit stuff. (I swear I had all that up and working before Mavericks....)

I did find my Arduino stuff while reorganizing a few weeks back, and I've been following the main thread for this to keep up... so I'm as interested as trying this as you. It's just a matter of finding the energy to grok code outside of work after having it thrown at me all day.

[cyoung_mi]

Not entirely. Not yet at least.

To give a bit of an update: I've not been able to get the gcc build environment set up right on my Mac, at least such that I could build the libs needed to hook into. That's something I was going to tackle two weeks back, as I /really/ need to build a couple plugins for Gimp (so I can stop using it in a VM), which in-turn needs GTK, which includes what I need to build the bits of serial code extracted from Unity. I'll try to get to that Saturday and see what I can see. I was having multilib issues last I tried, and it was doing weird things like mapping unsigned long ints wrong, among other weird 32-bit vs 64-bit stuff. (I swear I had all that up and working before Mavericks....)

I did find my Arduino stuff while reorganizing a few weeks back, and I've been following the main thread for this to keep up... so I'm as interested as trying this as you. It's just a matter of finding the energy to grok code outside of work after having it thrown at me all day.

Thank you so much for your continued work on this.. I understand you are doing it in your free time, with no compensation..

If there is anything I can to do help .. Just let me know.

Thanks again.

Chris

[Cydonian Monk]

Well, the compensation is that I get to use it once we get it working.

[Cydonian Monk]

So I've attempted to build two different serial implementations for OS-X today: The one stripped form mono linked by Faark, and this one: serial by wjwwood, which is basically exactly what I wanted (a C-languge/C++ implementation of pyserial). I can get the unix parts of the wjwwood library to build without issue, until it tries to link, at which point it freaks out due to me missing some linker flag that I don't yet know about. (Apple really doesn't make stock OS-X friendly towards those of us that build things... at least things that aren't Cocoa.)

The serial implementation from mono built perfectly once I did a bunch of legwork and cog greasing (mostly to get the above wjwwood library built). So we'll go with that. Next step is to test it and get the proper magical C# invocations and incantations hammered out, and then we might be somewhere.

There are still some minor changes required for zitronen's plugin to get it to work for us UNIX volk, namely removing skipping the code that checks the registry. Once I get the serial implementation to the point that it works, and works properly, I'll [edit] see if I can make the plugin code platform-agnostic and then [/edit] send zitronen a pull request so the plugin can work for both Windows and OS-X without too much trouble. And maybe then I'll look at what the GNU/Linux folk need.

Edited April 6, 2014 by Cydonian Monk

[zitronen]

Progess! I think there is only one line that does the registry check. You can pull or fork or whatever you want when you get it working!

[Background_nose]

Hi,

I thought I would poke my head in as I too am trying to get this working with OSX.

I *believe* I am making progress by simplifying and stripping down the port selection to a hard coded port name. For me this is "/dev/cu.usbmodem1411" which is found from the arduino IDE. Doing this allows all the registry check to be stripped out and the port name set.

Unfortunately this crude change hasn't completely worked and I have become a bit stuck. The log now reports:

[Log]: Error opening serial port /dev/cu.usbmodem1411: kernel32

The stack trace is perhaps more interesting:

[Log]: Stack Trace: at (wrapper managed-to-native) OpenNETCF.IO.Serial.Port:LocalAlloc (int,int)

at OpenNETCF.IO.Serial.Port.Open () [0x00000] in <filename unknown>:0

at OpenNETCF.IO.Ports.Streams.WinStream..ctor (Int32 baudRate, Int32 dataBits, Boolean discardNull, Boolean dtrEnable, Handshake handshake, Parity parity, Byte parityReplace, System.String portName, Int32 readBufferSize, Int32 readTimeout, Int32 receivedBytesThreshold, Boolean rtsEnable, StopBits stopBits, Int32 writeBufferSize, Int32 writeTimeout) [0x00000] in <filename unknown>:0

at OpenNETCF.IO.Ports.SerialPort.Open () [0x00000] in <filename unknown>:0

at KSPSerialIO.KSPSerialPort.Awake () [0x00000] in <filename unknown>:0

This suggests that there is still some windows stuffs going on here in WinStream.

It seems looking at the code that LocalAlloc is not good. This apparently should be changed to "calloc".

I've located the source to OpenNETCF.IO.Ports and I'm thinking of trying to make the changes necessary to fix this. Does this seem to others to be sensible? I've not messed around with code like this before.

[Cydonian Monk]

As it stands the entire SerialPort.dll is only for Windows and WindowsCE, so yes, there's a good bit of Windows stuff still going on. The two biggest things to get past in the KSPSerialIO plugin are removing/bypassing the registry check (which requires Windows dlls that I can't build against), and using a 64-bit UNIX Serial Port library.

The route I've been taking is to build the UNIX Serial Port code from the Mono libraries natively for OS-X. That much is done and works outside of KSP/Unity (using a stub to test). The next step is to write the Marshaling code for C# to load the library, which is where I was before a security project came up at work and ate my free time/energy. (It's been a stupidly busy year so far, which is both good and bad.)

If you'd like to take a stab at it, feel free. I can give pointers on what needed to change in the Mono Serial stuff when I'm home, but mostly it was just removing dependencies and resolving multiple declarations in header files. I could also zip up the modified source and cobble together a quick makefile too. There are also some posts a few pages back that might help.

[Background_nose]

Since then I have stripped out windows specific stuff to the point that It fails to open a port as the name I am passing to SerialPort.Open() is not in the IP:PORT format it expects. Which is where I got stuck for the day. I can't grok how they go from a "/dev/tty..." style port (or even "COM1" style) to this format. Which I am guessing means I have fundamentally misunderstood something. I think I will try to get it running under windows and use prints to see how things are changing, then try to follow that under OSX.

I would love to see what your approach has been and how far you've got to direct my own efforts.

I've skim read through the the past few pages, but I will sit down and try to follow this thread in depth to catch up.

If you could zip up your modifications that would be great to read through.

Many thanks.

[lawnmowerlatte]

Hey, just poking this thread to see if any progress had been made on the Mac or Linux side of things?

[Cydonian Monk]

I've not made any progress, and probably won't in the immediate future. I'm on the road for most of July, and getting away from code is the whole point of the trip. Maybe when I'm back. The sad thing is it doesn't seem to need much, I'm just burned out/up/blah.

For those with time/energy: Compiling the Mono unix serial port code was a simple matter of copying it and the required headers out to a second location and updating paths. That produced a working library for me (using either gcc and clang), and should for you. From that point all you need is the marshaling code for C#, which is what I've not quite been able to wrap my head around. (And as I've spent the last several months at work swimming in and fixing alien, barely-working, 3rd party code, the last thing I've wanted to do is confuse myself with something new....)

Linux already has a couple prebuilt serial options to choose from, as generally RS-232 is still in use and well supported. All you would need, again, is the wrapper for C#, and then a change for the KSP Arduino library to use that instead of the 31-flavours-of-Windows library it currently uses. I think.

[lawnmowerlatte]

Thanks for the update! Sorry to say that it all seems a bit over my head.

[Background_nose]

I thought I would weigh in with where I have got to. I have been taking a different route to Cydonian Monk and feel like I'm making some progress.

I have solved the problem by creating a new program that runs independently from KSP. This program controls all arduino communications and in addition displays a homebrewed Navball. KSP then communicates with this program by sending out and receiving the necessary data via UDP to the local 127.0.0.1 address.

The code is still very much in an embryonic state and I'm calling it successful purely on the back of sending Roll, Pitch, Yaw data from KSP to the Navball Program this morning. There may well be trouble ahead I haven't found yet.

The solution isn't elegant but for me it is great. I need to draw a navball on a separate monitor from KSP anyway, so it makes sense to have this program control arduino IO as well, away from KSP's oppressive security regime that has been causing problems.

I'll publish some code once I have a more complete version working, with 2 way communication between the Ardiuno and KSP. But it is all simple stuff.