| |
PA2AGA > HDDIG 04.02.00 21:32l 182 Lines 6380 Bytes #-9591 (0) @ EU
BID : HD_2000_34B
Read: DL6KCF GUEST
Subj: HamDigitalDigest 2000/34B
Path: DB0AAB<DB0PV<DB0MAK<DB0ERF<DB0ABZ<DK0MNL<DB0ROF<DB0AIS<DB0ME<ON6AR<
PI8HWB<PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 000204/0216Z @:PI8VNW.#ZH2.NLD.EU #:48684 [HvHolland] FBB7.00g24
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA29603 ; Fri, 04 Feb 00 00:44:11 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.70/7.5.3) with SMTP
id AA00017781 ; Thu, 03 Feb 2000 21:01:33 MET
Date: Thu, 03 Feb 00 20:58:34 MET
Message-Id: <hd_2000_34B>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 2000/34B
X-BBS-Msg-Type: B
interrupt at 4 or 8 characters in the receive FIFO (especially with
Windows, where interrupt latency is a problem), the real-life number of
characters is a bit less than 32, but certainly 17.
This is a UART issue, not a terminal program issue. Your terminal program
can (via a system call) disable the FIFO, but that would defeat its
purpose.
This has *nothing* to do with sync modes.
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, 01 Feb 2000 23:18:18 GMT
From: "Hank Oredson" <horedson@att.net>
Subject: Kantroncs bugs?
"Rob Janssen" <nomail@rob.knoware.nl> wrote in message
news:slrn89e6ul.9gb.nomail@linux.pe1chl.ampr.org...
> 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.
Consider RTS/CTS vs. DSR/DTR vs. ^S/^Q.
Many different behaviors are possible, depending on how well the
terminal program is written, and whether it is configured to properly
deal with the connected device, and whether ALL the control lines
are connected, or some subset. HP published an exceptionally good
book on these topics.
The above only starts to scratch the surface.
--
... Hank
http://horedson.home.att.net
>.
------------------------------
Date: Wed, 02 Feb 2000 19:23:47 GMT
From: "Hank Oredson" <horedson@att.net>
Subject: Kantroncs bugs?
"Rob Janssen" <nomail@rob.knoware.nl> wrote in message
news:slrn89g6e9.hmv.nomail@linux.pe1chl.ampr.org...
> Hank Oredson <horedson@att.net> wrote:
>
> >However it is easy, as I've mentioned, to deal with this in the terminal
> >program, and most are able to handle the situation without any trouble.
>
> >...
>
> >But this is a "terminal program" issue, nothing to do with the TNCs or
> >other controllers. They "do what they do", and the terminal program
> >must take account of whatever that might be. Ain't no harder than
> >BISYNC, UDLC, 2780/3790, etc. ad nauseum.
>
> THat is not true, Hank. With a 16550A with 16-byte output FIFO setting,
> there is nothing your terminal program can do to avoid sending 17 more
> characters after CTS is lowered, or at worst case 32 more characters when
> a XOFF arrives, and ends up in the nearly-filled FIFO when only one
> interrupt per FIFO load is taken. As it is customary to issue a receive
> interrupt at 4 or 8 characters in the receive FIFO (especially with
> Windows, where interrupt latency is a problem), the real-life number of
> characters is a bit less than 32, but certainly 17.
>
> This is a UART issue, not a terminal program issue. Your terminal program
> can (via a system call) disable the FIFO, but that would defeat its
> purpose.
>
> This has *nothing* to do with sync modes.
Like I said, it is a terminal program issue.
The use of the FIFO can be disabled, and any reasonable terminal
program (all the ones I use, for example) can deal with this.
The connected device "does what it does".
You need to deal with that, whether it is a requirement for software
flow control, the number of sync characters to be sent, whether local
or remote echo is to be used, and whether the UART FIFO should
be enabled, disabled, set to 8 char mode, and any other parameters
the connected device requires.
I've had *no* problems using any of the TNCs, as mentioned in a
previous message. Pretending the problem cannot be solved locally
is just a waste of time. Set up your terminal program to deal with
whatever the connected device needs, and stop whinging.
Won't even talk about reasonable ISR architecture ...
--
... Hank
http://horedson.home.att.net
>.
------------------------------
Date: Thu, 03 Feb 2000 09:24:22 +0100
From: Alexander Kurpiers <a.kurpiers@uet.tu-darmstadt.de>
Subject: Kantroncs bugs?
This is a multi-part message in MIME format.
--------------88B5B896161F059E369B6099
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Hank Oredson wrote:
> > THat is not true, Hank. With a 16550A with 16-byte output FIFO setti=
ng,
> > there is nothing your terminal program can do to avoid sending 17 mor=
e
> > characters after CTS is lowered, or at worst case 32 more characters =
when
> > a XOFF arrives, and ends up in the nearly-filled FIFO when only one
> > interrupt per FIFO load is taken. As it is customary to issue a rece=
ive
> > interrupt at 4 or 8 characters in the receive FIFO (especially with
> > Windows, where interrupt latency is a problem), the real-life number =
of
> > characters is a bit less than 32, but certainly 17.
> >
> > This is a UART issue, not a terminal program issue. Your terminal pr=
ogram
> > can (via a system call) disable the FIFO, but that would defeat its
> > purpose.
Even that all would make no difference, if flow-control is implemented
on the TNC/modem/KAM or what-so-ever in the right way. Some people still
think flow-control means: once my buffer is completely full, I have to
lower CTS, because I can=B4t take anything more. The same with AX.25: RNR=
To be continued in digest: hd_2000_34C
Read previous mail | Read next mail
| |
