[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Tips on programming usb devices?
On Thu, 6 Sep 2012, Brian Buhrow wrote:
> For those of you who haven't been following the thread, I'm working on
> a driver for the Novatel 551L USB modem. I believe this device is based on
> the Qualcomm Gobi 3,000 chip set and features a multi-interface USB device.
do you know if this would cover the mini-PCIe board too? I understood some
mini-PCIe boards show up as USB hubs..
> The first 4 interfaces present themselves as general communications ports,
> of which the first permits standard serial connections through which modem
> Hayes style AT commands can be sent to control the modem's behavior. The
> other 3 ports are available and, I believe, work, but I don't know how to
> use them.
one of them may be a GPS port.. the uhso devices seem to also have these
(though mine does not)
> The last 2 interfaces look like a cdce(4) ethernet device, which once
> the modem is activated, responds to dhcp client requests and allows IP
> traffic to flow in and out through the device.
I am not sure if you are using 'interfaces' to mean 'USB interfaces' here,
or to just mean a general IO method?
> The driver I have, which runs under NetBSD-5, is essentially a
> mash up of the u3g(4) and cdce(4) drivers. It attaches the first four
> interfaces as serial ports using the ucom(4) driver and presents an
> ethernet interface to the system for the last two interfaces. The Linux
> folks have chosen to extend their cdce kernel driver to allow it to
> attach serial ports on selected devices. Because I was learning how to
> do USB programming on this project, I elected to implement a stand-alone
> driver. The new driver, which I'm calling ugobi(4), can support other
> devices of this nature, I'm thinking of devices like the LG Vl600 or the
> Pantech 290. I can think of three ways to approach this issue, which is
> where I'd like feedback. Here are my thoughts:
> 1. Keep the ugobi(4) driver as it is and commit it as a new USB driver,
> complete with manual page and sample scripts showing how to activate the
> modem through the At modem interface. Then, as more folks encounter these
> modems, they can easily add them to this driver.
essentially that is what I did for uhso(4), though in that case the
network interface was not the same as CDCE, and some of the serial ports
were not the same as umodem
> 2. Extend the cdce(4) driver to look for flags in device specific entries
> telling it to attach serial ports in addition to the ethernet interface.
> this seems somehow unclean to me, though it was my original idea to do this
> when I started this project.
I don't think this is any good; the cdce driver only attaches to a "USB
interface" in any case, it has no knowledge of the other interfaces that
the device may provide..
> 3. Extend the umodem(4) driver to attach the unclaimed interfaces of these
> modems as serial ports. This seems like the cleanest approach from a code
> development perspective, but could cause a little confusion in practical
> usage, as it could be more challenging to match up which serial ports go
> with which ethernet interfaces. (Approach 1 doesn't have this problem
> because the name of the base driver shows up on the same line as all the
> sub-devices when the thing probes, see below.)
and this is much the same; umodem driver attaches to a "USB interface"
only, so I don't see how that can work..?
> 4. Another approach I haven't thought of?
If the interface code is exactly the same as the CDCE driver, then you
could modify the cdce(4) driver, so that the USB attachment code is a
wrapper around cdce_ifattach() calls for example.. then you can use the
same cdce_ifattach() call from your ugobi.c driver.. if that makes sense?
Then the ugobi(4) driver is basically a wrapper which attaches to the base
device, and attaches the appropriate com/cdce drivers to it
> Here's the output from dmesg for the new device.
> ugobi0 at uhub3 port 4
> ugobi0: Novatel Wireless, Inc. Novatel Wireless 4G, rev 2.00/0.15, addr 2
> ucom0 at ugobi0 portno 0: uGobi Serial Device
> ucom1 at ugobi0 portno 1: uGobi Serial Device
> ucom2 at ugobi0 portno 2: uGobi Serial Device
> ucom3 at ugobi0 portno 3: uGobi Serial Device
do you know if the ports have specific functions? with uhso(4) there is a
clear declaration of what the ports are for, so I embedded that into the
autoconf messages, eg
uhso0 at uhub0 port 2
uhso0: Option N.V. Globetrotter HSDPA Modem, rev 1.10/0.00, addr 2
uhso0: Control (port 0) attached as mux tty
uhso0: Application (port 3) attached as mux tty
uhso0: Network (port 11) attached as ifnet
uhso0: Diagnostic (port 1) attached as bulk tty
uhso0: Modem (port 8) attached as bulk tty
and then you can infer that /dev/ttyHS0.08 is the "Modem"
Main Index |
Thread Index |