Hi all,
picking this up again. Lets summarize the main points:
* auto-detection can only be relied on for certain pure USB devices
* auto-detection can not be relied on when "standard" serial bridge
chips are used
* if we can resolve /dev/ttyUSB0 to a particular USB device, we can
potentially select a smarter (i.e. improved FTDI) code path instead of
regular read/write from the tty device.
* /dev/ttyUSB0 is not stable, unless explicit devd setup is done.
* this makes alterantive OWFS device addressing interesting, by
specifying USB serial. this would avoid devd all together.
-----
A new suggestion regarding owfs invocation:
Kept as is:
-d <tty> (deprecate, as this is ambigous?)
-u all (autosearches for verifiable devices only, i.e. explicit vid/pid)
-u <usb identifier> (specific device, only usable for verifiable devices)
Added:
--ds9097U <tty | usb-identifier> (or ds2480b? chip vs product)
--ds9097 <tty | usb-identifier>
Extended:
--link <tty | usb-identifier>
--prm <tty | usb-identifier>
....(all devices which uses ft_serial today)
<usb-identifier> is one of:
"3:4" for explicit device at bus 3, device 4
"s:<serial>" for explicit device with specified serial
<tty> is a regular /dev/ttyXXX or /dev/cuaXXX.
If OS probing is available, we try to look up the matching USB device.
If it's a known serial emulator with special code path (initially only
FTDI), and we use that for lowlevel comms. Else, we use regular tty
device read/write.
This allows previous setups to work without changes, but still giving
them improved speed if a FTDI device happens to be in use.
For new/updated setups, it allows the administrator to specify an
explicit USB device without having to involve devd.
What do you think?
/Johan
On 24/09/14 04:52, Roberto Spadim wrote:
> I think the problem isn't usb device
> The problem is serial protocol that don't have a plug and play feature
>
> Em terça-feira, 23 de setembro de 2014, David Torrey
> <t...@woodsidelane.net <mailto:t...@woodsidelane.net>> escreveu:
>
> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','Owfs-developers@lists.sourceforge.net');>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> --
> Roberto Spadim
> SPAEmpresarial
> Eng. Automação e Controle
>
>
>
> ------------------------------------------------------------------------------
> 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
