Announcement

Collapse
No announcement yet.

Problem with com program

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mike Luther
    replied
    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]

    Leave a comment:


  • Lance Edmonds
    replied
    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.



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

    Leave a comment:


  • Clay Clear
    replied
    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.


    ------------------

    Leave a comment:


  • Clay Clear
    replied
    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).


    ------------------

    Leave a comment:


  • Clay Clear
    replied
    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.


    ------------------

    Leave a comment:


  • Mike Luther
    replied
    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]

    Leave a comment:


  • Lance Edmonds
    replied
    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.

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

    Leave a comment:


  • Mike Burgett
    replied
    Bob.


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


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


    CardInput:

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



    Perhaps this may help you.




    ------------------
    Michael Burgett

    Leave a comment:


  • Bob Haynes
    started a topic Problem with com program

    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
    Rem ********* BEGIN DATA COLLECTION ***********
    Rem
    MAIN:
    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.

    Bob



    ------------------
Working...
X