libftdi support: take 2

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

libftdi support: take 2

Johan Ström-3
Hi,

some of you may remember my earlier attempts to add a libftdi based LinkUSB interface into master. For reference: http://sourceforge.net/p/owfs/mailman/message/32492037/
In short, the client-timings are generally cut about 2.5 times, depending on operation. A temp sensor is read in ~50ms instead of ~123ms. More details can be found at the link.

Last time (2014) it was well received, but got stuck on discussions about different methods of auto-detection (something which isn't too easy/possible with FTDI).  I have since run that code in production without any glitches, so the ftdi-part has really proven stable.
In the recent days, I've cleaned up the code to not be LinkUSB specific, but rather work with any serial-based device (and fixed some minor issues). There is no auto-detection though (and again, I don't believe that is possible to do reliable with serial devices; see discussions in above link).

A cut from the (updated) man page is available below, please see that for usage details.
I realize that this isn't the simplest thing to explain to a user, but then again, a regular user who don't really care about those extra milliseconds shaved off each request can easily use the same old /dev/ttyS0 addressing. For us who *do* care however, it is very useful.

The ftdi parts of the code has been running since 2014, but only with LinkUSB. But it's mostly the device setup parts which has changed lately, so it shouldn't be any unstability. I've tested the LinkUSB, emulated and --link mode,  and DS2480 through a FTDi adapter without any issues.

I've commited all the changes in the new ftdi branch: http://sourceforge.net/p/owfs/code/ci/2982df8ca648bd9cec4d820151046b044ef504e0/
The above is a clean patch based on my earlier work (which may be interesting for those wanting to check out how it evolved) at http://sourceforge.net/u/stromnet/owfs/ci/ca85d64eefaaa9f1e90bbc079db65cfda623c472/log/?path=

One potential issue could be the BUS_close related changes in ow_connection.c, could someone take a look at that please? I think that is actually a bug fix, basically it calls device-specific BUS_close *before* cleaning up and closing the device, instead of after.. But an extra set of eyes would be great.

Another issue could be that I now bring any link-devices into 19200-mode after initial detection (also increases the speed a lot). This is the mode I've been running my LinkUSB during the last years, via the FTDI layer, so should be OK. But I have not tested with older links, or non-USB based links (or the linkusb via old serial addressing for any longer duration).

To sum it up, I hope we can get this branch merged into master sooner rather than later! If we want to add a sane auto-detection scheme somehow, let's add that later..

Any testing and feedback is much appreciated!

Regards
Johan

Man-page cut:
-------
* Serial devices
       port specifies a serial port, e.g.  /dev/ttyS0

       If OWFS was built with libftdi support, you may  be  able  to  use  the
       ftdi: prefix to address a FTDI-based USB device.
       For details, see the FTDI ADDRESSING section.

....
FTDI ADDRESSING
       FTDI  is  a brand of USB-to-serial chips which are very common. If your
       serial device is connected via a USB serial  dongle  based  on  a  FTDI
       chip,  or  if  your adapter uses a built-in FTDI USB chip (for example,
       the LinkUSB), you can use this FTDI addressing.

       The main benifit with this mode of access is that we can  decrease  the
       communication  delay,  yielding  twice  as fast 1-Wire communication in
       many cases.

       The following values for port can be used to identify a  specific  FTDI
       port.  Note that this requires that OWFS is built with libftdi support.

       ftdi:d:<devicenode>
              path of bus and device-node (e.g. "003/001") within  usb  device
              tree (usually at /proc/bus/usb/)

       ftdi:i:<vendor>:<product>
              first  device with given vendor and product id, ids can be deci-
              mal, octal (preceded by "0") or hex (preceded by "0x")

       ftdi:i:<vendor>:<product>:<index>
              as above with index being the number  of  the  device  (starting
              with 0) if there are more than one

       ftdi:s:<vendor>:<product>:<serial>
              first device with given vendor id, product id and serial string

       The  above formats are parsed fully by libftdi, but with the ftdi: pre-
       fix stripped.

   Simplified device serial-only support
       An additional format is supported, for certain  bus  types.  This  only
       specifies the USB serial number.

       ftdi:<serial>
              Identifies  a  FTDI  device  by serial only.  Currently, this is
              only valid for the VID/PID found on the LinkUSB  (i.e.  --link).
              Note that those VID/PID's are the default for any FT232R device,
              and in no way exclusive to LinkUSB.

-----

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Stefano Miccoli
Good news.

In a few days I will have an old LinkUSB available for testing, although with a limited number of sensors only: I will try-out your implementation.


Let me just add a few remarks.

Auto-detection (or plug and play). I’m an old Unix guy and configuration and tuning is just part of the fun: I do not see a big problem here. Explicit is better than implicit.

User space vs. kernel space. OWFS is a user space tool, and it makes sense to keep everything in user-space: direct driving of the FTDI chip is an improvement (although configuration becomes a little bit more complicated).

Ease of use: maybe a little helper program could help: something that scans the USB bus, looks for FTDI chips, and prints the relevant libftdi description string.

Documentation: stress that the only sensible (permanent) address is s:<vendor>:<product>:<serial>. All other are basing on assumption that cannot always be met.

Instruction for the user could be:

1) unplug linkUSB
2) start libftdi-discover program
3) plug linkUSB
4) read output of libftdi-discover 
5) edit owfs.conf

libftdi-discover could even be (on *nix) just a couple of bash lines.

Stefano

 

On 25 Jan 2016, at 21:39, Johan Ström <[hidden email]> wrote:

Hi,

some of you may remember my earlier attempts to add a libftdi based LinkUSB interface into master. For reference: http://sourceforge.net/p/owfs/mailman/message/32492037/
In short, the client-timings are generally cut about 2.5 times, depending on operation. A temp sensor is read in ~50ms instead of ~123ms. More details can be found at the link.

Last time (2014) it was well received, but got stuck on discussions about different methods of auto-detection (something which isn't too easy/possible with FTDI).  I have since run that code in production without any glitches, so the ftdi-part has really proven stable.
In the recent days, I've cleaned up the code to not be LinkUSB specific, but rather work with any serial-based device (and fixed some minor issues). There is no auto-detection though (and again, I don't believe that is possible to do reliable with serial devices; see discussions in above link).

A cut from the (updated) man page is available below, please see that for usage details.
I realize that this isn't the simplest thing to explain to a user, but then again, a regular user who don't really care about those extra milliseconds shaved off each request can easily use the same old /dev/ttyS0 addressing. For us who *do* care however, it is very useful.

The ftdi parts of the code has been running since 2014, but only with LinkUSB. But it's mostly the device setup parts which has changed lately, so it shouldn't be any unstability. I've tested the LinkUSB, emulated and --link mode,  and DS2480 through a FTDi adapter without any issues.

I've commited all the changes in the new ftdi branch: http://sourceforge.net/p/owfs/code/ci/2982df8ca648bd9cec4d820151046b044ef504e0/
The above is a clean patch based on my earlier work (which may be interesting for those wanting to check out how it evolved) at http://sourceforge.net/u/stromnet/owfs/ci/ca85d64eefaaa9f1e90bbc079db65cfda623c472/log/?path=

One potential issue could be the BUS_close related changes in ow_connection.c, could someone take a look at that please? I think that is actually a bug fix, basically it calls device-specific BUS_close *before* cleaning up and closing the device, instead of after.. But an extra set of eyes would be great.

Another issue could be that I now bring any link-devices into 19200-mode after initial detection (also increases the speed a lot). This is the mode I've been running my LinkUSB during the last years, via the FTDI layer, so should be OK. But I have not tested with older links, or non-USB based links (or the linkusb via old serial addressing for any longer duration).

To sum it up, I hope we can get this branch merged into master sooner rather than later! If we want to add a sane auto-detection scheme somehow, let's add that later..

Any testing and feedback is much appreciated!

Regards
Johan

Man-page cut:
-------
* Serial devices
       port specifies a serial port, e.g.  /dev/ttyS0

       If OWFS was built with libftdi support, you may  be  able  to  use  the
       ftdi: prefix to address a FTDI-based USB device.
       For details, see the FTDI ADDRESSING section.

....
FTDI ADDRESSING
       FTDI  is  a brand of USB-to-serial chips which are very common. If your
       serial device is connected via a USB serial  dongle  based  on  a  FTDI
       chip,  or  if  your adapter uses a built-in FTDI USB chip (for example,
       the LinkUSB), you can use this FTDI addressing.

       The main benifit with this mode of access is that we can  decrease  the
       communication  delay,  yielding  twice  as fast 1-Wire communication in
       many cases.

       The following values for port can be used to identify a  specific  FTDI
       port.  Note that this requires that OWFS is built with libftdi support.

       ftdi:d:<devicenode>
              path of bus and device-node (e.g. "003/001") within  usb  device
              tree (usually at /proc/bus/usb/)

       ftdi:i:<vendor>:<product>
              first  device with given vendor and product id, ids can be deci-
              mal, octal (preceded by "0") or hex (preceded by "0x")

       ftdi:i:<vendor>:<product>:<index>
              as above with index being the number  of  the  device  (starting
              with 0) if there are more than one

       ftdi:s:<vendor>:<product>:<serial>
              first device with given vendor id, product id and serial string

       The  above formats are parsed fully by libftdi, but with the ftdi: pre-
       fix stripped.

   Simplified device serial-only support
       An additional format is supported, for certain  bus  types.  This  only
       specifies the USB serial number.

       ftdi:<serial>
              Identifies  a  FTDI  device  by serial only.  Currently, this is
              only valid for the VID/PID found on the LinkUSB  (i.e.  --link).
              Note that those VID/PID's are the default for any FT232R device,
              and in no way exclusive to LinkUSB.

-----
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3
Hi, thanks for your input!

On 27/01/16 18:40, Stefano Miccoli wrote:
Good news.

In a few days I will have an old LinkUSB available for testing, although with a limited number of sensors only: I will try-out your implementation.

Great! I've been running one LinkUSB and one DS2480B, FTDI-dongle, since I sent the email (so ~48h). Polling /uncached/alarm every 0.2s on each network, no issues.

Let me just add a few remarks.

Auto-detection (or plug and play). I’m an old Unix guy and configuration and tuning is just part of the fun: I do not see a big problem here. Explicit is better than implicit.
Agree

User space vs. kernel space. OWFS is a user space tool, and it makes sense to keep everything in user-space: direct driving of the FTDI chip is an improvement (although configuration becomes a little bit more complicated).
Well, from that point of view we're just using another interface (libusb instead of /dev/ttyXx).

Ease of use: maybe a little helper program could help: something that scans the USB bus, looks for FTDI chips, and prints the relevant libftdi description string.

Documentation: stress that the only sensible (permanent) address is s:<vendor>:<product>:<serial>. All other are basing on assumption that cannot always be met.
Instruction for the user could be:

1) unplug linkUSB
2) start libftdi-discover program
3) plug linkUSB
4) read output of libftdi-discover 
5) edit owfs.conf
Great idea!

libftdi-discover could even be (on *nix) just a couple of bash lines.
Hm, on FreeBSD I can do usbconfig dump_device_desc, on Linux I think it is lsusb? So, different tools and outputs for different OSes, suitable for humans rather than machines.
A simple libusb-based application which lists devices is only 10-15 rows or something, and would not be platform-dependent, so I'd rather use that.

Question is: build it into owserver, or standalone tool?

(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)

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3


On 27/01/16 23:09, Johan Ström wrote:
Hi, thanks for your input!

On 27/01/16 18:40, Stefano Miccoli wrote:
Good news.

In a few days I will have an old LinkUSB available for testing, although with a limited number of sensors only: I will try-out your implementation.

Great! I've been running one LinkUSB and one DS2480B, FTDI-dongle, since I sent the email (so ~48h). Polling /uncached/alarm every 0.2s on each network, no issues.

One think to point out though, I've only tested this on FreeBSD. So some Linux testing would be great!

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Jan Kandziora
In reply to this post by Johan Ström-3
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.


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.


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?

Kind regards

        Jan

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Stefano Miccoli
In reply to this post by Johan Ström-3
Minor glitch on module/owlib/src/c/ow_ftdi.c:

here you use MIN and MAX macros, which are defined in <sys/param.h>. Don’t ask me why, but this file is not included in linux:

— form ow.h:

#ifdef HAVE_SYS_TYPES_H
#ifdef __FreeBSD__
#include <sys/param.h>
#endif /* __FreeBSD__ */
#include <sys/types.h>                  /* for stat */
#endif                                                  /* HAVE_SYS_TYPES_H */

— 

Therefore your branch won’t compile… (or better won’t link.). MIN/MAX macros are frowned upon, so maybe if you positively like them you should  define them in ow_ftdi.c or better use an inline function… like this page suggests: https://dustri.org/b/min-and-max-macro-considered-harmful.html 

Please find a patch enclosed…

As what regards the libftdi-discover I would suggest a standalone tool… could be handy also independently from OWFS.

S.



On 27 Jan 2016, at 23:09, Johan Ström <[hidden email]> wrote:

Hi, thanks for your input!

On 27/01/16 18:40, Stefano Miccoli wrote:
Good news.

In a few days I will have an old LinkUSB available for testing, although with a limited number of sensors only: I will try-out your implementation.

Great! I've been running one LinkUSB and one DS2480B, FTDI-dongle, since I sent the email (so ~48h). Polling /uncached/alarm every 0.2s on each network, no issues.

Let me just add a few remarks.

Auto-detection (or plug and play). I’m an old Unix guy and configuration and tuning is just part of the fun: I do not see a big problem here. Explicit is better than implicit.
Agree

User space vs. kernel space. OWFS is a user space tool, and it makes sense to keep everything in user-space: direct driving of the FTDI chip is an improvement (although configuration becomes a little bit more complicated).
Well, from that point of view we're just using another interface (libusb instead of /dev/ttyXx).

Ease of use: maybe a little helper program could help: something that scans the USB bus, looks for FTDI chips, and prints the relevant libftdi description string.

Documentation: stress that the only sensible (permanent) address is s:<vendor>:<product>:<serial>. All other are basing on assumption that cannot always be met.
Instruction for the user could be:

1) unplug linkUSB
2) start libftdi-discover program
3) plug linkUSB
4) read output of libftdi-discover 
5) edit owfs.conf
Great idea!

libftdi-discover could even be (on *nix) just a couple of bash lines.
Hm, on FreeBSD I can do usbconfig dump_device_desc, on Linux I think it is lsusb? So, different tools and outputs for different OSes, suitable for humans rather than machines.
A simple libusb-based application which lists devices is only 10-15 rows or something, and would not be platform-dependent, so I'd rather use that.

Question is: build it into owserver, or standalone tool?

(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)

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

0001-fix-MIN-MAX-macro-problem.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3
In reply to this post by Jan Kandziora
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3
In reply to this post by Stefano Miccoli


On 27/01/16 23:45, Stefano Miccoli wrote:
Minor glitch on module/owlib/src/c/ow_ftdi.c:

here you use MIN and MAX macros, which are defined in <sys/param.h>. Don’t ask me why, but this file is not included in linux:

— form ow.h:

#ifdef HAVE_SYS_TYPES_H
#ifdef __FreeBSD__
#include <sys/param.h>
#endif /* __FreeBSD__ */
#include <sys/types.h>                  /* for stat */
#endif                                                  /* HAVE_SYS_TYPES_H */

— 

Therefore your branch won’t compile… (or better won’t link.). MIN/MAX macros are frowned upon, so maybe if you positively like them you should  define them in ow_ftdi.c or better use an inline function… like this page suggests: https://dustri.org/b/min-and-max-macro-considered-harmful.html 

Please find a patch enclosed…

Ah, thanks for pointing out! A patch has been pushed, but I placed min/max in ow_minmax.h instead for reusability (maybe it should be ow_min/ow_max instead?).

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3
In reply to this post by Johan Ström-3


On 28/01/16 08:16, Johan Ström wrote:

> On 27/01/16 23:42, Jan Kandziora wrote:
>> Am 27.01.2016 um 23:09 schrieb Johan Ström:
>>
>>
>> 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).

So, I now have a owusbprobe, commited in ftdi branch:
http://sourceforge.net/p/owfs/code/ci/d043952b83570ca5860018413887960a29522496/
Looks like this:

-----
$ ./module/owshell/src/c/owusbprobe
NOTE: You are running as a non-root user. Unless permissions are already
configured
you will probably not find any devices.

Please disconnect any USB devices you which to identify.
A bus scan will then be made to create a base-line of ignored devices.

Press Enter when you are ready to proceed

Scanning USB devices...
Found 0 devices
Please reconnect one of the device you which to identify.

When you are ready to proceed, wait a few seconds.
Then press Enter

Scanning USB devices...
Found 0 devices
No new devices detect.. Re-scanning in 2s...
Scanning USB devices...
Found 1 devices
Found device:
 > Vendor ID    : 0x0403               Product ID   : 0x6001
   Manufacturer : FTDI                 Description  : FT232R USB UART
   Serial       : A900xxxxxW        Bus: 5, Addr: 2

This device is identified as a generic FTDI adapter. To address it, use
the following adressing:

   ftd:s:0x0403:0x6001:A900xxxxxW

This MAY be a LinkUSB device. If so, you may put the following in your
owfs.conf:

   link = ftd:s:0x0403:0x6001:A900xxxxxW

Or, if running from command line:

   --link ftd:s:0x0403:0x6001:A900xxxxxW

If NOT a LinkUSB, you have to check the documentation on how to target
your particular device type.
For any serial type device, you should be able to use the above addressing.
------------------------------------------------------------------


If running as root, a message is printed after a match: "NOTE: You are
running as root. You may have to configure your OS to allow your user to
access the device. Please see owfs documentation for details."
If running with --all parameter, a non-interactive mode is activated
which just lists all found USB devices.
If the vid/pid matches any known FTDI chip, the above will be outputted.
If it is an exact vid/pid match for the LinkUSB, those LinkUSB specific
rows are outputted.
If the vid/pid matches the DS2490, a similar output is emitted.
If vid/pid does not match anything known, "This device is not a known
compatible device" is emitted.

What do you think?

Regards
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Jan Kandziora
Am 28.01.2016 um 23:38 schrieb Johan Ström:
>
> What do you think?
>
Sounds reasonable. But if you name it owusbprobe, it should be able to
detect DS9490 and DS9481, too.

Kind regards

        Jan

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3

On 28/01/16 23:58, Jan Kandziora wrote:
> Am 28.01.2016 um 23:38 schrieb Johan Ström:
>> What do you think?
>>
> Sounds reasonable. But if you name it owusbprobe, it should be able to
> detect DS9490 and DS9481, too.
>
Actually, I think DS9490 is based on the DS2490 chip, so that is
implicitly supported (but output can be more explicit)?

As for the DS9481, it seems to be based on the Prolific PL-2303HXD chip,
a generic adapter chip similar to the FTDI. Behind that, it emulates a
DS2480B (owfs source code doesn't even mention this adapter actually).
I don't see any specific VID/PID info in the Maxim datasheet, and
Prolific has default 0x067B, 0x2303. So, no way to tell user it *is* an
DS9481. (does anyone have any and can verify this?)
Also, since we don't have any Prolific layer (yet), we must use the
systems regular COM port emulation. This presents a new issue: doing so
cross-platform.

My suggestion for now (so we don't get stuck again, as last time):

a) be more explicit about DS9490 in text
b) detect prolific, and say that it *may* be a DS9481, but the user
himself must find out which TTY port it is located on.
c) Update the docs with owusbprobe, and some devd-notes for permissions
(unless we already have that?)

Future:
try to resolve usb device -> tty port, if possible.


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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3
On 29/01/16 08:28, Johan Ström wrote:
>
> Also, since we don't have any Prolific layer (yet), we must use the
> systems regular COM port emulation. This presents a new issue: doing so
> cross-platform.
>

Ehr, the issue is mapping the USB device to the correct /dev/ttyXX name
cross-platform, to show to the user. Not actually using it.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Jan Kandziora
In reply to this post by Johan Ström-3
Am 29.01.2016 um 08:28 schrieb Johan Ström:

>
> On 28/01/16 23:58, Jan Kandziora wrote:
>> Am 28.01.2016 um 23:38 schrieb Johan Ström:
>>> What do you think?
>>>
>> Sounds reasonable. But if you name it owusbprobe, it should be able to
>> detect DS9490 and DS9481, too.
>>
> Actually, I think DS9490 is based on the DS2490 chip, so that is
> implicitly supported (but output can be more explicit)?
>
In a multi-DS9490 setup, you may want to identify the adaptor by port.
We don't have a tool for that yet, so it would be nice if your tool
covers this, too. In the end, we can come up with a better scheme that
-u -u2 and so on.


> As for the DS9481, it seems to be based on the Prolific PL-2303HXD chip,
> a generic adapter chip similar to the FTDI. Behind that, it emulates a
> DS2480B (owfs source code doesn't even mention this adapter actually).
> I don't see any specific VID/PID info in the Maxim datasheet,
>
That information seems outdated. The adaptor board which came with my
DS28E17 eval kit says DS9481P-300 and it is based on a MAXQ1010 µC. Not
much else in there, the schematics from their datasheet don't match the
circuit at all.

So, don't check for a PL2303 in there but for 0b6a:5a03. The driver is
cdc_acm rather that pl2303. It works with owfs as a DS2480 on /dev/ttyACMx.

Kind regards

        Jan

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3


On 29/01/16 15:02, Jan Kandziora wrote:

> Am 29.01.2016 um 08:28 schrieb Johan Ström:
>> On 28/01/16 23:58, Jan Kandziora wrote:
>>> Am 28.01.2016 um 23:38 schrieb Johan Ström:
>>>> What do you think?
>>>>
>>> Sounds reasonable. But if you name it owusbprobe, it should be able to
>>> detect DS9490 and DS9481, too.
>>>
>> Actually, I think DS9490 is based on the DS2490 chip, so that is
>> implicitly supported (but output can be more explicit)?
>>
> In a multi-DS9490 setup, you may want to identify the adaptor by port.
> We don't have a tool for that yet, so it would be nice if your tool
> covers this, too. In the end, we can come up with a better scheme that
> -u -u2 and so on.
Would that be the one based on the device iteration order? Can someone
elaborate on how that digit is computed? From my quick look, it seems to
be a number incrementing
for every single USB device seen, regardless if it matched or not (might
be wrong, just glanced).

Does the DS9490/DS2490 has a serial number that could be used for proper
identification?

>
>> As for the DS9481, it seems to be based on the Prolific PL-2303HXD chip,
>> a generic adapter chip similar to the FTDI. Behind that, it emulates a
>> DS2480B (owfs source code doesn't even mention this adapter actually).
>> I don't see any specific VID/PID info in the Maxim datasheet,
>>
> That information seems outdated. The adaptor board which came with my
> DS28E17 eval kit says DS9481P-300 and it is based on a MAXQ1010 µC. Not
> much else in there, the schematics from their datasheet don't match the
> circuit at all.
Oh, ok. Both
https://www.maximintegrated.com/en/products/interface/controllers-expanders/DS9481R-200.html
and
https://www.maximintegrated.com/en/products/comms/ibutton/DS9481R-3C7.html
mentions Prolific.  Didn't even find DS9481P-300 until explicitly
searching for it.

>
> So, don't check for a PL2303 in there but for 0b6a:5a03. The driver is
> cdc_acm rather that pl2303. It works with owfs as a DS2480 on /dev/ttyACMx.
>
Great, then we can uniquely identify it at least. And ask user to use
/dev/ttyACM*something* at least, even if we cannot identify the port.

A note on identifying the port, I found this old thread:
http://owfs-developers.1086194.n5.nabble.com/tty2usb-td10852.html
Seems it was never finished, or fully resolved..
Given that, I'd like to skip any port-mapping attempts for the moment
and just merge the current ftdi support (with some improvements to the
tool).


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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Matthias Urlichs-3
In reply to this post by Stefano Miccoli
Hi,

On 27.01.2016 23:45, Stefano Miccoli wrote:
> #ifdef HAVE_SYS_TYPES_H
> #ifdef __FreeBSD__
> #include <sys/param.h>

Umm, why doesn't this code use HAVE_SYS_PARAM_H ??

--
-- Matthias Urlichs


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Jan Kandziora
In reply to this post by Johan Ström-3
Am 29.01.2016 um 15:17 schrieb Johan Ström:
>
> Would that be the one based on the device iteration order? Can
> someone elaborate on how that digit is computed? From my quick look,
> it seems to be a number incrementing for every single USB device
> seen, regardless if it matched or not (might be wrong, just
> glanced).
>
Yes, it is that way, not even stable between reboots, as kernel/hardware
enumeration may permute it at will.


>
> Does the DS9490/DS2490 has a serial number that could be used for
> proper identification?
>
The DS2490 hasn't but I doubt there are any DS2490-based adaptors but
the DS9490 out in the wild as the chip isn't available outside of it for
a long time now.

The DS9490 has a built-in DS2401 with family code 81. OWFS currently
uses that chip to identify the DS9490 over USB disconnects which may
happen from time to time, so the enumeration is stable with an owlib
program as long at it is running.

It should be easy to build a very small libusb based program which just
issues the 0x0f Read ROM command on a DS9490, then read back the
provided id. DS2401 are the only chips reacting to that command so if no
iButton is connected to the bus it would also work for a populated bus.


Kind regards

        Jan



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3
In reply to this post by Stefano Miccoli

On 27/01/16 18:40, Stefano Miccoli wrote:
Good news.

In a few days I will have an old LinkUSB available for testing, although with a limited number of sensors only: I will try-out your implementation.


Stefano,

did you get any chance to give my ftdi code a spin?

Regards
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=272487151&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3
In reply to this post by Matthias Urlichs-3

On 29/01/16 16:54, Matthias Urlichs wrote:
> Hi,
>
> On 27.01.2016 23:45, Stefano Miccoli wrote:
>> #ifdef HAVE_SYS_TYPES_H
>> #ifdef __FreeBSD__
>> #include <sys/param.h>
> Umm, why doesn't this code use HAVE_SYS_PARAM_H ??
>
No idea, was not introduced in the ftdi branch. I've commited a fix
there now though.


------------------------------------------------------------------------------
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=272487151&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Johan Ström-3
In reply to this post by Jan Kandziora

On 29/01/16 15:02, Jan Kandziora wrote:

> Am 29.01.2016 um 08:28 schrieb Johan Ström:
>
>
>> As for the DS9481, it seems to be based on the Prolific PL-2303HXD chip,
>> a generic adapter chip similar to the FTDI. Behind that, it emulates a
>> DS2480B (owfs source code doesn't even mention this adapter actually).
>> I don't see any specific VID/PID info in the Maxim datasheet,
>>
> That information seems outdated. The adaptor board which came with my
> DS28E17 eval kit says DS9481P-300 and it is based on a MAXQ1010 µC. Not
> much else in there, the schematics from their datasheet don't match the
> circuit at all.
>
> So, don't check for a PL2303 in there but for 0b6a:5a03. The driver is
> cdc_acm rather that pl2303. It works with owfs as a DS2480 on /dev/ttyACMx.
>
I've now updated the probe to output the following:

vid=0x067B, pid=0x2303
"This device is identified as a generic Prolific USB adapter.
It MAY be a DS9481 adapter. If it is, you need to use the DS2480B device,
and point it to the appropriate /dev/ttyUSBx device."

vid =0x0B6A, pid = 0x5A03
"This device is identified as a DS18E17 / DS9481P-300 USB adapter.
To use this, you need to use the DS2480B device, and point it to
the appropriate /dev/ttyACMx device"

both have instructions to use --device

Also, the DS2490/DS9490 detection now says "This device is identified as
a DS2490 / DS9490 USB adapter."

Have I got everything right now?

--
I've had another idea. We are asking user to unplug device to get a
baseline, and then reconnect the device and scan, to discover the one
new device. We could scan /dev/ for new tty/cua/acm devices in the same
way, and at least present the user with a suggestion (and some warnings
that it is unstable).
Of course this will not work for the -a mode (list all), but it is at
least useful in some cases.

What do you think?


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=272487151&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: libftdi support: take 2

Jan Kandziora
Am 04.02.2016 um 23:11 schrieb Johan Ström:
>
> vid =0x0B6A, pid = 0x5A03
> "This device is identified as a DS18E17 / DS9481P-300 USB adapter.
> To use this, you need to use the DS2480B device, and point it to
> the appropriate /dev/ttyACMx device"
>
Skip the DS28E17 part, as the adapter is part of some other Maxim
onewire eval kits, too, and I think also available separately.


>
> I've had another idea. We are asking user to unplug device to get a
> baseline, and then reconnect the device and scan, to discover the one
> new device. We could scan /dev/ for new tty/cua/acm devices in the same
> way, and at least present the user with a suggestion (and some warnings
> that it is unstable).
> Of course this will not work for the -a mode (list all), but it is at
> least useful in some cases.
>
> What do you think?
>
That would be most useful. It's an interactive tool after all, not
something to be built into scripts.

Kind regards

        Jan



------------------------------------------------------------------------------
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=272487151&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
12