Porting RM libraries to Mac OS X

[gfb107]

Excellent. Are you going to try compiling the jp12serial interface code next?

[alex750]

I have already started. Here's the makefile I'm using:

Code: Select all

.SUFFIXES:
.SUFFIXES: .jnilib .cpp .hpp 

GPP = g++
ARCH = x86_64
JAVA_INCLUDE=/System/Library/Frameworks/JavaVM.framework
INCLUDE = -I$(JAVA_INCLUDE)/Libraries -I$(JAVA_INCLUDE)/Headers

all: libjp12serial.jnilib

libjp12serial.jnilib: jp12serial.cpp jp12serial.hpp
	$(GPP) $(INCLUDE) -shared -arch $(ARCH) -fPIC -o libjp12serial.jnilib jp12serial.cpp

I read through the readme; it doesn't look like I'll need to worry about anything other than jp12serial.cpp and jp12serial.hpp...The file com_hifiremote_jp1_io_JP12Serial.h states that it's machine generated. Do I need to keep this?

I haven't made any changes to jp12serial.hpp.

I did add the following to jp12serial.cpp, at line 336 (in the function "const char *portNames[]"):

Code: Select all

#ifdef __apple-darwin //AKA Mac OS X
  "/dev/ttyp0", "/dev/ttyp1", "/dev/ttyp2", "/dev/ttyp3", "/dev/ttyp4", "/dev/ttyp5", "/dev/ttyp6", "/dev/ttyp7", "/dev/ttyp8", "/dev/ttyp9", "/dev/ttypa", "/dev/ttypb", "/dev/ttypc", "/dev/ttypd", "/dev/ttype", "/dev/ttypf",
  "/dev/ttyq0", "/dev/ttyq1", "/dev/ttyq2", "/dev/ttyq3", "/dev/ttyq4", "/dev/ttyq5", "/dev/ttyq6", "/dev/ttyq7", "/dev/ttyq8", "/dev/ttyq9", "/dev/ttyqa", "/dev/ttyqb", "/dev/ttyqc", "/dev/ttyqd", "/dev/ttyqe", "/dev/ttyqf",
  "/dev/ttyr0", "/dev/ttyr1", "/dev/ttyr2", "/dev/ttyr3", "/dev/ttyr4", "/dev/ttyr5", "/dev/ttyr6", "/dev/ttyr7", "/dev/ttyr8", "/dev/ttyr9", "/dev/ttyra", "/dev/ttyrb", "/dev/ttyrc", "/dev/ttyrd", "/dev/ttyre", "/dev/ttyrf",
  "/dev/ttys0", "/dev/ttys1", "/dev/ttys2", "/dev/ttys3", "/dev/ttys4", "/dev/ttys5", "/dev/ttys6", "/dev/ttys7", "/dev/ttys8", "/dev/ttys9", "/dev/ttysa", "/dev/ttysb", "/dev/ttysc", "/dev/ttysd", "/dev/ttyse", "/dev/ttysf",
  "/dev/ttyt0", "/dev/ttyt1", "/dev/ttyt2", "/dev/ttyt3", "/dev/ttyt4", "/dev/ttyt5", "/dev/ttyt6", "/dev/ttyt7", "/dev/ttyt8", "/dev/ttyt9", "/dev/ttyta", "/dev/ttytb", "/dev/ttytc", "/dev/ttytd", "/dev/ttyte", "/dev/ttytf",
  "/dev/ttyu0", "/dev/ttyu1", "/dev/ttyu2", "/dev/ttyu3", "/dev/ttyu4", "/dev/ttyu5", "/dev/ttyu6", "/dev/ttyu7", "/dev/ttyu8", "/dev/ttyu9", "/dev/ttyua", "/dev/ttyub", "/dev/ttyuc", "/dev/ttyud", "/dev/ttyue", "/dev/ttyuf",
  "/dev/ttyv0", "/dev/ttyv1", "/dev/ttyv2", "/dev/ttyv3", "/dev/ttyv4", "/dev/ttyv5", "/dev/ttyv6", "/dev/ttyv7", "/dev/ttyv8", "/dev/ttyv9", "/dev/ttyva", "/dev/ttyvb", "/dev/ttyvc", "/dev/ttyvd", "/dev/ttyve", "/dev/ttyvf",
  "/dev/ttyw0", "/dev/ttyw1", "/dev/ttyw2", "/dev/ttyw3", "/dev/ttyw4", "/dev/ttyw5", "/dev/ttyw6", "/dev/ttyw7", "/dev/ttyw8", "/dev/ttyw9", "/dev/ttywa", "/dev/ttywb", "/dev/ttywc", "/dev/ttywd", "/dev/ttywe", "/dev/ttywf",
#endif

I believe this reflects the /dev entries OS X uses for USB. I didn't find any specific /dev/usb entries.

Anyway, here's the dump from my first compile attempt:

Code: Select all

g++ -I/System/Library/Frameworks/JavaVM.framework/Libraries -I/System/Library/Frameworks/JavaVM.framework/Headers -shared -arch x86_64 -fPIC -o libjp12serial.jnilib jp12serial.cpp
jp12serial.cpp:242:79: error: termio.h: No such file or directory
jp12serial.cpp:296: error: ‘HINSTANCE’ does not name a type
jp12serial.cpp: In function ‘int jp12EscapeComm(int)’:
jp12serial.cpp:384: error: ‘ioctl’ was not declared in this scope
jp12serial.cpp: In function ‘int jp12Init(char*)’:
jp12serial.cpp:521: error: ‘IUCLC’ was not declared in this scope
jp12serial.cpp:525: error: ‘OLCUC’ was not declared in this scope
jp12serial.cpp:543: error: ‘XCASE’ was not declared in this scope
jp12serial.cpp: In function ‘bool openPort(const char*)’:
jp12serial.cpp:1026: error: ‘port’ was not declared in this scope
jp12serial.cpp: In function ‘const char* openRemote(const char*)’:
jp12serial.cpp:1122: error: ‘OutputDebugString’ was not declared in this scope
jp12serial.cpp:1169: error: ‘OutputDebugString’ was not declared in this scope
make: *** [libjp12serial.jnilib] Error 1

[gfb107]

You might be able to just comment out line 242.

Line 296 should be moved down so it is inside the IFDEF WIN32

For IUCLC you could try

Code: Select all

#ifdef IUCLC
  options.c_iflag &= ~IUCLC;
#endif

Do something similar for OLCUC and XCASE.

Change line 1026 to

Code: Select all

	strcpy(new_portName,portName);

I think you can change the outputDebugString calls to printf calls

[mathdon]

The file com_hifiremote_jp1_io_JP12Serial.h states that it's machine generated. Do I need to keep this?

Greg didn't answer you on this one. I think you do need to keep it. It is machine generated, but by Java to provide the hooks needed to link the native dll to the java RemoteMaster. My understanding is that you did keep the corresponding header for DecodeIR.

I think you can change the outputDebugString calls to printf calls

Alex, I suggest instead that you surround each of them with a #ifdef WIN32. These output to a MS debugger called DbgView and only have a significance when that program is open on the desktop.

[gfb107]

Thanks Graham, missed that. You definitely need to use com_hifiremote_jp1_io_JP12Serial.h. It is an import part of the glue that allows RMIR to make calls into the JP12Serial shared library/dll.

I think we should take out the #define and #ifdef that makes it seem optional.

[alex750]

I have made the following changes:
Line 242: Commented out, with a note to uncomment on non-Apple Unices.
Line 296: Moved into the #ifdef WIN32 block below.
Lines 521, 525, 543: Surrounded calls to IUCLC, OLCUC, XCASE with #ifndef __APPLE__ blocks (not __apple-darwin--I did a "cpp -dM" to find the correct option).
Line 1026: Changed strcpy(new_portName,portName[port]) to strcpy(new_portName,portName).
Lines 1122, 1169: Surrounded calls to OutputDebugString with #ifdef WIN32 blocks.

I'm still getting the error related to ioctl, though. This particular bit of code puzzles me:

Code: Select all

int jp12EscapeComm( int func )
{
#ifdef WIN32
  if ( !EscapeCommFunction( hSerial, func ))
//	FIXME: Call to ioctl fails in __APPLE__
#else
  int status;
  ioctl( hSerial, TIOCMGET, &status );
  switch ( func )
  {
    case CLRDTR:
      status &= ~TIOCM_DTR;
      break;
    case SETDTR:
      status |= TIOCM_DTR;
      break;
    case CLRRTS:
      status &= ~TIOCM_RTS;
      break;
    case SETRTS:
      status |= TIOCM_RTS;
      break;
    case CLRBREAK: 
      return (ioctl(hSerial, TIOCCBRK, 0) == 0);
    case SETBREAK: 
      return (ioctl(hSerial, TIOCSBRK, 0) == 0);
    default:
      printf( "Unknown function %i\n", func );
      return 0;
  }
  if ( ioctl( hSerial, TIOCMSET, &status ) != 0 )
#endif
  {
    printf( "EscapeCommFunction( %i ) failed: ", func );
    jp12PrintLastError();
    return 0;
  }
  return 1;
}

From what I can surmise, this is an error handler in case an RS-232 line gets stuck.

[gfb107]

It is not an error handler. It is the bit of code that allows us to set DTR, RTS, and BREAK to put the remote into communication mode.

Unforunately it is modelled on the Windows EscapeCommFunction function, just because that was the first version of the JP12Serial interface code we wrote, and it was ported to Linux by someone not very familiar with Linux.

There may well be a better API to use for this.

What exactly is the ioctl related error you are getting?

[mathdon]

You definitely need to use com_hifiremote_jp1_io_JP12Serial.h. ... I think we should take out the #define and #ifdef that makes it seem optional.

I don't agree with removing the #define and #ifdef, as they enable someone without the Java SDK to work on it and to test it in the Windows environment. Last year, WagonMaster did exactly that. He made good improvements but did not have, and did not want to install, the Java SDK. It seems helpful to me to keep this flexibility.

[gfb107]

Well, it will inevitably lead to a build getting out that will not work with RMIR, and we will have to deal with supporting the unwitting user who downloads the new and improved driver only to discover it doesn't work at all. This has already happened once.

And even people who are trying to port to a new platform specifically for RMIR might unwittingly turn off the Java, and make the job that much harder just because they didn't know any better.

I understand not wanting to install unnecessary files, but the Java SDK is not that big, it's free, and it can easily and completely be uninstalled once work is finished.

At the very least add comments warning about the side effects of building without the JDK, and to be careful not to release binaries for general consumption that do not include Java support. I would take out the #define and #idef, and provide instructions to those who really want to build without the Java SDK on how to do add them back in.

We the RMIR developers don't have access to all the platforms the drivers will be ported to, so we can't test to make sure the drivers have been correctly built when we make a new release.

[alex750]

What exactly is the ioctl related error you are getting?

This one:

Code: Select all

jp12serial.cpp: In function ‘int jp12EscapeComm(int)’: 
jp12serial.cpp:384: error: ‘ioctl’ was not declared in this scope 

That's why I posted the jp12EscapeComm function above. (Sorry about the duplicate post--browser trouble.) From Greg's description, this bit of code is critical. It seems I've run across this 'ioctl' somewhere in years past, but I can't recall where, or in what library.

Is this a standard Unix/C++ system call? If not, I'll probably need to go digging through OS X's IOKit, written in Objective--very much machine specific.

[Kevin Timmerman]

Try:

#include <sys/ioctl.h>


The usual Posix serial port handshake ioctls work on OS-X if the driver for the USB to serial chip works properly. I think FTDI works, but Prolific chips may require a third party driver.

[mathdon]

Earlier, I wrote:

I don't agree with removing the #define and #ifdef, as they enable someone without the Java SDK to work on it and to test it in the Windows environment.

in reply to which

At the very least add comments warning about the side effects of building without the JDK, and to be careful not to release binaries for general consumption that do not include Java support. I would take out the #define and #ifdef, and provide instructions to those who really want to build without the Java SDK on how to do add them back in.

The jp12serial.dll source code currently says:

Code: Select all

// 
// Define this whenever the Java SDK/JDK is available.  By undefining it (or
// simply commenting it out), it is possible to build this library without the
// Java header files.
// 

#define JAVA_SDK_AVAILABLE

Could we not just expand that comment to read:

Code: Select all

// 
// Define this whenever the Java SDK/JDK is available.  By undefining it (or
// simply commenting it out), it is possible to build this library without the
// Java header files, but if you do so it will NOT work with RMIR and the
// compiled binary SHOULD NOT BE ISSUED FOR GENERAL USE.
// 

#define JAVA_SDK_AVAILABLE

I suggest this because there are many places where there are #ifdef statements testing for this #define and it would be tedious to reinsert them. WagonMaster, last year, adhered to the above rule. He did his development without the Java SDK but only posted the source code, not the binary. I don't feel very strongly about this, though, so if you, Greg, still want them taken out, I'll go along with it.

[gfb107]

Graham, that is fine.

alex750, any luck with Kevin's suggestion?

[alex750]

alex750, any luck with Kevin's suggestion?

Yep. It's all good. I made some additional changes to the makefile, #ifdef'd out some other stuff that cropped up, et voilá--libjp12serial.jnilib.

My testing, however, is limited to the fact that RMIR recognizes its presence: the "download" button is now active, and "JP1.2 Serial" shows up in Remote->Interface. I don't yet have Tommy's cable.

Both binaries (for all architectures) are available here. In the zip file, I have placed a README that warns this is untested, alpha software, and the user should save his/her remote's contents "in IR.exe or RMIR on your other platform" before proceeding.

The modified source for jp12serial is here. Check out the const char *portNames[] listing under #ifdef __APPLE__--there are 128 possible /dev/tty entries!

[mathdon]

Wow, that all sounds wonderful! It's really good to bring another platform into the fold. Congratulations!

I presume you are getting a cable from Tommy so that you can make use of your excellent work. Please keep us informed when you have it and have tested it all "for real".