Re: RS485 implementation questions (primarly in atmel_serial.c)

[Guido Classen <clagix@gmail.com>]

> Our Linux tty/serial drivers do support "plain" a RS-485 mode without
> pre/post RTS hold times (the plain RS-485 mode is supported by the
> UART itself).  The pre/post RTS hold times feature can be used from
> Linux applications, but to take advantage of those sort of features we
> don't use Linux tty/serial device drivers.  For many industrial I/O
> applications we've found it much simpler to avoid the termios/tty
> stuff and connect to the serial hardware via Ethernet and TCP/IP
> instead.
>
> Over the years we've found that the Unix "tty" API is rather
> ill-suited for doing things other than talking to terminals.  In other
> news, we've found that a screwdriver is ill-suited for doing things
> other than driving screws. :)

You are absolutely right, the "TTY" API is ill-suited for fieldbus style
half-duplex communication. But in my opinion this form of communication is
still very common and even today not every device has an ethernet connector.
So what are the consequences?

1. Don't use Linux at all for this purpose. For PCs and Server it may
be indeed the better solution to use TCP/IP instead. But for embedded
Linux the situation is different. One important application here is to
implement exactly these Ethernet/TCP/IP to "some lowlevel stuff"
boxes!

2. Sole Userspace software using Posix TTY API. This will work (more
or less) if the speed (baudrate) is relatively low and the time
between sending and receiving is long enough. You also can not benefit
from serial hardware which have special support for fieldbus style
communication like the Atmel AT91 USARTS.

3. Use some board specific drivers or modifications to the drivers and
Linux TTY stack (E.G. additional ioctls). I think this way is mostly
used in practically embedded Linux. Drawbacks are, that userspace
software must include support for each specific board it is intend to
run on.

4. The TIOCSRS485 ioctl may open new doors, but as I see there are
only few drivers implementing it.


Maybe someone else on this list will share his thoughts about this issues


>
> For example, our serial interfaces are used quite a bit in traffic and
> parking applications, but in those cases the long-haul connections are
> TCP/IP over fiber, and the serial ports are only used to communicate
> locally within a roadside cabinet.  To the user application, each of
> the serial devices (camera controller, inductive loop sensor, ramp
> light controller, card reader, gate arm, etc.) is just another network
> device addressed via an <ipaddr,ipport> tuple.
>
> Programmers seem to get themselves into much less trouble with the TCP
> socket API than they do with the tty API

That's crazy, It seems we are working almost with the same things. I am
a software developer and so I also prefer TCP. It's much simpler to
use and has a clean, portable API. In new installations, TCP is quite
common. We also have fiber optics and copper rings for long-haul
connections. But there also very old copper wires which are to long to
be used with SHDSL. Sensors and actors are mostly connected serial. At least
in Germany for road traffic equipments protocols are often specified by
national standards. There also old installations which should be extended or
modified. So at the end we don't get rid of serial and we must be able to
support it in parallel to the TCP/IP infrastructure!

Regards,
  Guido Classen