ftdi-usb-sio-devel — FTDI USB Device Driver development discussion list

Re: [Ftdi-usb-sio-devel] [SOLVED] Baudrate setting is broken.

[Bill R. <bil...@gm...>]

Hi there,

The c_cflag settings don't set the baud rate.

They set other communications modes like stop bits, parity etc.

So you can't set the baudrate in c_cflag.

You've solved the problem yourself by calling the speed setting functions.

You should remove the baudr from your c_cflag setting also because you
might be settings things you don't want to accidentally.



Here's the posix documentation

http://pubs.opengroup.org/onlinepubs/7908799/xsh/termios.h.html

and the linux documentation

http://man7.org/linux/man-pages/man3/termios.3.html


Enjoy serial programming!

Bill


On Tue, Sep 30, 2014 at 4:58 AM, Teunis van Beelen <te...@gm...> wrote:
> Dear maintainers,
>
> It looks like I solved the problem.
>
> I was using this code to set the params for the serial port:
>
>   new_port_settings.c_cflag = baudr | cbits | cpar | bstop | CLOCAL | CREAD;
>   new_port_settings.c_iflag = IGNPAR;
>   new_port_settings.c_oflag = 0;
>   new_port_settings.c_lflag = 0;
>   new_port_settings.c_cc[VMIN] = 0;      /* block untill n bytes are received */
>   new_port_settings.c_cc[VTIME] = 0;     /* block untill a timer
> expires (n * 100 mSec.) */
>   cfsetispeed(&new_port_settings, baudr);
>   cfsetospeed(&new_port_settings, baudr);
>   error = tcsetattr(Cport[comport_number], TCSANOW, &new_port_settings);
>
> After adding the next two lines to my sourcecode, it works fine:
>
> cfsetispeed(&new_port_settings, baudr);
> cfsetospeed(&new_port_settings, baudr);
>
> So, this means that setting the baudrate with:
>
> new_port_settings.c_cflag = baudr | cbits | cpar | bstop | CLOCAL | CREAD;
>
> is not sufficient??
>
> (baudr is an int that contains the value B9600 or B19200, etc.)
>
> Sorry for bothering,
>
> Best Regards,
>
> Teunis van Beelen
>
>
> --
> "C'è qualcosa nella nebbia! Qualcosa nella nebbia ha preso John Lee!"
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel

[Ftdi-usb-sio-devel] [SOLVED] Baudrate setting is broken.

[Teunis v. B. <te...@gm...>]

Dear maintainers,

It looks like I solved the problem.

I was using this code to set the params for the serial port:

  new_port_settings.c_cflag = baudr | cbits | cpar | bstop | CLOCAL | CREAD;
  new_port_settings.c_iflag = IGNPAR;
  new_port_settings.c_oflag = 0;
  new_port_settings.c_lflag = 0;
  new_port_settings.c_cc[VMIN] = 0;      /* block untill n bytes are received */
  new_port_settings.c_cc[VTIME] = 0;     /* block untill a timer
expires (n * 100 mSec.) */
  cfsetispeed(&new_port_settings, baudr);
  cfsetospeed(&new_port_settings, baudr);
  error = tcsetattr(Cport[comport_number], TCSANOW, &new_port_settings);

After adding the next two lines to my sourcecode, it works fine:

cfsetispeed(&new_port_settings, baudr);
cfsetospeed(&new_port_settings, baudr);

So, this means that setting the baudrate with:

new_port_settings.c_cflag = baudr | cbits | cpar | bstop | CLOCAL | CREAD;

is not sufficient??

(baudr is an int that contains the value B9600 or B19200, etc.)

Sorry for bothering,

Best Regards,

Teunis van Beelen


-- 
"C'è qualcosa nella nebbia! Qualcosa nella nebbia ha preso John Lee!"

[Ftdi-usb-sio-devel] Baudrate setting is broken.

[Teunis v. B. <te...@gm...>]

Dear driver maintainers,

There is a serious bug regarding setting the baudrate.

Certain standard baudrates produce wrong baudrates during transmit:

baudrate set   baudrate produced

1200  ->  9600
2400  ->  +/-35700

4800  ->  4800
9600  ->  9600
19200  ->  19200
38400  ->  38400

57600  ->  +/-500000
115200  ->  +/-570000

As you can see, baudrates lower than 4800 or higher than 38400 are set wrong.

I measured this using an oscilloscope. Other parameters I used: 8
databits, no parity, 1 stopbit.

I did check this with two different converters from FTDI and Prolific:

idVendor=0403, idProduct=6001

idVendor=067b, idProduct=2303

I checked it with a desktop pc running openSuse 12.3 64-bit with
kernel 3.7.10 and
a laptop running Ubuntu 14.04 32-bit with kernel 3.13.0

Both converters work correctly on windows 7.

For the tests I used this code: http://www.teuniz.net/RS-232/

Let me know if you need more info/tests/measurements.

I hope you can fix this.

Best Regards,

Teunis van Beelen


-- 
"C'è qualcosa nella nebbia! Qualcosa nella nebbia ha preso John Lee!"

Re: [Ftdi-usb-sio-devel] Connection losses on Sanguinololu

[Bill R. <bil...@gm...>]

Perhaps there's some kind of usb hardware problem going on here.

You could try a different USB port, USB cable, or even connecting
through a USB hub.

The USB stack is seeing the device disconnect but not giving an error
condition. Is the 3D printer restarting the interface for some reason
perhaps?



On Mon, Jul 21, 2014 at 8:17 AM, JPT <j-...@gm...> wrote:
> Hi,
>
> is this the driver that's still built into kernel 3.6?
>
> I built a 3d printer using a Sanguinololu.
> I am experiencing connection losses. This is very annyoing in the middle
> of a print.
>
> Sanguinololu has got an onboard FT232RL (Vendor=0403, Product=6001)
>
> I tried to switch on debug log, but did not get additional output in syslog:
>   sudo modprobe ftdi_sio vendor=0x403 product=0x6001 debug
>
> When a connection loss occurs, the following is logged:
>
> 20:50:14 kernel: [245476.341732] usb 3-12: USB disconnect, device number 57
> 20:50:14 kernel: [245476.342111] ftdi_sio ttyUSB0: FTDI USB Serial
> Device converter now disconnected from ttyUSB0
> 20:50:15 kernel: [245476.611948] usb 3-12: new full-speed USB device
> number 58 using xhci_hcd
> 20:50:15 kernel: [245476.633980] usb 3-12: New USB device found,
> idVendor=0403, idProduct=6001
> 20:50:15 kernel: [245476.633990] usb 3-12: New USB device strings:
> Mfr=1, Product=2, SerialNumber=3
> 20:50:15 kernel: [245476.633995] usb 3-12: Product: FT232R USB UART
> 20:50:15 kernel: [245476.633999] usb 3-12: Manufacturer: FTDI
> 20:50:15 kernel: [245476.634003] usb 3-12: SerialNumber: AH01R0T7
> 20:50:15 kernel: [245476.636987] ftdi_sio 3-12:1.0: FTDI USB Serial
> Device converter detected
> 20:50:15 kernel: [245476.637051] usb 3-12: Detected FT232RL
> 20:50:15 kernel: [245476.637056] usb 3-12: Number of endpoints 2
> 20:50:15 kernel: [245476.637060] usb 3-12: Endpoint 1 MaxPacketSize 64
> 20:50:15 kernel: [245476.637064] usb 3-12: Endpoint 2 MaxPacketSize 64
> 20:50:15 kernel: [245476.637068] usb 3-12: Setting MaxPacketSize 64
> 20:50:15 kernel: [245476.637423] usb 3-12: FTDI USB Serial Device
> converter now attached to ttyUSB1
>
> so, it's almost instantly reconnected, but with different device file,
> because the old one is still in use by Pronterface.
>
> How could I solve this problem?
>
> thanks,
>
> JPT
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel

[Ftdi-usb-sio-devel] Connection losses on Sanguinololu

[JPT <j-...@gm...>]

Hi,

is this the driver that's still built into kernel 3.6?

I built a 3d printer using a Sanguinololu.
I am experiencing connection losses. This is very annyoing in the middle
of a print.

Sanguinololu has got an onboard FT232RL (Vendor=0403, Product=6001)

I tried to switch on debug log, but did not get additional output in syslog:
  sudo modprobe ftdi_sio vendor=0x403 product=0x6001 debug

When a connection loss occurs, the following is logged:

20:50:14 kernel: [245476.341732] usb 3-12: USB disconnect, device number 57
20:50:14 kernel: [245476.342111] ftdi_sio ttyUSB0: FTDI USB Serial
Device converter now disconnected from ttyUSB0
20:50:15 kernel: [245476.611948] usb 3-12: new full-speed USB device
number 58 using xhci_hcd
20:50:15 kernel: [245476.633980] usb 3-12: New USB device found,
idVendor=0403, idProduct=6001
20:50:15 kernel: [245476.633990] usb 3-12: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
20:50:15 kernel: [245476.633995] usb 3-12: Product: FT232R USB UART
20:50:15 kernel: [245476.633999] usb 3-12: Manufacturer: FTDI
20:50:15 kernel: [245476.634003] usb 3-12: SerialNumber: AH01R0T7
20:50:15 kernel: [245476.636987] ftdi_sio 3-12:1.0: FTDI USB Serial
Device converter detected
20:50:15 kernel: [245476.637051] usb 3-12: Detected FT232RL
20:50:15 kernel: [245476.637056] usb 3-12: Number of endpoints 2
20:50:15 kernel: [245476.637060] usb 3-12: Endpoint 1 MaxPacketSize 64
20:50:15 kernel: [245476.637064] usb 3-12: Endpoint 2 MaxPacketSize 64
20:50:15 kernel: [245476.637068] usb 3-12: Setting MaxPacketSize 64
20:50:15 kernel: [245476.637423] usb 3-12: FTDI USB Serial Device
converter now attached to ttyUSB1

so, it's almost instantly reconnected, but with different device file,
because the old one is still in use by Pronterface.

How could I solve this problem?

thanks,

JPT

Re: [Ftdi-usb-sio-devel] Problems with FT245 on ttyUSB0

[Ralph L. <suc...@ih...>]

Also, is the board designed to operate with the FT245 in synchronous or
async mode?

The sync. mode requires the strobes on the FT245 to be driven
externally (e.g., by a microcontroller) - this is the default I think.

The easiest way to set the mode is probably to use libftdi - it has
python bindings.

Ralph.

On Thu, 18 Apr 2013 13:19:19 -0400
Ryan Neve <ne...@em...> wrote:

> I'm having trouble with a FT245RL based USB-relay board. It should be 
> easy enough to use. When I plug it in it appears as a serial port. I 
> send it three bytes which tell it what to turn on and off. E.g. 
> \xFF\x01\x01 turns on just relay 1 and \xff\x01\x00 turns everything off.
> 
> I wrote a very simple python program to test this on a Debian squeeze 
> machine:
> 
> import serial
> ser = serial.Serial('/dev/ttyUSB0') # Defaults to 9600 8N1
> ser.open()
> ser.write(chr(255) + chr(1) + chr(1))
> ser.close
> 
> ...and nothing happened no matter how much I fiddled. usually I get 
> nothing, and sometimes it blocks when I write. I installed the drivers 
> on a win7x64 machine, and changed one line to point to COM3, it works 
> great. I then tried it on a CentOS5 machine and it doesn't work here 
> either. I don't think it is permissions, I've added the users to the 
> dialout and uucp groups respectively. I've also tried it as root. I was 
> able to set up a udev rule on Debian which seems to work.
> 
> I'm wondering if there might be a problem with ftdi_sio? I'm a little 
> over my head, but I did this:
> 
> #/sbin/modprobe ftdi_sio vendor=0x403 product=0x6001 debug
> 
> and
> 
> #dmesg | grep ftdi
> [71621.091869] ftdi_sio ttyUSB0: ftdi_submit_read_urb - failed 
> submitting read urb, error -1
> [74607.375564] ftdi_sio ttyUSB0: ftdi_submit_read_urb - failed 
> submitting read urb, error -1
> 
> Ftdi has a Linux driver on their web site, but I think my kernels should 
> be new enough (2.6.33.7.2-rt30-1-686 and 
> 2.6.18-348.3.1.el5.centos.plusPAE) to not need it. If I do need it, is 
> there a guide on how to install available?
> 
> Thanks.
> -- 
> *Ryan Neve*
> University of North Carolina
> Institute of Marine Sciences
> 3431 Arendell St
> Morehead City, NC 28557
> (252) 726-6841 x179
> (252) 726.2426 Fax
> 

Re: [Ftdi-usb-sio-devel] Problems with FT245 on ttyUSB0

[Ralph L. <suc...@ih...>]

> I'm not convinced that the current ftdi_sio driver is working properly.
> I've been trying to use it and it behaves, well, strangely.  I posted
> a question about it here on April 5th and there's been no reply.

There were two replies (check the list archives), but Mr Haywoods email
was bouncing...

FWIW, the driver is working fine for me.  At first sight it did appear
that Mr Haywood was not using the ftdi_sio driver at all...

> FWIW this list seems to be dead.

Definitely alive.  Your email was dead, see failure headers below.

Cheers,
Ralph.


Subject: Delivery Status Notification (Failure)
Date: 09 Apr 2013 07:56:20 +1200

The following message to <ft...@ju...> was undeliverable.
The reason for the problem:
5.4.7 - Delivery expired (message too old) 'timeout'


Reporting-MTA: dns; filter7.content.vf.net.nz

Final-Recipient: rfc822;ft...@ju...
Action: failed
Status: 5.0.0 (permanent failure)
Diagnostic-Code: smtp; 5.4.7 - Delivery expired (message too old)
'timeout' (delivery attempts: 0)


> 
> --
> 
> 73,
> Ged.
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel

Re: [Ftdi-usb-sio-devel] Problems with FT245 on ttyUSB0

[Ralph L. <suc...@ih...>]

Ryan,

Is anything else talking to the device and confusing it?  ModemManager is one possible culprit, I have that disabled via a udev rule:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ENV{ID_MM_DEVICE_IGNORE}="1"

> but I think my kernels should 
> be new enough (2.6.33.7.2-rt30-1-686 and 
> 2.6.18-348.3.1.el5.centos.plusPAE) to not need it. If I do need it, is 
> there a guide on how to install available?

Those kernels are quite old.  There have been many changes to the ftdi_sio driver since.  I would sanity check with newer kernels, the easiest way to do that might be to download a bootable CD image.

Cheers,
Ralph.

> 
> Thanks.
> -- 
> *Ryan Neve*
> University of North Carolina
> Institute of Marine Sciences
> 3431 Arendell St
> Morehead City, NC 28557
> (252) 726-6841 x179
> (252) 726.2426 Fax
> 

Re: [Ftdi-usb-sio-devel] Problems with FT245 on ttyUSB0

[G.W. H. <ft...@ju...>]

Hi there,

On Thu, 18 Apr 2013, Ryan Neve wrote:

> I'm having trouble with a FT245RL based USB-relay board. ...
> I wrote a very simple python program to test this on a Debian squeeze 
> machine: ...and nothing happened no matter how much I fiddled. ...
> I'm wondering if there might be a problem with ftdi_sio?

I'm not convinced that the current ftdi_sio driver is working properly.
I've been trying to use it and it behaves, well, strangely.  I posted
a question about it here on April 5th and there's been no reply.

> #/sbin/modprobe ftdi_sio vendor=0x403 product=0x6001 debug

I did some digging and according to the latest kernel code the methods
for enabling debug information have changed.  I don't know when, so I
don't know if it affects your kernel/modules.  The documentation in
the kernel tree still refers to the old methods of enabling debugging
which give me nothing but kernel errors and cause the module not to load.

> #dmesg | grep ftdi
> [71621.091869] ftdi_sio ttyUSB0: ftdi_submit_read_urb - failed submitting 
> read urb, error -1
> [74607.375564] ftdi_sio ttyUSB0: ftdi_submit_read_urb - failed submitting 
> read urb, error -1

I'm not sure if that's debug output or normal (problem) output.

> Ftdi has a Linux driver on their web site, but I think my kernels should be 
> new enough (2.6.33.7.2-rt30-1-686 and 2.6.18-348.3.1.el5.centos.plusPAE) to 
> not need it. If I do need it, is there a guide on how to install available?

I think they might be keeping that older version of the driver on
their site because it works, but I don't know that it works.  I
haven't got a kernel old enough to try it but until I ran into some
other more pressing issues at work, after setting up a Windows VM to
try that was next idea on my list.

FWIW this list seems to be dead.

--

73,
Ged.

Re: [Ftdi-usb-sio-devel] Continuous stream of characters sent by ftdi_sio driver.

[Bill R. <bil...@gm...>]

Definitely use the stock kernel driver it is the definitive version.

You are almost certainly not using the ftdi_sio driver if you are seeing
the stream of bytes.

See http://ftdi-usb-sio.sourceforge.net/ for notes on how to load the
driver for a vid/pid which is not registered with your kernel.

In particular: http://ftdi-usb-sio.sourceforge.net/#sec7

---
Bill








On Sat, Apr 6, 2013 at 8:37 AM, Ralph Loader <suc...@ih...> wrote:

> Hi,
>
> > when I use the 'generic' driver instead of ftdi_sio.
> >
> > 1. The driver appears to be sending a constant stream of characters to
> > the computer (i.e. to the machine with the USB port).  The characters
> > are alternatiely 0x01 and 0x60.
>
> The USB data packets sent by the FTDI devices all start with 2 bytes of
> modem status bits.  It sounds like these are what you are seeing.  The
> ftdi_sio driver is expected to remove them.
>
> I would expect you to see these with the 'generic' USB serial driver, but
> the ftdi_sio driver definately should be stripping those off before the
> data gets to minicom.
>
> Is it possible that somehow the ftdi_sio driver failed to attach and
> instead the generic driver was always grabbing the device?  If you haven't
> already, check the kernel messages in /var/log/* to make sure that the
> ftdi_sio driver really is being used.
>
> > The version of the driver available on the FTDI website is very old,
>
> My experience with ftdi devices and Linux is that it is prefereable to use
> the stock kernel driver, or libusb/libftdi, rather than the FTDI code.
>
> Cheers,
> Ralph.
>
> > and contains a comment which refers to symptoms such as I am seeing.
> > Unfortunately this version of the driver does not compile for 3.8.3
> > and before I delve more deeply into the code I'm hoping that someone
> > with more intimate knowledge of the driver will be able to point me in
> > the right direction to fix it.
> >
> > --
> >
> > 73,
> > Ged.
> >
> >
> ------------------------------------------------------------------------------
> > Minimize network downtime and maximize team effectiveness.
> > Reduce network management and security costs.Learn how to hire
> > the most talented Cisco Certified professionals. Visit the
> > Employer Resources Portal
> > http://www.cisco.com/web/learning/employer_resources/index.html
> > _______________________________________________
> > Ftdi-usb-sio-devel mailing list
> > Ftd...@li...
> > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>

Re: [Ftdi-usb-sio-devel] Continuous stream of characters sent by ftdi_sio driver.

[Ralph L. <suc...@ih...>]

Hi,

> when I use the 'generic' driver instead of ftdi_sio.
> 
> 1. The driver appears to be sending a constant stream of characters to
> the computer (i.e. to the machine with the USB port).  The characters
> are alternatiely 0x01 and 0x60.

The USB data packets sent by the FTDI devices all start with 2 bytes of modem status bits.  It sounds like these are what you are seeing.  The ftdi_sio driver is expected to remove them.

I would expect you to see these with the 'generic' USB serial driver, but the ftdi_sio driver definately should be stripping those off before the data gets to minicom.

Is it possible that somehow the ftdi_sio driver failed to attach and instead the generic driver was always grabbing the device?  If you haven't already, check the kernel messages in /var/log/* to make sure that the ftdi_sio driver really is being used.

> The version of the driver available on the FTDI website is very old,

My experience with ftdi devices and Linux is that it is prefereable to use the stock kernel driver, or libusb/libftdi, rather than the FTDI code.

Cheers,
Ralph.

> and contains a comment which refers to symptoms such as I am seeing.
> Unfortunately this version of the driver does not compile for 3.8.3
> and before I delve more deeply into the code I'm hoping that someone
> with more intimate knowledge of the driver will be able to point me in
> the right direction to fix it.
> 
> --
> 
> 73,
> Ged.
> 
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire 
> the most talented Cisco Certified professionals. Visit the 
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel

[Ftdi-usb-sio-devel] Continuous stream of characters sent by ftdi_sio driver.

[G.W. H. <ft...@ju...>]

Hi there,

Recently I've been having trouble with a number of Seagate 'Barracuda'
hard drives, and one of the issues appears to be resolvable by means
of sending commands to the drive through a TTL-level serial interface
which apart from the voltage levels otherwise somewhat adheres to the
EIA/TIA-232 standard.  This USB/TTL-level serial interface converter
is available from a firm called KMtronic:

http://sigma-shop.com/product/112/ft232bm-bl-seagate-barracuda-7200-11-firmware-fix-tool-complete-usb-powered.html

It seems to work for most people who use it, but most people use what
I shall call a different operating system. :)

Under Linux, lsusb -v gives:

Bus 004 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

The current Linux kernel driver for this device is ftdi_sio.  When I
installed it in a Slackware box with a 3.8.3 kernel it failed with the
symptoms below.  Normally I use minicom for serial comms but the same
problem appears with another serial terminal package.  The same also
when I use the 'generic' driver instead of ftdi_sio.

1. The driver appears to be sending a constant stream of characters to
the computer (i.e. to the machine with the USB port).  The characters
are alternatiely 0x01 and 0x60.

2. Activity is seen on the LEDs on the USB-serial device itself only
when expected, i.e. when typing characters at the terminal (Tx LED)
and receiving them from the connected equipment (Rx LED).

3. When the converter is connected in a loopback arrangement, all the
characters sent via the serial terminal application (minicom) to the
device are echoed back properly from the serial output to the input as
expected, but they are interspersed with the continuous stream of 0x01
and 0x60 characters.

I'm pretty sure that the hardware is working OK.

The version of the driver available on the FTDI website is very old,
and contains a comment which refers to symptoms such as I am seeing.
Unfortunately this version of the driver does not compile for 3.8.3
and before I delve more deeply into the code I'm hoping that someone
with more intimate knowledge of the driver will be able to point me in
the right direction to fix it.

--

73,
Ged.

[Ftdi-usb-sio-devel] Strange behaviour discovered

[Valentin K. <val...@go...>]

Hello everyone,

For those who may be interessted (yeah, i'm laughing too :D):
I have written a year ago regarding low baudrates. The problem was solved a 
couple of days later: The reading device was not fast enough to process the 
input. The solution was (in this case :D) to increase stop-bits to 2.

To understand what I am talking about I first need to explain what is the 
environment:

I am working on an high-speed electricity measurement device. This device is 
run by an Atmel AtMega1280 (18 Mhz) and uses the "Bus 003 Device 009: ID 
0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-
UART/FIFO IC" FTDI chip for communication. The communication partners are 
standard personal computers running ubuntu 12.10 (linux 3.2.0-35-generic). 
Those machines run a variety of perl-scripts to communicate with the device. 
The scripts are using the "Device::SerialPort" package.

As you can see from the lsusb output the ftdi chip offers two serial ports. 
They are both used for the communication with the device and opened / closed 
independently.

A couple of weeks ago someone stated that he "could not connected to the 
device" when using some scripts multiple times. My first though was: Broken 
scripts, however i have discovered that they are not and further more that the 
problem may lie in other system components.

It "sometimes" happen that closing one serial port while the other one is 
opened, both serial ports some kind of get broken.

With broken I mean concretely:
The posix call "open(serialPort, O_RDWR | O_NOCTTY | O_NONBLOCK) blocks a 
while (on my machine, 17 seconds) and the driver prints errors to the kernel 
log. Afterwards the serial port is opened and works for the "session". When 
closing and reopening the port, it randomly opens correctly or not.

Those errors are printed to kernel log:
[18033.824011] ftdi_sio ttyUSB1: ftdi_set_termios FAILED to set 
databits/stopbits/parity
[18034.776535] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[18044.762011] ftdi_sio ttyUSB0: urb failed to clear flow control

I was able to reproduce this behaviour with 100% hit rate. I have written a 
small C-programm that just opens and closes a serialport forever. Running this 
programm twice, one for each port, will result in hanging "open(...)" 
syscalls. The programm is attached.

As i am no driver developer nor chip expert i cannot say whats going on and 
seek for help. I speculated that it could be a reentrance problem within the 
ftdi-driver or another kernel module (i could be really wrong :D), or the chip 
does things I do not understand :D

Many thanks in advance

Valentin Kautz

Re: [Ftdi-usb-sio-devel] Extending the ftdi_sio driver for RS-485 usage with the FT4232H

[Bill R. <bil...@gm...>]

Hi there,

The driver does not set the pin direction of any channel. It doesn't
need to for RS232 mode.

And the interface the driver implements was never designed to talk
that protocol.

You will need to ask ftdi to tell you how to do that.

Also libftdi is definitely your best bet because it can talk directly
to the chip how ever you like.

http://www.intra2net.com/en/developer/libftdi/links.php


On Sat, Jul 7, 2012 at 7:29 AM, Matt Barclay <mba...@gm...> wrote:
> Hello,
>
> Looking for some help understanding the ftdi_sio driver.  I've used the
> libftdi interface to this chip before and I'm not seeing many parallels in
> the Kernel driver.
>
> In the RS-485 configuration for the FT4232H, bit7 of the channel is used as
> an output for TXD Enable.  In UART mode (the default used by ftdi_sio), this
> is the input signal RI# (Ring Indicator).
>
> Where does the ftdi_sio.c driver set the pin direction for the channel?  I
> need to re-purpose this pin to be an input, and drive it high during TX
> operations.
>
> For reference, page 12 describes pin usage, page 19 describes RS-485
> configuration:
>
> http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT4232H.pdf
>
> Thanks,
> Matt
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>

[Ftdi-usb-sio-devel] Extending the ftdi_sio driver for RS-485 usage with the FT4232H

[Matt B. <mba...@gm...>]

Hello,

Looking for some help understanding the ftdi_sio driver.  I've used the
libftdi interface to this chip before and I'm not seeing many parallels in
the Kernel driver.

In the RS-485 configuration for the FT4232H, bit7 of the channel is used as
an output for TXD Enable.  In UART mode (the default used by ftdi_sio),
this is the input signal RI# (Ring Indicator).

Where does the ftdi_sio.c driver set the pin direction for the channel?  I
need to re-purpose this pin to be an input, and drive it high during TX
operations.

For reference, page 12 describes pin usage, page 19 describes RS-485
configuration:

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT4232H.pdf

Thanks,
Matt

[Ftdi-usb-sio-devel] low bandwidth with usb to serial converter running ftdio_sio

[Valentin K. <val...@go...>]

Hello ftdi-usb-sio-devel mailing list readers,

for you to know first, i am not a driver or kernel developer. I am
working at the Karlsruhe Institute for Technology in Germany on a
project concerning the measurement of the power consumption of small
sensoring computers.

For this purpose we are using a usb to serial converter to transfer data
from the measuring device to a serial console running on linux. The
converter is running with the ftdio_sio driver.

Everything is working great when the corresponding serial console
programm (i tried some) runs on 576000 baud or less. Trying to improve
the data throughput i wanted to run the device at 1152000 baud. But at
this speed i can only receive data, the data which i sent is not
recognized by the device. (I cannot run the device with baudrates
between 576000 and 1152000 because of the processor running on it (18
MHZ Atmel)

Now at this point you might wonder why the hell i am writing to this
list :D - I tried to find out where the problem might be, so i connected
the device with windows running on the same machine - it was working
well with 1152000 baud. And to try some more i did the same with windows
running within virtual box on linux - was also working. So it is
possible that the problem does not lie in the device nor the parts of
linux which are used by windows within virtual box. 

Is it possible that the driver is not working correctly? Where would you
look for the reason?

(I know i did not provide many information, but in case someone is
interested in my case i can provide more :D)

Many thanks in advance

Valentin Kautz

Re: [Ftdi-usb-sio-devel] Fwd: FT_Open(0) failed

[Michael P. <mic...@gm...>]

Mohsen Jamali wrote:
>> Hi dear guys
>> i have installed the driver of ftdi on ubuntu 11.10 but when trying to
run the example get the following error
>> without root privilege it says that cannot access to the device and after
using sudo command it cannot open the device.
>> as you know driver and examples are available here:
http://www.ftdichip.com/Drivers/D2XX.htm
>> what's wrong with me?!
>> thanks
>>
>> mohsen@mohsen-Aspire-5738:~/Desktop/libftd2xx1.0.4/sample/LargeRead$
./largereadlibusb couldn't open USB device /dev/bus/usb/005/002: Permission
denied.
>> libusb requires write access to USB device nodes.
>> Segmentation fault
>> mohsen@mohsen-Aspire-5738:~/Desktop/libftd2xx1.0.4/sample/LargeRead$ sudo
./largeread
>> FT_Open(0) failed


This list is for the ftdi serial driver built into the kernel.  libftdi's
list is for the open source libftdi.  Neither of those lists are appropriate
for your problem.  Your problem is with the proprietary driver, so you need
to contact FTDI themselves.  Or you can use libftdi, which is a better piece
of code anyway, if it does what you need.

Regards,
Michael

[Ftdi-usb-sio-devel] FT4232H semi-randomly fails to read EEPROM on cold reboot

[Joakim L. <joa...@to...>]

Hi,

I have a very odd problem with FT4242H devices, which I hope someone 
recognizes.

The FT4242H uses an external EEPROM for things like vendor/product 
strings and serial number. Without the external EEPROM the 
vendor/product strings reverts to defaults and there is no support for a 
serial number (which is the thing I'm really interested in). Typically I 
keep 4 separate devices conneced (so a total of 16 ports). On a cold 
reboot only about half of the FT4242H devices will read the EEPROM 
contents. The rest of them will just report defaults when examined with 
udevadm info. When one of the devices, which failed to report a serial 
number, is unplugged and plugged back in it will always succeed in 
reading the EEPROM contents, and will report the stored serial number. 
I've seen this issue turn up in both kernel 2.6.32.26 and 2.6.40.4.

The problem does not seem to be tied to particular devices. For example, 
if I swap a working and a non-working board the problem usually does not 
move with the board. If anything, specific USB ports seems to work 
better than others, but that's not the full explanation either. So far 
I've not been able to spot any significant difference between a 
successful and failed read in dmesg or messages.

Is there anyone here who is familiar with this type of problem?


Best regards,

-- 
Joakim Linde
Tangiamo AB (formerly TouchTable AB)

[Ftdi-usb-sio-devel] FTDI VCP Driver on Linux - ARM 7

[André G. <an...@gl...>]

Hi!

I am trying to install the FTDI driver on Linux (Kernel 2.6) that is 
running on ARM 7 architecture.

Does anyone done this? It is possible?


Regards,
André Gomes

[Ftdi-usb-sio-devel] Latency issue

[Patrick B. <bee...@gm...>]

So, I realize that the ftdi_sio in Linux default to ASYNC_LOW_LATENCY so 
latency_timer=1.  However, I have noticed that I still have quite a bit 
of latency in the system when compared to Windows.  I can run the EXACT 
same code on a Windows machine and get MUCH faster IO than in Linux.  
Does anyone out there know where this hidden latency lies?  I don't 
recall this being the case prior to the ASYNC_LATENCY_LOW flag, but it 
also does it when I turn than off and set the latency manually (to 1, 2 
,3, etc.).  I can make it go slower (e.g. 64 ms), but not faster.

[Ftdi-usb-sio-devel] no signal from FT232RL

[Asher <as...@gm...>]

I am using a FT232RL on a specialty board and connecting it with a USB cable
to a Linux box running 2.6.31-02063113-generic.  When I power up the board
and connect it, dmesg shows

[ 5615.720067] usb 2-2: new full speed USB device using ohci_hcd and address
5
[ 5615.954232] usb 2-2: configuration #1 chosen from 1 choice
[ 5615.962172] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
[ 5615.962213] usb 2-2: Detected FT232RL
[ 5615.962217] usb 2-2: Number of endpoints 2
[ 5615.962220] usb 2-2: Endpoint 1 MaxPacketSize 64
[ 5615.962222] usb 2-2: Endpoint 2 MaxPacketSize 64
[ 5615.962225] usb 2-2: Setting MaxPacketSize 64
[ 5615.964167] usb 2-2: FTDI USB Serial Device converter now attached to
ttyUSB0

The board is meant to send 64 bytes repeatedly and to accept 64-byte
commands.

When I use a modem program, such as gtkterm, connecting it to /dev/ttyUSB0,
no matter how I set combinations of baud rate, parity, stop bits, flow
control, I cannot detect any data coming from the card.  On the other hand,
using Windows XP Embedded, the LabView program that calls the Windows driver
for the FTDI chip is able to function properly, both sending and receiving.
I don't know why Linux only associates a single tty to the device (it has
two endpoints), and I don't know why I can't receive any data.  My attempts
to send data have also failed.

[Ftdi-usb-sio-devel] Reading more than 255 bytes at once

[Dennis B. <den...@go...>]

Hello ftdi-usb-sio-devel list!

I am using termios to process data on a /dev/ttyUSB*-port. Data is
coming in on one of these ports in burst of over 500bytes. I am doing
this with kernel 2.6.33.7, which contains FTDI-driver in Version 1.5.0.
My serial-hardware is a FT4232 and I am using non-canonical input.

My problem is, that I can only read bursts of up to 255 bytes, since the
array of control characters within the kernel named c_cc represents only
an unsigned char. So, if I set a value higher than 255 to c_cc[VMIN], it
won't be set the way I want within the kernel.

How would it be possible to read bursts of over 255 bytes? Right now I
am doing a workaround, which checks for data within the buffer (ioctl
SIOCINQ) of the serial driver and as soon as it gets above a wanted
value (let's say 501 bytes), I read the buffer and flush it.

I would rather like to do this with select(2) in combination with
read(2), which only returns after 501 bytes are available.

Is there a way to do this?

Very kind regards,
Dennis

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

[Chris S. <chr...@ya...>]

--- On Mon, 11/22/10, Chris Stankevitz <chr...@ya...> wrote:
> However, your implication that multiple reads would help
> got me excited.
>
> There is also something called a libftdi streaming read

Michael,

A "streaming read" is what you proposed earlier -- a method for submitting multiple async read requests.  Strangely, the performance is the same if you have 1 pending read or 100.  I'm going to learn more about this.  

Ping-pong rates:

ftdi_sio: 1000 Hz (but about 2 seconds of every 10 has degraded performance ~500Hz)

libftdi-1.0 using synchronous read: 500 Hz

libftdi-1.0 using asynchronous read (1 pending): 500 Hz

libftdi-1.0 using asynchronous read (>1 pending): Impossible

libftdi-1.0 using streaming read (1 pending): 1000 Hz consistently

libftdi-1.0 using streaming read (>1 pending): 1000 Hz consistently

Thank you,

Chris


      

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

[Chris S. <chr...@ya...>]

--- On Sun, 11/21/10, Michael Plante <mic...@gm...> wrote:
> How many transfers did you typically have scheduled at a
> time?

Michael, just one:

for ()
{
  tc = ftdi_read_data_submit();

  ftdi_write_data()

  ftdi_transfer_data_done(tc);

}

However, your implication that multiple reads would help got me excited.  Unfortunately, however, libftdi-1 only allows one outstanding read submission.  This is because all read submissions ultimately go into the same "global" buffer within libftdi.  However, I will look into using libusb and handling the transfers myself in the hopes I can improved latency over ftdi_sio.  (There is also something called a libftdi streaming read -- I'm not sure what that is yet.)

Thank you for your help and patience,

Chris


      

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

[Michael P. <mic...@gm...>]

Chris Stankevitz wrote:
>> 3. libftdi-1.0, async read (as you recommended): ~500Hz

How many transfers did you typically have scheduled at a time?

Regards,
Michael