> 1. Use of a half duplex protocol implies that the serial port
> has a flag indicating its state, with four valid states, as
> follows:
> a. RECEIVING - This port is currently receiving data, so
> anything to transmit is just queued until
> reception finishes.
> b. RX-TO-TX - This port is in the process of switching
> from reception to transmission of data.
> This would only occur when the receiver
> has been idle for a predefined length of
> time AND the transmit buffer is not empty.
> c. TRANSMITTING - This port is currently transmitting data,
> so is not able to receive anything.
> d. TX-TO-RX - This port is in the process of switching
> from transmission to reception of data.
Add an extra state FULL-DUPLEX, naturally. And perhaps FULL-TO-RX and
FULL-TO-TX.
> 2. Half duplex protocols are generally receiver driven, with
> a station wishing to transmit waiting for a clear channel.
> This suggests the first two hooks:
> a. A routine to be called to say "The receiver has not
> received any data for X units of time, and there is
> data waiting in the transmit buffer", with X being
> an attribute of the serial line, similar to those
> that already exist (such as close_delay). This would
> move the line into RX-TO-TX mode.
> b. A routine to be called to say "The transmitter has
> run out of data to transmit" which would move the
> line into TX-TO-RX mode.
> Comments?
Sounds like it should be almost good enough for my requirements.
I would need to convince myself that I could handle packetisation correctly.
An idle time of more than 27 bit times (3 chars) on the wire signifies the end
of an incoming packet, so the callback (a) would be necessary even when
there's nothing waiting to transmit. It also needs to give the current length
of the input buffer, or stick a marker in the buffer somehow - at the same
time as I receive this callback, I know that some machine somewhere else on
the RS485 bus will immediately start transmitting, before I have a chance to
clear the input buffer.
I need to be able to tell where the first packet ends and the next begins.
Also, I'd have to be sure that when sending packets of up to 256 octets,
there's no idle time between them. I don't know how efficient the current
drivers are at keeping the output FIFO busy.
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 7976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/