lkml.org 
[lkml]   [1999]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: serial.c (half duplex support)
Hi David.

>> 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.

I understood there was already a flag proposed to indicate half or
full duplex, separate to the above?

> And perhaps FULL-TO-RX and FULL-TO-TX.

If we're going to combine the two flags, I would suggest that the
following additional states be accounted for:

e. RX-TO-FULL - Switchback only allowed from receive mode.

f. FULL-DUPLEX - Current behaviour, default state.

g. FULL-TO-RX - On switching to half duplex, the natural target
state would normally be RX, and if a TX startup
is required, that can already be achieved.

h. NO-PORT - The specified serial port does not exist.

That gives a total of 8 states, so no unused values.

>> 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.

That sounds like part of your particular line discipline, rather than
a generic part of all half duplex protocols?

> 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.

So there's multiple senders on the other end of the wire? In that
case, each message will need to contain both the sender's and the
recipient's address - have a look at the AX.25 protocol, available
from...

http://www.tapr.org/tapr/html/Fax25.html

...which shows how this has been handled for many years in the amateur
radio arena. Alternatively, have a look at the various networking
protocols used within Linux itself - after all, as soon as you have
three or more systems connected to the same wire, you have a network.

> I need to be able to tell where the first packet ends and the
> next begins.

That should be part of the RS485 protocol itself, in one of two
formats:

1. Each packet forms a single message. In this form, the
message format should provide delimiting facilities of
some form, either specifying a particular character to
indicate END-OF-MSG (CR or LF often used), or by using
an explicit length field near the beginning of each of
the various message formats (see XMODEM).

2. Each packet contains a byte stream from a particular
sender. In this form, there should be a particular bit
or byte pattern that delimits the individual messages
AND each message should contain BOTH the sender's and
the recipient's address.

Again, refer to the sources mentioned above.

> 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.

Neither do I, but I would assume that they will do a reasonably decent
job if given the opportunity. After all, that's the whole aim of
interrupt driven I/O in the first place.

Best wishes from Riley.

PS: The kernel versions page is now back online at the URL below, and
includes separate sublists both for each kernel series, and for
each year of development.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.047 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site