No announcement yet.

Delay in serial com. sending.

  • Filter
  • Time
  • Show
Clear All
new posts

  • Delay in serial com. sending.

    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.



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

    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.


    • #3
      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$( )) + ":" + LTRIM$( STR$( exec( 28 ))) + ",n,8,2,rs,cs0,ds0,cd0"
      OPEN port$ AS #1 LEN = 1000 is the comm # and exec(29) is the baud rate (115200)

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

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




      • #4
        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

        There are no atheists in a fox hole or the morning of a math test.
        If my flag offends you, I'll help you pack.


        • #5
          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

          Any thoughts?




          • #6
            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.




            • #7
              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).]
              There are no atheists in a fox hole or the morning of a math test.
              If my flag offends you, I'll help you pack.


              • #8
                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



                • #9
                  $COM only sets a receive buffer. There is no transmit buffer.




                  • #10

                    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 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.


                    [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).]
                    Rgds, Aldo


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