Odd Side effects of using gnu.io.SerialPort.setSerialPortParams (from RxTx v2.1.7)
I have a VFD display (Matrix Orbital VK204-24-USB) which uses a USB connector but employs serial communication. I have FTDI USB serial driver working and associated with /dev/ttyUSB0 (came with the distro, v2.6.12-10-386), I checked dmesg all was OK). javax.comm.properties has the correct driver=gnu.io.RXTXCommDriver line in it.
I downloaded RxTx v2.1.7 (from SourceForge).
I tested the port with kermit & it works fine (both simple strings and control sequnces (ie >= ASCII 128)). I then modified the sample simpleWrite class to send both strings and control sequences to the USB serial port. Former WORKS latter doesn't :-(
I checked the settings with stty & found this:
(after initial sane)
speed 19200 baud; line = 0;
(after running my app.)
speed 19200 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
Now, my question (*FINALLY*) is what is setting those values & is that what's stopping the 8bit stuff being passed to the port properly (as kermit does perfectly well)???? How do I send the char 0xFE (+ some other bytes) to control my display properly??
Summary of Libraries/Methods used in my Java code:
import java.io.*;
import java.util.*;
import gnu.io.*;
<snip>
portList = CommPortIdentifier.getPortIdentifiers();
serialPort = (SerialPort) portId.open(self, 2000);
outputStream = serialPort.getOutputStream();
serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE);
serialPort.setSerialPortParams(19200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_N ONE);
serialPort.notifyOnOutputEmpty(true);
outputStream.write(message.getBytes()); (with 2000ms sleep)
serialPort.close();
Other details:
O/S: Ubuntu v5.1.0 (Breezy Badger)
Port Setting needed: 8N1 + no flow control
I would *LOVE* to get this great little display working in Linux as I don't want yet another XP box!
SG
|
