Java, RxTx and UART on the BeagleBone


This is a follow up to another poorly named discussion I started. My question is basically “Can Java work with the BeagleBone hardware interfacing directly enough to be effective?” With some help of Koen Kooi on another thread I came up with the following steps for getting Java to access a USB connection via RxTx.

Here is what I have done:

  1. Installed newest distro (not sure this made a difference, but needed to be done anyway)
  2. opkg update
  3. opkg install openjdk-6-jre
  4. opkg install rxtx
    4a. I had to copy all files from /usr/lib/jni/librxtx* to /usr/lib/jvm/java-6-openjdk/jre/lib/arm to make the libraries work at all. This was not done by the install rxtx above. Probably a better way todo this with a link if someone would like to comment on that.
  5. Run my program which basically just spits out the com ports. Output reads:

WARNING: RXTX Version mismatch
Jar version = RXTX-2.2pre1
native lib Version = RXTX-2.2pre2
RXTX Warning: Removing stale lock file. /var/lock/LCK…ttyUSB0
/dev/ttyUSB0 - Serial

Note: Changing the version of the jar file doesn’t get rid of the warning regardless. However, that is the USB device that is hooked up. It is spitting out a 9600 baud GPS signal from a UART to RS232 serial converter.

  1. When I run this on windows I come up with:


  1. However, when I change only the port ID to /dev/ttyUSB0 it comes up with the following on the BeagleBone:


It’s obviously getting something and parts of it are right. However, it’s not getting it correctly. I would post all my code up here, but it’s several files. Here are the biggies though:

This code spins up some stuff:

inBuffer = new StringBuffer();
outBuffer = new StringBuffer();

portIdentifier = CommPortIdentifier.getPortIdentifier("/dev/ttyUSB0");

CommPort commPort =“test”, 2000);

SerialPort serialPort = (SerialPort) commPort;

serialPort.setSerialPortParams(baudRate, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);

reader = new SerialReader(serialPort.getInputStream(), inBuffer);
writer = new SerialWriter(serialPort.getOutputStream(), outBuffer);

new Thread(reader).start();
new Thread(writer).start();

Then later this code reads it. This is the thread that gets started:

byte[] buffer = new byte[1024];
int len = -1;
try {
while ((len = > -1) {
if (pause) {

if(stop) {

String str = new String(buffer, 0, len);


} catch (IOException e) {

Bonus to anyone who can help me get a UART connection working too!



I tried to use rxtx with i2c ports and using:

CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("/dev/i2c-3");

gives me:

[01 Jun 2012 16:23:01,967]ERROR 52515[pool-3-thread-1] - TemperatureBean$ -
at com.xx.stirling.webRxTx.TemperatureBean$
at java.util.concurrent.Executors$
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(
at java.util.concurrent.FutureTask.runAndReset(
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(
at java.util.concurrent.ScheduledThreadPoolExecutor$
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$

I also have file in classpath with following content:

Has somebody succeeded comunicating through rxtx to i2c device?

Dne petek, 01. junij 2012 06:57:46 UTC+2 je oseba Gregg Harrington napisala:

I don’t know about the properties file you created, but the list of serial ports is hardcoded in rxtx, it’s not very good. I’ve always had to instantiate the RXTX port directly like new “/dev/someDevice” ). This does mean you’re not going through the standard API, but RXTX is the only real implementation anyway, and once you get past the constructor you can use the standard API.

To be honest, I don’t use RXTX for serial port communication on Linux anymore. The quality is not good at all. I normally just use FileInputStream and FileOutputStream on the serial port, and call out to stty. It sounds like a massive hack until you see it work cleaner, easier, and less overhead (RXTX’s weird threads and polling) than RXTX without the need to worry about RXTX library distribution/license/native code loading. However, that technique only works if you only need to send and receive bytes and not fiddle with the non-data RS232 lines like RTS, CTS, etc. It also works best with a device with a single speed (so you aren’t calling to stty but right before you start), and on “single purpose” machines like beaglebone where you can restrict one process at a time talking to the serial port (because there is no serial port “locking” – although RXTX’s locking only prevents other RXTX from using the port anyway).