Announcement

Collapse
No announcement yet.

Delay in serial com. sending.

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

  • Mike Luther
    replied
    In my experience, the problem gets even more difficult if the
    hardware you are trying to use only will work with ONE byte, I
    mean quantity (1) byte for an init string!

    Put on the back burner here but may come out soon to solve is the
    issue of enabling an IR-man remote control device under PB for DOS.
    You have to send it one byte to initialize it and get back only one
    in return! I could initialize it for test and research using ZOC
    for OS/2 in a native OS/2 session. But I never could get PB's
    COMM routines to ever send just one byte and pick off just one byte
    from the buffer(s) as used in a DOS-VDM, together with Ray Gwinn's
    SIO communications driver packages for OS/2.

    I could use a direct IN/OUT port style of access for the device.
    In OS/2 as part of the Session setup parameter choices that may be
    customized for each and every DOS-VDM session on an individual
    basis, one of the choices is to let the DOS-VDM session actually
    touch the hardware.

    But as has been pointed out in this thread in the discussion, if you
    do that, you are creating code which will fail on later versions of
    the Windows operating system which does not give you access or the
    option to access the hardware directly for your application, like
    you had in pure DOS or early Win work.

    Ray Gwinn has written a new version of SIO-2K which may solve this
    problem here under OS/2 DOS-VDM's. Notice that I did *NOT* make any
    claim that PB 3.5 is to blame for what I will, in humor here, call a
    'buffer under-run'! However it happens; it doesn't ... chuckle.

    Thus I am watching this thread closely to see if a choice morsel may
    get tossed out on the ground I can snarf up!

    There is one tool in Ray Gwinn's arsenal of port I/O munitions whicn
    does make work with this practical in both native OS/2 and DOS-VDM
    work. It is called "Poor Man's Line Monitor" (PMLM.EXE). When you
    license the product, the license key enables it and it produces both
    a visual display of every byte that moves in both transmit and receive
    across the examined port, plus writes that cascade of data to a disk
    file that anyone can examine later, even if they are not using OS/2
    and SIO. I've used this tool in a number of cases early on in the
    development of OS/2 to help debug modem programs for vendors that
    have problems we've found.

    It's been MANY years since I've used this same kind of tool in the
    work of debugging BBS systems over just this kind of stuff. But in
    the dark corners of my mind, I can recall that there *ARE* a few of
    these port monitoring tools available that will run under DOS to help
    one debug these problems. I think you can find at least one such tool
    which you can use under either plain DOS or even WIN-32 if you will
    just open up GOOGLE as your search engine. Put in the following:

    comm port monitor DOS

    On the first page of search returns alone are several possible sources
    for tools that may help anyone debug this. Sorry if it will take a
    lot of time to really fix this, but communications port acorns are
    like rare gems when you are reduced to nibbling a byte at a time.





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

    Leave a comment:


  • Aldo Cavini
    replied
    dan,

    a long time ago i used to program with turbobasic, and got some strange communication problems on certain pcs. the solution was to write my own com driver, via inps and outs. the thing is not too complicated - look at http://www.powerbasic.com/support/pb...read.php?t=837: i posted there a very simple low level driver (it doesn't use the fifos).

    since then two things happened: i moved to powerbasic (a better compiler than turbobasic was), and windows nt - windows 2k - windows xp made it impossible to inp/out the hardware registers by program. i no longer use such low-level driver... be sure your program will always run in plain dos before start writing your low level com driver.

    aldo

    [added later]

    i see your communication speed is 115200 baud: don't even try to receive records this speed under windows without an interrupt driven driver. may be the solution is to low-level tx and powerbasic rx (open com, setupt the tx fifo, rx via powerbasic com, tx on i/o polling), but i never tried something similar.

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

    [this message has been edited by aldo cavini (edited july 30, 2003).]

    Leave a comment:


  • Paul Dixon
    replied
    Mel,
    $COM only sets a receive buffer. There is no transmit buffer.

    Paul.


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

    Leave a comment:


  • Dan Symonds
    replied
    Gentlemen:
    Well, that seems to explain my exact problem. The polling of the
    FIFO buffer seems to be a pain but I'm sure it would be much faster
    than my current system.

    Thanks for your input. Now I need to research polling the FIFO.

    Thanks again
    Dan


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

    Leave a comment:


  • Mel Bishop
    replied
    Originally posted by Paul Dixon:
    There is no transmit buffer.
    Actually, there is using the $COM[bufsize] metastatement but I
    don't think this would help in this instance; But it might....
    ------------------


    [This message has been edited by Mel Bishop (edited July 29, 2003).]

    Leave a comment:


  • Paul Dixon
    replied
    Dan,
    that's a known "feature" of PB/DOS. It was mentioned/discussed years ago on the PB forum of Compuserve (before this website existed) and must never have been remedied.

    There is no transmit buffer. When you write to the port you get held up until the whole of the data has been sent.

    The proper way to do it is to have an interrupt driven Tx buffer and there are some libraries you can buy which implement this, or you can write one yourself.
    The quick fix, although my memory is a bit vague on it now, is to split your data into very small chunks which fit into the Tx FIFO of the UART being used. The size of that FIFO (and so the size of the chuncks) varies fron 1 byte to 16 bytes depending on which UART you have.
    You then poll the UART to see if the Tx FIFO is empty before sending the next chunk. If it isn't empty, you do a small amount of other processing before polling again.

    It's a pain to do it this way, but it's the only quick fix.


    Paul.




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

    Leave a comment:


  • Dan Symonds
    replied
    Mel:
    Yes I do understand that.

    The fact that I was able to have the systems running as a dos computer
    to dos computer system and the problem still existed seems to
    eliminate the windows question. Also, the delay is occuring in the
    dos only system not the windows side.

    I do occasionally get a 'delay' in the windows side while the OS
    goes off to do something else but the timing on that side is much
    less critical so I don't worry about it.

    I was wondering if I could somehow use the 'out' function to write
    the data to the serial buffer and even a for/next loop to write
    the data a byte at a time would be faster than what I'm currently
    getting.

    Any thoughts?

    Dan


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

    Leave a comment:


  • Mel Bishop
    replied
    On the DOS box side, you have to consider that DOS is a single
    tasking operating system. It will pause until it's done with
    what it's doing.

    The windows side is a multi-task'er (most of the time) that
    occasionally goes off and does other things while the comm port
    buffer is receiving data. Until windows comes back to the comm
    port, the DOS unit has no choice but to pause and wait for an
    acknowledgement.


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

    Leave a comment:


  • Dan Symonds
    replied
    I am running a pure dos system on the side I am concerned about
    but it is communicating with a windows system and my software is
    running in a dos box. I have booted the "windows" computer from
    a dos boot disk and run the systems togather as a dos to dos communication
    but it made no appreciable difference in the problem.

    When I say the system delays, I mean there appears to be a
    significant delay (several ms's) in the processing of the program
    code. It's as if the print # function is sequentially writting
    each character to the serial port and waiting for the send buffer
    to be empty before "printing" the next character. The time delay
    varies somewhat with the length of the data string to be written
    but not linearly. It only affects the delay by a few % (<10%).

    I use the following command to open the comm port:
    port$ = "com" + LTRIM$( STR$( pc.com.port )) + ":" + LTRIM$( STR$( exec( 28 ))) + ",n,8,2,rs,cs0,ds0,cd0"
    OPEN port$ AS #1 LEN = 1000

    pc.com.port is the comm # and exec(29) is the baud rate (115200)

    I use the following command to write to the serial port:
    PRINT #pc.com.port, send.cnc$

    Once I call the send data subroutine, I get a significant delay in
    returning back to program execution following the sub call.

    Thanks
    Dan




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

    Leave a comment:


  • Mel Bishop
    replied
    1. Can you put a definition on "the system delays"?
    2. Are you using pure DOS or a windows DOS box?


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

    Leave a comment:


  • Dan Symonds
    started a topic Delay in serial com. sending.

    Delay in serial com. sending.

    Gentlemen:
    I have written a program that communicates between two computers
    using the serial ports. The system works well with one exception.
    When I write data to the port, the system delays while the data
    is written. I have searched the archives but found no references
    to my problem.

    My question is:
    Does the Print # function write to the serial buffer and return or
    does it wait until all characters have been transmitted. If I
    could just dump to the buffer and move on it would greatly speed
    up my process.

    Any insight on this problem would be greatly appreciated.

    Dan


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