On 2012-05-22, John Nagle <na...@animats.com> wrote: > On 5/22/2012 8:42 AM, Grant Edwards wrote: >> On 2012-05-22, Albert van der Horst<alb...@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 -- http://mail.python.org/mailman/listinfo/python-list
