Subject: Re: (Pre-) Announce SHARK IR / Home Control
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
From: Mark J. Foster <mfoster@mail.com>
List: port-arm32
Date: 01/07/1999 22:39:16
Ken Hornstein wrote:
> Please leave room in your framework for at least switching the UART
> on the Shark into IrDA mode. Some of us completely insane bastards have
> replaced their current Shark IR receptor modules with IrDA-compatible
> versions :-)
>
OK - I remember reading about your work earlier (Congratulations, by the
way!). This would basically entail allowing the UART to remain in UART
mode with the IRDA flags set, rather than switching into consumer IR mode,
which works quite differently. Fortunately, the general structure of the
routines in the code does support this fairly well, other than that all of
the comments in the UART code would be wrong...
Actually, as I think about it, I'll have to make this a conditional, since
I can't think of a convenient way to poll for the IR transceiver format
(though if you were willing to, say, strap the internal Carrier Detect or
Ring Indicate pins to the opposite of their default state, we could perhaps
set a standard for this to be automatically polled versus a standard
SHARK).
There is one <big> potential downside, depending on the application you are
using. Since I steal the handshaking lines from the UART, it was necessary
for me to either completely rip apart the COM driver, or to create a new
one, and I've sort-of taken the second route. However, the RS-232 code is
basically just a data transfer routine; it does not do any TTY stuff, nor
H/W or S/W handshaking, etc. It really is assumed that the serial port
will be used for control applications which want control over how data is
passed back and forth... would this be OK for you?
As I haven't done <any> IOCTLs yet, I especially appreciate the early
warning here - in particular since the code has to do one <bad> thing, by
checking the absolute port address to determine if the "capable" UART or
the "stupid" UART is being attached - fortunately, that's done only once,
and from then on a flag determines what else happens... Similarly, the
devices are initialized by a simple port:value list, so that'll be easy to
do...
In other words, if your appplications do basic "raw" I/O, OK! Would you be
willing to add the internal wire?
Thanks!
MarkF
> --Ken