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
<mailto: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
<mailto: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
------------------------------------------------------------------------------
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