Quantcast

(Re:) libftdi only works if /dev/ttyUSBx is accessed by other method first

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

(Re:) libftdi only works if /dev/ttyUSBx is accessed by other method first

Johan Ström
Hi,

I had a problem with a FT232R based device, the LinkUSB 1-wire dongle, and my libftdi-based owfs (software package).
The issue was, after boot and/or device reconnect, I was not able to communicate at all with my device, but once I had interacted with it using the OS serial layer, it worked perfectly fine.

Upon researching the issue I found http://developer.intra2net.com/mailarchive/html/libftdi/2012/msg00331.html, which described the
exact same issue, but gave no solution.

In my case, I found the solution!
The FreeBSD (10.2) ucom/uftdi driver (provides /dev/cuaUx from FTDI devices) will, upon first open(), set RTS and DTR to 1.
By adding ftdi_setdtr_rts(ctx, 1, 1) to my code, it now works fine even if freshly booted and/or reconnected.
I did try setting SIO_RTS_CTS_HS instead, but that did not help at all.. Also, it seems it is enough to set RTS 1 and leave DTR 0.

So, three things:
a) Pelle Windestam (whom I cannot CC, since the email is hidden), I found a solution! Maybe it works for you too :)
b) Anyone else with the same problem, try this!
c) Would it make sense for libftdi to set rts/dts defaults to 1, as both Linux and FreeBSD seems to do this (when opening as a regular serial port)? Although, devices may use RTS/DTR for any purpose, it might be best to leave it alone..?

Anyway, this info might spare someone else trying to debug it!

Regards
Johan


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: (Re:) libftdi only works if /dev/ttyUSBx is accessed by other method first

Rogier Wolff
Hi,

Occasional reader, here...

On Sat, Jan 23, 2016 at 03:29:50PM +0100, Johan Ström wrote:
> c) Would it make sense for libftdi to set rts/dts defaults to 1, as
> both Linux and FreeBSD seems to do this (when opening as a regular
> serial port)? Although, devices may use RTS/DTR for any purpose, it
> might be best to leave it alone..?

The setting of CTS/RTS is "standard" when opening a serial port. The
default for those signals is "inactive": "please don't send anything,
there is (probably) nobody listening".

Once you open the port, the signal should go active: "we're listening,
go ahead, send data.".

However, for "other-than-standard-serial-port" devices, where you'd
want a libftdi driver, the signal might be used for completely
different purposes. Say: "Detonate the bomb".

So a default in libftdi to set the signal might not be a good idea.

If you need it, the "set the signal" belongs in the layer that uses
libftdi. "libow" or whatever it is called in your case.

        Roger.

--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: (Re:) libftdi only works if /dev/ttyUSBx is accessed by other method first

Johan Ström
Hi,

On 24/01/16 19:34, Rogier Wolff wrote:

> Hi,
>
> Occasional reader, here...
>
> On Sat, Jan 23, 2016 at 03:29:50PM +0100, Johan Ström wrote:
>> c) Would it make sense for libftdi to set rts/dts defaults to 1, as
>> both Linux and FreeBSD seems to do this (when opening as a regular
>> serial port)? Although, devices may use RTS/DTR for any purpose, it
>> might be best to leave it alone..?
> The setting of CTS/RTS is "standard" when opening a serial port. The
> default for those signals is "inactive": "please don't send anything,
> there is (probably) nobody listening".
>
> Once you open the port, the signal should go active: "we're listening,
> go ahead, send data.".
>
> However, for "other-than-standard-serial-port" devices, where you'd
> want a libftdi driver, the signal might be used for completely
> different purposes. Say: "Detonate the bomb".
>
> So a default in libftdi to set the signal might not be a good idea.
>
> If you need it, the "set the signal" belongs in the layer that uses
> libftdi. "libow" or whatever it is called in your case.
>
> Roger.
>
Yep, all good examples of why it would be a bad idea! Don't want to blow
any bombs prematurely.. :)

One thing I don't understand though.. the RTS pin of the FTDI chip isn't
actually tied to the chip (a PIC with RX/TX), as far as I know.. I
cannot open the device to verify, but there is a similar device for OEM
installations, and this does not expose anything but RX/TX..
So not sure why enabling RTS is required in this case.. Any ideas?

Anyway, anyone who does standard-serial-port stuff needs to be aware
that this should be done!
In my case, the only reason I use libftdi directly is to be able to tune
down the latency timer, to increases the throughput (a lot when dealing
with small transfers).

Johan


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]

Loading...