Re: Re: Is xPL the ideal work-around? Need to access the LPT port from Mister House...

[Gregg Liming <gregg@xxxxxxxxxxx>]

Quoting Gerry Duprey (10/25/05 2:24 PM):
> Howdy,
>
> Anyone have any thoughts on this?

Personally, I agree with all of your points below.  However, I also
admit to being quite biased toward multi-platform solutions if they can
happen.

> I feel I could knock this out in a fairly
> short period of time, but I don't want to produce something
incompatible
> with an existing app.

There certainly wouldn't be an incompatibility w/ mh.  If anything,
device abstraction as you describe is also performed by mh and is
therefore more consistent.  I can't addresss other app compatibility
issues.

> And yet there isn't anyway via Java I can use a
> device identifier like 888 to mean anything.
>
> The upside of a Java version is that it would run under Windows 98/ME
as
> well as NT/2000/XP.
>

...or osx, or most of the other *nix implementations

> I'd like to hear back from folks, even if it is a "I don't think
this need
> to happen" response -- I can backburner it at that point.

I personally would likely not use an app that performs single reads or
writes to parallel or serial ports as most devices that I tend to care
about implement protocols over those ports (also, other than Jack's
device, I am unaware of other parallel port devices useful to ha).
However, it might be a useful diagnostic utility.


> Thanks,
>
> Gerry
>
>
>>In the hopes of being able to use this cross platform, here are a
couple of
>>thoughts:
>>
>>
>>
>>>Bytes would be written using an xpl-cmnd message like:
>>>
>>>Control.basic
>>>{
>>>Device=888 (decimal address of LPT1)
>>
>>
>>The 888 part seems a bit problematic to me.  For one, it's really,
really
>>platform specific (to the point that two different machines on the
same O/S
>>may not have things at the same address (you can put devices at
other
>>addresses or have "virtual" device, etc)).
>>
>>Here's a couple of thoughts:
>>
>>1) Use device names (LPT1, /dev/lp0, etc)
>>Better abstracts things, allows the actual physical device to be
resolved on
>>the target machine, though still does not provide a uniform xPL
level naming
>>scheme
>>
>>2) Use device= and unit= (device=Parallel, unit=0 == LPT1 or
/dev/lp0)
>>Breaks things up into the general class of I/O and the unit within
in.  That
>>is likely to be pretty easy to interface with via xPL from other
platforms.
>>  Of course, the unit= thing breaks control.basic
>>
>>3) Use a extension of control.basic: control.parallel and
control.serial
>>
>>control.parallel
>>device=<unit # (0, 1, 2) or name (LPT1, LPT2, /dev/lp0)>
>>type=byte
>>current=255[,100[,200]]
>>
>>The extra bytes on the current= allows simple multi-byte writes
(optional
>>(that is what the [ and ] are meant to indicate) -- I could deal
with one
>>byte per packet, though that could be a bit wasteful when doing
lots of
>>control).  While I think it would be nice to also allow hex
notation (i.e.
>>0xff), I'm ok with decimal only.
>>
>>I think it would be good to also have a type=text and current= be
an ASCII
>>string that is sent out character by character.  This would make
things like
>>LCD displays and such easier to work with (send a few control
characters,
>>then a message to display)
>>
>>control.serial
>>device=<unit # or name (COM1, COM2, /dev/ttyS0, etc)
>>type=byte
>>current=255[,100[,200]]
>>[config={3001200240048009600192003840057600etc]},{78},{EVENODDNONE},{CTSXONNONE}]
>>
>>The optional config= tag would allow you to set the baud rate, data
bits,
>>even/odd/none parity and CTS/XON/NONE handshake.  If omited the
serial port
>>is used at it's last settings (i.e. nothing changes).  This could
also be
>>broken down into a baud=, databits=, handshake= and parity= tags
too --
>>perhaps that would be better?
>>
>>I believe I can put together a Java x-platform version of this, but
I do
>>know that it would not be able to do anything with a device address
like 888
>>because it would be abstracted and inaccessible.
>>
>>Gerry
>
>