RS232 modem-side driver - does it exist ?

I've been messing around with Linux serial stuff for a lot of years and I've never come across a driver like that.

You'll have to write your own anyway, since your hardware is unique, right?

Those don't need to be fast and thus can be set from user land using some bit-I/O driver.

-Michael

Hello Grant,

Grant Edwards schrieb:

Ok, thanks, saves me a bunch of searching.

Not quite, it's using an Atmel AT91 CPU, which is an ARM with built in UART (and other stuff); a "normal" (DTE-end) driver for this UART is already in the standard kernel sources.

Thanks and best wishes,

It shouldn't be difficult to modify that driver to treat RTS and DTR as inputs and CTS, DCD, DSR, RI as outputs. I don't think the tty layer cares -- it just passes the bitmasks back and forth between userspace and the low-level driver.

Grant Edwards schrieb:

Unfortunately, it does care a bit - it removes bits that belong to the "wrong" direction in drivers/char/tty_io.c, function tty_tiocmset. Shouldn't be too hard to patch, though.

You're right. It oughtn't, but it does.

There's no excuse not to make the tty layer DCE/DTE agnostic. The low-level driver's tiocmset() method should be quite capable of ignoring bits it can't control (and all the ones I've ever looked at certainly do).

The tty layer is throwing away perfectly good bits for no reason.

Grant Edwards schrieb:

And there's a lot more badness in drivers/serial/serial_core.c, though this arguably is already a part of the low-level code (or mabye one should call it mid-level).

Since you have already rewired the UART Tx to pin 2 on a 9 pin D-connector and UART Rx to pin 3, for simplified RS-232 handshaking, why don't you rewire e.g. the DTR UART bit to DCD D-connector pin and CTS UART bit to the RI pin on the D-connector. The DSR connector pin could be driven from the DCE power supply +12 V through a resistor. The software would have to control the DTR and DCD settings to alter the DCD and RI lines on the serial card.

However, if full DCE RS-232 handshaking is needed, at least the DTR, RTS inputs and DSR, CTS, DCD and RI outputs would be needed and it is unlikely that any ordinary UART would have 2 input and 4 output programmable control lines.

In practice, you would need to assign a separate (parallel) port on your micro controller and attach a suitable number of RS-232/TTL and TTL/RS-232 converters to that port and program the data direction register. Thus, this port would be separate from the serial port and could easily be controlled by user mode software.

Paul

I guess I would consider it a block of comon low-level code, and you're right: it assumes it's DTE (e.g. it tries to set set RTS+DTR on open).

If I were to write a DCE driver, I'd probably not use serial_core.c. FWIW, there are still serial drivers that don't use serial_core.c, since it makes some pretty restrictive assumptions about how the serial interface hardware works.

BTW.:

In this directory I see this file and several files for different hardware setups.

In /drivers/char there is rtc.c. This seems to be just for the PC based clock chip but not usable for (e.g.) ARM (as it e.g. uses "CMOS_WRITE" and friends). How can it be "legal" that there is no hint in the directory or file name that this is dedicated for a certain class of hardware ?

Would it not make sense to use a similar two level method as with serial_core.c ?

I am investigating this, as I am considering doing a "multiple-timer" driver that uses the RTC (on PC) or some hardware timer (on ARM) as a quite fast interrupt source and allows multiple user land processes (threads) to wait for periodic events with an individually definable frequency, but with certain (somewhat obscure ) mutual synchronizing features. I'd rater use some low level module to hook the interrupt than just copy the code from the hardware dependent driver into my module.

-Michael