[Rxtx] smoking is bad for your health
Dr. Douglas Lyon
lyon at docjava.com
Tue Aug 15 06:06:27 MDT 2006
If you are connecting to the parallel port and smoking
chips, it is time for extra stuff to buffer the parallel port.
You may be want more current, in which case
driver transistors are needed, or, if you are using
the port as an output only device, you may like to
add your own bus transceiver (e.g., 74245), set for output.
Do be careful to design this properly;
Some people like to use Octal D-type F.F's with OC outputs,
like a 74374,
I like this one, as it has the D FF's and can latch the outputs
for presentation to slower electronics (like relays). But careful!
A relay that needs more current than the family of the device you
have selected will look like a short to ground, and you
will smoke your bug!
And MOBO's do NOT come with the ability to drive
any load you like. Check the power specs on your relay and
be sure to protect the chip against back EMF with a diode.
It is best to smoke test this on a bread board BEFORE hooking
it to the computer. And be sure you smoke test the corner points
in the ckt for a while, lest it fail in the field.
>Ah, I see. I've seen the caveats about limited
>Parallel support, but I thought it was mainly
>about the javax.comm package. The
><http://gnu.io>gnu.io is derived from javax.comm
>package right? That is, is the parallel support
>in rxtx is a superset of what's in javax.comm?
>I'm using this not for hobby usage, but for some
>simple instrumenation and control. If the
>project mandates it, I'll gladly work on
>extending the support. In the meantime, I need
>to get some sanity checks working, and repair my
>relay board (I smoked the ULN2803 chip,
>apparently by tying the BUSY (pin 11) to vcc). I
>guess I'll try the SEL pin next (and a supply of
>2803s) with a ~1K pullup.
>The caveat in the comment block isn't very
>encouraging (!), but I borrowed an old Epson
>Stylus Color 600 printer to see what I can do.
> If I can write out characters to it I'll be
>happy. Parallel printers aren't easy to find
> I haven't yet looked at the native source, yet,
>but I've just imported it into eclipse and I'll
>surf around a bit.
>On 8/14/06, Trent Jarvi <<mailto:tjarvi at qbang.org>tjarvi at qbang.org> wrote:
>On Mon, 14 Aug 2006, Ed wrote:
>> When I try to get the mode with int mode = pPort.getMode(); it returns 0
>> which isn't any of the valid modes. I tried setting it explicitely with
>> pPort.setMode(ParallelPort.LPT_MODE_XXX );and all failed with
>> gnu.io.UnsupportedCommOperationException: setLPRMode was unable to proced
>> the requested mode in nativeSetSerialPortParams
>> at gnu.io.LPRPort.setLPRMode(Native Method)
>> at gnu.io.LPRPort.setMode(LPRPort.java:87)
>> Except for LPT_MODE_ANY, but the getMode call still failed out with an
>> invalid state.
>This is because rxtx only supports the basics.
>JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env,
> jclass jclazz, jint mode)
> case LPT_MODE_ANY:
> case LPT_MODE_SPP:
> case LPT_MODE_PS2:
> case LPT_MODE_EPP:
> case LPT_MODE_ECP:
> case LPT_MODE_NIBBLE:
> throw_java_exception( env, UNSUPPORTED_COMM_OPERATION,
> "setLPRMode was
>unable to proced the requested \
>One could program in more support. When I did that I just had a daisy
>wheel printer to test with and doing any more would have been blind.
>So that behavior is expected. I'll look to see if the Parallel Complete
>book mentions which pins you need to raise. If you look in the source
>code [ParallelImp.c] you can see this code isn't well tested. It has
>worked for hobby use in the past as I'd guess you are trying to do. But
>my experience with the code is as is mentioned in the top of the source:
> fear he who enter here. It appears that things have changed. An attempt
> has been made to put things the way the should be.
> It compiles and ParallelBlackBox runs. No further guarantees.
> Well... One.. it will print "Hello World!" on an epson DX 10 printer.
> you know.. the 10 character per second daisy wheel printer ;)
> - Trent Jarvi
>That comment is from 1997 or so.
>Since then some windows support was contributed but it is still very green
>code. We get about four requests for parallel support a year so its just
>not a well traveled area.
>It would be nice to have some documentation for the people trying to hook
>parallel ports to electronic projects. That appears to be the exclusive
>use of the Parallel support. The wiki pages are intended to let people
>share information like this to help each other in their projects as they
>figure out the details.
><mailto:tjarvi at qbang.org>tjarvi at qbang.org
>Rxtx mailing list
>Rxtx at qbang.org
More information about the Rxtx