On 27/01/16 23:42, Jan Kandziora wrote:
> Am 27.01.2016 um 23:09 schrieb Johan Ström:
>> (libftdi *does* have a ftdi_usb_find_all but "list all" only works on
>> libftdi >= 1.x. And it only lists devices with *known* FTDI vid/pid's.
>> Let's say a third party device uses a FTDI chip but has obtained it's
>> own PID (available for free from FTDI), then it would not be shown in
>> this list. So I prefer to go with libusb and list all accessible
>> devices, and output some marker if it is/isn't a known FTDI device)
>>
> The FTDI chip isn't the problem. The problem is we cannot say what's
> behind it. It may be ad DS2480 but it may be a printer or the system
> console either. We cannot probe it without disturbing another
> application, there are far too many FTDI based adapters out there.
>
> So the only safe way is topographical addressing. The user has to
> specify which USB device to use, no exception.
Yes, never had any plans otherwise.
>
>
> I'm against putting the listing/probing code into owserver. We have
> small tools for everything and shouldn't start overloading tools with
> functions now. Plus, putting it into owserver would concern users "that
> stupid tool fiddles with my system". Given the amount of support
> requests we have just because of broken default configurations, I think
> we should rather strip options from owserver et al. than adding more.
>
> So, make a new tool and name it owftdiprobe or so. That tool then also
> may disturb any FTDI adaptor connected (with the proper command line
> switch) to find out where the DS2480 is connected.
Sounds good. I'll see what I can come up with, my idea is to make it
interactive based on the idea Stefano put forward ("Please remove all
devices you which to discover", "Scanning...", "Found these new devices!
*Possibly* use them like this: xxxx"). Possibly needs to be run as root,
since the user has probably *not* added devd-rules to set the owner.
I'd say actual probing may be added later, I'm still skeptical to that
(even though the user would actively choose which devices to probe).
>
>
> By the way, the DS9481P adaptor from Maxim is cdc_acm+DS2480, I think.
> Any need or way to have this handled similar to FTDI+DS2480?
Hm, I've never used a ACM-based adapter, so not sure. But I guess it is
possible to communicate with it using libusb? Is there a "libftdi" for
these devices as well (handling all the libusb-interactions, giving us a
simple interface)?
The important question is, do we have a reason to do so? For FTDI, the
main (only?) reason which motivates it is that we get access to tune
down the latency timer, yielding faster 1W ops.
Johan
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
