Javaシリアル通信【資料】


/*-------------------------------------------------------------------------
|   rxtx is a native interface to serial ports in Java.
|   Copyright 1997-2002 by Trent Jarvi [email protected]
|
|   This library is free software; you can redistribute it and/or
|   modify it under the terms of the GNU Lesser General Public
|   License as published by the Free Software Foundation; either
|   version 2.1 of the License, or (at your option) any later version.
|
|   This library is distributed in the hope that it will be useful,
|   but WITHOUT ANY WARRANTY; without even the implied warranty of
|   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
|   Lesser General Public License for more details.
|
|   The following has been added to allow RXTX to be distributed with Sun
|   Microsystem's CommAPI library as suggested by the FSF.
|
|   http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface
|
|   A program that contains no derivative of any portion of RXTX, but
|   is designed to work with RXTX by being compiled or linked with it,
|   is considered a "work that uses the Library" subject to the terms and
|   conditions of the GNU Lesser General Public License.
|
|   As a special exception, the copyright holders of RXTX give you
|   permission to link RXTX with independent modules that communicate with
|   RXTX solely through the Sun Microsytems CommAPI interface, regardless of
|   the license terms of these independent modules, and to copy and distribute
|   the resulting combined work under terms of your choice, provided that
|   every copy of the combined work is accompanied by a complete copy of
|   the source code of RXTX (the version of RXTX used to produce the
|   combined work), being distributed under the terms of the GNU Lesser General
|   Public License plus this exception.  An independent module is a
|   module which is not derived from or based on RXTX.
|
|   Note that people who make modified versions of RXTX are not obligated
|   to grant this special exception for their modified versions; it is
|   their choice whether to do so.  The GNU Lesser General Public License
|   gives permission to release a modified version without this exception; this
|   exception also makes it possible to release a modified version which
|   carries forward this exception.
|
|   You should have received a copy of the GNU Lesser General Public
|   License along with this library; if not, write to the Free
|   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
--------------------------------------------------------------------------*/

--------------------------------------------------------------------------*/
This is the INSTALL file for RXTX.  Tue Aug 13 20:42:11 MDT 2002

If, while following the instructions, you find this file unclear or incorrect 
please make a note and email the details to [email protected].

A note on Mac OS X:

	Go to the MacOSX file for install instructions. 

1.  INSTALL INSTRUCTIONS IN OTHER LANGUAGES

	A. Japanese 

2.  BUILDING COMMAPI SUPPORT

	A.  Quick Install
	B.  Installing Sun's comm.jar
	C.  installing javax.comm.properties.
	D.  Add comm.jar to your CLASSPATH.
	E.  Build and Install the jar.
	F.  Add jcl.jar to your CLASSPATH
	G.  Where did everything end up?
	H.  Cross Compiling for Win32 support

3.  COMMON PROBLEMS

	A.  java.lang.UnsatisfiedLinkError: nSetOwner while loading driver
	    gnu.io.RXTXCommDriver
	B.  Exception in thread "main" java.lang.UnsatisfiedLinkError: 
	    no rxtxSerial in java.library.path
	C.  No serial ports found!
	D.  I Can Not Open the Port.
	E.  java.lang.NoClassDefFoundError: javax/comm/CommPort
	F.  The Compiler Cannot Find Java Include Files
	G.  Configure says 'unterminated sed command' and stops 
	H.  Java Can Not Find libstdc++-libc6.0-1.so.2 
	I.  BlackBox Can Not Handle all the ports!
	J.  Illegal use of nonvirtal function call!
	K.  My libc5 Linux system is generating SIGSEGV
	L.  AM_PROG_LIBTOOL not found in library
	M.  Problems with RMISecurityManager()
	O.  Which Wires Should be Connected?
	P.  Which Device Should be Used?
	Q.  It Did Not Work! 
	R.  Which jdk should be used? 
	S.  How does rxtx detect ports?  Can I override it?
	T.  How can I use Lock Files with rxtx?
	U.  How can I tell which version of rxtx is installed?
	V.  What Type of Latency can I expect with RXTX
	W.  I got rxtx working on a new OS but I can't read from the port
	X.  My ThinkPad is Not Working!

-------------------------------------------------------------------------------
1.  INSTALL INSTRUCTIONS IN OTHER LANGUAGES
A.  Japanese

	Instructions are available in Japanese at

	The instructions are fairly old but should help.

	http://www.geocities.co.jp/Technopolis/4789/settei.htm#id1
	Thanks to Masayuki "Tencho" Yamashita <[email protected]>
	home page http://www.geocities.co.jp/Technopolis/4789/ 

	A copy of these install instructions is provided in 
	install-japanese.html
	
	We will gladly include instructions in any language provided.  Tencho 
	was the first to contribute instructions in another language.

2.  BUILDING COMMAPI SUPPORT

	The following is concerned with building and installing commapi 
	support with Sun's CommAPI package.  A full stand alone version of 
	rxtx is in the CVS archive for interested developers.

	A.  Quick Install

	The following packages are used to build rxtx:

		autoconf-2.53
		automake-1.6.3
		libtool-1.4.2
		gnu make-3.79.1         On some systems like FreeBSD this is
					called gmake
		jdk 1.1 or newer	Preferably the native threads version of
		                        jdk. 
		commapi 2.0             the x86 Solaris version

	With the packages installed, proceed to build and install rxtx.

		$ tar -xzvf rxtx-2.0-1.tar.gz
		$ cd rxtx-2.0-1
		$ ./configure  (follow the instructions)
		$ make install (gmake if your system uses that convention)
		Read "T.  How can I use Lock Files with rxtx?"

	One catch that has showed up... you cannot have spaces in the path.
	for instance:  /home/jarvi/test build/rxtx/... will cause problems.
                                   ----^
	If that does not work or you do not want a script messing with the 
	system, read on..

	B.  Installing Sun's comm.jar

		http://java.sun.com/products/javacomm/index.html
		
		Obtain javacomm20-x86.tar.Z from Sun.

		This is the x86 Solaris version of commapi.
		Do not try to use the win32 version.  It will not work.

		extract the files from the archive

		$ tar -xzvf javacomm20-x86.tar.Z

		Place comm.jar in the proper directory.  Everyone likes to 
		put Java in different locations.  I'll use /usr/local/java
		throughout this document.

		jdk-1.1:

			/usr/local/java/lib/comm.jar

		jdk-1.2 and newer:

			/usr/local/java/jre/lib/ext/comm.jar

		IBM's comm.jar remaps 'COM1' to '/dev/ttyS0.'  It is not
		recommended to try mixing IBM's comm.jar and rxtx-2.0-1 at
		this time.  If you do try it, Watch out for the above.

	C.  Installing javax.comm.properties.

		javax.comm.properties needs the following text in it:

		Driver=gnu.io.RXTXCommDriver

		Some people have said it requires a blank line after the text.

		The file goes in different locations depending upon your jdk
		version

		jdk-1.1:

			/usr/local/java/lib

		jdk-1.2 and newer:

			/usr/local/java/jre/lib
	
		SEE: commapi/PlatformSpecific.html from Sun's commapi package 
		for details.

	D.  Add comm.jar to your CLASSPATH.

		jdk-1.1:

			make sure /usr/local/java/lib/comm.jar is in your
			CLASSPATH.  If you want to use apps that require
			comm.jar.

			in bash:

			$ export CLASSPATH=/usr/local/java/lib/comm.jar:.

		jdk-1.2 and newer:

			No changes are needed.

	E.  Build and Install the jar.

		configure       configure supports build directories.
				configure requires javac in its path or
				JAVA_HOME set to grab some java system
				properties.
		make 	 	to build jcl.jar and the libraries
		make install 	to place the jar and libraries in the correct 
				location

		You may select the JDK you wish to build with using $JAVA_HOME
		For example:
			export JAVA_HOME=/usr/local/java
		Otherwise, configure grabs the JDK from your PATH.

	F.  Add jcl.jar to your CLASSPATH
		
		jdk-1.1:

			make sure /usr/local/java/lib/jcl.jar is in your
			CLASSPATH. 

			in bash:

			$ export CLASSPATH=/usr/local/java/lib/comm.jar: /
				/usr/local/java/jcl.jar:.


		jdk-1.2 and newer:

			No changes are needed.
		
		This completes the process.  You will need to read the Section
		on Lock Files to make sure the user can create a Lock File.
		"T.  How can I use Lock Files with rxtx?"

	G.  Where did everything end up?

		Lets assume the top java directory is /usr/local/java

		jdk-1.2 the files go in
		
			/usr/local/java/jre/lib/ext/jcl.jar
			/usr/local/java/jre/lib/ext/comm.jar
			/usr/local/java/jre/lib/$(ARCH)/librxtxSerial.so.
			/usr/local/java/jre/lib/$(ARCH)/librxtxParallel.so.
			/usr/local/java/jre/lib/javax.comm.properties

		jdk-1.1.* the files go in 

			/usr/local/java/lib/jcl.jar
			/usr/local/java/lib/comm.jar
			/usr/lib/librxtxSerial.so.
			/usr/lib/librxtxParallel.so.
			/usr/local/java/lib/javax.comm.properties

			The librxtxSerial.so librxtxParallel.so are placed in 
			/usr/lib so people don't have to change with their 
			LD_LIBRARY_PATH.

	H.  Cross Compiling for Win32 support


		Get the Sun CommAPI if you want a plug-in solution.  The code 
		is provided for people that may have demanding needs and coding
		ability. 

		There is only serial port code at this time.

		Three ways of compiling win32 libraries are offered:

			mingw32 tools in DOS
			lcc tools in DOS
			cross-compiling from Linux

		----------------- mingw32 tools in DOS -----------------------

		Install mingw32  http://www.mingw.org
		Install a jdk    http://java.sun.com/j2se
		Make sure the ming32/bin and jdk/bin directories are in your
		path.
		In the rxtx top directory to the following:
		mkdir build
		copy Makefile.mingw32 build/Makefile
		cd build
		edit the Makefile and make sure the directories are correct.
		execute the following:
			make
			make install
		
		----------------- lcc tools in DOS ---------------------------

		Install a jdk    http://java.sun.com/j2se
		Install lcc http://www.cs.virginia.edu/~lcc-win32/

		A make file (Makefile.lcc) for compiling rxtx with lcc
		contributed by Valentin Pavlov

		You will need a config.h file in the src directory.  Other
		builds usually generate them automatically.  The following
		should work.

		#define HAVE_FCNTL_H
		#define HAVE_SIGNAL_H
		#undef HAVE_SYS_FCNTL_H
		#undef HAVE_SYS_FILE_H
		#undef HAVE_SYS_SIGNAL_H
		#undef HAVE_TERMIOS_H
		#undef HAVE_SYS_TIME_H

		if you know how to create the above in a dos Makefile send in			the changes.

		the following commands should then work fine on the command
		line.

		cd src
		make -f ../Makefile.lcc

		----------------- cross-compiling from Linux -----------------

		Grab ming32:

		Wayne Roberts contributed the version used by the maintainer.
		(Wayne is largely responsible for bringing rxtx back to win32.)
		http://www.linuxgrrls.org/~taj/crossmingw32-2.95-1.i386.rpm
		A more current version can be obtained:
		http://www.devolution.com/~slouken/SDL/Xmingw32/crossgcc/index.html
		prebuilt Binaries:
		http://www.devolution.com/~slouken/SDL/Xmingw32/mingw32-linux-x86-glibc-2.1.tar.gz

		I built the dll with jdk-1.2.2 for linux using jdk-1.2.2 
		include files from the win32 JDK.

		Make sure that ming32 bin dir is the first in your path (at 
		least before /usr/bin/gcc)

			$ export PATH=" /
				/usr/local/cross-tools/i386-mingw32/bin/: /
				$PATH:/usr/X11R6/bin:/usr/local/java/bin: /
				/usr/local/java/jre/bin/:"

		Place Sun jdk 1.2.2 win32 include files in a known location.

			$ mkdir /home/jarvi/win32java
			$ cp -r /mnt/win98//java/include /home/jarvi/win32java

			If you are developing win32 support you may want to
			export the location to make the config script
			non interactive

			$ export WIN32INCLUDE=/home/jarvi/tools/win32-include

		run configure to generate a Makefile

			$ cd /home/jarvi/rxtx-*
			$ mkdir build
			$ cd build
			$ ../configure --target=i386-mingw32  /
				--host=i386-redhat-linux

		build the class files and dll.

			$ make

		the files will be located in

			rxtx-*/build/...

		If you're looking at rxtx as an example of cross-compiling you 
		may be interested in looking at the examples provided at:

			ftp.xraylith.wisc.edu
			/pub/khan/gnu-win32/mingw32/misc/java-jni-examples.zip

3.  COMMON PROBLEMS

A.  I get java.lang.UnsatisfiedLinkError: nSetOwner while loading driver
    gnu.io.RXTXCommDriver when using rxtx.

	SetOwner appears to be some win32 call.
	Do not use Sun's win32 CommAPI files.  Get the Solaris version.
	"javacomm20-x86.tar.Z" 

	See Also: 2-B.  Installing Sun's comm.jar

B.  Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in 
    java.library.path

	librxtxSerial.so is located in the wrong directory.  Here is an example

	$ mv /usr/local/java/jre/lib/i386/librxtxSerial* /usr/local/lib
	$ java BlackBox
	Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in
	java.library.path
		at java.lang.ClassLoader.loadLibrary(Compiled Code)
		at java.lang.Runtime.loadLibrary0(Compiled Code)
		at java.lang.System.loadLibrary(Compiled Code)
		at gnu.io.NativePort.<clinit>(NativePort.java:32)
		at gnu.io.RXTXPort.<init>(Compiled Code)
		at gnu.io.RXTXCommDriver.getCommPort(Compiled Code)
		at javax.comm.CommPortIdentifier.open(Compiled Code)
		at SerialPortDisplay.openBBPort(Compiled Code)
		at SerialPortDisplay.<init>(Compiled Code)
		at BlackBox.addPort(Compiled Code)
		at BlackBox.main(Compiled Code)

		... lets fix it.

	$ mv /usr/local/lib/librxtxSerial.* /usr/local/java/jre/lib/i386/

C.  No serial ports found!

	There are three ways this can be generated.  

		1.  deleting or misplacing javax.comm.properties
		2.  a typo in javax.comm.properties
		3.  forgetting to put jcl.jar in CLASSPATH

	see also D.  I Can Not Open the Port.

	now for an example of each.

	1. deleting or misplacing javax.comm.properties

	assume the following is working:

	/usr/local/java/jre/lib/ext/comm.jar
	/usr/local/java/jre/lib/ext/jcl.jar
	/usr/local/java/jre/lib/ext/BlackBox.jar
	/usr/local/java/jre/lib/javax.comm.properties

	Deleting javax.comm.properties or placing it in 
	/usr/local/java/lib/javax.comm.properties results in

	$ java BlackBox
	No serial ports found!

	2.  a typo in javax.comm.properties

	lets break the properties files
	$ vi /usr/local/java/lib/javax.comm.properties
	>place intentional typo in the file<
	$ java BlackBox
	Caught java.lang.ClassNotFoundException: gnu.io.rXTXCommDriver 
	while loading driver gnu.io.rXTXCommDriver
	No serial ports found!
	      note------------------^

	$ vi /usr/local/java/lib/javax.comm.properties
	>fix typo<

	--
	For some, it is not clear what was being done here.  There is a single
	line in the file javax.comm.properties that contains
	"gnu.io.RXTXCommDriver" when properly installed.  We replaced the R with
	r in "gnu.io.RXTXCommDriver" to force an error.  After seeing the error
	we replaced the r with an R to fix it.

	3.  forgetting to put jcl.jar in CLASSPATH

	export CLASSPATH=./java/lib/comm.jar:.:./java/lib/classes.zip
	$ java BlackBox
	Caught java.lang.ClassNotFoundException: gnu.io.RXTXCommDriver 
	while loading driver gnu.io.RXTXCommDriver
	No serial ports found!
 
D.  I Can Not Open the Port.

	If you're not able to open the port (read the errors carefully) then you
	may not have permission to use the device.  Redhat Linux ships with the
	following permissions:

	crw-r--r--   /dev/ttyS?

	Users need to be able to read and write with serial communication...

	chmod 666 /dev/ttyS? 

	should fix the problem.  Be sure to check the file CommAPI for common 
	mistakes.

	see also: C.  No serial ports found!

E.  java.lang.NoClassDefFoundError: javax/comm/CommPort

	comm.jar is probably not in your classpath or not located in
	the proper directory.

	for example, lets not include comm.jar

	export CLASSPATH=..java/lib/jcl.jar:.:../java/lib/classes.zip
	$ java BlackBoxException in thread "main"
	java.lang.NoClassDefFoundError: javax/comm/CommPort

F.  The Compiler Cannot Find Java Include Files

	Check to top of the Makefile to make sure we agree on the location of
	the include files that came with the jdk.  Specifically:

	JAVAINCLUDE =  -I /usr/local/java/include/
	JAVANATINC =  -I /usr/local/java/include/genunix
	also check the classpath
	CLASSPATH = ...

G. Configure says 'unterminated sed command' and stops 

	Unterminated sed command errors usually result from `find` producing 
	unexpected results.   If you are unsure remove all comm.jar and 
	javax.comm.properties files and use configure to place them in the 
	correct place. 

H.  Java Can Not Find libstdc++-libc6.0-1.so.2 

	jdk-1.2 on redhat systems may note that Java complains about not being
	able to find libstdc++-libc6.0-1.so.2.  A symbolic link can be used to 
	get around this feature.

	ln -s /usr/lib/libstdc++ /usr/lib/libstdc++-libc6.0-1.so.2
	ls -l /usr/lib/libstdc++-libc6.0-1.so.2
 	/usr/lib/libstdc++-libc6.0-1.so.2 -> libstdc++.so.2.8.0

I.  BlackBox Can Not Handle all the ports!

	BlackBox has a hard coded limit in BlackBox.java that prevents it from 
	running if you don't specify a port.  We are considering alternative 
	ways of handling the large number of port names in Unix.  The line in 
	question

	is:

		portDisp = new SerialPortDisplay[50];
		
	just change 50 to say 256.

J.  Illegal use of nonvirtal function call!

	Exception in thread "main" java.lang.VerifyError: (class: 
	gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) 
	Illegal use of nonvirtual function call
		at gnu.io.RXTXCommDriver.getCommPort(Compiled Code)
		at javax.comm.CommPortIdentifier.open(Compiled Code)
		at SerialPortDisplay.openBBPort(Compiled Code)
		at SerialPortDisplay.<init>(Compiled Code)
		at BlackBox.addPort(Compiled Code)
		at BlackBox.main(Compiled Code)

	"1.1 compilers sometimes generate code that won't verify under 1.2.

	If you don't have the sources for the offending class to recompile with
	a 1.2 javac, the only solution I know of is to launch the VM with the
	-noverify option.

	Louis"

	In other words start with a fresh build directory, rebuild, and 
	reinstall to avoid the problem.

K.  My libc5 Linux system is generating SIGSEGV

	Older Linux Systems (libc5) should upgrade to a glibc system with 
	libpthread-0.7 or newer.  We have run into many problems with older 
	libraries.  SIGSEGV was the most common symptom.  Reported by  Peter 
	Bennett <[email protected]>

L.  AM_PROG_LIBTOOL not found in library

	cd. && aclocal
	aclocal:configure.in: 23: macro 'AM_PROG_LIBTOOL' not found in library
	make:***[aclocal.m4]Error 1

	If you're positive things are setup right you may try the autogen.sh 
	script to try regenerating the scripts with your tools.

M.  Problems with RMISecurityManager()

	Please see the file RMISecurityManager.html 

O.  Which Wires Should be Connected?

	With the DB25 use 2 (TX), 3 (RX) and 7 (GD) to connect to the device.
	With the DB9  use 2 (RX), 3 (TX) and 5 (GD) to connect to the device.

	You will need to hook up more than that for hardware flow control.

P.  Which Device Should be Used?

	Linux serial ports should use /dev/ttyS?
	specialx, cyclades and isdn4 linux have been reported to work.
	as many as 64 ports have worked at one time.
        FreeBSD uses cuaa?
	netbsd uses tty0?
	Irix  uses ttyd? ttym? ttyf?
	HP-UX uses tty0p? tty1p?
	BeOS uses /dev/ports/serial?
	Win32 uses COM?
  
Q.  It Did Not Work! 

	There are sure to be bugs.  The goal is to make the install as painless
	as possible.  Send back comments if something could be easier.

	If you run into a problem building the rxtx package please include the
	output generated by the following script.

        ---------------clip-----------------
#!/bin/sh
which java
java -version
uname -a
autoconf --version
automake --version
libtool --version
make --version
        ---------------clip-----------------

	Here's what's on my system for comparison.  Older make is known to cause
	problems.

		java 1.4
		autoconf-2.53
		automake-1.6.3
		libtool-1.4.2
		gnu make-3.79.1         On some systems like FreeBSD this is


	mail any bugs to [email protected].


R.  Which jdk should be used? 

	Ideally any jdk would be fine.  Here is a list of jdk's tried on
	RedHat 6.0/kernel 2.2.17pre13 with various versions of glibc.

                 Sun            IBM           Blackdown
                 2.1.2_006      1.3.0         1.1.8v1
                 green  native  green native  green native
                 ------------------------------------------
glibc-2.1.1-6   | OK   | *1   | *2   | *2   | OK   | *3   |
                -------------------------------------------
glibc-2.1.2-11  | OK   | *1   | OK   | OK   | OK   | OK   |
                -------------------------------------------
glibc-2.1.2-17  | OK   | *1   | OK   | OK   | OK   | OK   |
                -------------------------------------------
glibc-2.1.3-15  | OK   | *1   | OK   | OK   | OK   | OK   |
                -------------------------------------------

1)  BlackBox (a demo application shipped with CommAPI locks after multiple 
    open()/close()

2) java wont start "Unable to load /usr/local/java/jre/bin/libhpi.so: symbol
sem_wait, version GLIBC_2.1 not defined in file libpthread.so.0 with link time
reference Could not create the Java virtual machine."

3) java wont start "error in loading shared libraries:
/usr/local/java/bin/../lib/i686/native_threads/libjava.so: symbol sem_init,
version GLIBC_2.1 not defined in file libpthread.so.0 with link time reference"

Conclusion?  Avoid Sun's native threads unless you can figure out whats going
wrong.

S.  How does rxtx detect ports?  Can I override it?

rxtx tries to detect ports on by scanning /dev for files matching any
of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on.
Any ones that exist, are supposed to be good for the current operating
system, and that can be read and written are offered back from
CommPortIdentifier.getPortIdentifiers(), and only these can be used as
ports.

If you wish, you can set the system properties gnu.io.rxtx.SerialPorts
and gnu.io.rxtx.ParallelPorts.  If either of these is set, then no
scanning will be carried out and only the specified ports will be
available.  You can use this to make one platform look like another,
to restrict Java access to ports, or possibly for other reasons.  For
example

	java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp

will look kind of like Solaris, if you have created the appropriate
device nodes.

A note on Linux port enumeration.  We have set most ports aside.  Once the
number of possible devices started getting into the thousands, checking them
all made little sense.  Look in RXTXCommDriver.java and search for Linux.

You will see that only /dev/ttyS* is searched but the possible addition ports
that can be used are listed under it.  Just copy the few you need.

T.  How can I use Lock Files with rxtx?

Redhat users.  Note that Redhat changed group uucp to group lock with Redhat
7.2.

Mandrake users.  Note that /var/lock needs to be group uucp for this to work.
 
Mac OS X users.  Note that you may need to create the lock directory with group uucp ownership.

RXTX uses lock files by default.  configure --disable-lockfiles to generate
rxtx libraries without lock files.  Its strongly recommended that you do
use lock files to prevent rxtx from stomping on other programs using serial
ports.

Lock files are used to prevent more than one program accessing a port at a
time.  Lock files require a bit of sysadmin to work properly..

Rxtx has support for lock files on Linux only.  It may work on other
platforms but read the source before blindly trying it. 

Before you use lock files you need to do one of two things:

	1.  Be the root or uucp user on your machine whenever you use rxtx
	2.  add the specific user that needs to use rxtx to the group uucp.
	    (preferred)

To add a user to the uucp group edit /etc/group as root and change the 
following:
	uucp::14:uucp
to something like:
	uucp::14:uucp,jarvi
In this case jarvi is the login name for the user that needs to use lock files.
Do not change the number (14).  Whatever is in your group file is correct.

User jarvi in this case can now use rxtx with lock files.

The lock file code does not support kermit style lock files or lock files in
/var/spool.  Its sure to fail if you're using subdirectories in /dev or do not
have /dev.

	Still cant get things to run under a root account?

	Vadim Tkachenko writes:
	
	"Maybe you remember - couple of months back I've run into inability to
	run the JDK 1.3+ from under root account.

	Today, absolutely suddenly, something clicked in my head and the cause
	was found: libsafe. To make JDK work, it is enough to disable libsafe
	(unset LD_PRELOAD)."

As another option it is possible to use a Lock File Server.  In this case,
a server runs in group uucp or lock and rxtx then connects to localhost
to lock and unlock the port.  The server and install instructions can be
found in src/lfd.  RXTX will need to be configured to use the server:

	configure --enable-lockfile_server

Any user can then lock the ports if they are not already locked.

U.  How can I tell which version of rxtx is installed?

Version information is not documented in Sun's CommAPI so this is probably
unique to RXTX.

As of rxtx-1.5-4 and rxtx-1.4-6 a class has been added to allow developers to 
check which version of rxtx is installed.  The class is RXTXVersion.  

The static method: System.out.println(RXTXVersion.getVersion());

will print the rxtx version as a String in the following format:

        "RXTX-MAJOR.MINOR-PATCH".

an example would be:

        "RXTX-1.5-4"

A change in the MAJOR version would suggest you're in trouble.

Odd MINOR version are reserved for development.  Even MINOR versions are
reserved for 'stable' releases.

PATCH is used to differentiate incremental releases of the MINOR releases.

CommPortIdentifier is expected to support getVersion() in the RXTX-1.5 series.

V.  What Type of Latency can I expect with RXTX

	frantz <[email protected]> put RXTX under a scope and found
	the following:

	RXTX currently has a latency of 150-200ms on a PII at 450mhz.
	The latency can be reduced to 70-80ms by reducing the usleep()
	value in SerialImp.c:eventLoop() to usleep(5000)).

	Much lower latencies should be possible but the maintainer does not
	have equipment to test changes.

	He is going to look at this further.  He needs 20 ms or less latency.
	
W.  I got rxtx working on a new OS but I can't read from the port

> Now my java program starts up nicely without complaining. However, it does
> never read any data from the serial port. It looks like it can write data,
> because if I start a terminal program after I tried to run my program, I get
> all the return stuff from the modem that my program wrote.
> 
> I hacked around abit and found out that it hangs in the select() call which
> simply never returns.
> 
On Sun, 28 Jan 2001, Baldur Norddahl wrote:
> HPUX 11:
> 
> As I wrote to the mailinglist I had some wierd problems where it apparently
> could write data to the modem, but not read anything back. My terminal
> programs had no problem using the port. A few days after I reported the
> problem to the mailinglist, I had given up for now, but then I noticed that
> it suddenly worked! So it remains a mystery what was wrong as I did not
> change anything at all, neither in my program nor on the host.
> 
> Baldur
> 

I suspect two java applications had the port open.  Its easy to do while 
developing.  Perhaps <ctl> z instead of <ctl> c was entered.

This is the reason for adding lockfile support to rxtx.  If another application
has opened the port, a second application will appear to not be able to 
read or get only part of the data.  ..because the first one is reading.  Only
one of the select()s are waken.

Its possible to put lockfile support in for HPUX if it is known where other
applications place their lockfiles.   The easiest way to find out where is
to fire up minicom, kermit, ... and see where its lockfile is placed.

Here are the known suspects:

const char *lockdirs[]={ "/etc/locks", "/usr/spool/kermit",
                "/usr/spool/locks", "/usr/spool/uucp", "/usr/spool/uucp/",
                "/usr/spool/uucp/LCK", "/var/lock", "/var/lock/modem",
                "/var/spool/lock", "/var/spool/locks", "/var/spool/uucp",NULL
        };

freebsd uses /var/spool/uucp/, linux uses /var/lock those are the only two
I've done so far.  Adding the support is trivial once a directory is
decided upon.

Lockfiles are rather simple.  when an application opens a port it first checks
if there is a file with the ports name.  If there is it grabs the PID from the
file.  If that PID is still active the application does not open the port.

If the PID is not active or there is no lockfile, the application creates one
with its own PID in it.

The confusion starts when you have to decide where (see above) to put the
lockfile, what the name format is for the file and how to store the PID.

rxtx follows The File System Hierarchy Standard http://www.pathname.com/fhs/
on linux.  I'm not positive what is normal on other OS's.

                more reading:

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

                FSSTND
                ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/

                Proposed Changes to the File System Hierarchy Standard
                ftp://scicom.alphacdc.com/pub/linux/devlock-0.X.tgz

                "UNIX Network Programming", W. Richard Stevens,
                Prentice-Hall, 1990, pages 96-101.
                more reading:

X.  My ThinkPad is Not Working!

	Scott Burleigh <[email protected]> writes:

		For your files, and in case anybody asks in the 
		future, IBM Thinkpads ship with the external serial port
		*disabled* by default.  The Thinkpad configuration utility
		supplied with the machine (under Windows) says it's enabled,
		and the device manager in the System dialog of the Control
		panel says it's enabled, but they lie.  In order to enable the
		port you have to use the old DOS ps2.exe bios configuration 
		utility which, under Windows 2000, is in
		c:/Program Files/Thinkpad/utilities:

			ps2 sera enable

		Until you do, "setserial -ga /dev/ttyS0" will always tell you
		the UART is unknown.  

-- 
Trent Jarvi
[email protected]
-------------------------------------------------------------------------------
You made it this far.. what is one more line.

Sun, Solaris and Java are registered trademarks of Sun Microsystems, Inc.


reminder:

redhat 7.1 needs:
export LD_ASSUME_KERNEL=2.2.5