| |
PA2AGA > HDDIG 09.02.00 17:40l 203 Lines 7776 Bytes #-9586 (0) @ EU
BID : HD_2000_37C
Read: GUEST
Subj: HamDigitalDigest 2000/37C
Path: DB0AAB<DB0SL<DB0RGB<DB0ABH<DB0SRS<DB0AIS<DB0ME<ON6AR<PI8HWB<PI8HGL<
PE1MVX<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 000209/0550Z @:PI8VNW.#ZH2.NLD.EU #:50066 [HvHolland] FBB7.00g24
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA29979 ; Wed, 09 Feb 00 04:15:29 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.70/7.5.3) with SMTP
id AA00017844 ; Tue, 08 Feb 2000 18:16:59 MET
Date: Tue, 08 Feb 00 18:11:11 MET
Message-Id: <hd_2000_37C>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 2000/37C
X-BBS-Msg-Type: B
> when CTS is low. Some UARTs in computer history could do that, but the
> function was usually riddled with problems. The UART used in the PC will
> only present the status of the CTS input as a bit in a register, and will
> optionally issue an interrupt when the status changes. The other UARTS
> have this mode as well (and are usually operated in this mode).
>
> The software needs to catch those interrupts, and twiddle its state to
> not send more output to the UART when CTS state says it shouldn't.
> But the bytes that were already put in the UART will still be sent out
> to the line. The driver cannot reliably "cancel" bytes already written
> to the UART.
>
> Traditionally, this could be up to two bytes: one in the transmitter
> shift register (the one currently being shifted out), the other in the
> transmitter holding register (the next one to be clocked into the shift
> register).
> However, with the advent of FIFO buffers, there can be more bytes waiting
> in the UART. The popular 16550A has a 16-byte FIFO, although it can be
> configured to contain fewer bytes.
>
> "It only happens under Windows" is probably a matter of slow reaction to
> interrupts, that is a general problem with Windows. This was the reason
> the FIFO UARTs were introduced in the first place: in the 486 days, when
> a Windows machine had extreme trouble to reliably keep up with a UART
> above 9600 bps when it had no FIFO, my Linux system happily did 57600
> without ever losing a byte. To reliably receive data without loss, you
> need to react to each interrupt quickly enough. Windows, because of the
> frequent disabling of interrupts during long code fragements, doesn't.
> This is probably because of switching between different CPU modes.
>
> Transmit is less critical, but CTS handshake is, in a sense. When you
> don't react on the CTS interrupt quickly, you would in theory be in the
> position to send more data while the CTS line is low. However, the
sending
> of data is done in an interrupt handler as well, and one would need to
> have a very stupidly designed driver for it to continue servicing transmit
> interrupts while it is putting off service of CTS interrupts...
> I don't know how this detail is handled in Windows, but I cannot believe
> it would be implemented that way. On the other hand...
>
> Rob
> --
>
+----------------------------------+--------------------------------------+
> | Rob Janssen pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob
|
> | AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU
|
>
+----------------------------------+--------------------------------------+
>.
------------------------------
Date: Mon, 31 Jan 2000 22:24:50 GMT
From: chris@cvine--nospam--.freeserve.co.uk (Chris Vine)
Subject: Kantroncs bugs?
On Mon, 31 Jan 2000 09:56:18 GMT, nomail@rob.knoware.nl (Rob Janssen)
wrote:
[snip]
>
>It does not work like that... the UART does not automatically stop output
>when CTS is low. Some UARTs in computer history could do that, but the
>function was usually riddled with problems. The UART used in the PC will
>only present the status of the CTS input as a bit in a register, and will
>optionally issue an interrupt when the status changes. The other UARTS
>have this mode as well (and are usually operated in this mode).
>
>The software needs to catch those interrupts, and twiddle its state to
>not send more output to the UART when CTS state says it shouldn't.
>But the bytes that were already put in the UART will still be sent out
>to the line. The driver cannot reliably "cancel" bytes already written
>to the UART.
>
>Traditionally, this could be up to two bytes: one in the transmitter
>shift register (the one currently being shifted out), the other in the
>transmitter holding register (the next one to be clocked into the shift
>register).
>However, with the advent of FIFO buffers, there can be more bytes waiting
>in the UART. The popular 16550A has a 16-byte FIFO, although it can be
>configured to contain fewer bytes.
Thank you. A most interesting analysis. Presumably, it would be wise
for a TNC (or any other serial device) to take CTS low well in advance
of running short of buffer space. Is that what most modems do?
Chris.
--
If replying by e-mail, remove the --nospam--
>.
------------------------------
Date: Tue, 01 Feb 2000 04:09:14 GMT
From: "Hank Oredson" <horedson@att.net>
Subject: Kantroncs bugs?
"Rob" <Pse@NoEmail.Com> wrote in message
news:FUrl4.218326$5r2.578707@tor-nn1.netcom.ca...
> Hank,
>
> The CTS hardware handshaking does NOT work in the KANTRONICS KAM, KPC-3
and
> possibly other KANTRONICS TNC's even with expensive computer cables
> connecting all the right pins!
You have me confused with someone else.
I never said it *did* work right on Kantronics TNCs, or on any
other specific serial device. Please respond to what I actually write.
> I agree that it shouldn't be hard for KANTRONICS to fix this type of bug.
A
> lot of the code is probably very easy to find. Unfortunately, there isn't
> much political will.
>
> Many Hams use a HOSTMODE program which constantly checks the amount of
free
> space left in the TNC buffer. This approach has two advantages -- one can
> always send a command to the TNC since there is always some buffer space
> left in the TNC. Secondly, one can make sure the buffer will never get
full
> and lose characters due to KANTRONICS' poorly written handshaking protocol
> firmware in their TNCs. Consequently, many HAMS don't ever see the bug.
Close, no cigar. Read hostmode docs for how it really works.
> But some of use like using the terminal mode!
Then you might use terminal programs that are smart enough to avoid
this particular problem. It ain't hard ... even with Kantronics TNCs,
even without using host mode. I know, I've done it. Not a big deal.
Any terminal program that fails in this situation is brain dead.
> 73's
>
> Rob
--
... Hank
http://horedson.home.att.net
>.
------------------------------
Date: Tue, 01 Feb 2000 00:30:51 GMT
From: "Hank Oredson" <horedson@att.net>
Subject: Kantroncs bugs?
"Chris Vine" <chris@cvine--nospam--.freeserve.co.uk> wrote in message
news:38960b4c.1275448@news.freeserve.net...
> On Mon, 31 Jan 2000 09:56:18 GMT, nomail@rob.knoware.nl (Rob Janssen)
> wrote:
>
> [snip]
> >
> >It does not work like that... the UART does not automatically stop
output
> >when CTS is low. Some UARTs in computer history could do that, but the
> >function was usually riddled with problems. The UART used in the PC will
> >only present the status of the CTS input as a bit in a register, and will
> >optionally issue an interrupt when the status changes. The other UARTS
> >have this mode as well (and are usually operated in this mode).
> >
> >The software needs to catch those interrupts, and twiddle its state to
> >not send more output to the UART when CTS state says it shouldn't.
> >But the bytes that were already put in the UART will still be sent out
> >to the line. The driver cannot reliably "cancel" bytes already written
> >to the UART.
> >
> >Traditionally, this could be up to two bytes: one in the transmitter
> >shift register (the one currently being shifted out), the other in the
> >transmitter holding register (the next one to be clocked into the shift
To be continued in digest: hd_2000_37D
Read previous mail | Read next mail
| |
