Menu
▾
▴
Re: [Owfs-developers] Issues with FTDI based USB-Serial dongle & DS2480B
|
From: Johan S. <jo...@st...> - 2014-09-30 06:32:55
|
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 > <tj...@wo... <mailto:tj...@wo...>> 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 <pau...@gm... > <javascript:_e(%7B%7D,'cvml','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... >> <javascript:_e(%7B%7D,'cvml','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... >>> <javascript:_e(%7B%7D,'cvml','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... >>>> <javascript:_e(%7B%7D,'cvml','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... >>>> <javascript:_e(%7B%7D,'cvml','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... <javascript:_e(%7B%7D,'cvml','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... >>> <javascript:_e(%7B%7D,'cvml','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... <javascript:_e(%7B%7D,'cvml','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... >> <javascript:_e(%7B%7D,'cvml','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... >> <javascript:_e(%7B%7D,'cvml','Owf...@li...');> >> 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 > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
