serial module

[Grant Edwards]

On 2012-05-22, John Nagle <nagle at animats.com> wrote:
> On 5/22/2012 8:42 AM, Grant Edwards wrote:
>> On 2012-05-22, Albert van der Horst<albert at spenarnc.xs4all.nl>  wrote:
>
>>> It is anybody's guess what they do in USB.
>>
>> They do exactly what they're supposed to regardless of what sort of
>> bus is used to connect the CPU and the UART (ISA, PCI, PCI-express,
>> USB, Ethernet, etc.).
>
> If a device is registered as /dev/ttyUSBnn, one would hope that the
> Linux USB insertion event handler, which assigns that name,
> determined that the device was a serial port emulator.

The fact that it shows up as /dev/tty<something> means that the driver
registered the port as a tty (serial) device.

> Unfortunately, the USB standard device classes
> (http://www.usb.org/developers/defined_class) don't have "serial port
> emulator" as a standardized device.  So there's more variation in
> this area than in keyboards, mice, or storage devices.

I've used a log of USB connected serial devices, and they all worked
fine.  Some show up as /dev/ttyUSBn and some as /dev/ttyACMn, but the 
standard tty APIs all worked fine.  What sorts of vartiations have you
seen?

>>> The best answers is probably that it depends on the whim of whoever
>>> implements the usb device.
>>
>> It does not depend on anybody's whim.  The meaning of those
>> parameters is well-defined.
>>
>>> Certainly this stuff is system dependant,
>>
>> No, it isn't.
>
> It is, a little.  There's a problem with the way Linux does serial
> ports.  The only speeds allowed are the ones nailed into the kernel
> as named constants.

That hasn't been true for years.  The termios2 structure allows
arbitrary baud rates.  I don't know if all low-level serial drivers
support that API, but I believe all the in-kernel ones do (and I know
the out-of-kernel one's I maintain do).

The UART hardware may have limits in the buad-clock divider chains
that limit the number of baud rates that can be generated, but that's
a different problem.

> In the Windows world, the actual baud rate is passed to the driver.

That's also how it works with a modern Linux serial driver.  You 
use "struct termios2" instead of "struct termios" TCGETS2 et al
instead of TCGETS et al.

Here's source code for a command-line utility to set a Linux serial
port to an arbitrary baud rate:

  http://www.panix.com/~grante/files/arbitrary-baud.c

That said, the POSIX APIs in the libc implementations I know about
(glibc, uClibc) unfortunately haven't caught up yet. :)

> Serial ports on the original IBM PC were loaded with a clock rate, so
> DOS worked that way.
>
> This only matters if you need non-standard baud rates.  I've had to
> deal with that twice, for a SICK LMS LIDAR, (1,000,000 baud) and
> 1930s Teletype machines (45.45 baud).

We run our Sick LMS units at 500,000 baud, and bog-standard Linux
kernels support that just fine.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having a BIG BANG
                                  at               THEORY!!
                              gmail.com