Delay in serial com. sending.

[Dan Symonds]

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


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

[Mel Bishop]

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


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

[Dan Symonds]

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




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

[Mel Bishop]

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.


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

[Dan Symonds]

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


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

[Paul Dixon]

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.




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

[Mel Bishop]

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

[Dan Symonds]

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


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

[Paul Dixon]

Mel,
$COM only sets a receive buffer. There is no transmit buffer.

Paul.


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

[Aldo Cavini]

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

[Mike Luther]

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]