No announcement yet.

Problem with com program

  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem with com program

    Hello, I'm new to power basic and I was given the task of
    fixing this program!!
    The program is connecting to a serial buffer device and
    polling records out of the device into the program.
    It appears that the code is making a clean connection and
    the data is comming into the program.

    Here is the code that I have a question about...

    Open "COM1:1200,N,8,1" AS #2
    Open "CALLREC" For Append As #3
    DELAY 3
    Rem ********* BEGIN DATA COLLECTION ***********
    If Loc(2) > 20 Then
    'perform logic
    End If

    Through debugging my program using an evaluate on Loc(2), I
    noticed that the value is '?????'

    Does anyone know of any reason that Loc(2) is never receiving
    any of the data from the buffer device?

    Thanks so much for your assistance.



  • #2

    This is how I detect input from a bar code reader on com 1

    COM(1) ON
    ON COM(1) GOSUB CardInput


    COM(1) OFF
    INPUT #1, InData$
    : Handle data here
    COM(1) ON

    Perhaps this may help you.

    Michael Burgett
    Michael Burgett


    • #3
      LOC(n) is not a variable, but a native PowerBASIC function -- therefore you cannot "watch" its value directly by placing "LOC(2)" in the Watch Window.

      The solution is to assign it to a normal [integer class] variable and then add that variable to the Watch Window.

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


      • #4
        Lance ..

        Can you offer any tips on how to handle initialization routines which
        involve only passing one byte out the port and receiving one byte back
        in to signal initialization?

        I realize this is a possible issue with OS/2 and how OS/2 handles the
        comm port routines as a DOS-VDM, or at least could be. It doesn't have
        to be an issue with PowerBASIC at all. But in this case, possibly, and
        in mine for sure, a device like the IR-MAN controller which is this way
        has been a problem for me with the standard comm port routines in the
        DOS-VDM's. Somehow, just mashing one byte out the port to start things
        and getting one byte back in to signal success for initialization was
        a problem when I was working on this many months ago.

        Using Poor Man's Line Monitor for OS/2, PMLM, which is a distributed tool
        you get when you license Ray Gwinn's SIO and SIO2K comm port substitution
        drivers for OS/2 get us somewhere. This tool splices itself in the I/O
        channel for a given port. It lets you see every single byte and the order
        of the cascade of the data, both in and out, for the investigated port.

        Further, with the licensed version, you get a complete dumpable disk
        file with the data stream and sequencing in it for debugging and
        reporting purposes. The disk file so produced does not require any
        licensing to use the special reader or reader-printer which I am free
        to distribute as a DOS tool for troubleshooting purposes.

        Specifically, in this one out and one back in scenario, I can see
        the byte proceed out to the UART in the trace work from the standard PB
        3.5 comm routines. But I cannot see the return byte come back in from the
        UART that shows that the device has initialized! Thus the program does
        not really 'know' that we are ready or not to work, even though it will
        work if you second guess things and begin to use the IR-MAN. It's seemingly
        an issue about buffering through the UART for just one byte at a time each
        way, for receive time, it seems.

        I can use a native terminal program such as ZOC for OS/2, for test
        purposes in native OS/2. Using ZOC the exact same send routine, byte
        for byte and all, plus receive for the inbound byte, PMLM *DOES* show up
        that one byte return in the PMLM trace runs. We get to see initialization
        results just fine.

        Now .. if I use a terminal program for DOS, such as COMIT, I can see
        the exact same good results, even in the same DOS-VDM which we are
        using for PB 3.5 development for this tool enablement in my program
        suite. This, somehow, I have the as yet to be proven feeling that
        this is, somehow, related to the way PB handles one byte data strings,
        in relation to the INBOUND return byte, a single byte, as to LOC(#)
        which is under discussion here. Somehow, it seems that LOC(#) does
        not return anything for just one byte when just one byte comes back
        in to you.

        Although I have the ability to actually touch the hardware in OS/2
        DOS-VDM's, I have avoided that in all my comm port work so far. If
        I get into the IN/OUT game for ports, I could, I think, solve the
        problem. But that is *NOT* the way to plan for future portability
        for WIN whatever, nor LINUX, nor really, for even native OS/2 in whatever
        way the source might get to these platforms.

        For example, even though the old MIcrosoft PB7 compiler will produce
        both DOS and Native 16 bit OS/2 executables, one of the few things that
        you had to avoid was the use of IN/OUT functions for ports. That direct
        port function was not usable in native OS/2, nor recommended at all
        that you use it in DOS-VDM's either. The use of OUT with nowhere for
        the data to go or a failure in the I/O routine is one DARNED good way
        to hang an OS/2 session or DOS-VDM session under OS/2, I assure you.

        Even OS/2. as wonderful as it may be, has nice neat ways to bring things
        to a halt, grin!

        OK .. How can I investigate this, returning all these months later
        to the IR-MAN development, with LOC(#) and so on here? Is this, say,
        an issue where flushing the buffer wasn't/isn't possible for just one
        byte, when we are using an ON LOC(#) do this approach?

        Obviously the cow is somewhere in the pen, ready to come down the
        chute. even though there is only one cow in the trailer! Chuckle.

        I really would like some guidance and discussion of how to work at this,
        even to the extent that one MIGHT be able to do this with in-line
        assembler, say AFTER the port has been opened for high level use?
        Persish the thought! But, heck, as a conditional compilation, come time
        to do this in LINUX from common source, with PowerBASIC for LINUX,
        some discussion now over how to write this would sure be wonderful.

        At the same time, I think it actually might help the original poster
        to perhaps debug his routine for a bar code scanner! In a way, what
        he is doing and what I tried to do, and failed at, months back,
        seem strangely, perhaps, related?

        Again, I'm not saying PB is at fault. I'm just asking for pointers
        on how to research this issue and find for sure what is happening.
        It is time to finish my embedded system interface for in-room operations
        which does not even have a normal keyboard, in normal use.

        Thank you for any time given to this.. and your thoughts.

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


        • #5
          I could write you a very simple function to put the byte OUT the
          port (provided it is serial port 1-4), using the DOS 14h INT.
          However, reading a byte IN is problematic (or any number of bytes).
          Back when my BBS had remote login capability, I was experimenting
          with writing my own COMM functions (not out of dissatisfaction
          with PB's functions - I just wanted to "play"). But I could never
          get it to read IN data from the remote end. Putting data OUT the
          port was easy. I *believe* the problem with reading data in was
          caused by the fact that the serial port used a 16550 UART. As is
          the usual, my machine uses the serial port interrupts for processing
          data. On the otehr hand, the INT 14h services I was using use
          BIOS polling. Based on that, I am surpried that even the data OUTPUT
          worked. But, because it worked, it's quite possible that I was using
          bad code to read the data in.

          Would you like for me to rebegin these endeavors? If you answer "yes,"
          also specify whether you want the one byte that is sent/received
          to be processed as a numeric byte, or as a one-byte string. You may
          mix them, one for send, one for receive, if you want.



          • #6
            Just did some reading in Ralf's Lists. It turns out that the INT14h
            service that reads data in from a serial port will always fail if
            the DSR line is (or is not?) asserted. It will do this even if
            the service that returns port status says that data is ready. So,
            that could have been the cause for failure in my way-back coding.
            I do not know how to overcome this. However, Mike, if your proggy
            uses a FOSSIL driver for the port, then it would be a piece-of-cake.
            My FOSSIL procedures ALWAYS worked (provided you are using port 1-4).



            • #7
              Disregard, Mike. I just read MOST of your message, this time, and
              now see that you need the one byte functionality for OS/2. I do not
              know how to program for that OS.



              • #8
                I do recall going down this exact path with you before Mike -- IIRC we agree the problem was the port state as set by that hardware device?

                If that is the case, then the solution will probably have to be hardware too... make an RS232C adaptor lead that isolates all but pins 2, 3, and 5. Then adapt your code to ignore all handshaking, etc.

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


                • #9
                  Thanks to both of you Clay and Lance for your time and thoughts.

                  Clay .. you're right on target as to what I've done up to now. It
                  isn't getting the data out the port but recovering the one byte in
                  which is the problem. And yes, the 16550 series is involved. You
                  know, it never even crossed my mind to try a FOSSIL driver! I'll
                  think that through carefully. Where would that lead in a move to
                  LINUX if that ever happened?

                  Lance .. Your memory is quite correct and what happened is that
                  based on the work load for other more important things, the project
                  got shelved until other work was done. However, your reduction to
                  a simpler line status connection is new and thoughtful. I'll take
                  your suggestion and see what happens if I strip off the hardware access
                  except for those pins. It never dawned on me that the only way to
                  solve this might be to reverse the thought that we worry, worry, worry
                  that serial cables have the right wires in them to maximize data flow.

                  From both your comments, y'all are coaxing me back toward the world of
                  assembler for this task. You know, that whole possibility of having
                  to use assembler on this and not being able to use higher level code
                  from PB never crossed my mind, despite the fact that I'm already using
                  a complete assembler operation for all the ham station keying and
                  relay ontrol functions! Gee, I haven't touched all this and it is
                  still in use here today since I wrote it in the late 70's based on
                  Heathkit's REMARK magazine on assembler for the 8250 UART with my
                  old H89 computer and added sound monitoring in real-time with Robert
                  Jourdains's help from, "Programmers Problem Solver for the IBM PC,
                  XT and AT." (!)

                  BTW .. to the original poster and others interested in the world of
                  assembler for comm port work, you really ought to try to find that
                  Jourdain book, a Brady Book. It is a wonderful resource on all this.

                  But, a MASM .OBJ library yet? You guys really know how to make an
                  oldtimer sweat 'is own code! Gulp ...

                  In short, consider this a low level operation that it is, just use
                  the relay control issues for telegraph code and try my existing code
                  for it. Bonus byte! If the telegraph output functions work and I
                  can just add the look for the return string byte snatch, I'll get
                  the benefit of the existing mirror image of the tone for the action.

                  I could use the existing PC speaker code for the monitor tone for key
                  press prompts, altering the pitch for confirmation that the IR-MAN
                  system has acted on a request. Use the existing beep tones for that
                  from integrated assembler libraries I wrote back in the late 70's for
                  telegraph work still working today in OS/2 hosted systems. The user
                  would soon figure out if you hear only one tone, things ain't no good
                  in controller land. It takes two to tango!

                  But again. Where does that leave me for LINUX in the future as it
                  will be opened to me with PowerBASIC for that operating system? Will
                  we be able to use the same in-line assembler techniques in PB for
                  LINUX, for example?

                  And back to the original issue. OK, So I have opened up the port for
                  the really needed text based I/O for program use across the IR-MAN
                  port with conventional higher level PB techniques. You know, OPEN for
                  this or that.

                  Are you saying that I could do this single byte initialization stuff
                  with assembler, despite the fact that we have that port open the other
                  way as well?

                  I thought it was bad business to mix port I/O techniques between the
                  world of high level and low level tools. But is this a wrong notation
                  if you already have the port open at high level? Can you, as well
                  chunk this or that out of it and in from it via low level tools as
                  well ... because PB will simply gloss over it?

                  Is this the equivalent of the Ziploc Bag commercial, "A tiger won't
                  eat what a tiger can't smell!"

                  Puppy scratching ear here \? Not really wanting to get eaten by the
                  commuications tiger.

                  We get stuck in our own ruts. It often takes outside overview to get
                  the wagon turned a new direction.

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