Tweet
Pursuant to the game of control things by a common TV remote, I found
that the little IRMAN device looked interesting. Attaches to any old
serial port. In theory, behaves just like a *VERY* simple modem. You
set up the port at 9600,N,8,1 .. making sure that RTS and DTR are good
to go and fire up the port. That causes the return of one character
in the input bufffer to the port, an "X" as it turns out.
From there you simply send the IRMAN an "IR" two byte character string.
If it initializes, back comes a two byte string, "OK" and off we go.
The supplied demo simplistic TV remote has a scan mode button, much like
the Logitec RF mice I use. Pushing the sync search button lets IRMAN
figure out which of the seven IR frequency channels might be in use.
One locked, presto! You can look at the character string or character
which is returned by a particular TV remote and then do what you wish
with the byte pattern returned. The included demo unit returns the
alloted character for a particular botton, then an end of I/O character
to indicate the button has been released. Simple! Neat!
Well, how did I learn all this? Like you learn lots of things in OS/2
operations. In this case, I fired up Ray Gwinn's SIO comm port enhance
toolset utility called Poor Man's Line Monitor (PMLM) and as a shim
it lets you read, inspect, and record all data going each way across
any comm port line you like. Handy as a button on a shirt! As well,
I used one of several OS/2 native communications terminal programs to
piddle with it, in this case HyperAccess for OS/2 or could have used
ZOC, both of which are also available for WIN-whatever too.
OK, now, for what reason can't I get PowerBASIC, for the first time
in my whole DOS-VDM career with it, to write output to that port,
once the IRMAN is initialized?
Now I'm *NOT* complaining at all that PowerBASIC is flawed! Likely
not. Likely the flaw is in me or anywhere else but PowerBASIC!
Using either the example toolset or the standard COMM routines, that
I've been using seems like forever in these DOS-VDM's in OS/2. you just
use the common PRINT #x, DMY$; and what you send goes out the port.
Simple! I've done that with both the formal PB as just noted. I've
done it with the OUT &H03E8, Byte technique. I've done it with
in-line, various times in various programs. No problem.
Not this time!
No matter *WHAT* I seem to do, the byte(s), I only need TWO of them,
"IR", never go out the port! Using PMLM and PowerBASIC code, I can
see the device open. I can actually see that first "X" it returns in
the read buffer show up, both in PMLM and also as a function of the
normal LOC(#x) technique. No problem! I even can see it in INP(#x) as
well, for grins! So I *KNOW* the unit is there on the line!
I also know that in OS/2 DOS-VDM's, for this unit, for that COMM
port I also have to use a DOS set statement of RTS=ON, where the usual
setting on default for it is RTS=HS for us guys.
I've looked at CTS and DTR and all. The DOS-VDM settings for CTS
look like they are not being set properly by the device in a DOS-VDM
session, as contrasted to the native OS/2 operations!, but no setting
I can use for altering that in PowerBASIC, or from the example work
lets me see any way to change that. As well, the example code from
the PowerBASIC COMM unit sample which reports CTS, also reports back
a ZERO (0) value if I querry it before I attempt to send out the port.
That tells me something isn't right, but since PowerBASIC isn't in
native OS/2, I can't compare all this easily.
I've also tried setting the 16550 buffer at a level ONE bufer setting
with the example toolset assembler in-line code supplied. I've also
tried that in the Gwinn SIO toolset in OS/2's comm routines to no
good at all.
No other device I've ever had behaves this way with the PB code.
Of course this one *ONLY* works at no more than a two byte level or
so in I/O at all.
I've finally found something dumber than a mouse that is smarter than
I am!
Yes, I have C++ code that will do the job in native OS/2 and also
C++ code or C that will do the job in WIN-whatever. Frankly, that
translates just about exactly the same to PowerBASIC for this simple
task, which still doesn't work!
Can anyone here suggest how I can be more dumb-like? I hate to get
outsmarted by something even more benign than a mouse! Why can't
I feed this thing one byte at a time, nibble nibble???
Huge grin!
------------------
Mike Luther
[email protected]
that the little IRMAN device looked interesting. Attaches to any old
serial port. In theory, behaves just like a *VERY* simple modem. You
set up the port at 9600,N,8,1 .. making sure that RTS and DTR are good
to go and fire up the port. That causes the return of one character
in the input bufffer to the port, an "X" as it turns out.
From there you simply send the IRMAN an "IR" two byte character string.
If it initializes, back comes a two byte string, "OK" and off we go.
The supplied demo simplistic TV remote has a scan mode button, much like
the Logitec RF mice I use. Pushing the sync search button lets IRMAN
figure out which of the seven IR frequency channels might be in use.
One locked, presto! You can look at the character string or character
which is returned by a particular TV remote and then do what you wish
with the byte pattern returned. The included demo unit returns the
alloted character for a particular botton, then an end of I/O character
to indicate the button has been released. Simple! Neat!
Well, how did I learn all this? Like you learn lots of things in OS/2
operations. In this case, I fired up Ray Gwinn's SIO comm port enhance
toolset utility called Poor Man's Line Monitor (PMLM) and as a shim
it lets you read, inspect, and record all data going each way across
any comm port line you like. Handy as a button on a shirt! As well,
I used one of several OS/2 native communications terminal programs to
piddle with it, in this case HyperAccess for OS/2 or could have used
ZOC, both of which are also available for WIN-whatever too.
OK, now, for what reason can't I get PowerBASIC, for the first time
in my whole DOS-VDM career with it, to write output to that port,
once the IRMAN is initialized?
Now I'm *NOT* complaining at all that PowerBASIC is flawed! Likely
not. Likely the flaw is in me or anywhere else but PowerBASIC!
Using either the example toolset or the standard COMM routines, that
I've been using seems like forever in these DOS-VDM's in OS/2. you just
use the common PRINT #x, DMY$; and what you send goes out the port.
Simple! I've done that with both the formal PB as just noted. I've
done it with the OUT &H03E8, Byte technique. I've done it with
in-line, various times in various programs. No problem.
Not this time!
No matter *WHAT* I seem to do, the byte(s), I only need TWO of them,
"IR", never go out the port! Using PMLM and PowerBASIC code, I can
see the device open. I can actually see that first "X" it returns in
the read buffer show up, both in PMLM and also as a function of the
normal LOC(#x) technique. No problem! I even can see it in INP(#x) as
well, for grins! So I *KNOW* the unit is there on the line!
I also know that in OS/2 DOS-VDM's, for this unit, for that COMM
port I also have to use a DOS set statement of RTS=ON, where the usual
setting on default for it is RTS=HS for us guys.
I've looked at CTS and DTR and all. The DOS-VDM settings for CTS
look like they are not being set properly by the device in a DOS-VDM
session, as contrasted to the native OS/2 operations!, but no setting
I can use for altering that in PowerBASIC, or from the example work
lets me see any way to change that. As well, the example code from
the PowerBASIC COMM unit sample which reports CTS, also reports back
a ZERO (0) value if I querry it before I attempt to send out the port.
That tells me something isn't right, but since PowerBASIC isn't in
native OS/2, I can't compare all this easily.
I've also tried setting the 16550 buffer at a level ONE bufer setting
with the example toolset assembler in-line code supplied. I've also
tried that in the Gwinn SIO toolset in OS/2's comm routines to no
good at all.
No other device I've ever had behaves this way with the PB code.
Of course this one *ONLY* works at no more than a two byte level or
so in I/O at all.
I've finally found something dumber than a mouse that is smarter than
I am!
Yes, I have C++ code that will do the job in native OS/2 and also
C++ code or C that will do the job in WIN-whatever. Frankly, that
translates just about exactly the same to PowerBASIC for this simple
task, which still doesn't work!
Can anyone here suggest how I can be more dumb-like? I hate to get
outsmarted by something even more benign than a mouse! Why can't
I feed this thing one byte at a time, nibble nibble???
Huge grin!
------------------
Mike Luther
[email protected]
Comment