Arduino Addon for Mac

[cyoung_mi]

Hello all,

I'm really hoping I can find a Mac Modder out there that can fork this plugin..

I think the original idea was very cool, but unfortunately the creator is unable to made a Mac version of the plug in.

Can anyone help?

http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2804-Feb%29

Source code for the plugin

https://github.com/zitron-git/KSPSerialIO

[Cydonian Monk]

Hmm..... I'll take a look at this sometime over the weekend. After a quick glance it looks like it might be possible, and will just need updated to use OS-X serial ports instead of whatever is inside that serialport.dll blob. I've got all the other bits I'd need to test, and I /think/ the Arduino stuff is still installed on my MacBook....

No promises though, ok?

[cyoung_mi]

Great thanks!! If I can help out in anyway I'd be happy to..

I currently have my Arduino Uno programmed and wired for the three LED test tutorial listed.. just need the KSP plugin.

I think a plugin like this would be so useful..

I really like the idea of an external display.

[zitronen]

+1

I would start with looking at http://sourceforge.net/projects/serialportnet/, it's what I'm using. It's incomplete, but all the code is there and should run on Mac. I had to do some registry hacks to list the available ports in windows, because "getports()" doesn't work. Maybe it will work just fine on Macs or maybe you will need some other hacks, unfortunately I don't have a Mac to test.

[Cydonian Monk]

There's some discussion on the Unity forums about Serial Port support being broken on Unity for Mac. There's also the issue that dlls can't be copied into the KSP.app Application Bundle and work the same way as is done on Windows, where you can place dlls in KSP_data with no issue. (See discussion on the "KSP Soundtrack Editor" thread regarding the mp3 dll.) There are, however, work arounds that can be explored, as long as we don't need to rebuild the App Bundle. (Edit: none of that should be necessary anyway.)

Thanks for the link. Unless someone else beats me to it and gets it working I'll look at it this weekend. I'll need to find my Arduino stuff, too, which might be tricky as it's been in hiding since I moved.

Edited February 12, 2014 by Cydonian Monk

[Faark]

There's also the issue that dlls can't be copied into the KSP.app Application Bundle and work the same way as is done on Windows, where you can place dlls in KSP_data with no issue. (See discussion on the "KSP Soundtrack Editor" thread regarding the mp3 dll.) There are, however, work arounds that can be explored, as long as we don't need to rebuild the App Bundle.

Isn't it against the rules to place stuff outside the GameData directory? Its a bad style at least, thats why i use LoadLibrary(...) from Kernel32.dll to load my native dll from wherever i want... a Mac might allow sth similar?

[Cydonian Monk]

Isn't it against the rules to place stuff outside the GameData directory? Its a bad style at least....

Possibly. I know System.IO is (or was) off-limits, but modding Unity itself? Might be worth bringing up in the Soundtrack Editor thread if so. (That's the only place I've seen it done lately.)

I don't expect that'll be needed here, but without sitting down to look at it I can't say for sure.

Apple's SerialPort support is... different at best and broken at worst. I remember having issues with JMRI when I first jumped from Linux to OS-X that required minor code changes.

(Appologies if this is a duplicate post. My phone network just derp'd.)

Edited February 7, 2014 by Cydonian Monk

[cyoung_mi]

I guess I'm not sure why it would need to be in the app bundle, or even outside of the GameData directory..

but then I don't know much about KSP plugins..

There are other plugins that send data out to external devices.. but they are not using the serial port directly.. the CCP app ( Custom Control Pad ) for example..

I really hope we can figure this out.. It would be a lot of fun to play around with the Arduino.

Thanks again for all your hard work guys.. if I can help out at all.. Please let me know!

[Cydonian Monk]

Small update, since I've found some time to look at this today.

So far I haven't needed to change much (inside of KSPSerialIO). Obviously the registry hack zitronen was using won't work on OS-X, so that needs changed. The SerialPort library built without issues in MonoDevelop on OS-X, and the assembly is already included with KSPSerialIO so I'll just use that. From a project standpoint, KSPSerialIO had to be "updated" to target .NET 3.5, as .NET 4.5 doesn't exist in any format I can use in Mono. There is also an undefined reference to the Microsoft.CSharp assembly that I can't resolve, but as far as I can tell that isn't even needed, and the project build perfectly fine without it.

The trick then is getting a list of Serial Ports from OS-X. Serial/tty ports are exposed under /dev/tty* (or equivalent callouts, as discussed below). A connected device on my OS-X system follows the general "readable" format of /dev/tty.[DEVICENAME] and /dev/tty.[DEVICENAME]-[NNNNyyyy] (where NNNN counts up from a zero and yyyy is the year) in addition to its true hardware location of, say, /dev/ttys000. Having that date/iterator string attached to the end of the device path is going to be mildly problematic, and as I've discovered with my USB-RS232 dongle in JMRI it can change every time the device is plugged in to a different USB port.

What I'm looking at now is a discovery system for those connections. (As expected, System.IO.Ports is either hard-coded to be off-limits or just flat-out doesn't work. (And may not be in Unity at all?)) This should be simple enough, but we really need some way to select the one we want from inside of KSP. A quick work-around is declaring the device path in a config file and loading that at launch, which is sort of the same as the registry hack used currently by KSPSerialIO.... If I can get SerialPort discovery working though, a selection menu is the most ideal solution.

At the very least hard coding the serial port seems to "work"*, though naturally my trackball didn't know what was up when I tried to connect to it. Off to find my Arduino stuff..... (* Edit: As mentioned below, "work" as in "gets past trying to read the registry", not as in "successfully talks to anything.")

Edited February 12, 2014 by Cydonian Monk

[cyoung_mi]

Thanks for all the work Cydonian.. as for the serial ports.. you can search for /dev/cu.modem* I believe.

I think the idea of a config file would be fine, but a pull down selectable device would be even better!

Looking forward to testing what you come up with.

[Cydonian Monk]

I'm wondering if we'll even need to use the callout devices. I suppose it might be better to use them, though if anyone has a tty connection open to the Arduino they should expect it to block anyway.

[zitronen]

I just added a config file in my plugin which allows you to change COM port and Baud rate, if hardcoding works you can just do that and have the user choose the port in the config file.

[Cydonian Monk]

That is probably the better solution for now. There really doesn't appear to be anything that needs changed from the respect of your plugin (though I wasn't able to find my Arduino toolbox to test it before I had to leave for the day).

[cyoung_mi]

Is there a beta test plugin you can upload / send me? I'd be happy to test it.. I have my Arduino stuff all plugged in and ready to go.

[Cydonian Monk]

I'll be home in an hour or two. Taking a quick look at zitronen's config file change it shouldn't be much to remove the registry parts of the code and recompile. When that's done I'll upload a version (with the updated code and project and whatnot included) to DropBox and post a link.

[Faark]

As expected, System.IO.Ports is either hard-coded to be off-limits or just flat-out doesn't work.

Actually, Unity's mono environment isn't a standard net environment and just doesn't include System.IO.Ports. Such missing stuff is even more annoying when using third party libraries that depend on it. In your case would the compiler at least notify you, would you compile against the actual System.dll included in KSP. But thats even more tricky unless you let sth like UnityVS set it up for you. Anyway, back to the topic... you seems to have found a working port library. If not, another approach would be to use Mono's System.IO.Ports code... though getting it to work would take some time as well.

[Cydonian Monk]

Ok, this is a pretty quick and dirty hack here, and since I haven't really changed anything aside from performing surgical removal of some of zitronen's code (and filling in with stubs) I haven't bothered to do a real fork on GitHub. The source code and the updated solution is included in the zip file, and the license remains the same as zitronen's original, which I was unable to find. (I'm implying rights to fork the code and redistribute from these two posts: http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2808-Feb%29?p=944424&viewfull=1#post944424 and http://forum.kerbalspaceprogram.com/threads/68642-Arduino-Addon-for-Mac?p=955379&viewfull=1#post955379 If that's in error I'll freely remove the link and the file.)

Download is here: (Edit: Removed, since it doesn't even remotely work.)

Give that a whirl and let me know if anything happens, good bad or otherwise. As usual, copy everything in the GameData folder from the zip file to your KSP GameData folder. Try to do it in a "fresh" install of KSP if you can, so that any logs or crash reports are "untainted" by other mods. To change the serial port you'll need to open config.xml in the GameData/KSPSerialIOosx/PluginData/KSPSerialIO/ folder and change the DefaultPort node's value to the tty/cu that you want to use.

Anyway, back to the topic... you seems to have found a working port library. If not, another approach would be to use Mono's System.IO.Ports code... though getting it to work would take some time as well.

I'm not sold on calling it a working port library just yet, at least not for OS-X. It /does/ at least act like it's connecting to things (edit: this was a misinterpretation on my part), and seems to know when the port it's attempting to connect to doesn't exist (Edit: that much is true at least.... just don't expect a read to work....). If it doesn't work, though, it's something that's at the layer below KSPSerialIO and would likely need changes to the SerialPort lib (which may or may not be beyond what I'm allowed to get involved with, for various reasons, but would require further evaluation based on whatever issues crop up). Kind of why I wanted to test it fully before uploading it, but....

Edited February 14, 2014 by Cydonian Monk
Removed link.

[cyoung_mi]

Well I tried the plugin on a fresh install of .23 KSP.. I changed the config file to use /dev/tty.usbmodem1a1321 ( also tried /dev/cu.usbmodem1a1321 ) but when I launch KSP and launch a craft I get a "No Display Detected" message.

I have my Arduino Uno programmed with the KSPIODemo sketch.. ( the Tutorial one that only uses the three LEDs )

I verified my /dev port with the Arduino compiler, and made sure I closed it before launching KSP.

<?xml version="1.0" encoding="utf-8"?>

<config>

<double name="refresh">0.08</double>

<string name="DefaultPort">/dev/tty.usbmodem1a1321</string>

<int name="BaudRate">38400</int>

<int name="HandshakeDelay">2500</int>

</config>

Log file:

[LOG 02:45:26.180] KSPSerialIO: Default Port = /dev/tty.usbmodem1a1321

[LOG 02:45:26.180] KSPSerialIO: Refreshrate = 0.08

[LOG 02:45:26.180] KSPSerialIO: BaudRate = 38400

[LOG 02:45:26.180] KSPSerialIO: Handshake Delay = 2500

[LOG 02:45:26.181] AddonLoader: Instantiating addon 'KSPSerialPort' from assembly 'KSPSerialIO'

[LOG 02:45:26.182] KSPSerialIO: Version 0.12

[LOG 02:45:26.182] KSPSerialIO: Getting serial ports...

[LOG 02:45:26.182] KSPSerialIO: Found 2 serial ports

[LOG 02:45:26.182] KSPSerialIO: trying default port /dev/tty.usbmodem1a1321

[LOG 02:45:26.193] Error opening serial port /dev/tty.usbmodem1a1321: kernel32

[LOG 02:45:26.193] KSPSerialIO: Only default ports, exiting.

Thoughts?

Edited February 10, 2014 by cyoung_mi
forgot to include log

[Cydonian Monk]

Thoughts?

Yes. None pleasant. I've a good suspicion that's an issue with the SerialPort lib, and have a couple ideas (one of them being a DllImport in Port.cs that I just fixed). Nothing I'll be able to take a good stab at until tomorrow evening, though.

(Another being that kernel32 / WinAPI functions just don't exist outside of Windows, despite oft-repeated rumours on various sites that they might. Cross-platform C# is not something I deal with much at all, and reimplementing that SerialPort library could be treading a _bit_ too close to what I do for a living... and thus might cause "issues". What's weird are how some bits of this work while others don't, I suspect because it's trying to use Windows-specific memory routines....)

Edit: To be a bit more precise, with the default build SerialPort is throwing an exception when trying to use LocalAlloc, as that's a Windows memory thing and part of kernel32, which it didn't load (for a couple reasons). Getting beyond that (by fixing the DllImport and then either having a kernel32.dll it can load, or by forcing the lib to realize it's not on Windows), gets it to a point where it "works", but it fails when trying to write to the port it just opened. That's where I was yesterday, though at the time I was assuming it couldn't write to the things I had connected because they were busy or not writeable. Unfortunately it does the same when talking to a dummy listener (as I tested tonight), so I'll need to dig at it a bit. Might also help if I actually have the Arduino stuff connected, but it's not yet making it to the point where the handshaking occurs. (Edit: clearly anything that uses kernel32.dll (for Windows) or core.dll (for Windows CE) will never work on OS-X, despite my optimism for a magical solution....)

Edited February 12, 2014 by Cydonian Monk

[cyoung_mi]

At the very least hard coding the serial port seems to work, though naturally my trackball didn't know what was up when I tried to connect to it. Off to find my Arduino stuff.....

How did you get it to work hard coding the port? Not sure why

Port = new SerialPort(PortNumber, SettingsNStuff.BaudRate, Parity.None, 8, StopBits.One);

would work with a hard coded port, vs the variable.

[Cydonian Monk]

How did you get it to work hard coding the port? Not sure why

would work with a hard coded port, vs the variable.

Worked as in "got past the registry check in KSPSerialIO and didn't throw an exception prior to Port.Open()", not as in "Successfully talked to something."

[zitronen]

The source code and the updated solution is included in the zip file, and the license remains the same as zitronen's original, which I was unable to find.

Oh oops I forgot the license. There is no license, do whatever you want. I will put something in the thread.

<string name="DefaultPort">/dev/tty.usbmodem1a1321</string>

This will not work. Even in windows you can't use the device name as the port number, it has to be something like "COM1".

[Cydonian Monk]

<string name="DefaultPort">/dev/tty.usbmodem1a1321</string>

This will not work. Even in windows you can't use the device name as the port number, it has to be something like "COM1".

That's the only way that will work. Under POSIX environments the "named port" is the file descriptor itself. The SerialPort library seems to recognize this, but is being fooled into thinking it's running in a Windows environment by something.... Every bit of reading I've done on that library indicates that the SerialPort lib is POSIX compliant. Including this example: http://www.mono-project.com/HowToSystemIOPorts (Edit: This was also a misinterpretation on my part) I've not sat down and taken a through look at it, which I will do sometime this week when I find the time. Tonight if possible. (I may have been overthinking this anyway.)

Edited February 12, 2014 by Cydonian Monk

[zitronen]

huh.. ok my fault. I assumed it would be the same. From your link looks like mono has its own serial stuff, maybe you can find the mono code for serial port and make a new serialport.dll from that? They should all work the same so perhaps all you will need to do is replace the dll?

[Faark]

That's the only way that will work. Under POSIX environments the "named port" is the file descriptor itself. The SerialPort library seems to recognize this, but is being fooled into thinking it's running in a Windows environment by something.... Every bit of reading I've done on that library indicates that the SerialPort lib is POSIX compliant. Including this example: http://www.mono-project.com/HowToSystemIOPorts I've not sat down and taken a through look at it, which I will do sometime this week when I find the time. Tonight if possible. (I may have been overthinking this anyway.)

Uhm, you do have verified that the actual SerialPort-Library you are using is cross-platform? Your not using the standard .net/mono lib, so mono-docs are most likely not very helpful. Some quick googling for OpenNETCF.IO.Ports turned up this stackoverflow question, where an very old answer states that this is basically a wrapper around kernel32.dll. I couldn't find any source that produces the same library as zitronen's SerialPort.dll, but what i found doesn't look very promising as well. If OpenNETCF.IO.Ports does in deed require windows you have to find a port library for .net that does offer cross platform support. This might be not as easy, since .NET & Mono both come with a default implementation...

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). In that case i highly recommend you use a dev environment that compiles exactly against a unity runtime, so the compiler will notify you about other missing dependencies.

Edited February 10, 2014 by Faark