serial module

John Nagle nagle at animats.com
Tue May 22 16:47:35 EDT 2012


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.  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.
>
>> 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.  This is a holdover from UNIX, which is a
holdover from DEC PDP-11 serial hardware circa mid 1970s, which had
14 standard baud rates encoded in 4 bits.  Really.

    In the Windows world, the actual baud rate is passed to the
driver.  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).

    If you need non-standard speeds, see this:

http://www.aetherltd.com/connectingusb.html

    If 19,200 baud is enough for you, don't worry about it.

				John Nagle



More information about the Python-list mailing list