|
From: Dirk O. <Di...@do...> - 2014-09-23 22:44:42
|
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... > <mailto: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... >> <mailto: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... >> <mailto: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... <mailto: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... > <mailto: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 |