On Mon, 3 Apr 2000, Niclas Hedhman wrote:

> 
> If I am not mistaken, the Parity, Overrun and Framing Error bits are not
> representing the last byte, but any byte since last time the LSR was read. I.e
> upon reading LSR is cleared.
> 
> And as Lawson says. "Spacing condition" is called BREAK, sending BREAK or breaking
> condition. A permanent LOW level (-12V) on the RS232 side.
> 

As far as I know -12V is logical HIGH on the data lines of
RS232.

> Personally I think that the hardware is slightly wrongly designed. What we did was
> to AND the TxShiftEmpty pin (I believe it is available on the 8250 series as well,
> although we never used it) with the RTS pin to generate the actual RTS signal. The
> result from a programming point of view, doing RS485, was;
> a) Keep filling the THR until the whole packet is sent.
> b) Pull the RTS low after last byte is stored.
> 
> And no matter how deep the FIFO is, the RTS will nicely be lowered after the last
> character has been shifted out. IMO, this should be optionally available in the
> UART chips, to reduce the CPU load significantly.

Unfortunately most people are not willing or able to work in
their computer with a soldering iron. And additionally the
"modern" main boards with their integrated chipsets leave you no
chance at all.

This design of UART chips, namely leaving the work of doing
hardware handshake either to (external) hardware or software, is
common to most of the "unintelligent" chips dated from 1980 and
their "compatible" successors.

The developers of the IBM-PC choosed the latter, I assume the
additional AND-Gate (74LS08) was to expensive and they could not
imagine about data rates higher than 2400 bps (although they
implemented an interface up to 9600 bps). 
BASIC was fast enough to talk to 300 bps acousticcouplers in
these days, you see?


I agree, but this change of hardware will probably never happen.

Regards,

        Gerald Emig

> 

> Niclas
> 
> [EMAIL PROTECTED] wrote:
> 
> > Hi folks!
> >
> > After experiencing some difficulties with programming the serial interface
> > (not standard stuff. that should be explained sufficient in the Serial
> > HOWTO and the Serial Programming HOWTO.)
> > and to take into account the growing importance of home automation with
> > its 'unusual' interfaces, I thought it is now necessary to describe UART
> > hardware in a small HOWTO-manual.
> > I have attached a proposal. Any comments are highly appreciated!
> > Think of I'm not a native english speaker :-)
> >
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to [EMAIL PROTECTED]
> 

--
++++++++++++
+ Gerald Emig, Engelstr. 17, D - 66564 Ottweiler
+ Tel.+Fax +49 6858 6197
+ http://sites.inka.de/heisch/
++++++++++++


-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]

Reply via email to