Menu
▾
▴
Re: [Owfs-developers] Issues with FTDI based USB-Serial dongle & DS2480B
|
From: David T. <tj...@wo...> - 2014-09-24 01:13:18
|
Does this help? Seems to be a lot more complicated than it should be, but at least it’s fairly deterministic. http://askubuntu.com/questions/184526/how-to-get-bus-and-device-relationship-for-a-dev-ttyusb Dave On Sep 23, 2014, at 7:58 PM, Paul Alfille <pau...@gm...> wrote: > Ok, I'm perplexed! > > I need help mapping device name (e.g. /dev/ttyUSB0) to USB bus:devnum that I get in libusb. > > I can probably do it by parsing 'dmesg' but that's rather inelegant. Perhaps the data is somewhere in /sys or /proc? > > The problem is that after searching (and perhaps tuning) USB devices, I then need to use them as a serial device. > I need to go in both directions -- both to not open use a bus master twice and to check device names. > > Paul > > On Tue, Sep 23, 2014 at 5:37 PM, Dirk Opfer <Di...@do...> wrote: > Hi Paul, > > I have another one: > > Elabnet (PBM01) -- 0403:6015 -- with UNIQUE product and manufacture ID > > Sorry for the delay. I'm still negotiating a sample for your. > > Thanks > Dirk > > Am 23.09.2014 um 23:27 schrieb Paul Alfille: >> Ok, I did some testing of various USB 1-wire bus masters: >> >> LinkUSB -- 0403:6001 -- FTDI but no identifying charcteristics (Except serial number, but that's probably not consecutive) >> TAI603B -- 10c4:ea60 -- CP210x Unclear if it's generic or not >> USB9097 --1a86:7523 -- HL-340 Seems generic >> ECLO -- 0403:ea90 -- FTDI with UNIQUE product ID >> MasterHub -- 04d8:f897 -- MTI with UNIQUE product ID >> DS9490R -- 04fa:2490 -- Maxim with UNIQUE ID >> >> So it looks like only ECLO, the new Hobby Boards MasterHub, and the DS9490R can be auto-detected by USB scanning. I had high hopes for the LinkUSB, but perhaps I have an early version and the internal fields have changed. >> >> Paul Alfille >> >> >> >> >> On Tue, Sep 23, 2014 at 3:40 PM, Johan Ström <jo...@st...> wrote: >> I'm all for auto-detection, when it is possible to do so reliably. As you mentioned in the other reply, randomly poking at stuff is neither reliable or safe.. >> So, the question is what we can do to make it as smooth for the user as possible.. >> >> A possibly a new approach, with OS-specific resolving you mentioned: >> >> If user specifies --link /dev/ttyS0, -d /dev/ttyS0 or other, we could try OS-specific lookups to find what serial hardware it is using. For example, if we can find out that it is a FTDI based device, we could try to use ft_ftdi instead of ft_serial. If we cannot find out, we just fall back to regular TTY access. >> >> If user specifies --link 2:3, -d 3:4, --link usb:NNSERIAL or such, we look for that specific USB device. If it is a FTDI device, we use ft_ftdi. Else, we can either fail, or for device-types which are serial, we could try to reverse-lookup TTY using OS-specific approach. >> >> Note: on FreeBSD there are separate /dev permissions for accessing the TTY and the USB device. Not sure if Linux has the same. >> >> Or, a more intrusive approach, clean up all parameters and go a generic device-option: --device <type>[ <port-or-address>]. >> Examples: >> --device link /dev/ttyS0 (would also possibly try to use OS specific resolving) >> --device link usb:3:4 >> --device link usb:NNSERIAL >> --device ds9097 /dev/ttyS0 >> --device ds9097 usb:3:4 >> --device ds9097 usb:NNSERIAL >> --device ds9097u /dev/ttyS0 >> --device i2c /dev/i2c-0 >> --device masterhub /dev/ttyS0 >> --device usb (this would search for DS9490R or PuceBaboon or any other USb which we can *reliably* identify) >> >> What would your optimal owfs usage model look like? >> >> >> For the record, here are the usbconfig --dump_device_desc data for my two FTDI devices: >> >> ugen1.3: <FT232R USB UART FTDI> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (90mA) >> bLength = 0x0012 >> bDescriptorType = 0x0001 >> bcdUSB = 0x0200 >> bDeviceClass = 0x0000 >> bDeviceSubClass = 0x0000 >> bDeviceProtocol = 0x0000 >> bMaxPacketSize0 = 0x0008 >> idVendor = 0x0403 >> idProduct = 0x6001 >> bcdDevice = 0x0600 >> iManufacturer = 0x0001 <FTDI> >> iProduct = 0x0002 <FT232R USB UART> >> iSerialNumber = 0x0003 <A9xxxxxD> >> bNumConfigurations = 0x0001 >> >> ugen2.3: <USB FAST SERIAL ADAPTER FTDI> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (44mA) >> bcdUSB = 0x0110 >> bcdDevice = 0x0400 >> iManufacturer = 0x0001 <FTDI> >> iProduct = 0x0002 <USB FAST SERIAL ADAPTER> >> iSerialNumber = 0x0003 <FTCDXXX> >> (skipped all other attributes which are identical) >> >> >> >> Johan >> >> >> On 9/22/14 18:23 , Paul Alfille wrote: >>> I notice in recent Linux (Fedora specifically) that USB devices get pretty consistently listed by a reasonably consistent and recognizable name in /dev/serial/by_id. >>> >>> I haven't looked to closely at all the USB fields yet, but some devices have unique identifiers rather than the generic USB/serial. I was hoping to scan for known patterns, apply any optimizations, and then connect. The upcoming USB HobbyBoards hub will have that. >>> >>> My dream is that owfs will be as "automatic" as possible. Currently we can automatically scan for: >>> i2c >>> DS9490R >>> HA7Net >>> OWSERVER-ENET >>> w1 >>> >>> Hardware serial will always be a problem, but some USB-serial might be possible. >>> >>> Paul >>> >>> On Mon, Sep 22, 2014 at 2:59 AM, Johan Ström <jo...@st...> wrote: >>> >>> On 22/09/14 00:21, Robin Gilks wrote: >>> >> 1. Trying to resolve a serial port TTY name (i.e. /dev/cuaU1 on FreeBSD) >>> >> to a potential USB device is probably doable, but not without a lot of >>> >> effort and OS specific code. >>> >> I don't think it's worth trying to go down that road. >>> >> >>> > How about using udev on Linux (is there an equivalent on other OSes?) that >>> > creates a symlink to a device node with a unique name from the type (FTDI) >>> > and bus number and OWFS looks for that specific device name. >>> > >>> > Just an idea (had to do that years ago with serial devices to sort out a >>> > connection to a weather station and an IR blaster, never sure what device >>> > names each would come up with!). >>> > >>> > >>> >>> I have a similar setup myself, using FreeBSD's devd. It uses my known, >>> hard-coded USB serials to set up a symlink from /dev/cua-linkusb to >>> /dev/cuaXXX when device is detected, to easier find which tty device I >>> should be using for what (I think I have ~4 serial ports on my box) >>> >>> However, this doesn't solve the auto-deteciton problem, the user still >>> needs to manually tell which USB device to be used, by serial-no or >>> otherwise. And if that has to be done, it could just as well be done >>> directly in owfs. >>> >>> ------------------------------------------------------------------------------ >>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Owfs-developers mailing list >>> Owf...@li... >>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>> >>> >>> _______________________________________________ >>> Owfs-developers mailing list >>> Owf...@li... >>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Owfs-developers mailing list >> Owf...@li... >> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Owfs-developers mailing list >> Owf...@li... >> https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
