Re: Help with Java serial comms
Hunter Gratzner wrote:
On Sep 4, 1:26 pm, "brassed...@gmail.com" <brassed...@gmail.com>
wrote:
I'm using the rxtx libraries (RXTX-2.1.7) on Linux to communicate with
a serial printer that uses DSR/DTR flow control. Out of the box, the
rxtx libs either support XON/XOFF, RTS/CTS or no flow control.
You are not giving us much to work with, so I'll just respond with a
number of random thoughts.
Sorry. I realised that when I re-read the posting.
Check your Linux device drivers. The drivers in older Linux versions
couldn' even do DTR/DSR. If that's the case rewire the serial cable.
You can patch that in seconds with the breakout box for testing it.
Connect DSR/DTR from the printer to RTS/CTS on the PC and do RTS/CTS
flow control instead.
Thanks for that one... I didn't know the bit about the Linux drivers. I
am pretty certain I'm getting the signals, but I'll see if I can get a
breakout box. I'm sure once upon a time I used to have one when we used
to play about with serial terminals and the like. A serial port listener
does however show the state changing (ev.getEventType() == 4 from memory).
Your code doesn't show if you set DTR prior to sending data to the
printer.
Perhaps I need to go back and re-read the manual on serial comms!
while (!commPort.isDSR()) {
Never do that kind of polling. Implement a SerialPortEventListener,
ask for notification of DSR changes (in case you don't switch to RTS/
CTS, where the library should do all the flow control on its own), and
push out the next set of data once you get a notification. Once DSR is
set loop and write until it becomes cleared again.
byte[] data = new ...
int pos = ... // Index of next byte to write
int end = ... // Index after last byte to write
class TheSerialPortEventListener implements SerialPortEventListener {
void serialEvent(SerialPortEvent ev) {
switch(ev.getEventType()) {
case SerialPortEvent.DSR:
if(ev.getNewValue()) {
SerialPort port = (SerialPort)ev.getSource();
while(port.isDSR() && pos < end) {
port.write(data[pos++]);
}
}
break;
case: // handle other serial events in this
// event handler, too.
break;
}
}
}
Yes, I see where you're coming from. I'd thought of that but stalled
because I couldn't see how to make sure DSR was in the right state when
I started, especially if only printing during the listener event. The
other idea I'd had was a semaphore of some description that was managed
in the listener which I /think/ would have achieved the same end. My
worry was that if I started with DSR ok, I'd never get a state change
and therefore never see the indication to start printing. I may be
missing a trick?
Your idea would work quite nicely though because I'm sending to the
printer in raster mode, 48 bytes to a line. It's long-winded because the
printer doesn't have a rotated font and I want to effect landscape
printing on a credit-card sized form. (I've had to define my own font
and send the raster lines one at a time to recreate the characters;
there has to be an easier way to earn a crust :-)
A soldering iron and a patched up cable seems to be the best option.
Check the flow-control configuration of the printer. In particular
check if the printer's "high water mark" configuration is set to
something like 80% or 90%, so that the printer will drop DSR when its
buffer is filled up to 80% (or 90%), and not when its 100% filled.
There's not a right lot to go on in the manual sadly.
Thanks for your help... some interesting ideas.
--
David (from his other address)
blog: http://www.brassedoff.net/wp