Hi all,
some time ago I've been asked (by both Wolfram and Philippe) to
provide some minimal documentation about the usage of the RS485
interface.
Here is the document (updated with the very last changes in the
interface).
Best regards,
Claudio
Documentation about RS485 serial communications.
Signed-off-by: Claudio Scordino <[email protected]>
---
Documentation/serial/00-INDEX | 2 +
Documentation/serial/serial-rs485.txt | 123 +++++++++++++++++++++++++++++++++
2 files changed, 125 insertions(+), 0 deletions(-)
create mode 100644 Documentation/serial/serial-rs485.txt
diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
index 07dcdb0..e09468a 100644
--- a/Documentation/serial/00-INDEX
+++ b/Documentation/serial/00-INDEX
@@ -14,6 +14,8 @@ riscom8.txt
- notes on using the RISCom/8 multi-port serial driver.
rocket.txt
- info on the Comtrol RocketPort multiport serial driver.
+serial-rs485.txt
+ - info about RS485 structures and support in the kernel.
specialix.txt
- info on hardware/driver for specialix IO8+ multiport serial card.
stallion.txt
diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
new file mode 100644
index 0000000..f594831
--- /dev/null
+++ b/Documentation/serial/serial-rs485.txt
@@ -0,0 +1,123 @@
+ RS485 SERIAL COMMUNICATIONS
+
+1. INTRODUCTION
+
+ EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
+ electrical characteristics of drivers and receivers for use in balanced
+ digital multipoint systems.
+ This standard is widely used for communications in industrial automation
+ because it can be used effectively over long distances and in electrically
+ noisy environments.
+ Even though the data is transmitted over a 2-wire twisted pair bus, all
+ EIA-485 transceivers interpret the voltage levels of the differential
+ signals with respect to a third common voltage. Without this common
+ reference, a set of transceivers may interpret the differential signals
+ incorrectly.
+ See [1] for more information.
+
+
+2. HARDWARE-RELATED CONSIDERATIONS
+
+ Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working both
+ as RS232 and RS485. For these microcontrollers, the Linux driver should be
+ able of working in both modes, and proper ioctls (see later) should be made
+ available at user-level to allow switching from one mode to the other, and
+ viceversa.
+
+ On some other CPUs (e.g., Freescale imx25) the RS485 transceiver is not
+ integrated inside the microcontroller itself. Therefore, manufacturers who
+ use these microcontrollers to produce embedded boards need to connect an
+ external transceiver to some pin of the CPU.
+ On these architectures, therefore, no assumptions can be done at the
+ CPU-level about the presence of a RS485 transceiver, because the connection
+ (if any) is done outside the microcontroller. Moreover, even in case of
+ RS485 transceiver, the manufacturer is free to choose the CPU pin used for
+ the connection.
+
+
+3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+
+ The Linux kernel provides the serial_rs485 structure (see [2]) to handle
+ RS485 communications. This data structure is used to set and configure RS485
+ parameters in the platform data and in ioctls.
+
+ Any driver for devices capable of working both as RS232 and RS485 should
+ provide at least the following ioctls:
+
+ - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
+ to enable/disable RS485 mode from user-space
+
+ - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
+ to get RS485 mode from kernel-space (i.e., driver) to user-space.
+
+ In other words, the serial driver should contain a code similar to the next
+ one:
+
+ static struct uart_ops atmel_pops = {
+ /* ... */
+ .ioctl = handle_ioctl,
+ };
+
+ static int handle_ioctl(struct uart_port *port,
+ unsigned int cmd,
+ unsigned long arg)
+ {
+ struct serial_rs485 rs485conf;
+
+ switch (cmd) {
+ case TIOCSRS485:
+ if (copy_from_user(&rs485conf,
+ (struct serial_rs485 *) arg,
+ sizeof(rs485conf)))
+ return -EFAULT;
+
+ /* ... */
+ break;
+
+ case TIOCGRS485:
+ if (copy_to_user((struct serial_rs485 *) arg,
+ ...,
+ sizeof(rs485conf)))
+ return -EFAULT;
+ /* ... */
+ break;
+
+ /* ... */
+ }
+ }
+
+
+4. USAGE FROM USER-LEVEL
+
+ From user-level, RS485 configuration can be get/set using the previous
+ ioctls. For instance, to set RS485 you can use the following code:
+
+ #include <linux/serial.h>
+
+ /* Driver-specific ioctls: */
+ #define TIOCGRS485 0x542E
+ #define TIOCSRS485 0x542F
+
+ /* Open specific device: */
+ int fd = open ("/dev/mydevice", O_RDWR);
+ struct serial_rs485 rs485conf;
+
+ /* Set RS485 mode: */
+ rs485conf.flags |= SER_RS485_ENABLED;
+
+ /* Set rts delay before send, if needed: */
+ rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+ rs485conf.delay_rts_before_send = ...;
+
+ /* Set rts delay after send, if needed: */
+ rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
+ rs485conf.delay_rts_after_send = ...;
+
+ ioctl (fd, TIOCSRS485, &rs485conf);
+
+ close (fd);
+
+5. REFERENCES
+
+ [1] http://en.wikipedia.org/wiki/Rs485
+ [2] include/linux/serial.h
--
1.6.0.4
On Wed, Aug 11, 2010 at 11:26:23AM +0200, Claudio Scordino wrote:
> Hi all,
>
> some time ago I've been asked (by both Wolfram and Philippe) to
> provide some minimal documentation about the usage of the RS485
> interface.
>
> Here is the document (updated with the very last changes in the
> interface).
Thanks
>
> Best regards,
>
> Claudio
>
>
> Documentation about RS485 serial communications.
>
> Signed-off-by: Claudio Scordino <[email protected]>
> ---
> Documentation/serial/00-INDEX | 2 +
> Documentation/serial/serial-rs485.txt | 123 +++++++++++++++++++++++++++++++++
> 2 files changed, 125 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/serial/serial-rs485.txt
>
> diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
> index 07dcdb0..e09468a 100644
> --- a/Documentation/serial/00-INDEX
> +++ b/Documentation/serial/00-INDEX
> @@ -14,6 +14,8 @@ riscom8.txt
> - notes on using the RISCom/8 multi-port serial driver.
> rocket.txt
> - info on the Comtrol RocketPort multiport serial driver.
> +serial-rs485.txt
> + - info about RS485 structures and support in the kernel.
> specialix.txt
> - info on hardware/driver for specialix IO8+ multiport serial card.
> stallion.txt
> diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
> new file mode 100644
> index 0000000..f594831
> --- /dev/null
> +++ b/Documentation/serial/serial-rs485.txt
> @@ -0,0 +1,123 @@
> + RS485 SERIAL COMMUNICATIONS
> +
> +1. INTRODUCTION
> +
> + EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
> + electrical characteristics of drivers and receivers for use in balanced
> + digital multipoint systems.
> + This standard is widely used for communications in industrial automation
> + because it can be used effectively over long distances and in electrically
> + noisy environments.
> + Even though the data is transmitted over a 2-wire twisted pair bus, all
> + EIA-485 transceivers interpret the voltage levels of the differential
> + signals with respect to a third common voltage. Without this common
> + reference, a set of transceivers may interpret the differential signals
> + incorrectly.
> + See [1] for more information.
> +
> +
> +2. HARDWARE-RELATED CONSIDERATIONS
> +
> + Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working both
> + as RS232 and RS485. For these microcontrollers, the Linux driver should be
> + able of working in both modes, and proper ioctls (see later) should be made
> + available at user-level to allow switching from one mode to the other, and
> + viceversa.
> +
> + On some other CPUs (e.g., Freescale imx25) the RS485 transceiver is not
> + integrated inside the microcontroller itself. Therefore, manufacturers who
> + use these microcontrollers to produce embedded boards need to connect an
> + external transceiver to some pin of the CPU.
> + On these architectures, therefore, no assumptions can be done at the
> + CPU-level about the presence of a RS485 transceiver, because the connection
> + (if any) is done outside the microcontroller. Moreover, even in case of
> + RS485 transceiver, the manufacturer is free to choose the CPU pin used for
> + the connection.
> +
> +
> +3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
> +
> + The Linux kernel provides the serial_rs485 structure (see [2]) to handle
> + RS485 communications. This data structure is used to set and configure RS485
> + parameters in the platform data and in ioctls.
> +
> + Any driver for devices capable of working both as RS232 and RS485 should
> + provide at least the following ioctls:
> +
> + - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
> + to enable/disable RS485 mode from user-space
> +
> + - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
> + to get RS485 mode from kernel-space (i.e., driver) to user-space.
> +
> + In other words, the serial driver should contain a code similar to the next
> + one:
> +
> + static struct uart_ops atmel_pops = {
> + /* ... */
> + .ioctl = handle_ioctl,
> + };
> +
> + static int handle_ioctl(struct uart_port *port,
> + unsigned int cmd,
> + unsigned long arg)
> + {
> + struct serial_rs485 rs485conf;
> +
> + switch (cmd) {
> + case TIOCSRS485:
> + if (copy_from_user(&rs485conf,
> + (struct serial_rs485 *) arg,
> + sizeof(rs485conf)))
> + return -EFAULT;
> +
> + /* ... */
> + break;
> +
> + case TIOCGRS485:
> + if (copy_to_user((struct serial_rs485 *) arg,
> + ...,
> + sizeof(rs485conf)))
> + return -EFAULT;
> + /* ... */
> + break;
> +
> + /* ... */
> + }
> + }
> +
> +
> +4. USAGE FROM USER-LEVEL
> +
> + From user-level, RS485 configuration can be get/set using the previous
> + ioctls. For instance, to set RS485 you can use the following code:
> +
> + #include <linux/serial.h>
> +
> + /* Driver-specific ioctls: */
> + #define TIOCGRS485 0x542E
> + #define TIOCSRS485 0x542F
Should those defines not come from a linux header file ?
> +
> + /* Open specific device: */
> + int fd = open ("/dev/mydevice", O_RDWR);
> + struct serial_rs485 rs485conf;
> +
> + /* Set RS485 mode: */
> + rs485conf.flags |= SER_RS485_ENABLED;
> +
> + /* Set rts delay before send, if needed: */
> + rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
> + rs485conf.delay_rts_before_send = ...;
> +
> + /* Set rts delay after send, if needed: */
> + rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
> + rs485conf.delay_rts_after_send = ...;
> +
> + ioctl (fd, TIOCSRS485, &rs485conf);
I surmise that all the real work, the read() and write() system calls,
must come here, before the close() system call.
> +
> + close (fd);
> +
> +5. REFERENCES
> +
> + [1] http://en.wikipedia.org/wiki/Rs485
> + [2] include/linux/serial.h
> --
> 1.6.0.4
>
--
Philippe De Muyter phdm at macqel dot be Tel +32 27029044
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077
On Wed, 11 Aug 2010 11:26:23 +0200 Claudio Scordino wrote:
> Hi all,
>
> some time ago I've been asked (by both Wolfram and Philippe) to
> provide some minimal documentation about the usage of the RS485
> interface.
>
> Here is the document (updated with the very last changes in the
> interface).
>
> Best regards,
>
> Claudio
>
>
> Documentation about RS485 serial communications.
>
> Signed-off-by: Claudio Scordino <[email protected]>
> ---
> Documentation/serial/00-INDEX | 2 +
> Documentation/serial/serial-rs485.txt | 123 +++++++++++++++++++++++++++++++++
> 2 files changed, 125 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/serial/serial-rs485.txt
> diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
> new file mode 100644
> index 0000000..f594831
> --- /dev/null
> +++ b/Documentation/serial/serial-rs485.txt
> @@ -0,0 +1,123 @@
> + RS485 SERIAL COMMUNICATIONS
> +
...
> +
> +2. HARDWARE-RELATED CONSIDERATIONS
> +
> + Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working both
> + as RS232 and RS485. For these microcontrollers, the Linux driver should be
> + able of working in both modes, and proper ioctls (see later) should be made
should be able to work in both modes
or
should be made capable of working in both modes
> + available at user-level to allow switching from one mode to the other, and
> + viceversa.
vice versa.
> +
> + On some other CPUs (e.g., Freescale imx25) the RS485 transceiver is not
> + integrated inside the microcontroller itself. Therefore, manufacturers who
> + use these microcontrollers to produce embedded boards need to connect an
> + external transceiver to some pin of the CPU.
> + On these architectures, therefore, no assumptions can be done at the
> + CPU-level about the presence of a RS485 transceiver, because the connection
> + (if any) is done outside the microcontroller. Moreover, even in case of
> + RS485 transceiver, the manufacturer is free to choose the CPU pin used for
> + the connection.
> +
> +
> +3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
> +
> + The Linux kernel provides the serial_rs485 structure (see [2]) to handle
> + RS485 communications. This data structure is used to set and configure RS485
> + parameters in the platform data and in ioctls.
> +
> + Any driver for devices capable of working both as RS232 and RS485 should
> + provide at least the following ioctls:
> +
> + - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
> + to enable/disable RS485 mode from user-space
> +
> + - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
> + to get RS485 mode from kernel-space (i.e., driver) to user-space.
TIOC[SG]RS485 are #defined in <asm-generic/ioctls.h>, so
#include <asm-generic/ioctls.h>
here and/or below (in userspace program).
> + In other words, the serial driver should contain a code similar to the next
contain code similar to this:
> + one:
> +
> + static struct uart_ops atmel_pops = {
> + /* ... */
> + .ioctl = handle_ioctl,
> + };
> +
> + static int handle_ioctl(struct uart_port *port,
> + unsigned int cmd,
> + unsigned long arg)
> + {
> + struct serial_rs485 rs485conf;
> +
> + switch (cmd) {
> + case TIOCSRS485:
Coding style: we put switch and case at the same indent level.
> + if (copy_from_user(&rs485conf,
> + (struct serial_rs485 *) arg,
> + sizeof(rs485conf)))
> + return -EFAULT;
> +
> + /* ... */
> + break;
> +
> + case TIOCGRS485:
> + if (copy_to_user((struct serial_rs485 *) arg,
> + ...,
> + sizeof(rs485conf)))
> + return -EFAULT;
> + /* ... */
> + break;
> +
> + /* ... */
> + }
> + }
> +
> +
> +4. USAGE FROM USER-LEVEL
> +
> + From user-level, RS485 configuration can be get/set using the previous
> + ioctls. For instance, to set RS485 you can use the following code:
> +
> + #include <linux/serial.h>
> +
> + /* Driver-specific ioctls: */
> + #define TIOCGRS485 0x542E
> + #define TIOCSRS485 0x542F
> +
...
> +
> +5. REFERENCES
> +
> + [1] http://en.wikipedia.org/wiki/Rs485
> + [2] include/linux/serial.h
Thanks for the addition.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Hi Randy,
thank you for the feedback.
[...]
>
> TIOC[SG]RS485 are #defined in <asm-generic/ioctls.h>, so
> #include <asm-generic/ioctls.h>
> here and/or below (in userspace program).
>
I noticed that for some architectures (e.g., cris) these ioctls are defined also in arch/cris/include/asm/ioctls.h, and with different values with respect to the values defined on asm-generic/ioctls.h.
Therefore, I wasn't completely sure that the values defined in asm-generic are being used in every driver...
Best regards,
Claudio
----- Original Message -----
From: [email protected]
To: [email protected]
Sent: Wednesday, August 11, 2010 12:59:08 PM GMT -08:00 US/Canada Pacific
Subject: Re: [PATCH] Documentation about RS485 serial communications
Hi Randy,
thank you for the feedback.
[...]
>
> TIOC[SG]RS485 are #defined in <asm-generic/ioctls.h>, so
> #include <asm-generic/ioctls.h>
> here and/or below (in userspace program).
>
I noticed that for some architectures (e.g., cris) these ioctls are defined also in arch/cris/include/asm/ioctls.h, and with different values with respect to the values defined on asm-generic/ioctls.h.
Therefore, I wasn't completely sure that the values defined in asm-generic are being used in every driver...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Oh, OK, I see. Thanks for the info.
~Randy
Randy Dunlap ha scritto:
> On Wed, 11 Aug 2010 11:26:23 +0200 Claudio Scordino wrote:
>
>> Hi all,
>>
>> some time ago I've been asked (by both Wolfram and Philippe) to
>> provide some minimal documentation about the usage of the RS485
>> interface.
>>
[...]
>
> Thanks for the addition.
>
Hi all,
here is the document about RS485 with the requested additions.
If OK, somebody please provide for merging.
Best regards,
Claudio
Documentation about RS485 serial communications.
Signed-off-by: Claudio Scordino <[email protected]>
---
Documentation/serial/00-INDEX | 2 +
Documentation/serial/serial-rs485.txt | 126 +++++++++++++++++++++++++++++++++
2 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 Documentation/serial/serial-rs485.txt
diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
index 07dcdb0..e09468a 100644
--- a/Documentation/serial/00-INDEX
+++ b/Documentation/serial/00-INDEX
@@ -14,6 +14,8 @@ riscom8.txt
- notes on using the RISCom/8 multi-port serial driver.
rocket.txt
- info on the Comtrol RocketPort multiport serial driver.
+serial-rs485.txt
+ - info about RS485 structures and support in the kernel.
specialix.txt
- info on hardware/driver for specialix IO8+ multiport serial card.
stallion.txt
diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
new file mode 100644
index 0000000..93b029e
--- /dev/null
+++ b/Documentation/serial/serial-rs485.txt
@@ -0,0 +1,126 @@
+ RS485 SERIAL COMMUNICATIONS
+
+1. INTRODUCTION
+
+ EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
+ electrical characteristics of drivers and receivers for use in balanced
+ digital multipoint systems.
+ This standard is widely used for communications in industrial automation
+ because it can be used effectively over long distances and in electrically
+ noisy environments.
+ Even though the data is transmitted over a 2-wire twisted pair bus, all
+ EIA-485 transceivers interpret the voltage levels of the differential
+ signals with respect to a third common voltage. Without this common
+ reference, a set of transceivers may interpret the differential signals
+ incorrectly.
+ See [1] for more information.
+
+
+2. HARDWARE-RELATED CONSIDERATIONS
+
+ Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working both
+ as RS232 and RS485. For these microcontrollers, the Linux driver should be
+ made capable of working in both modes, and proper ioctls (see later) should
+ be made available at user-level to allow switching from one mode to the
+ other, and vice versa.
+
+ On some other CPUs (e.g., Freescale imx25) the RS485 transceiver is not
+ integrated inside the microcontroller itself. Therefore, manufacturers who
+ use these microcontrollers to produce embedded boards need to connect an
+ external transceiver to some pin of the CPU.
+ On these architectures, therefore, no assumptions can be done at the
+ CPU-level about the presence of a RS485 transceiver, because the connection
+ (if any) is done outside the microcontroller. Moreover, even in case of
+ RS485 transceiver, the manufacturer is free to choose the CPU pin used for
+ the connection.
+
+
+3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+
+ The Linux kernel provides the serial_rs485 structure (see [2]) to handle
+ RS485 communications. This data structure is used to set and configure RS485
+ parameters in the platform data and in ioctls.
+
+ Any driver for devices capable of working both as RS232 and RS485 should
+ provide at least the following ioctls:
+
+ - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
+ to enable/disable RS485 mode from user-space
+
+ - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
+ to get RS485 mode from kernel-space (i.e., driver) to user-space.
+
+ In other words, the serial driver should contain a code similar to the next
+ one:
+
+ static struct uart_ops atmel_pops = {
+ /* ... */
+ .ioctl = handle_ioctl,
+ };
+
+ static int handle_ioctl(struct uart_port *port,
+ unsigned int cmd,
+ unsigned long arg)
+ {
+ struct serial_rs485 rs485conf;
+
+ switch (cmd) {
+ case TIOCSRS485:
+ if (copy_from_user(&rs485conf,
+ (struct serial_rs485 *) arg,
+ sizeof(rs485conf)))
+ return -EFAULT;
+
+ /* ... */
+ break;
+
+ case TIOCGRS485:
+ if (copy_to_user((struct serial_rs485 *) arg,
+ ...,
+ sizeof(rs485conf)))
+ return -EFAULT;
+ /* ... */
+ break;
+
+ /* ... */
+ }
+ }
+
+
+4. USAGE FROM USER-LEVEL
+
+ From user-level, RS485 configuration can be get/set using the previous
+ ioctls. For instance, to set RS485 you can use the following code:
+
+ #include <linux/serial.h>
+
+ /* Driver-specific ioctls: */
+ #define TIOCGRS485 0x542E
+ #define TIOCSRS485 0x542F
+
+ /* Open your specific device (e.g., /dev/mydevice): */
+ int fd = open ("/dev/mydevice", O_RDWR);
+ struct serial_rs485 rs485conf;
+
+ /* Set RS485 mode: */
+ rs485conf.flags |= SER_RS485_ENABLED;
+
+ /* Set rts delay before send, if needed: */
+ rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+ rs485conf.delay_rts_before_send = ...;
+
+ /* Set rts delay after send, if needed: */
+ rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
+ rs485conf.delay_rts_after_send = ...;
+
+ ioctl (fd, TIOCSRS485, &rs485conf);
+
+ /* Use read() and write() syscalls here... */
+
+ /* Close the device when finished: */
+ close (fd);
+
+5. REFERENCES
+
+ [1] http://en.wikipedia.org/wiki/Rs485
+ [2] include/linux/serial.h
--
1.6.0.4
On 08/14/10 05:50, Claudio Scordino wrote:
> Randy Dunlap ha scritto:
>> On Wed, 11 Aug 2010 11:26:23 +0200 Claudio Scordino wrote:
>>
>>> Hi all,
>>>
>>> some time ago I've been asked (by both Wolfram and Philippe) to
>>> provide some minimal documentation about the usage of the RS485
>>> interface.
>>>
>
> [...]
>
>>
>> Thanks for the addition.
>>
>
> Hi all,
>
> here is the document about RS485 with the requested additions.
>
> If OK, somebody please provide for merging.
I would expect GregKH to merge it.
Acked-by: Randy Dunlap <[email protected]>
Thanks.
> Best regards,
>
> Claudio
>
>
> Documentation about RS485 serial communications.
>
> Signed-off-by: Claudio Scordino <[email protected]>
> ---
> Documentation/serial/00-INDEX | 2 +
> Documentation/serial/serial-rs485.txt | 126 +++++++++++++++++++++++++++++++++
> 2 files changed, 128 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/serial/serial-rs485.txt
>
> diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
> index 07dcdb0..e09468a 100644
> --- a/Documentation/serial/00-INDEX
> +++ b/Documentation/serial/00-INDEX
> @@ -14,6 +14,8 @@ riscom8.txt
> - notes on using the RISCom/8 multi-port serial driver.
> rocket.txt
> - info on the Comtrol RocketPort multiport serial driver.
> +serial-rs485.txt
> + - info about RS485 structures and support in the kernel.
> specialix.txt
> - info on hardware/driver for specialix IO8+ multiport serial card.
> stallion.txt
> diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
> new file mode 100644
> index 0000000..93b029e
> --- /dev/null
> +++ b/Documentation/serial/serial-rs485.txt
> @@ -0,0 +1,126 @@
> + RS485 SERIAL COMMUNICATIONS
> +
> +1. INTRODUCTION
> +
> + EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
> + electrical characteristics of drivers and receivers for use in balanced
> + digital multipoint systems.
> + This standard is widely used for communications in industrial automation
> + because it can be used effectively over long distances and in electrically
> + noisy environments.
> + Even though the data is transmitted over a 2-wire twisted pair bus, all
> + EIA-485 transceivers interpret the voltage levels of the differential
> + signals with respect to a third common voltage. Without this common
> + reference, a set of transceivers may interpret the differential signals
> + incorrectly.
> + See [1] for more information.
> +
> +
> +2. HARDWARE-RELATED CONSIDERATIONS
> +
> + Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working both
> + as RS232 and RS485. For these microcontrollers, the Linux driver should be
> + made capable of working in both modes, and proper ioctls (see later) should
> + be made available at user-level to allow switching from one mode to the
> + other, and vice versa.
> +
> + On some other CPUs (e.g., Freescale imx25) the RS485 transceiver is not
> + integrated inside the microcontroller itself. Therefore, manufacturers who
> + use these microcontrollers to produce embedded boards need to connect an
> + external transceiver to some pin of the CPU.
> + On these architectures, therefore, no assumptions can be done at the
> + CPU-level about the presence of a RS485 transceiver, because the connection
> + (if any) is done outside the microcontroller. Moreover, even in case of
> + RS485 transceiver, the manufacturer is free to choose the CPU pin used for
> + the connection.
> +
> +
> +3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
> +
> + The Linux kernel provides the serial_rs485 structure (see [2]) to handle
> + RS485 communications. This data structure is used to set and configure RS485
> + parameters in the platform data and in ioctls.
> +
> + Any driver for devices capable of working both as RS232 and RS485 should
> + provide at least the following ioctls:
> +
> + - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
> + to enable/disable RS485 mode from user-space
> +
> + - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
> + to get RS485 mode from kernel-space (i.e., driver) to user-space.
> +
> + In other words, the serial driver should contain a code similar to the next
> + one:
> +
> + static struct uart_ops atmel_pops = {
> + /* ... */
> + .ioctl = handle_ioctl,
> + };
> +
> + static int handle_ioctl(struct uart_port *port,
> + unsigned int cmd,
> + unsigned long arg)
> + {
> + struct serial_rs485 rs485conf;
> +
> + switch (cmd) {
> + case TIOCSRS485:
> + if (copy_from_user(&rs485conf,
> + (struct serial_rs485 *) arg,
> + sizeof(rs485conf)))
> + return -EFAULT;
> +
> + /* ... */
> + break;
> +
> + case TIOCGRS485:
> + if (copy_to_user((struct serial_rs485 *) arg,
> + ...,
> + sizeof(rs485conf)))
> + return -EFAULT;
> + /* ... */
> + break;
> +
> + /* ... */
> + }
> + }
> +
> +
> +4. USAGE FROM USER-LEVEL
> +
> + From user-level, RS485 configuration can be get/set using the previous
> + ioctls. For instance, to set RS485 you can use the following code:
> +
> + #include <linux/serial.h>
> +
> + /* Driver-specific ioctls: */
> + #define TIOCGRS485 0x542E
> + #define TIOCSRS485 0x542F
> +
> + /* Open your specific device (e.g., /dev/mydevice): */
> + int fd = open ("/dev/mydevice", O_RDWR);
> + struct serial_rs485 rs485conf;
> +
> + /* Set RS485 mode: */
> + rs485conf.flags |= SER_RS485_ENABLED;
> +
> + /* Set rts delay before send, if needed: */
> + rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
> + rs485conf.delay_rts_before_send = ...;
> +
> + /* Set rts delay after send, if needed: */
> + rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
> + rs485conf.delay_rts_after_send = ...;
> +
> + ioctl (fd, TIOCSRS485, &rs485conf);
> +
> + /* Use read() and write() syscalls here... */
> +
> + /* Close the device when finished: */
> + close (fd);
> +
> +5. REFERENCES
> +
> + [1] http://en.wikipedia.org/wiki/Rs485
> + [2] include/linux/serial.h
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Sun, Aug 15, 2010 at 03:02:57PM -0700, Randy Dunlap wrote:
> On 08/14/10 05:50, Claudio Scordino wrote:
> > diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
> > new file mode 100644
> > index 0000000..93b029e
> > --- /dev/null
> > +++ b/Documentation/serial/serial-rs485.txt
> > @@ -0,0 +1,126 @@
> > + RS485 SERIAL COMMUNICATIONS
> > +
> > +1. INTRODUCTION
> > +
> > + EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
> > + electrical characteristics of drivers and receivers for use in balanced
> > + digital multipoint systems.
> > + This standard is widely used for communications in industrial automation
> > + because it can be used effectively over long distances and in electrically
> > + noisy environments.
> > + Even though the data is transmitted over a 2-wire twisted pair bus, all
> > + EIA-485 transceivers interpret the voltage levels of the differential
> > + signals with respect to a third common voltage. Without this common
> > + reference, a set of transceivers may interpret the differential signals
> > + incorrectly.
> > + See [1] for more information.
There are devices on the market which are fully isolating RS485
transceivers which just take the A/B connections, measuring the
differential voltage, and provide you with the TXD/RXD TTL signals
for your UART.
Also note that [1] appears a little confused about the number of pins
required for RS485 - it says two, and then lists three pins. I don't
think you can use this as being supportive of the requirement for three
connections - and as there are these fully isolating transceivers...
> > +4. USAGE FROM USER-LEVEL
> > +
> > + From user-level, RS485 configuration can be get/set using the previous
> > + ioctls. For instance, to set RS485 you can use the following code:
> > +
> > + #include <linux/serial.h>
> > +
> > + /* Driver-specific ioctls: */
> > + #define TIOCGRS485 0x542E
> > + #define TIOCSRS485 0x542F
> > +
> > + /* Open your specific device (e.g., /dev/mydevice): */
> > + int fd = open ("/dev/mydevice", O_RDWR);
> > + struct serial_rs485 rs485conf;
> > +
> > + /* Set RS485 mode: */
> > + rs485conf.flags |= SER_RS485_ENABLED;
> > +
> > + /* Set rts delay before send, if needed: */
> > + rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
> > + rs485conf.delay_rts_before_send = ...;
> > +
> > + /* Set rts delay after send, if needed: */
> > + rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
> > + rs485conf.delay_rts_after_send = ...;
> > +
> > + ioctl (fd, TIOCSRS485, &rs485conf);
Example code really should do things right, such as check for error
conditions - otherwise people will copy'n'paste this and assume that
the ioctl never fails.
> > +
> > + /* Use read() and write() syscalls here... */
> > +
> > + /* Close the device when finished: */
> > + close (fd);
> > +
> > +5. REFERENCES
> > +
> > + [1] http://en.wikipedia.org/wiki/Rs485
> > + [2] include/linux/serial.h
Le 24/10/2010 13:29, Claudio Scordino :
[..]
> Hi all,
>
> sorry for the misuse of the term "transceiver", and thank you
> for your corrections.
>
> Hopefully, this new version of the document is slightly better.
Hi all,
This documentation is floating around for some time now. Claudio has
enhanced it and it is maybe time to merge it in mainline...
So, can serial people include it in their tree (Greg?) or should it go
through another path?
Thanks to all of you.
Best regards,
> Many thanks,
>
> Claudio
>
>
> Documentation about RS485 serial communications
>
> Signed-off-by: Claudio Scordino <[email protected]>
> ---
> Documentation/serial/00-INDEX | 2 +
> Documentation/serial/serial-rs485.txt | 119 +++++++++++++++++++++++++++++++++
> 2 files changed, 121 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/serial/serial-rs485.txt
>
> diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
> index 07dcdb0..e09468a 100644
> --- a/Documentation/serial/00-INDEX
> +++ b/Documentation/serial/00-INDEX
> @@ -14,6 +14,8 @@ riscom8.txt
> - notes on using the RISCom/8 multi-port serial driver.
> rocket.txt
> - info on the Comtrol RocketPort multiport serial driver.
> +serial-rs485.txt
> + - info about RS485 structures and support in the kernel.
> specialix.txt
> - info on hardware/driver for specialix IO8+ multiport serial card.
> stallion.txt
> diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
> new file mode 100644
> index 0000000..40f09c6
> --- /dev/null
> +++ b/Documentation/serial/serial-rs485.txt
> @@ -0,0 +1,119 @@
> + RS485 SERIAL COMMUNICATIONS
> +
> +1. INTRODUCTION
> +
> + EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
> + electrical characteristics of drivers and receivers for use in balanced
> + digital multipoint systems.
> + This standard is widely used for communications in industrial automation
> + because it can be used effectively over long distances and in electrically
> + noisy environments.
> +
> +2. HARDWARE-RELATED CONSIDERATIONS
> +
> + Some CPUs (e.g., Atmel AT91) contain a built-in half-duplex mode capable of
> + automatically controlling line direction by toggling RTS. That can used to
> + control external half-duplex hardware like an RS485 transceiver or any
> + RS232-connected half-duplex device like some modems.
> +
> + For these microcontrollers, the Linux driver should be made capable of
> + working in both modes, and proper ioctls (see later) should be made
> + available at user-level to allow switching from one mode to the other, and
> + vice versa.
> +
> +3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
> +
> + The Linux kernel provides the serial_rs485 structure (see [1]) to handle
> + RS485 communications. This data structure is used to set and configure RS485
> + parameters in the platform data and in ioctls.
> +
> + Any driver for devices capable of working both as RS232 and RS485 should
> + provide at least the following ioctls:
> +
> + - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
> + to enable/disable RS485 mode from user-space
> +
> + - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
> + to get RS485 mode from kernel-space (i.e., driver) to user-space.
> +
> + In other words, the serial driver should contain a code similar to the next
> + one:
> +
> + static struct uart_ops atmel_pops = {
> + /* ... */
> + .ioctl = handle_ioctl,
> + };
> +
> + static int handle_ioctl(struct uart_port *port,
> + unsigned int cmd,
> + unsigned long arg)
> + {
> + struct serial_rs485 rs485conf;
> +
> + switch (cmd) {
> + case TIOCSRS485:
> + if (copy_from_user(&rs485conf,
> + (struct serial_rs485 *) arg,
> + sizeof(rs485conf)))
> + return -EFAULT;
> +
> + /* ... */
> + break;
> +
> + case TIOCGRS485:
> + if (copy_to_user((struct serial_rs485 *) arg,
> + ...,
> + sizeof(rs485conf)))
> + return -EFAULT;
> + /* ... */
> + break;
> +
> + /* ... */
> + }
> + }
> +
> +
> +4. USAGE FROM USER-LEVEL
> +
> + From user-level, RS485 configuration can be get/set using the previous
> + ioctls. For instance, to set RS485 you can use the following code:
> +
> + #include <linux/serial.h>
> +
> + /* Driver-specific ioctls: */
> + #define TIOCGRS485 0x542E
> + #define TIOCSRS485 0x542F
> +
> + /* Open your specific device (e.g., /dev/mydevice): */
> + int fd = open ("/dev/mydevice", O_RDWR);
> + if (fd < 0) {
> + /* Error handling. See errno. */
> + }
> +
> + struct serial_rs485 rs485conf;
> +
> + /* Set RS485 mode: */
> + rs485conf.flags |= SER_RS485_ENABLED;
> +
> + /* Set rts delay before send, if needed: */
> + rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
> + rs485conf.delay_rts_before_send = ...;
> +
> + /* Set rts delay after send, if needed: */
> + rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
> + rs485conf.delay_rts_after_send = ...;
> +
> + if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) {
> + /* Error handling. See errno. */
> + }
> +
> + /* Use read() and write() syscalls here... */
> +
> + /* Close the device when finished: */
> + if (close (fd) < 0) {
> + /* Error handling. See errno. */
> + }
> +
> +5. REFERENCES
> +
> + [1] include/linux/serial.h
--
Nicolas Ferre
On Wed, Nov 10, 2010 at 10:17:03AM +0100, Nicolas Ferre wrote:
> Le 24/10/2010 13:29, Claudio Scordino :
>
> [..]
>
> > Hi all,
> >
> > sorry for the misuse of the term "transceiver", and thank you
> > for your corrections.
> >
> > Hopefully, this new version of the document is slightly better.
>
> Hi all,
>
> This documentation is floating around for some time now. Claudio has
> enhanced it and it is maybe time to merge it in mainline...
>
> So, can serial people include it in their tree (Greg?) or should it go
> through another path?
I can take it, if someone resends it with the accumulated acks that I
think it gathered over the review cycle.
thanks,
greg k-h
Greg KH ha scritto:
> On Wed, Nov 10, 2010 at 10:17:03AM +0100, Nicolas Ferre wrote:
>> Le 24/10/2010 13:29, Claudio Scordino :
>>
>> [..]
>>
>>> Hi all,
>>>
>>> sorry for the misuse of the term "transceiver", and thank you
>>> for your corrections.
>>>
>>> Hopefully, this new version of the document is slightly better.
>> Hi all,
>>
>> This documentation is floating around for some time now. Claudio has
>> enhanced it and it is maybe time to merge it in mainline...
>>
>> So, can serial people include it in their tree (Greg?) or should it go
>> through another path?
>
> I can take it, if someone resends it with the accumulated acks that I
> think it gathered over the review cycle.
Here it is.
Thanks,
Claudio
Documentation about RS485 serial communications
Signed-off-by: Claudio Scordino <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Acked-by: Russell King <[email protected]>
Acked-by: Grant Edwards <[email protected]>
---
Documentation/serial/00-INDEX | 2 +
Documentation/serial/serial-rs485.txt | 119 +++++++++++++++++++++++++++++++++
2 files changed, 121 insertions(+), 0 deletions(-)
create mode 100644 Documentation/serial/serial-rs485.txt
diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
index 07dcdb0..e09468a 100644
--- a/Documentation/serial/00-INDEX
+++ b/Documentation/serial/00-INDEX
@@ -14,6 +14,8 @@ riscom8.txt
- notes on using the RISCom/8 multi-port serial driver.
rocket.txt
- info on the Comtrol RocketPort multiport serial driver.
+serial-rs485.txt
+ - info about RS485 structures and support in the kernel.
specialix.txt
- info on hardware/driver for specialix IO8+ multiport serial card.
stallion.txt
diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
new file mode 100644
index 0000000..40f09c6
--- /dev/null
+++ b/Documentation/serial/serial-rs485.txt
@@ -0,0 +1,119 @@
+ RS485 SERIAL COMMUNICATIONS
+
+1. INTRODUCTION
+
+ EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
+ electrical characteristics of drivers and receivers for use in balanced
+ digital multipoint systems.
+ This standard is widely used for communications in industrial automation
+ because it can be used effectively over long distances and in electrically
+ noisy environments.
+
+2. HARDWARE-RELATED CONSIDERATIONS
+
+ Some CPUs (e.g., Atmel AT91) contain a built-in half-duplex mode capable of
+ automatically controlling line direction by toggling RTS. That can used to
+ control external half-duplex hardware like an RS485 transceiver or any
+ RS232-connected half-duplex device like some modems.
+
+ For these microcontrollers, the Linux driver should be made capable of
+ working in both modes, and proper ioctls (see later) should be made
+ available at user-level to allow switching from one mode to the other, and
+ vice versa.
+
+3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+
+ The Linux kernel provides the serial_rs485 structure (see [1]) to handle
+ RS485 communications. This data structure is used to set and configure RS485
+ parameters in the platform data and in ioctls.
+
+ Any driver for devices capable of working both as RS232 and RS485 should
+ provide at least the following ioctls:
+
+ - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
+ to enable/disable RS485 mode from user-space
+
+ - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
+ to get RS485 mode from kernel-space (i.e., driver) to user-space.
+
+ In other words, the serial driver should contain a code similar to the next
+ one:
+
+ static struct uart_ops atmel_pops = {
+ /* ... */
+ .ioctl = handle_ioctl,
+ };
+
+ static int handle_ioctl(struct uart_port *port,
+ unsigned int cmd,
+ unsigned long arg)
+ {
+ struct serial_rs485 rs485conf;
+
+ switch (cmd) {
+ case TIOCSRS485:
+ if (copy_from_user(&rs485conf,
+ (struct serial_rs485 *) arg,
+ sizeof(rs485conf)))
+ return -EFAULT;
+
+ /* ... */
+ break;
+
+ case TIOCGRS485:
+ if (copy_to_user((struct serial_rs485 *) arg,
+ ...,
+ sizeof(rs485conf)))
+ return -EFAULT;
+ /* ... */
+ break;
+
+ /* ... */
+ }
+ }
+
+
+4. USAGE FROM USER-LEVEL
+
+ From user-level, RS485 configuration can be get/set using the previous
+ ioctls. For instance, to set RS485 you can use the following code:
+
+ #include <linux/serial.h>
+
+ /* Driver-specific ioctls: */
+ #define TIOCGRS485 0x542E
+ #define TIOCSRS485 0x542F
+
+ /* Open your specific device (e.g., /dev/mydevice): */
+ int fd = open ("/dev/mydevice", O_RDWR);
+ if (fd < 0) {
+ /* Error handling. See errno. */
+ }
+
+ struct serial_rs485 rs485conf;
+
+ /* Set RS485 mode: */
+ rs485conf.flags |= SER_RS485_ENABLED;
+
+ /* Set rts delay before send, if needed: */
+ rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+ rs485conf.delay_rts_before_send = ...;
+
+ /* Set rts delay after send, if needed: */
+ rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
+ rs485conf.delay_rts_after_send = ...;
+
+ if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) {
+ /* Error handling. See errno. */
+ }
+
+ /* Use read() and write() syscalls here... */
+
+ /* Close the device when finished: */
+ if (close (fd) < 0) {
+ /* Error handling. See errno. */
+ }
+
+5. REFERENCES
+
+ [1] include/linux/serial.h
--
1.6.0.4
Hi!
> Documentation about RS485 serial communications
I have seen hardware (kontron pmc-6l) that was capable of switching
between RS232, RS485 and one other standard by software.
Is such hw common? If so, should we have standard interface?
> + From user-level, RS485 configuration can be get/set using the previous
> + ioctls. For instance, to set RS485 you can use the following code:
> +
> + #include <linux/serial.h>
> +
> + /* Driver-specific ioctls: */
> + #define TIOCGRS485 0x542E
> + #define TIOCSRS485 0x542F
> +
> + /* Open your specific device (e.g., /dev/mydevice): */
> + int fd = open ("/dev/mydevice", O_RDWR);
> + if (fd < 0) {
> + /* Error handling. See errno. */
> + }
> +
> + struct serial_rs485 rs485conf;
> +
> + /* Set RS485 mode: */
> + rs485conf.flags |= SER_RS485_ENABLED;
IOW... is this supposed to switch electrical levels?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hello,
On Tuesday 16 November 2010, 15:30:16 Pavel Machek wrote:
> > Documentation about RS485 serial communications
>
> I have seen hardware (kontron pmc-6l) that was capable of switching
> between RS232, RS485 and one other standard by software.
Maybe you mean RS422 here.
> Is such hw common? If so, should we have standard interface?
Especially in industrial system, you may have RS485 or RS422 additionally to
RS232. This also often means switching some GPIO to change the external signal
levels. Any the drivers must also be capable of turning on and off the
transmitter.
Best regards,
Alexander
On Tue, Nov 16, 2010 at 8:30 AM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>> Documentation about RS485 serial communications
>
> I have seen hardware (kontron pmc-6l) that was capable of switching
> between RS232, RS485 and one other standard by software.
>
> Is such hw common? If so, should we have standard interface?
In my opinion this type of card is not that common. Generally
speaking the achievable baud rates for this type of multi-protocol
card are very limited because of limitations of the transceiver chips.
It seems that most of the time people would rather have a faster
serial port than one that does several different voltages.
Matt Schulte
On Tue, 16 Nov 2010 10:13:22 -0600
Matt Schulte <[email protected]> wrote:
> On Tue, Nov 16, 2010 at 8:30 AM, Pavel Machek <[email protected]> wrote:
> > Hi!
> >
> >> Documentation about RS485 serial communications
> >
> > I have seen hardware (kontron pmc-6l) that was capable of switching
> > between RS232, RS485 and one other standard by software.
> >
> > Is such hw common? If so, should we have standard interface?
>
> In my opinion this type of card is not that common. Generally
> speaking the achievable baud rates for this type of multi-protocol
> card are very limited because of limitations of the transceiver chips.
> It seems that most of the time people would rather have a faster
> serial port than one that does several different voltages
If there are two types in common use then thats enough to say we should
have a common interface IMHO
On 2010-11-16, Alan Cox <[email protected]> wrote:
> On Tue, 16 Nov 2010 10:13:22 -0600
> Matt Schulte <[email protected]> wrote:
>
>> On Tue, Nov 16, 2010 at 8:30 AM, Pavel Machek <[email protected]> wrote:
>> > Hi!
>> >
>> >> Documentation about RS485 serial communications
>> >
>> > I have seen hardware (kontron pmc-6l) that was capable of switching
>> > between RS232, RS485 and one other standard by software.
>> >
>> > Is such hw common? If so, should we have standard interface?
>>
>> In my opinion this type of card is not that common. Generally
>> speaking the achievable baud rates for this type of multi-protocol
>> card are very limited because of limitations of the transceiver chips.
>> It seems that most of the time people would rather have a faster
>> serial port than one that does several different voltages
>
> If there are two types in common use then thats enough to say we should
> have a common interface IMHO
Comtrol, Moxa, B&B, Sealevel, and others all sell PCI cards and
Ethernet attached serial ports that have selectable interfaces
(typically RS-232/422/485). Comtrol and Moxa have had drivers in the
kernel tree for ages, but they've always had to use custom ioctl calls
for things like configuring 232/485/422 mode and half/full-duplex
mode.
There are also tons of small Linux-based industrial server appliances
from Comtrol, Silex, Digi, Moxa, and others that have selectable
interface serial ports.
Having a standard API for things like interface mode, half-full
duplex, inter-character timeout, 9-bit mode, and so on would be life a
lot easier for those of us who maintain Linux serial drivers...
--
Grant Edwards grant.b.edwards Yow! I always have fun
at because I'm out of my
gmail.com mind!!!
On Tue, Nov 16, 2010 at 10:28 AM, Grant Edwards
<[email protected]> wrote:
> On 2010-11-16, Matt Schulte <[email protected]> wrote:
>> On Tue, Nov 16, 2010 at 8:30 AM, Pavel Machek <[email protected]> wrote:
>>> Hi!
>>>
>>>> Documentation about RS485 serial communications
>>>
>>> I have seen hardware (kontron pmc-6l) that was capable of switching
>>> between RS232, RS485 and one other standard by software.
>>>
>>> Is such hw common? If so, should we have standard interface?
>>
>> In my opinion this type of card is not that common. ?Generally
>> speaking the achievable baud rates for this type of multi-protocol
>> card are very limited because of limitations of the transceiver chips.
>
> I'm curious which selectable interface cards you're talking about that
> are slow? ?The ones I'm familiar with generally support baud rates up
> to either 460K bps or 921K bps
>
>> It seems that most of the time people would rather have a faster
>> serial port than one that does several different voltages.
>
> Where did you find a selectable interface serial card that couldn't
> support high baud rates?
In my world 460kbps for an RS422 card is slow. RS422 cards generally
push multi megabit/s rates.
Matt Schulte
> Comtrol, Moxa, B&B, Sealevel, and others all sell PCI cards and
> Ethernet attached serial ports that have selectable interfaces
> (typically RS-232/422/485). Comtrol and Moxa have had drivers in the
> kernel tree for ages, but they've always had to use custom ioctl calls
> for things like configuring 232/485/422 mode and half/full-duplex
> mode.
Ok so what is needed that isn't covered by the current termiox and
TIOCG/SRS485 ioctls ?
> Having a standard API for things like interface mode, half-full
> duplex, inter-character timeout, 9-bit mode, and so on would be life a
> lot easier for those of us who maintain Linux serial drivers...
9bit mode is a real problem with the tty layer defined in terms of 8bit
streams but yes.
On Tue 2010-11-16 20:04:26, Alan Cox wrote:
> > Comtrol, Moxa, B&B, Sealevel, and others all sell PCI cards and
> > Ethernet attached serial ports that have selectable interfaces
> > (typically RS-232/422/485). Comtrol and Moxa have had drivers in the
> > kernel tree for ages, but they've always had to use custom ioctl calls
> > for things like configuring 232/485/422 mode and half/full-duplex
> > mode.
>
> Ok so what is needed that isn't covered by the current termiox and
> TIOCG/SRS485 ioctls ?
IIRC selection of 232/485/422 mode was missing from proposed api.
> > Having a standard API for things like interface mode, half-full
> > duplex, inter-character timeout, 9-bit mode, and so on would be life a
> > lot easier for those of us who maintain Linux serial drivers...
>
> 9bit mode is a real problem with the tty layer defined in terms of 8bit
> streams but yes.
Well, if you wanted to have some fun... kontron card is able to
timestamp incoming characters, and saves state of the control signals
when character is received...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html