No announcement yet.

Comm Port Question with IRMAN device ..

  • Filter
  • Time
  • Show
Clear All
new posts

  • Comm Port Question with IRMAN device ..

    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]
    Mike Luther
    [email protected]

  • #2
    The first question to ask is this: can you talk to it with PowerBASIC under MS-DOS or Windows (ie, a "normal" non-OS/2 operating system)?

    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    mailto:[email protected]


    • #3
      Of course you are correct, Lance, lowest common denominator approach
      is the way we go.

      Thanks ..

      I'm setting up to try that, but in doing so that introduces another
      whole different hardware layer into the issue also. There is no way
      I can ever provide the same hardware testbed under DOS or WIN at all.
      I used to have that capability using FAT 16 hard disk operations.
      That went away years ago with the HPFS file system which sure stopped
      a ton of instability problems and also gave me a huge bonus of I/O
      and storage improvement.

      It may be possible over the weekend to set up a borrowed laptop to
      work with in a DOS box in WIN-95, but not a pure DOS box..

      Ordinarily this sort of thing isn't an issue. PowerBASIC is so darned
      good that I've long ago stopped trying to test everything on DOS and
      WIN boxes that works on OS/2 DOS-VDM's as to client release code!

      And, again, if I can get this working in PB 3.5 for DOS, I will post the
      needed code for the PowerBASIC crew.

      Mike Luther
      [email protected]
      Mike Luther
      [email protected]