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 <paul.alfi...@gmail.com> 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 <d...@do13.de> 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...@stromnet.se> 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...@stromnet.se> 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
>>> Owfs-developers@lists.sourceforge.net
>>> 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
>>> Owfs-developers@lists.sourceforge.net
>>> 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
>> Owfs-developers@lists.sourceforge.net
>> 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
>> Owfs-developers@lists.sourceforge.net
>> 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
> Owfs-developers@lists.sourceforge.net
> 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
> Owfs-developers@lists.sourceforge.net
> 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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
