Since this serial i/o adapter interfaces to the host computer as a USB device, a quick HowTo find out about a USB device that was just connected.
While written about the USB-serial adapter cable to be used, the details of learning information about a kernel module here is general in nature.
Note: Shown while logged in as 'root' (su -l) but only this first command requires root privledge level (dmesg -c). You can do these commands as a regular user, using the form: 'sudo dmesg -c' for this first command.
Clear the kernel message buffer:
Code:
core2quad ~ # dmesg -c
- - - big snip - - -
Hot plug a device. Here the USB-serial converter:
Code:
core2quad ~ # dmesg
[ 7087.268150] usb 2-3.5: new full speed USB device number 5 using ehci_hcd
[ 7087.843883] usbcore: registered new interface driver usbserial
[ 7087.843895] USB Serial support registered for generic
[ 7087.843930] usbcore: registered new interface driver usbserial_generic
[ 7087.843932] usbserial: USB Serial Driver core
[ 7087.850645] USB Serial support registered for FTDI USB Serial Device
[ 7087.850758] ftdi_sio 2-3.5:1.0: FTDI USB Serial Device converter detected
[ 7087.850789] usb 2-3.5: Detected FT232RL
[ 7087.850791] usb 2-3.5: Number of endpoints 2
[ 7087.850793] usb 2-3.5: Endpoint 1 MaxPacketSize 64
[ 7087.850795] usb 2-3.5: Endpoint 2 MaxPacketSize 64
[ 7087.850797] usb 2-3.5: Setting MaxPacketSize 64
[ 7087.851096] usb 2-3.5: FTDI USB Serial Device converter now attached to ttyUSB0
[ 7087.851111] usbcore: registered new interface driver ftdi_sio
[ 7087.851112] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
The information of primary importance to the user is this line:
Quote:
FTDI USB Serial Device converter now attached to ttyUSB0
|
Which says that software can now access the adapter cable as /dev/ttyUSB0
This device name was assigned (or could have been assigned) by either the kernel's module autoloader or a udev event rule.
In this specific case, that looks like the kernel's default name, not been re-named by the udev event rules, although you could do that if desired.
Additional information in the kernel message buffer above is the announcement of two new driver modules that where autoloaded.
Code:
core2quad ~ # lsmod
Module Size Used by
ftdi_sio 35827 0
usbserial 37203 1 ftdi_sio
- - - snip - - -
Additional information about those modules is available, including parameters that the module recognizes.
These parameter values can be passed to the module from the kernel command line or on the command line of the manual module loader command.
Code:
core2quad ~ # modinfo ftdi_sio
filename: /lib/modules/3.0.0-16-generic/kernel/drivers/usb/serial/ftdi_sio.ko
license: GPL
description: USB FTDI Serial Converters Driver
author: Greg Kroah-Hartman <greg@kroah.com>, Bill Ryder <bryder@sgi.com>, Kuba Ober <kuba@mareimbrium.org>, Andreas Mohr, Johan Hovold <jhovold@gmail.com>
srcversion: 1719192F096E98EA81E5982
alias: usb:v0483p3747d*dc*dsc*dp*ic*isc*ip*
- - - snip about 640 devices - - -
alias: usb:v0403pF7C0d*dc*dsc*dp*ic*isc*ip*
depends: usbserial
vermagic: 3.0.0-16-generic SMP mod_unload modversions 686
parm: debug:Debug enabled or not (bool)
parm: vendor:User specified vendor ID (default=0x0403) (ushort)
parm: product:User specified product ID (ushort)
parm: ndi_latency_timer:NDI device latency timer override (int)
Of possible interest is the ability to control the latency timer in this driver.
The values and their effect should be in the Documentation tree of the kernel source.
Although just asking your favorite web-search engine sometimes works also.
Notice in the above that this driver depends on (requires) the usbserial driver.
Learning a bit about that driver:
Code:
core2quad ~ # modinfo usbserial
filename: /lib/modules/3.0.0-16-generic/kernel/drivers/usb/serial/usbserial.ko
license: GPL
description: USB Serial Driver core
author: Greg Kroah-Hartman, greg@kroah.com, http://www.kroah.com/linux/
srcversion: 8451423FD3B5DEEE801B6DB
depends:
vermagic: 3.0.0-16-generic SMP mod_unload modversions 686
parm: vendor:User specified USB idVendor (ushort)
parm: product:User specified USB idProduct (ushort)
parm: debug:Debug enabled or not (bool)
Which does not list any dependencies.
Although from the dmesg you can see that it depends on the usbcore system, which is usually built-in to the kernel rather than being a module.
Note also that this kernel was built with the module unloader enabled.
You can unload these modules (rmmod, remove module) and then re-load them manually, perhaps with different parameters.
Such as with debug enabled or changed latency timer values.
Consider these drivers as a "stack" (they are) and use the dependency information to get the manual un-load and load command order correct.
Unload top-down:
rmmod ftdi_sio
rmmod usbserial (if changing something about it)
Load bottom-up:
insmod usbserial
insmod ftdi_sio ndi_latency_timer=some.number
There is both summary and detail information available about devices on the USB bus, the quick summary:
Code:
core2quad ~ # lsusb
- - - snip - - -
Bus 002 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
And the more than anyone wants to know, detail listing command:
Code:
core2quad ~ # lsusb -vvv -d 0403:6001
Bus 002 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 USB-Serial (UART) IC
bcdDevice 6.00
iManufacturer 1 FTDI
iProduct 2 TTL232RG-VREG1V8
iSerial 3 FTUU8UJ7
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 TTL232RG-VREG1V8
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
The vendor and device information is being translated to strings using the usb.ids file, located at:
Code:
/var/lib/usbutils/usb.ids
Which you can view for more information about the vendors and devices.
Or query it using grep:
Code:
core2quad ~ # grep -B1 'Amazon' /var/lib/usbutils/usb.ids
1949 Lab126
0002 Amazon Kindle
0004 Amazon Kindle 3
You (as admin user: 'root') can also edit this database to translate ids that are not included. Directions are in the top of the file.
Of possible interest in the above, the comment about the udev rules and the info shown in the detailed listing.
From reading the chip documentation manual, you know there is a unique serial number burned into each chip and it could be seen here:
That value __should__ be available to the udev rules, if you want to write a udev rule that always assigns the same device name to this cable.
Handy if you have more than one adapter cable plugged into your machine.
FTDI Chip has a version of this cable with all leads on a bit-banging interface, for use as interesting things like an eJTAG adapter cable. Uses this same driver, so assigning distinctive names to the cables can become a very usefull feature.