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