Allan,
(still CC Claudio)
Forgive me for replying to myself... I'd like to look into this further
(as time permits), but would like some more input on the preferred way of
adding this kind of functionality.
On Sun, 20 Feb 2011 01:06:17 +0100, Frode Tennebà <frode@xxxxxxxxxxx>
wrote:
On Sat, 19 Feb 2011 17:56:11 +0100, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
wrote:
full-duplex, terminating DTE (which really is RS-422). Hence, as I
understands it, the current naming/implementation is a bit misleading -
and I can very well be wrong on this. :) (BTW: How can the driver
revert back to RS-232?)
That's usually the case - interfaces grow. The important thing is to
have
one interface in common and with commonality for the common features.
Right. So, for the existing implementation of TIOC[S|G]RS485, which
RS-485 mode does it actually map to for the two devices which currently
implements this?
The current IOCTL, TIOSRS485, has the functionality to set RS-485
functionality for a device to on or off. There are two problems with this
approach:
1) On: The way I understand it RS-485 is more than just on/off. There
are several different modes of operations including:
- Full duplex
- Half duplex, auto
- Half duplex, RTS control
- Half duplex, DTR control
In addition some UARTs also supports local echo and local termination.
2) Off: This is also unambiguous: Most (all?) UARTs which supports
RS-485 also supports RS-422 and RS-232, but I have seen no separate "off"
state.
Right now TIOCSRS485 really only deals with some of the less flexible
devices so we've always know it would need a bit of extending.
OK. I was not aware that this already has received some thought by
some. :) What is the preferred way of doing this? Add additional
IOCTLs, or extend the serial_rs485 struct to include UART modes?
And how is/should the RS-422 and RS-232 mode switching [be] handled? A
different set of IOCTLs?
To allow for the complexity described above, I propose a rename of the
current IOCTLs and control struct, or a completely new set of IOCTLs and
structs to avoid incompatibilities if this is a concern (which I believe
it is, but I also understand that there is an aversion agains new
IOCTLs). I think we need the following IOCTLs:
TIOCSSERIAL
TIOCGSERIAL
and either extend the serial_struct type or introduce a new one, e.g.
serial_ctrl, with the following components:
/*
* SER_AUTO_TOGGLE Multidrop, i.e. TX driver is automatically
enabled
* before data is transmitted, then disabled
immediately
* after all data has been transmitted.
* SER_RTS_CONTROL RTS (Request To Send) is used to control the TX
* driver.
* SER_DTR_CONTROL DTR (Data Terminal Ready) is used to control
the TX
* driver.
*
* SER_NO_ECHO Receiver only active when no TX.
* SER_LOCAL_ECHO Receiver will always be active.
*
* SER_NO_TERMINATION Device has no termination ("middle unit" for
RS485.
* SER_LOCAL_TERMINATION Device has termination ("end unit" for RS485.
*
* SER_SLAVE The device is slave.
* SER_MASTER Receiver will always be active.
*
* SER_NO_SIGNALING RTS or DTR is enabled just before send.
* SER_SIGNAL_BEFORE_SEND RTS or DTR is enabled just before send.
* SER_SIGNAL_AFTER_SEND RTS or DTR is enabled just after send.
*/
struct serial_ctrl {
__u8 uart_mode; /* serial UART mode */
#define SER_DISABLED (1 << 0)
#define SER_RS232 (1 << 1)
#define SER_RS422 (1 << 2)
#define SER_RS485 (1 << 3)
__u8 duplex; /* duplex mode */
#define SER_HALF_DUPLEX (1 << 0)
#define SER_FULL_DUPLEX (1 << 1)
__u8 duplex_mode; /* iff half duplex */
#define SER_AUTO_TOGGLE (1 << 0)
#define SER_RTS_CONTROL (1 << 1)
#define SER_DTR_CONTROL (1 << 2)
__u8 echo; /* echo mode */
#define SER_NO_ECHO (1 << 0)
#define SER_LOCAL_ECHO (1 << 1)
__u8 termination; /* termination mode */
#define SER_NO_TERMINATION (1 << 0)
#define SER_LOCAL_TERMINATION (1 << 1)
__u8 rs485_class; /* iff RS485 */
#define SER_SLAVE (1 << 0)
#define SER_MASTER (1 << 1)
__u8 signaling_mode /* signaling mode */
#define SER_NO_SIGNALING (1 << 0)
#define SER_SIGNAL_BEFORE_SEND (1 << 1)
#define SER_SIGNAL_AFTER_SEND (1 << 2)
/* Milliseconds between RTS/DTR is enabled and data is sent */
__u32 delay_send_after_signal;
};
Should there be anything reserved at the end? I have probably forgotten
something, but it could be a first draft.
There are some overlaps here, e.g. RS-422 could be seen as the same state
as RS-485 with full duplex as master (termination accordingly).
But I'm on thin ice here. And since I have no previous knowledge of this
part of the kernel nor any of the devices which currently supports RS-485,
nor I'm not entirely sure how the Cris and Atmel devices maps to what I
have described above, I would like some consensus before proceeding.
-Frode
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
