X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Trace-PostClient-IP: 68.147.131.211
From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT Invalid>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: pmcom and overrun
Organization: Systematic Software
Message-ID: <1hhj90lsio0duj32jai9sijg8a45191et3@4ax.com>
References: <40994659$0$21761$a0ced6e1 AT news DOT skynet DOT be>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 49
Date: Thu, 06 May 2004 05:37:26 GMT
NNTP-Posting-Host: 24.71.223.147
X-Complaints-To: abuse AT shaw DOT ca
X-Trace: pd7tw2no 1083821846 24.71.223.147 (Wed, 05 May 2004 23:37:26 MDT)
NNTP-Posting-Date: Wed, 05 May 2004 23:37:26 MDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On Wed, 5 May 2004 21:54:10 +0200 in comp.os.msdos.djgpp, "Patrick
Talloen" <p DOT talloen AT hotmail DOT com> wrote:

>Hi,
>I'm using pmcom for serial communication between windows-pc and dos-pc
>(Rocky 512) (speed 115200)
>My serial ports are UART 16C550 compatible with a fifo of 16 bytes
>During data transfer (XON-XOFF handshaking) a buffer overrun happens
>frequently, even with a small amount of data (<16 byte)

XON-XOFF is only good to /maybe/ 19.2kbps. Implementation has to allow
for processing and transmission latency and delays and have
hysteresis: buffer size proportional to line speed ~1s data; send XOFF
at buffer ~75% full; send XON at buffer ~25% full if XOFF sent;
received XOFF *immediately* stop sending; received XON resume sending
at leisure. 
Above 19.2kbps you need to use RTS/CTS hardware handshaking. Similar
approach required to handling XON-XOFF. 
Do as little as possible in transmit ISR: stash status, bump transmit
pointer, fetch and send next char(s); other setup should be done in
the transmit setup routine called by the user. 
Do as little as possible in receive ISR, bump receive pointer, stash
char and status; additional processing should be done at the end of
the receive routine called by the user. Before leaving receive ISR, do
a programmed check for other interrupt conditions or characters
received and handle them. 

>After a overrun no transfer is possible anymore.
>How can this overrun condition be resetted?

Reset receive FIFO; see: http://byterunner.com/16550.html

>Why does this happen ? In my previous application in16bit (Greenleaf com
>lib) i could master 4 comports at a speed of 115200

Set receive FIFO trigger level lower to allow for latency and delays. 

>Are ISR in PM that slow ?

Probably: see Intel data sheets for your CPU. 

>Where can i find a good serial library for djgpp (RM ISR) (a commercial one
>?)

-- 
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian DOT Inglis AT CSi DOT com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply