>
> 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.
My doc says parity/framing error at receiving the last byte. I have not
the equipment to check this. But the LSR have to be read frequently to
check if there's a byte, so it should be the same, hm, at least with a
non-FIFO UART. Ok, I will change the HOWTO.
>
> And as Lawson says. "Spacing condition" is called BREAK, sending BREAK or
> breaking
> condition. A permanent LOW level (-12V) on the RS232 side.
My doc speaks of 'spacing condition', as opposite of 'marking condition'.
It's 2:1 for 'breaking condition' :-)
>
> 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.
Nice idea. It should be possible to add this with little electronic
knowledge.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]