| |
PA2AGA > HDDIG 09.02.00 17:41l 209 Lines 7807 Bytes #-9586 (0) @ EU
BID : HD_2000_37D
Read: GUEST
Subj: HamDigitalDigest 2000/37D
Path: DB0AAB<DB0PV<DB0MAK<DB0ERF<DB0ROF<DB0AIS<DB0ME<ON6AR<PI8HWB<PI8HGL<
PE1MVX<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 000209/0623Z @:PI8VNW.#ZH2.NLD.EU #:50067 [HvHolland] FBB7.00g24
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA29980 ; Wed, 09 Feb 00 04:56:03 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.70/7.5.3) with SMTP
id AA00017847 ; Tue, 08 Feb 2000 18:17:09 MET
Date: Tue, 08 Feb 00 18:11:13 MET
Message-Id: <hd_2000_37D>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 2000/37D
X-BBS-Msg-Type: B
> >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?
Properly written code will twiddle the appropriate control lines
to make certain there is no possibility of buffer overrun due to UART
output buffering.. Code to handle this correctly is not difficult. It is
easy to allow for a "reasonable" number of characters to arrive after
the appropriate control line has been twiddled. Note that both ends
of the link must use the proper control line twiddling protocol, and
the cable connecting the two UARTS must have all the needed pins
connected. Most "bugs" of this nature seem to be due to cables with
missing wires, and not bad code in the sending or receiving device,
since that code is almost trivial to get right.
--
... Hank
http://horedson.home.att.net
>.
------------------------------
Date: Mon, 31 Jan 2000 21:53:22 -0500
From: "Rob" <Pse@NoEmail.Com>
Subject: Kantroncs bugs?
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!
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.
But some of use like using the terminal mode!
73's
Rob
"Hank Oredson" <horedson@att.net> wrote in message
news:%Opl4.243$6B1.41661@bgtnsc06-news.ops.worldnet.att.net...
>
> "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
> > >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?
>
> Properly written code will twiddle the appropriate control lines
> to make certain there is no possibility of buffer overrun due to UART
> output buffering.. Code to handle this correctly is not difficult. It is
> easy to allow for a "reasonable" number of characters to arrive after
> the appropriate control line has been twiddled. Note that both ends
> of the link must use the proper control line twiddling protocol, and
> the cable connecting the two UARTS must have all the needed pins
> connected. Most "bugs" of this nature seem to be due to cables with
> missing wires, and not bad code in the sending or receiving device,
> since that code is almost trivial to get right.
>
> --
>
> ... Hank
>
> http://horedson.home.att.net
>
>
>
>.
------------------------------
Date: Tue, 1 Feb 2000 17:45:57 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: Kantroncs bugs?
Hank Oredson <horedson@att.net> wrote:
>the appropriate control line has been twiddled. Note that both ends
>of the link must use the proper control line twiddling protocol, and
>the cable connecting the two UARTS must have all the needed pins
>connected. Most "bugs" of this nature seem to be due to cables with
>missing wires, and not bad code in the sending or receiving device,
>since that code is almost trivial to get right.
I don't believe that. When the wiring is incorrect, the handshaking
will not work *at all*, and the uploading of a file via a 9600 baud
RS232 link into a 1200 baud packet radio connection will not result
in the loss of "a few bytes", but in the loss of nearly the complete
file after one buffer size. That is not the reported problem.
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: Tue, 1 Feb 2000 17:43:44 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: Kantroncs bugs?
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>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?
Yes. And most other "RS232 serial devices with RTS/CTS handshake" as well.
Apparently the Kantronics TNCs don't.
A possible catch is that the number of bytes one has to have available
in the buffer when CTS is lowered has increased over time. But so has
the average size of memories, and hence of buffer spaces. So this should
not really be a problem, except when development has stood still over the
last 15 years. This may be the problem with TNC firmware.
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: Wed, 2 Feb 2000 11:50:03 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: Kantroncs bugs?
Hank Oredson <horedson@att.net> wrote:
>Consider RTS/CTS vs. DSR/DTR vs. ^S/^Q.
>Many different behaviors are possible, depending on how well the
To be continued in digest: hd_2000_37E
Read previous mail | Read next mail
| |
