The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

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



Howdy,

Anyone have any thoughts on this?  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.  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.

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.

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

--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org



xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.