Sorry guys, I went to the beach for a few days. Back now though :)
ODB-II is something I want so I hope to get to it at some point, but since it took me two years to get off my butt and do this much I wouldn't wait on me to do it ;)
Well, it seems like what you really need is some good code to communicate with serial devices. If you had that, you could:
1. Communicate with serial OBDII devices
2. Control XM Direct units
3. Output data to LCD/LED displays
4. Get data from NMEA GPS devices
I'm too swamped for the next few months to get on the path to figure this out, though. Anybody else willing to put some serial comm code into CFE?
I'm open to ideas on what people think it should do (though remember it should be generic to allow the plugin developer to do the specifics like talk to a GPS, ODB-II, etc..).
Just some quick thoughts:
- It should manage connection prefs (e.g. last device connected) storage.
- Handle error checking for missing device (at startup and while running).
- Handle input and output (should this be done by notifications, selector call backs, or both?)
- Configure the port speed.
I'd have to look at the serial interface (it's been awhile and I can't look right now) to see what other things should be bubbled up/handled.
I looked into this a few months ago and I could tell that it wouldn't be incredibly difficult to do but I hadn't programmed in Cocoa at that point and it was an uphill climb.
I've got some serial code that Jirka very helpfully sent to a friend of mine when we were working on XM that could be helpful. PM me if you're interested.
I've already started to think about the interface to it, but if someone wants to beat me to the punch they are more than welcome to ;)
.net 2.0+ has a great SerialPort class (System.IO.SerialPort). It has event callback functionality and everything. I've successfully used it to communicate with and parse data from a Holux M1000 GPS. I've started a little bit of work to communicate with and parse data from a Elmscan 5, just haven't gotten around to it yet. Either way, that library is awesome. No looping through or waiting for returns, just use the built in eventhandler functions and you're good to go.
NSFileHandle has the same functionality that you are talking about, it is just for basic file handles though. You just need to request the underlying C file id from the object so you can set it up the serial port configuration (bits, speed, etc..), then you just use NSFileHandle to handle your select loop type monitoring of it and it will notify you when there is work to be done.
Oh geez sorry about that I actually got linked to this thread from a google search ;)
ironically, the google search was "ODB serial port C#"