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

[Grant Edwards <grant.b.edwards@gmail.com>]

On 2013-01-30, Guido Classen <clagix@gmail.com> wrote:
>> What I'm thinking about doing is instead of using a tty driver,
>> writing a char driver.  That eliminates the whole tty/ldisc tangle and
>> allows you to implement read()/write() as packet operations rather
>> than bytestream operations.  You can still implement whatever subset
>> of the termios ioctl() calls make sense along with whatever new
>> ioctl() calls are needed to control/configure things like inter-byte
>> timeouts, 9th-bit addressing modes, frame-recognition state-machines,
>> etc.
>
> If I understand this right, you suggest to introduce a new subsystem for
> half-duplex field-bus style communication which is fully independent from
> the existing POSIX tty subsystem. This subsystem will include own ioctls
> for settings timeouts, addressing, turn on and turn off times and so on,
> will support some temios ioctls which are applicable like setting baud-rates.

It wouldn't have to be half-duplex.

> There will be plugable frame-recognition state-machines. How will the
> low-level side look like? Will it use the existing serial drivers
> (over some kind of new interface?)

I haven't gotten that far.  Since the existing serial drivers assume
the existance and use of the tty layer, they probably can't be used
as-is.

> Or will it have it's own set of serial drivers which are designed for
> frame based half duplex communication. This means duplicate drivers
> for each kind of UART hardware (8250, atmel, ...)

Unfortunately, that's probably what it would take.

> I am not sure if this is a good design, but on other hand there are
> already duplicate drivers for 16550 style UARTs in the kernel for
> special purposes like bluetooth, irda and MIDI-interfaces.
>
> From userspace view this will make thinks much easier, so I
> personally will support this approach. But we have to be aware that
> this will introduce a new API which is not standardized and portable
> to other OSs.

That's a very real issue.  The applications I'm initially interested
in porting aren't Unix/Linux apps anyway, so for my particular project
the applications have to be ported to something, and the existing tty
API just doesn't provide the required features.

> Furthermore there must be some way to have access to the same
> hardware either over this API or over the TTY API.

That's not one of my requirements.  My plan is that you either enable
the serial_core driver or my "low-level char/frame" driver -- you
can't use both.  You could, of course, build them both as modules and
switch back and forth without rebooting.

There's no reason that the driver I'm thinking about can't be
partially API compatible so that you can use the same libc calls to do
common things like set baud rate/parity, get/set modem status/control
lines, and so on.

-- 
Grant Edwards               grant.b.edwards        Yow! I can't decide which
                                  at               WRONG TURN to make first!!
                              gmail.com            I wonder if BOB GUCCIONE
                                                   has these problems!