Usb tm reader linux

USB serial¶

Introduction¶

The USB serial driver currently supports a number of different USB to serial converter products, as well as some devices that use a serial interface from userspace to talk to the device.

See the individual product section below for specific information about the different devices.

Configuration¶

Currently the driver can handle up to 256 different serial interfaces at one time.

The major number that the driver uses is 188 so to use the driver, create the following nodes:

When the device is connected and recognized by the driver, the driver will print to the system log, which node(s) the device has been bound to.

Specific Devices Supported¶

ConnectTech WhiteHEAT 4 port converter¶

ConnectTech has been very forthcoming with information about their device, including providing a unit to test with.

The driver is officially supported by Connect Tech Inc. http://www.connecttech.com

For any questions or problems with this driver, please contact Connect Tech’s Support Department at support @ connecttech . com

HandSpring Visor, Palm USB, and Clié USB driver¶

This driver works with all HandSpring USB, Palm USB, and Sony CliГ© USB devices.

Only when the device tries to connect to the host, will the device show up to the host as a valid USB device. When this happens, the device is properly enumerated, assigned a port, and then communication _should_ be possible. The driver cleans up properly when the device is removed, or the connection is canceled on the device.

This means that in order to talk to the device, the sync button must be pressed BEFORE trying to get any program to communicate to the device. This goes against the current documentation for pilot-xfer and other packages, but is the only way that it will work due to the hardware in the device.

When the device is connected, try talking to it on the second port (this is usually /dev/ttyUSB1 if you do not have any other usb-serial devices in the system.) The system log should tell you which port is the port to use for the HotSync transfer. The “Generic” port can be used for other device communication, such as a PPP link.

For some Sony CliГ© devices, /dev/ttyUSB0 must be used to talk to the device. This is true for all OS version 3.5 devices, and most devices that have had a flash upgrade to a newer version of the OS. See the kernel system log for information on which is the correct port to use.

If after pressing the sync button, nothing shows up in the system log, try resetting the device, first a hot reset, and then a cold reset if necessary. Some devices need this before they can talk to the USB port properly.

Devices that are not compiled into the kernel can be specified with module parameters. e.g. modprobe visor vendor=0x54c product=0x66

There is a webpage and mailing lists for this portion of the driver at: http://sourceforge.net/projects/usbvisor/

For any questions or problems with this driver, please contact Greg Kroah-Hartman at greg @ kroah . com

PocketPC PDA Driver¶

This driver can be used to connect to Compaq iPAQ, HP Jornada, Casio EM500 and other PDAs running Windows CE 3.0 or PocketPC 2002 using a USB cable/cradle. Most devices supported by ActiveSync are supported out of the box. For others, please use module parameters to specify the product and vendor id. e.g. modprobe ipaq vendor=0x3f0 product=0x1125

The driver presents a serial interface (usually on /dev/ttyUSB0) over which one may run ppp and establish a TCP/IP link to the PDA. Once this is done, you can transfer files, backup, download email etc. The most significant advantage of using USB is speed — I can get 73 to 113 kbytes/sec for download/upload to my iPAQ.

This driver is only one of a set of components required to utilize the USB connection. Please visit http://synce.sourceforge.net which contains the necessary packages and a simple step-by-step howto.

Once connected, you can use Win CE programs like ftpView, Pocket Outlook from the PDA and xcerdisp, synce utilities from the Linux side.

To use Pocket IE, follow the instructions given at http://www.tekguru.co.uk/EM500/usbtonet.htm to achieve the same thing on Win98. Omit the proxy server part; Linux is quite capable of forwarding packets unlike Win98. Another modification is required at least for the iPAQ — disable autosync by going to the Start/Settings/Connections menu and unchecking the “Automatically synchronize …” box. Go to Start/Programs/Connections, connect the cable and select “usbdial” (or whatever you named your new USB connection). You should finally wind up with a “Connected to usbdial” window with status shown as connected. Now start up PIE and browse away.

If it doesn’t work for some reason, load both the usbserial and ipaq module with the module parameter “debug” set to 1 and examine the system log. You can also try soft-resetting your PDA before attempting a connection.

Other functionality may be possible depending on your PDA. According to Wes Cilldhaire @ hotmail . com>, with the Toshiba E570, …if you boot into the bootloader (hold down the power when hitting the reset button, continuing to hold onto the power until the bootloader screen is displayed), then put it in the cradle with the ipaq driver loaded, open a terminal on /dev/ttyUSB0, it gives you a “USB Reflash” terminal, which can be used to flash the ROM, as well as the microP code.. so much for needing Toshiba’s $350 serial cable for flashing!! 😀 NOTE: This has NOT been tested. Use at your own risk.

Keyspan PDA Serial Adapter¶

Single port DB-9 serial adapter, pushed as a PDA adapter for iMacs (mostly sold in Macintosh catalogs, comes in a translucent white/green dongle). Fairly simple device. Firmware is homebrew. This driver also works for the Xircom/Entrega single port serial adapter.

basic input/output (tested with ‘cu’)

blocking write when serial line can’t keep up

changing baud rates (up to 115200)

getting/setting modem control pins (TIOCM)

sending break (although duration looks suspect)

device strings (as logged by kernel) have trailing binary garbage

device ID isn’t right, might collide with other Keyspan products

changing baud rates ought to flush tx/rx to avoid mangled half characters

parity, 7 vs 8 bits per char, 1 or 2 stop bits

HW flow control

not all of the standard USB descriptors are handled: Get_Status, Set_Feature, O_NONBLOCK, select()

For any questions or problems with this driver, please contact Brian Warner at warner @ lothar . com

Keyspan USA-series Serial Adapters¶

Single, Dual and Quad port adapters — driver uses Keyspan supplied firmware and is being developed with their support.

The USA-18X, USA-28X, USA-19, USA-19W and USA-49W are supported and have been pretty thoroughly tested at various baud rates with 8-N-1 character settings. Other character lengths and parity setups are presently untested.

The USA-28 isn’t yet supported though doing so should be pretty straightforward. Contact the maintainer if you require this functionality.

More information is available at:

For any questions or problems with this driver, please contact Hugh Blemings at hugh @ misc . nu

FTDI Single Port Serial Driver¶

This is a single port DB-25 serial adapter.

Devices supported include:

TripNav TN-200 USB GPS

Navis Engineering Bureau CH-4711 USB GPS

For any questions or problems with this driver, please contact Bill Ryder.

ZyXEL omni.net lcd plus ISDN TA¶

This is an ISDN TA. Please report both successes and troubles to azummo @ towertech . it

Cypress M8 CY4601 Family Serial Driver¶

This driver was in most part developed by Neil “koyama” Whelchel. It has been improved since that previous form to support dynamic serial line settings and improved line handling. The driver is for the most part stable and has been tested on an smp machine. (dual p2)

Chipsets supported under CY4601 family:

CY7C63723, CY7C63742, CY7C63743, CY7C64013

DeLorme’s USB Earthmate GPS (SiRF Star II lp arch)

Cypress HID->COM RS232 adapter

Cypress Semiconductor claims no affiliation with the hid->com device.

Most devices using chipsets under the CY4601 family should work with the driver. As long as they stay true to the CY4601 usbserial specification.

The Earthmate starts out at 4800 8N1 by default… the driver will upon start init to this setting. usbserial core provides the rest of the termios settings, along with some custom termios so that the output is in proper format and parsable.

The device can be put into sirf mode by issuing NMEA command:

As far as I can tell it supports pretty much every sirf command as documented online available with firmware 2.31, with some unknown message ids.

The hid->com adapter can run at a maximum baud of 115200bps. Please note that the device has trouble or is incapable of raising line voltage properly. It will be fine with null modem links, as long as you do not try to link two together without hacking the adapter to set the line high.

The driver is smp safe. Performance with the driver is rather low when using it for transferring files. This is being worked on, but I would be willing to accept patches. An urb queue or packet buffer would likely fit the bill here.

If you have any questions, problems, patches, feature requests, etc. you can contact me here via email:

(your problems/patches can alternately be submitted to usb-devel)

Источник

Writing USB Device Drivers¶

Introduction¶

The Linux USB subsystem has grown from supporting only two different types of devices in the 2.2.7 kernel (mice and keyboards), to over 20 different types of devices in the 2.4 kernel. Linux currently supports almost all USB class devices (standard types of devices like keyboards, mice, modems, printers and speakers) and an ever-growing number of vendor-specific devices (such as USB to serial converters, digital cameras, Ethernet devices and MP3 players). For a full list of the different USB devices currently supported, see Resources.

The remaining kinds of USB devices that do not have support on Linux are almost all vendor-specific devices. Each vendor decides to implement a custom protocol to talk to their device, so a custom driver usually needs to be created. Some vendors are open with their USB protocols and help with the creation of Linux drivers, while others do not publish them, and developers are forced to reverse-engineer. See Resources for some links to handy reverse-engineering tools.

Because each different protocol causes a new driver to be created, I have written a generic USB driver skeleton, modelled after the pci-skeleton.c file in the kernel source tree upon which many PCI network drivers have been based. This USB skeleton can be found at drivers/usb/usb-skeleton.c in the kernel source tree. In this article I will walk through the basics of the skeleton driver, explaining the different pieces and what needs to be done to customize it to your specific device.

Linux USB Basics¶

If you are going to write a Linux USB driver, please become familiar with the USB protocol specification. It can be found, along with many other useful documents, at the USB home page (see Resources). An excellent introduction to the Linux USB subsystem can be found at the USB Working Devices List (see Resources). It explains how the Linux USB subsystem is structured and introduces the reader to the concept of USB urbs (USB Request Blocks), which are essential to USB drivers.

The first thing a Linux USB driver needs to do is register itself with the Linux USB subsystem, giving it some information about which devices the driver supports and which functions to call when a device supported by the driver is inserted or removed from the system. All of this information is passed to the USB subsystem in the usb_driver structure. The skeleton driver declares a usb_driver as:

The variable name is a string that describes the driver. It is used in informational messages printed to the system log. The probe and disconnect function pointers are called when a device that matches the information provided in the id_table variable is either seen or removed.

The fops and minor variables are optional. Most USB drivers hook into another kernel subsystem, such as the SCSI, network or TTY subsystem. These types of drivers register themselves with the other kernel subsystem, and any user-space interactions are provided through that interface. But for drivers that do not have a matching kernel subsystem, such as MP3 players or scanners, a method of interacting with user space is needed. The USB subsystem provides a way to register a minor device number and a set of file_operations function pointers that enable this user-space interaction. The skeleton driver needs this kind of interface, so it provides a minor starting number and a pointer to its file_operations functions.

The USB driver is then registered with a call to usb_register() , usually in the driver’s init function, as shown here:

When the driver is unloaded from the system, it needs to deregister itself with the USB subsystem. This is done with the usb_deregister() function:

To enable the linux-hotplug system to load the driver automatically when the device is plugged in, you need to create a MODULE_DEVICE_TABLE . The following code tells the hotplug scripts that this module supports a single device with a specific vendor and product ID:

There are other macros that can be used in describing a struct usb_device_id for drivers that support a whole class of USB drivers. See usb.h for more information on this.

Device operation¶

When a device is plugged into the USB bus that matches the device ID pattern that your driver registered with the USB core, the probe function is called. The usb_device structure, interface number and the interface ID are passed to the function:

The driver now needs to verify that this device is actually one that it can accept. If so, it returns 0. If not, or if any error occurs during initialization, an errorcode (such as -ENOMEM or -ENODEV ) is returned from the probe function.

In the skeleton driver, we determine what end points are marked as bulk-in and bulk-out. We create buffers to hold the data that will be sent and received from the device, and a USB urb to write data to the device is initialized.

Conversely, when the device is removed from the USB bus, the disconnect function is called with the device pointer. The driver needs to clean any private data that has been allocated at this time and to shut down any pending urbs that are in the USB system.

Now that the device is plugged into the system and the driver is bound to the device, any of the functions in the file_operations structure that were passed to the USB subsystem will be called from a user program trying to talk to the device. The first function called will be open, as the program tries to open the device for I/O. We increment our private usage count and save a pointer to our internal structure in the file structure. This is done so that future calls to file operations will enable the driver to determine which device the user is addressing. All of this is done with the following code:

After the open function is called, the read and write functions are called to receive and send data to the device. In the skel_write function, we receive a pointer to some data that the user wants to send to the device and the size of the data. The function determines how much data it can send to the device based on the size of the write urb it has created (this size depends on the size of the bulk out end point that the device has). Then it copies the data from user space to kernel space, points the urb to the data and submits the urb to the USB subsystem. This can be seen in the following code:

When the write urb is filled up with the proper information using the usb_fill_bulk_urb() function, we point the urb’s completion callback to call our own skel_write_bulk_callback function. This function is called when the urb is finished by the USB subsystem. The callback function is called in interrupt context, so caution must be taken not to do very much processing at that time. Our implementation of skel_write_bulk_callback merely reports if the urb was completed successfully or not and then returns.

The read function works a bit differently from the write function in that we do not use an urb to transfer data from the device to the driver. Instead we call the usb_bulk_msg() function, which can be used to send or receive data from a device without having to create urbs and handle urb completion callback functions. We call the usb_bulk_msg() function, giving it a buffer into which to place any data received from the device and a timeout value. If the timeout period expires without receiving any data from the device, the function will fail and return an error message. This can be shown with the following code:

The usb_bulk_msg() function can be very useful for doing single reads or writes to a device; however, if you need to read or write constantly to a device, it is recommended to set up your own urbs and submit them to the USB subsystem.

When the user program releases the file handle that it has been using to talk to the device, the release function in the driver is called. In this function we decrement our private usage count and wait for possible pending writes:

One of the more difficult problems that USB drivers must be able to handle smoothly is the fact that the USB device may be removed from the system at any point in time, even if a program is currently talking to it. It needs to be able to shut down any current reads and writes and notify the user-space programs that the device is no longer there. The following code (function skel_delete ) is an example of how to do this:

If a program currently has an open handle to the device, we reset the flag device_present . For every read, write, release and other functions that expect a device to be present, the driver first checks this flag to see if the device is still present. If not, it releases that the device has disappeared, and a -ENODEV error is returned to the user-space program. When the release function is eventually called, it determines if there is no device and if not, it does the cleanup that the skel_disconnect function normally does if there are no open files on the device (see Listing 5).

Isochronous Data¶

This usb-skeleton driver does not have any examples of interrupt or isochronous data being sent to or from the device. Interrupt data is sent almost exactly as bulk data is, with a few minor exceptions. Isochronous data works differently with continuous streams of data being sent to or from the device. The audio and video camera drivers are very good examples of drivers that handle isochronous data and will be useful if you also need to do this.

Conclusion¶

Writing Linux USB device drivers is not a difficult task as the usb-skeleton driver shows. This driver, combined with the other current USB drivers, should provide enough examples to help a beginning author create a working driver in a minimal amount of time. The linux-usb-devel mailing list archives also contain a lot of helpful information.

Источник