ftdi-usb-sio-devel Mailing List for FTDI USB Serial Converter Driver (Page 4)
Brought to you by:
bryder
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(11) |
Nov
(25) |
Dec
(25) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(16) |
Feb
(98) |
Mar
(46) |
Apr
(35) |
May
(15) |
Jun
(73) |
Jul
(49) |
Aug
(28) |
Sep
(16) |
Oct
(24) |
Nov
(36) |
Dec
(37) |
2004 |
Jan
(40) |
Feb
(21) |
Mar
(32) |
Apr
(27) |
May
(32) |
Jun
(48) |
Jul
(62) |
Aug
(22) |
Sep
(13) |
Oct
(14) |
Nov
(24) |
Dec
(26) |
2005 |
Jan
(15) |
Feb
(14) |
Mar
(31) |
Apr
(19) |
May
(23) |
Jun
(76) |
Jul
(64) |
Aug
(68) |
Sep
(30) |
Oct
(11) |
Nov
(20) |
Dec
(14) |
2006 |
Jan
(7) |
Feb
(5) |
Mar
(10) |
Apr
(10) |
May
(17) |
Jun
(13) |
Jul
(9) |
Aug
(8) |
Sep
(27) |
Oct
(54) |
Nov
(38) |
Dec
(31) |
2007 |
Jan
(21) |
Feb
(4) |
Mar
(3) |
Apr
(3) |
May
(3) |
Jun
(2) |
Jul
(2) |
Aug
(11) |
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
|
2008 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(8) |
Sep
|
Oct
(3) |
Nov
(6) |
Dec
(2) |
2009 |
Jan
(14) |
Feb
(3) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(2) |
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(5) |
Dec
(6) |
2010 |
Jan
(3) |
Feb
(5) |
Mar
(2) |
Apr
(4) |
May
(1) |
Jun
(7) |
Jul
(7) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(15) |
Dec
(1) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(2) |
2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(3) |
2015 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Bill R. <bil...@gm...> - 2010-06-23 05:14:39
|
Have a look at this: http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html You are probably setup to do 0.1s timeout when reading the port which is the default. you need to set VMIN/VTIME properly. On Wed, Jun 23, 2010 at 4:57 PM, Tao Jin <jin...@gm...> wrote: > Dear all,http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html > > I am trying to get my laptop running Ubuntu to communicate with a > sensor through serial interface. I used usb-to-serial adapter to > connect the laptop and sensor serial RX/TX pins. I observed a long > latency when I do a one-byte serial echo test, around 10ms. > > I googled a bit, and seems a lot of people had the same issue. someone > said setserial /dev/ttyS* low_latency can get the serial device work > in low latency mode, with higher CPU load. I tried, that doesn't work > for me. > > Anyone here know about this latency issue on serial link? Could you > please provide some guidance to resolve this issue? > > Thanks a lot in advance! > > jintao > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Ftdi-usb-sio-devel mailing list > Ftd...@li... > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > |
From: Tao J. <jin...@gm...> - 2010-06-23 04:57:58
|
Dear all, I am trying to get my laptop running Ubuntu to communicate with a sensor through serial interface. I used usb-to-serial adapter to connect the laptop and sensor serial RX/TX pins. I observed a long latency when I do a one-byte serial echo test, around 10ms. I googled a bit, and seems a lot of people had the same issue. someone said setserial /dev/ttyS* low_latency can get the serial device work in low latency mode, with higher CPU load. I tried, that doesn't work for me. Anyone here know about this latency issue on serial link? Could you please provide some guidance to resolve this issue? Thanks a lot in advance! jintao |
From: Kiran P <kir...@gm...> - 2010-05-18 10:04:02
|
HI, I am using FT232RL in my Project for converting the serial data to USB and then transferring it to my PC.. I have developed a GUI in which the data being received is displayed. It works good on Windows XP platform, but now i need it to run on my QNX platform , so i need the USB-Serial driver for it..... Please can u help me this QNX Version 6.4.1 Thank you, Kiran P -- (¨`•.•´¨) Always `•.¸(¨`•.•´¨) Keep (¨`•.•´¨)¸.•´ Smiling! `•.¸.•´ With Regards, Kiran.P $# K|tTy$# |
From: Bill R. <bil...@gm...> - 2010-04-28 20:25:19
|
You could try setting VTIME to 1 for testing purposes. Or even 0. On Thu, Apr 29, 2010 at 3:35 AM, Michael Plante <mic...@gm...>wrote: > Matti Dahlbom wrote: > >> // configure the new port settings for 9600baud, 8N1, raw output > >> termios options = termios(); > >> options.c_cflag = B9600 | CS8 | CLOCAL | CREAD; > >> options.c_iflag = 0; > >> options.c_oflag = 0; > >> options.c_lflag = 0; > >> > >> // 1 second port read timeout > >> options.c_cc[VMIN] = 0; > >> options.c_cc[VTIME] = 10; > >> > >> // register the new port settings > >> tcflush(m_fd, TCIFLUSH); > >> if ( tcsetattr(m_fd, TCSANOW, &options) == -1 ) > > Just a guess, since I don't generally use my ftdi chips this way (but have > used real serial ports this way), but termios has other members. I'm not > entirely sure what the termios() function does (constructor of some sort?), > but you might try a memset(&options, 0, sizeof(options)); before you start > fiddling with them, or, better yet, a tcgetattr() first. I have no idea if > tcflush() can fail, but you might also printf its return value. > > Michael > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ftdi-usb-sio-devel mailing list > Ftd...@li... > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > |
From: Michael P. <mic...@gm...> - 2010-04-28 15:35:55
|
Matti Dahlbom wrote: >> // configure the new port settings for 9600baud, 8N1, raw output >> termios options = termios(); >> options.c_cflag = B9600 | CS8 | CLOCAL | CREAD; >> options.c_iflag = 0; >> options.c_oflag = 0; >> options.c_lflag = 0; >> >> // 1 second port read timeout >> options.c_cc[VMIN] = 0; >> options.c_cc[VTIME] = 10; >> >> // register the new port settings >> tcflush(m_fd, TCIFLUSH); >> if ( tcsetattr(m_fd, TCSANOW, &options) == -1 ) Just a guess, since I don't generally use my ftdi chips this way (but have used real serial ports this way), but termios has other members. I'm not entirely sure what the termios() function does (constructor of some sort?), but you might try a memset(&options, 0, sizeof(options)); before you start fiddling with them, or, better yet, a tcgetattr() first. I have no idea if tcflush() can fail, but you might also printf its return value. Michael |
From: Matti D. <ma...@77...> - 2010-04-28 07:59:53
|
Hello - I'm writing a piece of software to talk to my dive computer Suunto D6 from a linux machine, since Suunto only provides Windows software for extracting the dive data. To do this I have written some serial code to talk to the dive computer over the FTDI driver. Plugging the device in the USB port, the FTDI driver immediately properly loads and creates /dev/ttyUSB0. I then succesfully open the port, write data to it, but never get anything back. There just is no reply from the device. I have verified the protocol format using a byte by byte Serial sniffer on a Windows machine, where the exact same sequence works properly. Perhaps there is something wrong in the way I initialize the FTDI serial port? Code below: --------------------------------------------------------------------- m_fd = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_SYNC); if ( m_fd == -1 ) { perror("failed to open serial port - "); exit(-1); } // configure the new port settings for 9600baud, 8N1, raw output termios options = termios(); options.c_cflag = B9600 | CS8 | CLOCAL | CREAD; options.c_iflag = 0; options.c_oflag = 0; options.c_lflag = 0; // 1 second port read timeout options.c_cc[VMIN] = 0; options.c_cc[VTIME] = 10; // register the new port settings tcflush(m_fd, TCIFLUSH); if ( tcsetattr(m_fd, TCSANOW, &options) == -1 ) { perror("tcsetattr() failed - "); exit(-1); } --------------------------------------------------------------------- After that I just use write(2) and read(2) for rx/tx. I have tried pretty much every port setting I could think of, and even tried manually setting the DSR flag. I am out of options debugging this, and would very much like to get it running in order not have to have a Windows installation for this single thing.. BR, Matti |
From: Bill R. <Bi...@Re...> - 2010-03-31 20:10:13
|
Ubuntu 9.10 supports the FTDI chipset right out of the box. No need to compile anything! Try this: ls /dev/ttyUSB* there should be nothing listed, but if there is, take note of what's there] Now plug in your FTDI dongle and again: ls /dev/ttyUSB* You'll see an additional port there. That's your new mock serial port. From: Damian Leuthold [mailto:dam...@gm...] Sent: Wednesday, March 31, 2010 3:53 PM To: ftd...@li... Subject: [Ftdi-usb-sio-devel] FTDI USB Serial Device 0403:6001 Driver Compile Errors Hello my new temporary best friends (if you can help me solve this), I am trying to get my new cutting plotter to work in Ubuntu Linux 9.10, kernel 2.6.31-20. It uses an FTDI usb-serial port chip. I have tried to load the driver but it does not compile. The make file generates many include errors. It appears to be looking in the wrong location for various files. I've started to modify the make file to look in the correct location for those files, but then it started getting messy. Before I go further I'm hoping for confirmation that I am going in the right direction. Is it ok to use the '/usr/src/linux-header' rather than '/lib/modules' files? What am I missing? Detail: Standard driver loads (before I removed the ftdi-sio module 'rmmod ftdi-sio' now no /dev/ttyUSB0)- $ dmesg [42999.312037] usb 5-2: new full speed USB device using uhci_hcd and address 2 [42999.490413] usb 5-2: configuration #1 chosen from 1 choice [42999.635294] usbcore: registered new interface driver usbserial [42999.635316] USB Serial support registered for generic [42999.635356] usbcore: registered new interface driver usbserial_generic [42999.635359] usbserial: USB Serial Driver core [42999.652709] USB Serial support registered for FTDI USB Serial Device [42999.652779] ftdi_sio 5-2:1.0: FTDI USB Serial Device converter detected [42999.652820] usb 5-2: Detected FT232BM [42999.652824] usb 5-2: Number of endpoints 2 [42999.652827] usb 5-2: Endpoint 1 MaxPacketSize 64 [42999.652830] usb 5-2: Endpoint 2 MaxPacketSize 64 [42999.652832] usb 5-2: Setting MaxPacketSize 64 [42999.654488] usb 5-2: FTDI USB Serial Device converter now attached to ttyUSB0 [42999.654527] usbcore: registered new interface driver ftdi_sio [42999.654532] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver $ lsusb Bus 005 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub $ udevadm info -q all -n /dev/ttyUSB0 P: /devices/pci0000:00/0000:00:1d.3/usb5/5-2/5-2:1.0/ttyUSB0/tty/ttyUSB0 N: ttyUSB0 S: char/188:0 S: serial/by-path/pci-0000:00:1d.3-usb-0:2:1.0-port0 S: serial/by-id/usb-FTDI_USB__-__Serial-if00-port0 E: UDEV_LOG=3 E: DEVPATH=/devices/pci0000:00/0000:00:1d.3/usb5/5-2/5-2:1.0/ttyUSB0/tty/ttyUSB 0 E: MAJOR=188 E: MINOR=0 E: DEVNAME=/dev/ttyUSB0 E: SUBSYSTEM=tty E: ID_PORT=0 E: ID_PATH=pci-0000:00:1d.3-usb-0:2:1.0 E: ID_VENDOR=FTDI E: ID_VENDOR_ENC=FTDI E: ID_VENDOR_ID=0403 E: ID_MODEL=USB__-__Serial E: ID_MODEL_ENC=USB\x20\x3c-\x3e\x20Serial E: ID_MODEL_ID=6001 E: ID_REVISION=0400 E: ID_SERIAL=FTDI_USB__-__Serial E: ID_TYPE=generic E: ID_BUS=usb E: ID_USB_INTERFACES=:ffffff: E: ID_USB_INTERFACE_NUM=00 E: ID_USB_DRIVER=ftdi_sio E: ID_IFACE=00 E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd E: ID_MODEL_FROM_DATABASE=FT232 USB-Serial (UART) IC E: DEVLINKS=/dev/char/188:0 /dev/serial/by-path/pci-0000:00:1d.3-usb-0:2:1.0-port0 /dev/serial/by-id/usb-FTDI_USB__-__Serial-if00-port0 --------------------------- The original make command: $ make gcc -Wall -D__KERNEL__ -DMODULE -I/lib/modules/2.6.31-20-generic/build/include -D__SMP__ -DSMP -DMODVERSIONS -include /lib/modules/2.6.31-20-generic/build/include/linux/modversions.h -I/usr/src/linux-2.6.31-20-generic/drivers/usb/serial/ -O -c -o ftdi_sio.o ftdi_sio.c Make errors: cc1: error: /lib/modules/2.6.31-20-generic/build/include/linux/modversions.h: No such file or directory In file included from /lib/modules/2.6.31-20-generic/build/include/linux/kernel.h:11, from ftdi_sio.c:251: /lib/modules/2.6.31-20-generic/build/include/linux/linkage.h:5:25: error: asm/linkage.h: No such file or directory In file included from /lib/modules/2.6.31-20-generic/build/include/linux/kernel.h:15, from ftdi_sio.c:251: ... ftdi_sio.c: In function 'ftdi_tiocmget': ftdi_sio.c:2206: error: expected ')' before 'KBUILD_MODNAME' ftdi_sio.c:2225: error: expected ')' before 'KBUILD_MODNAME' ftdi_sio.c: In function 'ftdi_ioctl': ftdi_sio.c:2276: error: 'current' undeclared (first use in this function) make: *** [ftdi_sio.o] Error 1 Make search location: /lib/modules/2.6.31-20-generic/build/include/linux/modversions.h Correct location: /usr/src/linux-headers-2.6.31-20-generic/include/config/modversions.h Make search location: /lib/modules/2.6.31-20-generic/build/include/linux/kernel.h Correct location: /usr/src/linux-headers-2.6.31-20-generic/include/linux/kernel.h ---------------------------- Modified make file: $ make gcc -Wall -D__KERNEL__ -DMODULE -I/usr/src/linux-headers-2.6.31-20-generic/config -D__SMP__ -DSMP -DMODVERSIONS -include /usr/src/linux-headers-2.6.31-20-generic/include/linux/modversions.h -I/usr/src/linux-headers-2.6.31-20-generic/include/config/ -I/usr/src/linux-2.6.31-20-generic/drivers/usb/serial/ -O -c -o ftdi_sio.o ftdi_sio.c New make errors: $make cc1: error: /usr/src/linux-headers-2.6.31-20-generic/include/linux/modversions.h: No such file or directory ftdi_sio.c:253:24: error: linux/init.h: No such file or directory ftdi_sio.c:254:24: error: linux/slab.h: No such file or directory ftdi_sio.c:256:30: error: linux/tty_driver.h: No such file or directory ... -- Damian Leuthold co-owner Advanced Communications http://advancedcommunications.us/ (h) 970-375-5445 (m) 720-949-3988 |
From: Damian L. <dam...@gm...> - 2010-03-31 19:52:47
|
Hello my new temporary best friends (if you can help me solve this), I am trying to get my new cutting plotter to work in Ubuntu Linux 9.10, kernel 2.6.31-20. It uses an FTDI usb-serial port chip. I have tried to load the driver but it does not compile. The make file generates many include errors. It appears to be looking in the wrong location for various files. I've started to modify the make file to look in the correct location for those files, but then it started getting messy. Before I go further I'm hoping for confirmation that I am going in the right direction. Is it ok to use the '/usr/src/linux-header' rather than '/lib/modules' files? What am I missing? Detail: *Standard driver loads (*before I removed the ftdi-sio module 'rmmod ftdi-sio' now no /dev/ttyUSB0*)- $ dmesg* [42999.312037] usb 5-2: new full speed USB device using uhci_hcd and address 2 [42999.490413] usb 5-2: configuration #1 chosen from 1 choice [42999.635294] usbcore: registered new interface driver usbserial [42999.635316] USB Serial support registered for generic [42999.635356] usbcore: registered new interface driver usbserial_generic [42999.635359] usbserial: USB Serial Driver core [42999.652709] USB Serial support registered for FTDI USB Serial Device [42999.652779] ftdi_sio 5-2:1.0: FTDI USB Serial Device converter detected [42999.652820] usb 5-2: Detected FT232BM [42999.652824] usb 5-2: Number of endpoints 2 [42999.652827] usb 5-2: Endpoint 1 MaxPacketSize 64 [42999.652830] usb 5-2: Endpoint 2 MaxPacketSize 64 [42999.652832] usb 5-2: Setting MaxPacketSize 64 [42999.654488] usb 5-2: FTDI USB Serial Device converter now attached to ttyUSB0 [42999.654527] usbcore: registered new interface driver ftdi_sio [42999.654532] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver *$ lsusb* Bus 005 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub *$ udevadm info -q all -n /dev/ttyUSB0* P: /devices/pci0000:00/0000:00:1d.3/usb5/5-2/5-2:1.0/ttyUSB0/tty/ttyUSB0 N: ttyUSB0 S: char/188:0 S: serial/by-path/pci-0000:00:1d.3-usb-0:2:1.0-port0 S: serial/by-id/usb-FTDI_USB__-__Serial-if00-port0 E: UDEV_LOG=3 E: DEVPATH=/devices/pci0000:00/0000:00:1d.3/usb5/5-2/5-2:1.0/ttyUSB0/tty/ttyUSB0 E: MAJOR=188 E: MINOR=0 E: DEVNAME=/dev/ttyUSB0 E: SUBSYSTEM=tty E: ID_PORT=0 E: ID_PATH=pci-0000:00:1d.3-usb-0:2:1.0 E: ID_VENDOR=FTDI E: ID_VENDOR_ENC=FTDI E: ID_VENDOR_ID=0403 E: ID_MODEL=USB__-__Serial E: ID_MODEL_ENC=USB\x20\x3c-\x3e\x20Serial E: ID_MODEL_ID=6001 E: ID_REVISION=0400 E: ID_SERIAL=FTDI_USB__-__Serial E: ID_TYPE=generic E: ID_BUS=usb E: ID_USB_INTERFACES=:ffffff: E: ID_USB_INTERFACE_NUM=00 E: ID_USB_DRIVER=ftdi_sio E: ID_IFACE=00 E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd E: ID_MODEL_FROM_DATABASE=FT232 USB-Serial (UART) IC E: DEVLINKS=/dev/char/188:0 /dev/serial/by-path/pci-0000:00:1d.3-usb-0:2:1.0-port0 /dev/serial/by-id/usb-FTDI_USB__-__Serial-if00-port0 --------------------------- *The original make command:* *$ make* gcc -Wall -D__KERNEL__ -DMODULE -I/lib/modules/2.6.31-20-generic/build/include -D__SMP__ -DSMP -DMODVERSIONS -include /lib/modules/2.6.31-20-generic/build/include/linux/modversions.h -I/usr/src/linux-2.6.31-20-generic/drivers/usb/serial/ -O -c -o ftdi_sio.o ftdi_sio.c *Make errors:* cc1: error: /lib/modules/2.6.31-20-generic/build/include/linux/modversions.h: No such file or directory In file included from /lib/modules/2.6.31-20-generic/build/include/linux/kernel.h:11, from ftdi_sio.c:251: /lib/modules/2.6.31-20-generic/build/include/linux/linkage.h:5:25: error: asm/linkage.h: No such file or directory In file included from /lib/modules/2.6.31-20-generic/build/include/linux/kernel.h:15, from ftdi_sio.c:251: ... ftdi_sio.c: In function ‘ftdi_tiocmget’: ftdi_sio.c:2206: error: expected ‘)’ before ‘KBUILD_MODNAME’ ftdi_sio.c:2225: error: expected ‘)’ before ‘KBUILD_MODNAME’ ftdi_sio.c: In function ‘ftdi_ioctl’: ftdi_sio.c:2276: error: ‘current’ undeclared (first use in this function) make: *** [ftdi_sio.o] Error 1 *Make search location:*/lib/modules/2.6.31-20-generic/build/include/linux/modversions.h *Correct location:*/usr/src/linux-headers-2.6.31-20-generic/include/config/modversions.h *Make search location: * /lib/modules/2.6.31-20-generic/build/include/linux/kernel.h *Correct location:*/usr/src/linux-headers-2.6.31-20-generic/include/linux/kernel.h ---------------------------- *Modified make file: *$ make gcc -Wall -D__KERNEL__ -DMODULE -I/usr/src/linux-headers-2.6.31-20-generic/config -D__SMP__ -DSMP -DMODVERSIONS -include /usr/src/linux-headers-2.6.31-20-generic/include/linux/modversions.h -I/usr/src/linux-headers-2.6.31-20-generic/include/config/ -I/usr/src/linux-2.6.31-20-generic/drivers/usb/serial/ -O -c -o ftdi_sio.o ftdi_sio.c *New make errors: *$make cc1: error: /usr/src/linux-headers-2.6.31-20-generic/include/linux/modversions.h: No such file or directory ftdi_sio.c:253:24: error: linux/init.h: No such file or directory ftdi_sio.c:254:24: error: linux/slab.h: No such file or directory ftdi_sio.c:256:30: error: linux/tty_driver.h: No such file or directory ... -- Damian Leuthold co-owner Advanced Communications http://advancedcommunications.us/ (h) 970-375-5445 (m) 720-949-3988 |
From: Bill R. <bil...@gm...> - 2010-02-16 21:03:23
|
Hi there, minicom uses the TIOCMGET and TIOCMSET calls which are properly implemented. microcom does not. Which is possibly why minicom was working and microcom was not. The flow control was set properly by minicom 1044 10:12:29.685847 ioctl(3, TIOCMGET, [TIOCM_CTS|TIOCM_DSR]) = 0 <0.000875> 1044 10:12:29.688026 ioctl(3, TIOCMSET, [TIOCM_RTS|TIOCM_CTS|TIOCM_DSR]) = 0 <0.000802> Also minicom was quite careful about checking the stats of the various flowcontrol/status lines and microcom does not. Bill On Wed, Feb 17, 2010 at 8:22 AM, Timo TH <ti...@po...> wrote: > Did the strace reveal something interesting? about why the microcom > and pppd hang. > > On 12 February 2010 12:17, Timo TH <ti...@po...> wrote: > > You were correct, using minicom things worked, > > attached both straces, > > > > On 11 February 2010 20:46, Bill Ryder <bil...@gm...> wrote: > >> Are able to try minicom instead of microcom? > >> > >> If that actually works can you get an strace of both of them? I'm > curious to > >> see how they setup the serial port. > >> > >> To get the detail it would need to be something like: > >> > >> strace -f -w /tmp/microcom.strace -tt -T -v microcom whatever arguments > >> > >> I like the -tt -T for timing reasons. The important thing is the -v and > >> maybe the -f. But the -v is necessary to get the full ioctl/termios > >> settings. > >> > >> And you could be right - there may be some kind of flow control setting > >> getting in the way. > >> > >> > >> > >> > |
From: Timo TH <ti...@po...> - 2010-02-16 19:23:01
|
Did the strace reveal something interesting? about why the microcom and pppd hang. On 12 February 2010 12:17, Timo TH <ti...@po...> wrote: > You were correct, using minicom things worked, > attached both straces, > > On 11 February 2010 20:46, Bill Ryder <bil...@gm...> wrote: >> Are able to try minicom instead of microcom? >> >> If that actually works can you get an strace of both of them? I'm curious to >> see how they setup the serial port. >> >> To get the detail it would need to be something like: >> >> strace -f -w /tmp/microcom.strace -tt -T -v microcom whatever arguments >> >> I like the -tt -T for timing reasons. The important thing is the -v and >> maybe the -f. But the -v is necessary to get the full ioctl/termios >> settings. >> >> And you could be right - there may be some kind of flow control setting >> getting in the way. >> >> >> >> |
From: Timo TH <ti...@po...> - 2010-02-12 10:25:27
|
You were correct, using minicom things worked, attached both straces, On 11 February 2010 20:46, Bill Ryder <bil...@gm...> wrote: > Are able to try minicom instead of microcom? > > If that actually works can you get an strace of both of them? I'm curious to > see how they setup the serial port. > > To get the detail it would need to be something like: > > strace -f -w /tmp/microcom.strace -tt -T -v microcom whatever arguments > > I like the -tt -T for timing reasons. The important thing is the -v and > maybe the -f. But the -v is necessary to get the full ioctl/termios > settings. > > And you could be right - there may be some kind of flow control setting > getting in the way. > > > > |
From: Bill R. <bil...@gm...> - 2010-02-11 18:47:14
|
Are able to try minicom instead of microcom? If that actually works can you get an strace of both of them? I'm curious to see how they setup the serial port. To get the detail it would need to be something like: strace -f -w /tmp/microcom.strace -tt -T -v microcom whatever arguments I like the -tt -T for timing reasons. The important thing is the -v and maybe the -f. But the -v is necessary to get the full ioctl/termios settings. And you could be right - there may be some kind of flow control setting getting in the way. |
From: Timo TH <ti...@po...> - 2010-02-11 13:20:21
|
Anyone seen this kind of a problem? Environment : ARM9 SAM9263ek, gprs modem on usb, (pppd 2.4.4) With Linux 2.6.27.34 and ftdi_sio 1.4.3, everything worked OK. Upgraded to Linux 2.6.31.6, which brought ftdi_sio 1.5.0 and now everything works upto point where data connection should be made. Something wrong with handling of DTR or DCD or what? # modprobe ftdi_sio usbcore: registered new interface driver usbserial USB Serial support registered for generic usbcore: registered new interface driver usbserial_generic USB Serial support registered for FTDI USB Serial Device ftdi_sio 1-2.2:1.0: usb_probe_interface ftdi_sio 1-2.2:1.0: usb_probe_interface - got id ftdi_sio 1-2.2:1.0: FTDI USB Serial Device converter detected usb 1-2.2: Detected FT2232C usb 1-2.2: Number of endpoints 2 usb 1-2.2: Endpoint 1 MaxPacketSize 64 usb 1-2.2: Endpoint 2 MaxPacketSize 64 usb 1-2.2: Setting MaxPacketSize 64 usb 1-2.2: FTDI USB Serial Device converter now attached to ttyUSB0 ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver # microcom /dev/ttyUSB0 AT OK AT+CPIN=0000 OK AT+CREG? +CREG: 0,1 ATD*98# //// No reply of any kind With 2.6.27.34, everything above is same and there ATD gets reply CONNECT Strange detail, If instead of microcom doing # cat < /dev/ttyUSB0 in one terminal, and just echo in the AT commands in another terminal, then the cat displays CONNECT But this is no help for my goal, since I'm trying to use pppd and it only gets timeout to its ATD command. Greatly appreciating any help and hints already.. - Timmy |
From: Craig V. D. <cr...@yo...> - 2010-01-03 21:46:56
|
I just checked and determined that the kernel 2.6.32.1-9 currently in Ubuntu-10.04-Alpha1 can be complied and used in Kubuntu 9.10, at least it seems to run fine on my system. My problem with ftdi_sio is solved in that kernel without special effort. On Saturday 02 January 2010 21:07:22 Craig Van Degrift wrote: > Comment #10 in the following forum was helpful for getting my FTDI 2232C > working again when I upgraded to Ubuntu 9.10. It seems this fix is still > not in the Ubuntu updates. It might help with your problem. > > http://ubuntuforums.org/showthread.php?t=1327965 > > On Saturday 02 January 2010 18:36:04 David Powell wrote: > > Hello. I've searched everywhere for a solution to this problem, but > > can't find one. I'm hoping someone here can help. > > > > The background: > > I have only just recently replaced my old slow Windows XT machine with a > > new HP 64-bit quad processor. It came with 64-bit Vista which doesn't > > allow 32-bit drivers, so I decided this is the decade that I will switch > > to Linux and loaded 64-bit Ubuntu 9.10 (Karmic Koala) on it. > > I also have an Arduino clone (Seeduino) which uses the FTDI FT232RL chip > > that I want to use. > > > > The problem: > > If I plug in the Arduino to the USB port, /dev/ttyUSB0 appears and this > > appears in the messages log: > > > > usb 4-1: new full speed USB device using ohci_hcd and address 2 > > usb 4-1: configuration #1 chosen from 1 choice > > usbcore: registered new interface driver usbserial > > USB Serial support registered for generic > > usbcore: registered new interface driver usbserial_generic > > usbserial: USB Serial Driver core > > USB Serial support registered for FTDI USB Serial Device > > ftdi_sio 4-1:1.0: FTDI USB Serial Device converter detected > > usb 4-1: Detected FT232RL > > usb 4-1: Number of endpoints 2 > > usb 4-1: Endpoint 1 MaxPacketSize 64 > > usb 4-1: Endpoint 2 MaxPacketSize 64 > > usb 4-1: Setting MaxPacketSize 64 > > usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0 > > usbcore: registered new interface driver ftdi_sio > > ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver > > > > If I unplug the Arduino right away, /dev/ttyUSB0 goes away, as it > > should. So far, so good. > > > > If, however, I leave the Arduino plugged in, about every 5 minutes I get > > this in the messages log: > > > > modem-manager D 0000000000000000 0 929 1 0x00000000 > > ffff8801ffc07cd8 0000000000000086 ffff8801f710c8a0 0000000000015880 > > ffff880213b43110 0000000000015880 0000000000015880 0000000000015880 > > 0000000000015880 ffff880213b43110 0000000000015880 0000000000015880 > > Call Trace: > > [<ffffffff8139ec15>] usb_kill_urb+0x85/0xc0 > > [<ffffffff81078b20>] ? autoremove_wake_function+0x0/0x40 > > [<ffffffffa0bc7fc1>] ftdi_close+0x31/0x70 [ftdi_sio] > > [<ffffffffa0bb9909>] serial_down+0x69/0x80 [usbserial] > > [<ffffffffa0bb9c16>] serial_close+0x76/0xc0 [usbserial] > > [<ffffffff812f4319>] tty_release_dev+0x159/0x5f0 > > [<ffffffff81130270>] ? pollwake+0x0/0x60 > > [<ffffffff81427610>] ? sys_sendto+0x120/0x180 > > [<ffffffff812f47c9>] tty_release+0x19/0x30 > > [<ffffffff81120cd0>] __fput+0xf0/0x210 > > [<ffffffff81120e0d>] fput+0x1d/0x30 > > [<ffffffff8111cec8>] filp_close+0x58/0x90 > > [<ffffffff8111cfb9>] sys_close+0xb9/0x110 > > [<ffffffff81012002>] system_call_fastpath+0x16/0x1b > > > > > > In either case, I can't actually *use* the Arduino - if I try to > > download a program to it, the download program (avrdude) will simply > > hang - very hard. I can't even kill it from the command line. Also, if > > I try "lsusb", that too will hang with no way to kill it. Another, > > possibly unrelated, problem is that some time after that my Logitech > > PS/2 mouse will stop working. > > > > Can anyone tell from the hieroglyphics that I've posted here where the > > problem is? > > > > Thanks, David > |
From: Craig V. D. <cr...@yo...> - 2010-01-03 05:32:41
|
Comment #10 in the following forum was helpful for getting my FTDI 2232C working again when I upgraded to Ubuntu 9.10. It seems this fix is still not in the Ubuntu updates. It might help with your problem. http://ubuntuforums.org/showthread.php?t=1327965 On Saturday 02 January 2010 18:36:04 David Powell wrote: > Hello. I've searched everywhere for a solution to this problem, but > can't find one. I'm hoping someone here can help. > > The background: > I have only just recently replaced my old slow Windows XT machine with a > new HP 64-bit quad processor. It came with 64-bit Vista which doesn't > allow 32-bit drivers, so I decided this is the decade that I will switch > to Linux and loaded 64-bit Ubuntu 9.10 (Karmic Koala) on it. > I also have an Arduino clone (Seeduino) which uses the FTDI FT232RL chip > that I want to use. > > The problem: > If I plug in the Arduino to the USB port, /dev/ttyUSB0 appears and this > appears in the messages log: > > usb 4-1: new full speed USB device using ohci_hcd and address 2 > usb 4-1: configuration #1 chosen from 1 choice > usbcore: registered new interface driver usbserial > USB Serial support registered for generic > usbcore: registered new interface driver usbserial_generic > usbserial: USB Serial Driver core > USB Serial support registered for FTDI USB Serial Device > ftdi_sio 4-1:1.0: FTDI USB Serial Device converter detected > usb 4-1: Detected FT232RL > usb 4-1: Number of endpoints 2 > usb 4-1: Endpoint 1 MaxPacketSize 64 > usb 4-1: Endpoint 2 MaxPacketSize 64 > usb 4-1: Setting MaxPacketSize 64 > usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0 > usbcore: registered new interface driver ftdi_sio > ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver > > If I unplug the Arduino right away, /dev/ttyUSB0 goes away, as it > should. So far, so good. > > If, however, I leave the Arduino plugged in, about every 5 minutes I get > this in the messages log: > > modem-manager D 0000000000000000 0 929 1 0x00000000 > ffff8801ffc07cd8 0000000000000086 ffff8801f710c8a0 0000000000015880 > ffff880213b43110 0000000000015880 0000000000015880 0000000000015880 > 0000000000015880 ffff880213b43110 0000000000015880 0000000000015880 > Call Trace: > [<ffffffff8139ec15>] usb_kill_urb+0x85/0xc0 > [<ffffffff81078b20>] ? autoremove_wake_function+0x0/0x40 > [<ffffffffa0bc7fc1>] ftdi_close+0x31/0x70 [ftdi_sio] > [<ffffffffa0bb9909>] serial_down+0x69/0x80 [usbserial] > [<ffffffffa0bb9c16>] serial_close+0x76/0xc0 [usbserial] > [<ffffffff812f4319>] tty_release_dev+0x159/0x5f0 > [<ffffffff81130270>] ? pollwake+0x0/0x60 > [<ffffffff81427610>] ? sys_sendto+0x120/0x180 > [<ffffffff812f47c9>] tty_release+0x19/0x30 > [<ffffffff81120cd0>] __fput+0xf0/0x210 > [<ffffffff81120e0d>] fput+0x1d/0x30 > [<ffffffff8111cec8>] filp_close+0x58/0x90 > [<ffffffff8111cfb9>] sys_close+0xb9/0x110 > [<ffffffff81012002>] system_call_fastpath+0x16/0x1b > > > In either case, I can't actually *use* the Arduino - if I try to > download a program to it, the download program (avrdude) will simply > hang - very hard. I can't even kill it from the command line. Also, if > I try "lsusb", that too will hang with no way to kill it. Another, > possibly unrelated, problem is that some time after that my Logitech > PS/2 mouse will stop working. > > Can anyone tell from the hieroglyphics that I've posted here where the > problem is? > > Thanks, David > |
From: David P. <da...@de...> - 2010-01-03 03:02:59
|
Hello. I've searched everywhere for a solution to this problem, but can't find one. I'm hoping someone here can help. The background: I have only just recently replaced my old slow Windows XT machine with a new HP 64-bit quad processor. It came with 64-bit Vista which doesn't allow 32-bit drivers, so I decided this is the decade that I will switch to Linux and loaded 64-bit Ubuntu 9.10 (Karmic Koala) on it. I also have an Arduino clone (Seeduino) which uses the FTDI FT232RL chip that I want to use. The problem: If I plug in the Arduino to the USB port, /dev/ttyUSB0 appears and this appears in the messages log: usb 4-1: new full speed USB device using ohci_hcd and address 2 usb 4-1: configuration #1 chosen from 1 choice usbcore: registered new interface driver usbserial USB Serial support registered for generic usbcore: registered new interface driver usbserial_generic usbserial: USB Serial Driver core USB Serial support registered for FTDI USB Serial Device ftdi_sio 4-1:1.0: FTDI USB Serial Device converter detected usb 4-1: Detected FT232RL usb 4-1: Number of endpoints 2 usb 4-1: Endpoint 1 MaxPacketSize 64 usb 4-1: Endpoint 2 MaxPacketSize 64 usb 4-1: Setting MaxPacketSize 64 usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: registered new interface driver ftdi_sio ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver If I unplug the Arduino right away, /dev/ttyUSB0 goes away, as it should. So far, so good. If, however, I leave the Arduino plugged in, about every 5 minutes I get this in the messages log: modem-manager D 0000000000000000 0 929 1 0x00000000 ffff8801ffc07cd8 0000000000000086 ffff8801f710c8a0 0000000000015880 ffff880213b43110 0000000000015880 0000000000015880 0000000000015880 0000000000015880 ffff880213b43110 0000000000015880 0000000000015880 Call Trace: [<ffffffff8139ec15>] usb_kill_urb+0x85/0xc0 [<ffffffff81078b20>] ? autoremove_wake_function+0x0/0x40 [<ffffffffa0bc7fc1>] ftdi_close+0x31/0x70 [ftdi_sio] [<ffffffffa0bb9909>] serial_down+0x69/0x80 [usbserial] [<ffffffffa0bb9c16>] serial_close+0x76/0xc0 [usbserial] [<ffffffff812f4319>] tty_release_dev+0x159/0x5f0 [<ffffffff81130270>] ? pollwake+0x0/0x60 [<ffffffff81427610>] ? sys_sendto+0x120/0x180 [<ffffffff812f47c9>] tty_release+0x19/0x30 [<ffffffff81120cd0>] __fput+0xf0/0x210 [<ffffffff81120e0d>] fput+0x1d/0x30 [<ffffffff8111cec8>] filp_close+0x58/0x90 [<ffffffff8111cfb9>] sys_close+0xb9/0x110 [<ffffffff81012002>] system_call_fastpath+0x16/0x1b In either case, I can't actually *use* the Arduino - if I try to download a program to it, the download program (avrdude) will simply hang - very hard. I can't even kill it from the command line. Also, if I try "lsusb", that too will hang with no way to kill it. Another, possibly unrelated, problem is that some time after that my Logitech PS/2 mouse will stop working. Can anyone tell from the hieroglyphics that I've posted here where the problem is? Thanks, David |
From: Florian L. <fl...@rf...> - 2009-12-21 12:53:32
|
Hi, i trying to build the poor-mans-LOM 1) with a FTDI EVAL 232R board, using some CBUS pins to drive power and reset relais - to power cycle and/or reset the attached machines. (Build park). I know i can set the CBUS I/O pins with libftdi but the problem seems to be that the endpoint disconnects or at least the ttyUSB device gets disconnected when using the example cbus_bitbang program. My idea would have been to export the CBUS pins which have been set as GPIO in the eeprom as sys files or better, hand them off to the GPIO layer. Has anyone done something like this in the past? Flo 1) http://silicon-verl.de/home/flo/projects/smlom/ -- Florian Lohoff fl...@rf... "Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen." - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin |
From: Roger S. <ro...@tp...> - 2009-12-20 07:08:40
|
Hi All ..... any confirmation or help greatly appreciated To clarify further.... My device uses FT232RL from http://www.dontronics-shop.com/super4-usb-relay-module.html My experience is very limited, the problem could be other than the libraries , & the manufactures (TCTEC) (www.emx.net.au) . The support folks from TCTEC (http://www.emx.net.au/super4usbrelay.htm) tell me that FTPI (www.ftpichip.com) developers will update the libftd2xx.so library, in the 1st quarter of 2010. Whether this is true , and would it fix the problem I don't know. libftd2xx.so.0.4.1X (ALL) libraries all have a major defiency. from kernels 2.6.18 up to 2.6.32 kernels they all suffer the same problem. The /dev/ttyUSBX disappears when you unplug the device. .... as you would expect! BUT The disappearing of the device occurs when it is still plugged in. All you need to do is run the "lrelayset" command. either listing , setting or unsetting will do. Although the /dev listing disappears the "lrelayset" command is still usable/active.! Connecting another USB device will choose the 1st port. Now there will be 2 devices using /dev/ttyUSB0. & the new one(device) won't work . So I need this fixed ASAP. again ... any confirmation or help greatly appreciated Cheers Roger Salisbury ----- Original Message ----- From: Roger Salisbury To: ftd...@li... Sent: Monday, December 14, 2009 6:17 PM Subject: Regarding FTDI Library 0.4.16 -- wish list Hi Please understand my wish list! Regarding FTDI Library 0.4.16 versus the FTDI Library 0.4.13 The V16 & V13 libraries. Which is better. They both have serious defiencies V16 does indeed allow ttyUSB0 to be reused SUCCESSFULLY! V13 does NOT allow ttyUSB0 to be reused SUCCESSFULLY! V16 does indeed reset every device! V13 does NOT reset every device! (only the selected ones if new state is to be different) Wish list .... to have the benefit of both in the one Version My want list to to switch Power wires before data wires. If you physically plug in my USB dongle.... power is connected before data. IE pin 1 & 4 connects before 2 & 3. (2 & 3 gold connectors are offset inwardly from 1 & 4 ) The module: I have power wire "red & black" on relay 1 & 2 & data on 3 & 4 So the code below on Ver 13 ... it works like I want , BUT on Ver 16 it doesn't # lrelayset -sFTSIL4VG,3 # sleep 1 # lrelayset -sFTSIL4VG,15 Also for me 12 & 15 should also do the same The 2 sets of code below behaves the same in V13 # lrelayset -sFTSIL4VG,3 # sleep 1 # lrelayset -sFTSIL4VG,12 ######################################## # lrelayset -sFTSIL4VG,3 # sleep 1 # lrelayset -sFTSIL4VG,15 ----- Original Message ----- From: Roger Salisbury To: ftd...@li... Sent: Sunday, December 13, 2009 4:55 PM Subject: Linux support for FT232RL not production ready Hi Not sure if Bill Ryder or Greg Kroah-Hartman or some of the other names fromm google searches can help. As is Linux specific but the only support thus far is http://www.ftdichip.com/FTSupport.htm#DriverSupport Which hasn't helped yet. So Any other help greatly appreciated. I have a problem using Linux with the device from http://www.dontronics-shop.com/super4-usb-relay-module.html Linux support for the Super4 USB Relay Module .. using FT232RL would it be considered production ready? The Super4 USB Relay Module does work to a point on "puppy" linux & a few others . I want to use this device on Ubuntu910. I want to be able to powercycle a broadband USB modem from the CLI . BUT Both devices want to use ttyUSB0. If ttyUSB0 is NOT free (in use) the USBmodem will select ttyUSB1. But USB0 becomes free (or considered to be free at some level ) when it shouln't & will select ttyUSB0. Most Linux installation it kind of works. RH5, RH4, FC11,Debian Lenny (even puppy linux has this same problem) At least All 4 relays can be set & unset from the CLI (command line interface). The problem is :: on plugging in the USB cable an entry in /dev appears. (/dev/ttyUSB0) The entry thereafter disappears when the device is accessed or set or unset. #lrelayset -l the above command lists the number of devices with the SerialNumbers. After issuing the command the (/dev/ttyUSB0) disappears. So subsequent USB devices want to use the same (/dev/ttyUSB0) device, causing conflicts it seems. Perhaps that is normal, BUT this seems bizzare to me! The Setup on linux is simple : Any modern Linux distro with 2 supplementary files /usr/bin/lrelayset -l /usr/lib/libftd2xx.so linked to libftd2xx.so.0.4.13 (http://emx.net.au/page426.htm) On installations that don't work. IE where the "lrelayset -l" doesn't work, the similiarities are very similiar to a working?? system. Below are listing from "lsusb -v" on two systems. firstly kernel messages to "/var/log/messages" compared. Fc11 has 5 uniq lines & ubuntu910 has 4. 10 lines are common to both. So ubuntu must be close to working ???? COMMON ::::::::::: ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected usb 3-2: configuration #1 chosen from 1 choice usb 3-2: configuration #1 chosen from 1 choice usb 3-2: Detected FT232RL usb 3-2: Detected FT232RL usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0 usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0 usb 3-2: new full speed USB device using uhci_hcd and address 3 usb 3-2: new full speed USB device using uhci_hcd and address 3 Fedora Core 11 :::::::::::: usb 3-2: New USB device found, idVendor=0403, idProduct=6001 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2: Product: TCTEC USB RELAY usb 3-2: SerialNumber: FTSIL4VG usb 3-2: Manufacturer: TCTEC Ubuntu 910 :::::::::::: usb 3-2: Number of endpoints 2 usb 3-2: Setting MaxPacketSize 64 usb 3-2: Endpoint 1 MaxPacketSize 64 usb 3-2: Endpoint 2 MaxPacketSize 64 ######################################################################### ########################################################################## likewise >From the "lsusb -v listings from both machines the listing is almost identical except for the following 3 lines :::::::::::::::::::::::::::::::::::::::::::::::::: Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT Bus 003 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC 232 USB-Serial (UART) IC :::::::::::::::::::::::::::::::::::::::::::::::::::::: ##################################################################################### Fedora Core 11 ::::::::::::: [root@stc ~]# lsusb -v -d 0403:6001 Bus 003 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 TCTEC iProduct 2 TCTEC USB RELAY iSerial 3 FTSIL4VG bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 320mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 TCTEC USB RELAY Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) [root@stc ~]# Ubuntu 910:::::::::::::: root@ubuntu-laptop:~# lsusb -v -d 0403:6001 Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT 232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 TCTEC iProduct 2 TCTEC USB RELAY iSerial 3 FTSIL4VG bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 320mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 TCTEC USB RELAY Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) root@ubuntu-laptop:~# Also ######################################################################### The kernel version for lrelayset :2.6.16. this may/may not be significant when run on different kernels ?? root@roger-laptop:~# file /usr/bin/lrelayset /usr/bin/lrelayset: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped root@roger-laptop:~# ########################################################################## |
From: <gry...@gm...> - 2009-12-16 16:11:49
|
From: Grygoriy Fuchedzhy <gry...@gm...> --- drivers/usb/serial/ftdi_sio.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index f99498f..4fa17f3 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -2048,7 +2048,7 @@ static int ftdi_process_packet(struct tty_struct *tty, flag = TTY_NORMAL; if (packet[1] & FTDI_RS_OE) { flag = TTY_OVERRUN; - dbg("OVERRRUN error"); + dbg("OVERRUN error"); } if (packet[1] & FTDI_RS_BI) { flag = TTY_BREAK; -- 1.6.4.4 |
From: Roger S. <ro...@tp...> - 2009-12-14 07:17:39
|
Hi Please understand my wish list! Regarding FTDI Library 0.4.16 versus the FTDI Library 0.4.13 The V16 & V13 libraries. Which is better. They both have serious defiencies V16 does indeed allow ttyUSB0 to be reused SUCCESSFULLY! V13 does NOT allow ttyUSB0 to be reused SUCCESSFULLY! V16 does indeed reset every device! V13 does NOT reset every device! (only the selected ones if new state is to be different) Wish list .... to have the benefit of both in the one Version My want list to to switch Power wires before data wires. If you physically plug in my USB dongle.... power is connected before data. IE pin 1 & 4 connects before 2 & 3. (2 & 3 gold connectors are offset inwardly from 1 & 4 ) The module: I have power wire "red & black" on relay 1 & 2 & data on 3 & 4 So the code below on Ver 13 ... it works like I want , BUT on Ver 16 it doesn't # lrelayset -sFTSIL4VG,3 # sleep 1 # lrelayset -sFTSIL4VG,15 Also for me 12 & 15 should also do the same The 2 sets of code below behaves the same in V13 # lrelayset -sFTSIL4VG,3 # sleep 1 # lrelayset -sFTSIL4VG,12 ######################################## # lrelayset -sFTSIL4VG,3 # sleep 1 # lrelayset -sFTSIL4VG,15 ----- Original Message ----- From: Roger Salisbury To: ftd...@li... Sent: Sunday, December 13, 2009 4:55 PM Subject: Linux support for FT232RL not production ready Hi Not sure if Bill Ryder or Greg Kroah-Hartman or some of the other names fromm google searches can help. As is Linux specific but the only support thus far is http://www.ftdichip.com/FTSupport.htm#DriverSupport Which hasn't helped yet. So Any other help greatly appreciated. I have a problem using Linux with the device from http://www.dontronics-shop.com/super4-usb-relay-module.html Linux support for the Super4 USB Relay Module .. using FT232RL would it be considered production ready? The Super4 USB Relay Module does work to a point on "puppy" linux & a few others . I want to use this device on Ubuntu910. I want to be able to powercycle a broadband USB modem from the CLI . BUT Both devices want to use ttyUSB0. If ttyUSB0 is NOT free (in use) the USBmodem will select ttyUSB1. But USB0 becomes free (or considered to be free at some level ) when it shouln't & will select ttyUSB0. Most Linux installation it kind of works. RH5, RH4, FC11,Debian Lenny (even puppy linux has this same problem) At least All 4 relays can be set & unset from the CLI (command line interface). The problem is :: on plugging in the USB cable an entry in /dev appears. (/dev/ttyUSB0) The entry thereafter disappears when the device is accessed or set or unset. #lrelayset -l the above command lists the number of devices with the SerialNumbers. After issuing the command the (/dev/ttyUSB0) disappears. So subsequent USB devices want to use the same (/dev/ttyUSB0) device, causing conflicts it seems. Perhaps that is normal, BUT this seems bizzare to me! The Setup on linux is simple : Any modern Linux distro with 2 supplementary files /usr/bin/lrelayset -l /usr/lib/libftd2xx.so linked to libftd2xx.so.0.4.13 (http://emx.net.au/page426.htm) On installations that don't work. IE where the "lrelayset -l" doesn't work, the similiarities are very similiar to a working?? system. Below are listing from "lsusb -v" on two systems. firstly kernel messages to "/var/log/messages" compared. Fc11 has 5 uniq lines & ubuntu910 has 4. 10 lines are common to both. So ubuntu must be close to working ???? COMMON ::::::::::: ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected usb 3-2: configuration #1 chosen from 1 choice usb 3-2: configuration #1 chosen from 1 choice usb 3-2: Detected FT232RL usb 3-2: Detected FT232RL usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0 usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0 usb 3-2: new full speed USB device using uhci_hcd and address 3 usb 3-2: new full speed USB device using uhci_hcd and address 3 Fedora Core 11 :::::::::::: usb 3-2: New USB device found, idVendor=0403, idProduct=6001 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2: Product: TCTEC USB RELAY usb 3-2: SerialNumber: FTSIL4VG usb 3-2: Manufacturer: TCTEC Ubuntu 910 :::::::::::: usb 3-2: Number of endpoints 2 usb 3-2: Setting MaxPacketSize 64 usb 3-2: Endpoint 1 MaxPacketSize 64 usb 3-2: Endpoint 2 MaxPacketSize 64 ######################################################################### ########################################################################## likewise >From the "lsusb -v listings from both machines the listing is almost identical except for the following 3 lines :::::::::::::::::::::::::::::::::::::::::::::::::: Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT Bus 003 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC 232 USB-Serial (UART) IC :::::::::::::::::::::::::::::::::::::::::::::::::::::: ##################################################################################### Fedora Core 11 ::::::::::::: [root@stc ~]# lsusb -v -d 0403:6001 Bus 003 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 TCTEC iProduct 2 TCTEC USB RELAY iSerial 3 FTSIL4VG bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 320mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 TCTEC USB RELAY Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) [root@stc ~]# Ubuntu 910:::::::::::::: root@ubuntu-laptop:~# lsusb -v -d 0403:6001 Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT 232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 TCTEC iProduct 2 TCTEC USB RELAY iSerial 3 FTSIL4VG bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 320mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 TCTEC USB RELAY Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) root@ubuntu-laptop:~# Also ######################################################################### The kernel version for lrelayset :2.6.16. this may/may not be significant when run on different kernels ?? root@roger-laptop:~# file /usr/bin/lrelayset /usr/bin/lrelayset: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped root@roger-laptop:~# ########################################################################## |
From: Roger S. <ro...@tp...> - 2009-12-13 05:56:04
|
Hi Not sure if Bill Ryder or Greg Kroah-Hartman or some of the other names fromm google searches can help. As is Linux specific but the only support thus far is http://www.ftdichip.com/FTSupport.htm#DriverSupport Which hasn't helped yet. So Any other help greatly appreciated. I have a problem using Linux with the device from http://www.dontronics-shop.com/super4-usb-relay-module.html Linux support for the Super4 USB Relay Module .. using FT232RL would it be considered production ready? The Super4 USB Relay Module does work to a point on "puppy" linux & a few others . I want to use this device on Ubuntu910. I want to be able to powercycle a broadband USB modem from the CLI . BUT Both devices want to use ttyUSB0. If ttyUSB0 is NOT free (in use) the USBmodem will select ttyUSB1. But USB0 becomes free (or considered to be free at some level ) when it shouln't & will select ttyUSB0. Most Linux installation it kind of works. RH5, RH4, FC11,Debian Lenny (even puppy linux has this same problem) At least All 4 relays can be set & unset from the CLI (command line interface). The problem is :: on plugging in the USB cable an entry in /dev appears. (/dev/ttyUSB0) The entry thereafter disappears when the device is accessed or set or unset. #lrelayset -l the above command lists the number of devices with the SerialNumbers. After issuing the command the (/dev/ttyUSB0) disappears. So subsequent USB devices want to use the same (/dev/ttyUSB0) device, causing conflicts it seems. Perhaps that is normal, BUT this seems bizzare to me! The Setup on linux is simple : Any modern Linux distro with 2 supplementary files /usr/bin/lrelayset -l /usr/lib/libftd2xx.so linked to libftd2xx.so.0.4.13 (http://emx.net.au/page426.htm) On installations that don't work. IE where the "lrelayset -l" doesn't work, the similiarities are very similiar to a working?? system. Below are listing from "lsusb -v" on two systems. firstly kernel messages to "/var/log/messages" compared. Fc11 has 5 uniq lines & ubuntu910 has 4. 10 lines are common to both. So ubuntu must be close to working ???? COMMON ::::::::::: ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected usb 3-2: configuration #1 chosen from 1 choice usb 3-2: configuration #1 chosen from 1 choice usb 3-2: Detected FT232RL usb 3-2: Detected FT232RL usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0 usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0 usb 3-2: new full speed USB device using uhci_hcd and address 3 usb 3-2: new full speed USB device using uhci_hcd and address 3 Fedora Core 11 :::::::::::: usb 3-2: New USB device found, idVendor=0403, idProduct=6001 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2: Product: TCTEC USB RELAY usb 3-2: SerialNumber: FTSIL4VG usb 3-2: Manufacturer: TCTEC Ubuntu 910 :::::::::::: usb 3-2: Number of endpoints 2 usb 3-2: Setting MaxPacketSize 64 usb 3-2: Endpoint 1 MaxPacketSize 64 usb 3-2: Endpoint 2 MaxPacketSize 64 ######################################################################### ########################################################################## likewise >From the "lsusb -v listings from both machines the listing is almost identical except for the following 3 lines :::::::::::::::::::::::::::::::::::::::::::::::::: Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT Bus 003 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC 232 USB-Serial (UART) IC :::::::::::::::::::::::::::::::::::::::::::::::::::::: ##################################################################################### Fedora Core 11 ::::::::::::: [root@stc ~]# lsusb -v -d 0403:6001 Bus 003 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 TCTEC iProduct 2 TCTEC USB RELAY iSerial 3 FTSIL4VG bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 320mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 TCTEC USB RELAY Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) [root@stc ~]# Ubuntu 910:::::::::::::: root@ubuntu-laptop:~# lsusb -v -d 0403:6001 Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT 232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 TCTEC iProduct 2 TCTEC USB RELAY iSerial 3 FTSIL4VG bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 320mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 TCTEC USB RELAY Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) root@ubuntu-laptop:~# Also ######################################################################### The kernel version for lrelayset :2.6.16. this may/may not be significant when run on different kernels ?? root@roger-laptop:~# file /usr/bin/lrelayset /usr/bin/lrelayset: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped root@roger-laptop:~# ########################################################################## |
From: Eike S. <ei...@al...> - 2009-12-01 14:47:47
|
Hello all, I'm encountering both randomly missing and added (repeated?) bytes while using an FT232R in loop-back mode with RTS/CTS handshaking enabled, lange packets make the problem worse, higher bit rates as well. I'm currently using a 2.6.31 kernel. My final goal is attaching an FPGA-based design with proper handshaking and buffering at 3M Baud/s, the problem surfaced while developing the FPGA design and encountering corrupt data, I went back to the loop-back connection for debugging. Luckily, I was able to compare a serial port dongle employing an FT232B and could find no such problem at up to 500k Baud/s. My wild guess is that the problem might be related to the smaller buffer size of the FT232R. However, I'm neither familiar with kernel driver nor USB programming, and so I'm stuck right now. How do I go about debugging this kind of issue? Best regards, eike |
From: Bill R. <bil...@gm...> - 2009-11-25 18:27:20
|
Hi there, This list is for the kernel driver which you access through the normal open,close termios stuff. The driver doesn't have a userspace ftdi.h. It looks like you're using a userspace ftdi library and so will probably want a different forum. On Thu, Nov 26, 2009 at 4:50 AM, T. Horsnell <ts...@mr...> wrote: > Hi, > I'm struggling with what ought to be the most straightforward thing. > I'm trying to write to channel A of an FT2232H mini-module in serial > mode, but after writing a total of 4096 bytes, the writes hang > and I get an error -110 returned. > Presumably the buffer on the mini-module has filled up. But why > is this not being emptied as the device send things to its serial pin? > I've set flow-control to SIO_DISABLE_FLOW_CTRL (does this function > actually work? It seems to return success even if I try idiot values > like -1 or 12345 for the flow-control parameter). > > Thanks, > Terry > > My code: > > #include <stdio.h> > #include <time.h> > #include <unistd.h> > #include <usb.h> > #include <ftdi.h> > > const int vendor_id=0x0403; > const int product_id=0x6010; //FT2232H > > int main(int argc, char **argv) > { > struct ftdi_context ftdicA,ftdicB; > int f,i,j,k; > > printf("setting up channel A\n"); > ftdi_init(&ftdicA); > f = ftdi_usb_open(&ftdicA, vendor_id, product_id); > if(f < 0 && f != -5) > { > fprintf(stderr, "unable to open ftdi device: %d - > %s\n",f,ftdicA.error_str); > exit(-1); > } > printf("ftdi open A succeeded: %d\n",f); > > printf("setting flowcontrol\n"); > //i=ftdi_setflowctrl(&ftdicA, SIO_DISABLE_FLOW_CTRL); > i=ftdi_setflowctrl(&ftdicA, 7); > if (i != 0) > { > printf("setting channel A flow-control failed. stat=%i\n",i); > exit(0); > } > > #define BUFLEN 100000 > unsigned char buf0[BUFLEN]; > for (i=0; i<BUFLEN; i++) buf0[i]=0xff; > > for (j=0; j<5; j++) > { > printf("loop=%i\n",j); > //write a buffer > f = ftdi_write_data(&ftdicA, buf0, 1000); > if(f < 0) > { > fprintf(stderr,"write failed for %x, error %d - > %s\n",buf0[0],f,ftdicA.error_str); > break; > } > } > > ftdi_usb_close(&ftdicA); > ftdi_deinit(&ftdicA); > return 0; > } > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Ftdi-usb-sio-devel mailing list > Ftd...@li... > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > |
From: T. H. <ts...@mr...> - 2009-11-25 15:58:02
|
Hi, I'm struggling with what ought to be the most straightforward thing. I'm trying to write to channel A of an FT2232H mini-module in serial mode, but after writing a total of 4096 bytes, the writes hang and I get an error -110 returned. Presumably the buffer on the mini-module has filled up. But why is this not being emptied as the device send things to its serial pin? I've set flow-control to SIO_DISABLE_FLOW_CTRL (does this function actually work? It seems to return success even if I try idiot values like -1 or 12345 for the flow-control parameter). Thanks, Terry My code: #include <stdio.h> #include <time.h> #include <unistd.h> #include <usb.h> #include <ftdi.h> const int vendor_id=0x0403; const int product_id=0x6010; //FT2232H int main(int argc, char **argv) { struct ftdi_context ftdicA,ftdicB; int f,i,j,k; printf("setting up channel A\n"); ftdi_init(&ftdicA); f = ftdi_usb_open(&ftdicA, vendor_id, product_id); if(f < 0 && f != -5) { fprintf(stderr, "unable to open ftdi device: %d - %s\n",f,ftdicA.error_str); exit(-1); } printf("ftdi open A succeeded: %d\n",f); printf("setting flowcontrol\n"); //i=ftdi_setflowctrl(&ftdicA, SIO_DISABLE_FLOW_CTRL); i=ftdi_setflowctrl(&ftdicA, 7); if (i != 0) { printf("setting channel A flow-control failed. stat=%i\n",i); exit(0); } #define BUFLEN 100000 unsigned char buf0[BUFLEN]; for (i=0; i<BUFLEN; i++) buf0[i]=0xff; for (j=0; j<5; j++) { printf("loop=%i\n",j); //write a buffer f = ftdi_write_data(&ftdicA, buf0, 1000); if(f < 0) { fprintf(stderr,"write failed for %x, error %d - %s\n",buf0[0],f,ftdicA.error_str); break; } } ftdi_usb_close(&ftdicA); ftdi_deinit(&ftdicA); return 0; } |
From: Thomas T. <ta...@gm...> - 2009-11-13 15:05:53
|
Hi, could the maintainer of the FTDI driver please add support for the Cedrus USB response pads? http://www.cedrus.com/responsepads/rb_series.htm Attached you find my patch against Ubuntu 2.6.28-16 kernel but it should be trivial to adapt it the latest kernel. Thank you! -- Thomas Tanner ------ email: ta...@gm... GnuPG: 1024/5924D4DD |