Messages in this thread | | | Subject | Re: serial.c (half duplex support) | Date | Sat, 23 Oct 1999 16:47:03 +0100 | From | David Woodhouse <> |
| |
rhw@MemAlpha.CX said: > I don't have much experience of half duplex protocols outside of the > amateur radio world, but there are certain hooks that appear to be > obvious starting points, as follows:
> 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/
| |