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

[Ftdi-usb-sio-devel] falcom twist...

[Kalle K. <kal...@te...>]

Hi!

I have bought Falcom Twist USB GPRS -modem. Have anyone developed
linux-driver for it?

Regards,
Kalle
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27.1.2003

Re: [Ftdi-usb-sio-devel] Request for modification

[Bill R. <br...@pa...>]

Hi Wayne,

I'll do this soon. I should get an LCD to test with since Matrix Orbital 
are going to send me some for testing hopefully.


Wayne Wylupski wrote:

> Hello,
>  
> Matrix Orbital (www.matrixorbital.com <http://www.matrixorbital.com>) 
> has a set of USB displays that use the FT232BM USB driver, which, as 
> it was previously mentioned on this list, is similar to the supported 
> 8U232AM.  Please could the ftdi_sio be modified so as to recognize the 
> product IDs for these devices?  MO obtained a bank of seven product 
> IDs under FTDI's vendor ID. 
>  
> The patch follows, which I have tested out toi the best of my 
> ability.  If there are any questions, feel free to send me e-mail, for 
> I'd like to see this included in future versions of the device driver.
>  
> Thanks!
> Wayne Wylupski (pro...@we... 
> <mailto:pro...@we...>)
>  
>  
> --- ftdi_sio.h  2003-01-30 19:32:56.000000000 -0500
> +++ /home/wayne/linux-2.4.20/drivers/usb/serial/ftdi_sio.h      
> 2002-11-28 18:53:14.000000000 -0500
> @@ -25,19 +25,6 @@
>  #define FTDI_NF_RIC_VID        0x0DCD  /* Vendor Id */
>  #define FTDI_NF_RIC_PID        0x0001  /* Product Id */
>  
> -/*
> - * The following are the values for the Matrix Orbital LCD displays,
> - * which are the FT232BM ( similar to the 8U232AM )
> - */
> -#define FTDI_MTXORB_VID                FTDI_VID        /* Matrix 
> Orbital Product Id */
> -#define FTDI_MTXORB_0_PID      0xFA00  /* Matrix Orbital Product Id */
> -#define FTDI_MTXORB_1_PID      0xFA01  /* Matrix Orbital Product Id */
> -#define FTDI_MTXORB_2_PID      0xFA02  /* Matrix Orbital Product Id */
> -#define FTDI_MTXORB_3_PID      0xFA03  /* Matrix Orbital Product Id */
> -#define FTDI_MTXORB_4_PID      0xFA04  /* Matrix Orbital Product Id */
> -#define FTDI_MTXORB_5_PID      0xFA05  /* Matrix Orbital Product Id */
> -#define FTDI_MTXORB_6_PID      0xFA06  /* Matrix Orbital Product Id */
> -
>  #define FTDI_SIO_RESET                 0 /* Reset the port */
>  #define FTDI_SIO_MODEM_CTRL    1 /* Set the modem control register */
>  #define FTDI_SIO_SET_FLOW_CTRL 2 /* Set flow control register */
>  
>  
> --- ftdi_sio.c  2003-01-30 19:33:36.000000000 -0500
> +++ /home/wayne/linux-2.4.20/drivers/usb/serial/ftdi_sio.c      
> 2002-11-28 18:53:14.000000000 -0500
> @@ -154,13 +154,6 @@
>  static struct usb_device_id id_table_8U232AM [] = {
>         { USB_DEVICE(FTDI_VID, FTDI_8U232AM_PID) },
>         { USB_DEVICE(FTDI_NF_RIC_VID, FTDI_NF_RIC_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_0_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_1_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_2_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_3_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_4_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_5_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_6_PID) },
>         { }                                             /* Terminating 
> entry */
>  };
>  
> @@ -169,13 +162,6 @@
>         { USB_DEVICE(FTDI_VID, FTDI_SIO_PID) },
>         { USB_DEVICE(FTDI_VID, FTDI_8U232AM_PID) },
>         { USB_DEVICE(FTDI_NF_RIC_VID, FTDI_NF_RIC_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_0_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_1_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_2_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_3_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_4_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_5_PID) },
> -       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_6_PID) },
>         { }                                             /* Terminating 
> entry */
>  };

[Ftdi-usb-sio-devel] Request for modification

[Wayne W. <wa...@co...>]

Hello,

Matrix Orbital (www.matrixorbital.com) has a set of USB displays that =
use the FT232BM USB driver, which, as it was previously mentioned on =
this list, is similar to the supported 8U232AM.  Please could the =
ftdi_sio be modified so as to recognize the product IDs for these =
devices?  MO obtained a bank of seven product IDs under FTDI's vendor =
ID.=20

The patch follows, which I have tested out toi the best of my ability.  =
If there are any questions, feel free to send me e-mail, for I'd like to =
see this included in future versions of the device driver.

Thanks!
Wayne Wylupski (pro...@we...)


--- ftdi_sio.h  2003-01-30 19:32:56.000000000 -0500
+++ /home/wayne/linux-2.4.20/drivers/usb/serial/ftdi_sio.h      =
2002-11-28 18:53:14.000000000 -0500
@@ -25,19 +25,6 @@
 #define FTDI_NF_RIC_VID        0x0DCD  /* Vendor Id */
 #define FTDI_NF_RIC_PID        0x0001  /* Product Id */
=20
-/*
- * The following are the values for the Matrix Orbital LCD displays,
- * which are the FT232BM ( similar to the 8U232AM )
- */
-#define FTDI_MTXORB_VID                FTDI_VID        /* Matrix =
Orbital Product Id */
-#define FTDI_MTXORB_0_PID      0xFA00  /* Matrix Orbital Product Id */
-#define FTDI_MTXORB_1_PID      0xFA01  /* Matrix Orbital Product Id */
-#define FTDI_MTXORB_2_PID      0xFA02  /* Matrix Orbital Product Id */
-#define FTDI_MTXORB_3_PID      0xFA03  /* Matrix Orbital Product Id */
-#define FTDI_MTXORB_4_PID      0xFA04  /* Matrix Orbital Product Id */
-#define FTDI_MTXORB_5_PID      0xFA05  /* Matrix Orbital Product Id */
-#define FTDI_MTXORB_6_PID      0xFA06  /* Matrix Orbital Product Id */
-
 #define FTDI_SIO_RESET                 0 /* Reset the port */
 #define FTDI_SIO_MODEM_CTRL    1 /* Set the modem control register */
 #define FTDI_SIO_SET_FLOW_CTRL 2 /* Set flow control register */
=20
=20
--- ftdi_sio.c  2003-01-30 19:33:36.000000000 -0500
+++ /home/wayne/linux-2.4.20/drivers/usb/serial/ftdi_sio.c      =
2002-11-28 18:53:14.000000000 -0500
@@ -154,13 +154,6 @@
 static struct usb_device_id id_table_8U232AM [] =3D {
        { USB_DEVICE(FTDI_VID, FTDI_8U232AM_PID) },
        { USB_DEVICE(FTDI_NF_RIC_VID, FTDI_NF_RIC_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_0_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_1_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_2_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_3_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_4_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_5_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_6_PID) },
        { }                                             /* Terminating =
entry */
 };
=20
@@ -169,13 +162,6 @@
        { USB_DEVICE(FTDI_VID, FTDI_SIO_PID) },
        { USB_DEVICE(FTDI_VID, FTDI_8U232AM_PID) },
        { USB_DEVICE(FTDI_NF_RIC_VID, FTDI_NF_RIC_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_0_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_1_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_2_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_3_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_4_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_5_PID) },
-       { USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_6_PID) },
        { }                                             /* Terminating =
entry */
 };

[Ftdi-usb-sio-devel] kernel panic using FT8U245AM

[Mathias F. <ma...@we...>]

Hello,

I am using a FT8U245AM on a ucontoller board.
The ucontroller receives characters until CR ("\r") is found and sends bac=
k a prompt ("> ") plus the received characters.
Using minicom I got a kernel panic after some typing.
I did further testing and was able to reproduce the kernel panic from the =
shell simply by:

echo -e "\r" >/dev/ttyUSB0

The attached two oops'es were produced by a vanilla 2.4.20 kernel, but the=
 problem occurs on 2.4.19 and even 2.5.59 as well.

(The oops was captured using the serial console.)

Any idea what is happening here=3F


Thanks,

Matthias



ksymoops 2.4.8 on i686 2.4.20.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

kernel BUG at sched.c:564!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c01155ff>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000018   ebx: f76e0878   ecx: c0274608   edx: 0000001b
esi: f75b1b9c   edi: f75b0000   ebp: f75b1b88   esp: f75b1b64
ds: 0018   es: 0018   ss: 0018
Process bash (pid: 167, stackpage=3Df75b1000)
Stack: c023601e f76e0878 f75b1b9c f75b0000 00000000 c0125e09 00000000 f75b=
0000=20
       f76e0878 f75b3368 c0107624 f76e081c f76e0800 ffffffea 00000001 f75b=
0000=20
       f76e0884 f76e0884 c0107784 f76e0878 f76e0800 00000000 c01ee661 0000=
0030=20
Call Trace:    [<c0125e09>] [<c0107624>] [<c0107784>] [<c01ee661>] [<c018c=
5d8>]
  [<c018c93a>] [<c018d11f>] [<c0126312>] [<c012685e>] [<c01088f8>] [<c01e6=
9c6>]
  [<c01e869b>] [<c018bf57>] [<c018bff4>] [<c01ef735>] [<c01e8c45>] [<c01e8=
d4c>]
  [<c0109c7f>] [<c0109dfe>] [<c019aef3>] [<c019f2db>] [<c0118149>] [<c0118=
1b7>]
  [<c0118275>] [<c011849e>] [<c0118415>] [<c01ef15e>] [<c01ecb7a>] [<c018c=
8d3>]
  [<c0125e0a>] [<c01158a6>] [<c018e79e>] [<c018a408>] [<c018e630>] [<c0134=
256>]
  [<c0108807>]
Code: 0f 0b 34 02 16 60 23 c0 83 c4 04 8b 4d f4 c1 e1 06 81 c1 40=20


>>EIP; c01155ff <schedule+4f/320>   <=3D=3D=3D=3D=3D

>>ebx; f76e0878 <=5Fend+373e1da8/38549530>
>>ecx; c0274608 <console=5Fsem+0/14>
>>esi; f75b1b9c <=5Fend+372b30cc/38549530>
>>edi; f75b0000 <=5Fend+372b1530/38549530>
>>ebp; f75b1b88 <=5Fend+372b30b8/38549530>
>>esp; f75b1b64 <=5Fend+372b3094/38549530>

Trace; c0125e09 <do=5Fno=5Fpage+139/190>
Trace; c0107624 <=5F=5Fdown+54/a0>
Trace; c0107784 <=5F=5Fdown=5Ffailed+8/c>
Trace; c01ee661 <.text.lock.usbserial+41/e0>
Trace; c018c5d8 <opost+18/1b0>
Trace; c018c93a <echo=5Fchar+5a/60>
Trace; c018d11f <n=5Ftty=5Freceive=5Fbuf+3df/f20>
Trace; c0126312 <=5F=5Fvma=5Flink+62/b0>
Trace; c012685e <do=5Fmmap=5Fpgoff+40e/4d0>
Trace; c01088f8 <error=5Fcode+34/3c>
Trace; c01e69c6 <uhci=5Fclean=5Ftransfer+86/1c0>
Trace; c01e869b <process=5Ftransfer+2cb/2e0>
Trace; c018bf57 <flush=5Fto=5Fldisc+d7/e0>
Trace; c018bff4 <tty=5Fflip=5Fbuffer=5Fpush+14/60>
Trace; c01ef735 <ftdi=5Fread=5Fbulk=5Fcallback+2a5/320>
Trace; c01e8c45 <process=5Furb+1c5/200>
Trace; c01e8d4c <uhci=5Finterrupt+cc/130>
Trace; c0109c7f <handle=5FIRQ=5Fevent+2f/60>
Trace; c0109dfe <do=5FIRQ+6e/b0>
Trace; c019aef3 <serial=5Fin+13/30>
Trace; c019f2db <serial=5Fconsole=5Fwrite+5b/190>
Trace; c0118149 <=5F=5Fcall=5Fconsole=5Fdrivers+39/50>
Trace; c01181b7 <=5Fcall=5Fconsole=5Fdrivers+57/60>
Trace; c0118275 <call=5Fconsole=5Fdrivers+b5/e0>
Trace; c011849e <release=5Fconsole=5Fsem+2e/80>
Trace; c0118415 <printk+105/120>
Trace; c01ef15e <ftdi=5Fwrite+4e/280>
Trace; c01ecb7a <serial=5Fwrite+da/110>
Trace; c018c8d3 <opost=5Fblock+163/170>
Trace; c0125e0a <do=5Fno=5Fpage+13a/190>
Trace; c01158a6 <schedule+2f6/320>
Trace; c018e79e <write=5Fchan+16e/210>
Trace; c018a408 <tty=5Fwrite+198/210>
Trace; c018e630 <write=5Fchan+0/210>
Trace; c0134256 <sys=5Fwrite+96/f0>
Trace; c0108807 <system=5Fcall+33/38>

Code;  c01155ff <schedule+4f/320>
00000000 <=5FEIP>:
Code;  c01155ff <schedule+4f/320>   <=3D=3D=3D=3D=3D
   0:   0f 0b                     ud2a      <=3D=3D=3D=3D=3D
Code;  c0115601 <schedule+51/320>
   2:   34 02                     xor    $0x2,%al
Code;  c0115603 <schedule+53/320>
   4:   16                        push   %ss
Code;  c0115604 <schedule+54/320>
   5:   60                        pusha =20
Code;  c0115605 <schedule+55/320>
   6:   23 c0                     and    %eax,%eax
Code;  c0115607 <schedule+57/320>
   8:   83 c4 04                  add    $0x4,%esp
Code;  c011560a <schedule+5a/320>
   b:   8b 4d f4                  mov    0xfffffff4(%ebp),%ecx
Code;  c011560d <schedule+5d/320>
   e:   c1 e1 06                  shl    $0x6,%ecx
Code;  c0115610 <schedule+60/320>
  11:   81 c1 40 00 00 00         add    $0x40,%ecx

 <0>Kernel panic: Aiee, killing interrupt handler!

1 warning issued.  Results may not be reliable.


---------------------------

ksymoops 2.4.8 on i686 2.4.20.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

kernel BUG at sched.c:564!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c01155ff>]    Tainted: P=20
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000018   ebx: f78a8878   ecx: 00000001   edx: 00000001
esi: c0289db0   edi: c0288000   ebp: c0289d9c   esp: c0289d78
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=3Dc0289000)
Stack: c023601e f78a8878 c0289db0 c0288000 00000040 00000001 00000000 c028=
8000=20
       f78a8878 f6fc1168 c0107624 f78a881c f78a8800 ffffffea 00000001 c028=
8000=20
       f78a8884 f78a8884 c0107784 f78a8878 f78a8800 00000000 c01ee661 0000=
000a=20
Call Trace:    [<c0107624>] [<c0107784>] [<c01ee661>] [<c018c5d8>] [<c018d=
4bf>]
  [<c01dcba6>] [<c01e5b69>] [<c01e69c6>] [<c01e869b>] [<c018bf57>] [<c018b=
ff4>]
  [<c01ef735>] [<c01e8c45>] [<c01e8d4c>] [<c0109c7f>] [<c0109dfe>] [<c0106=
d50>]
  [<c0106d50>] [<c0106d50>] [<c0106d50>] [<c0106d73>] [<c0106de2>] [<c0105=
000>]
  [<c0105027>]
Code: 0f 0b 34 02 16 60 23 c0 83 c4 04 8b 4d f4 c1 e1 06 81 c1 40=20


>>EIP; c01155ff <schedule+4f/320>   <=3D=3D=3D=3D=3D

>>ebx; f78a8878 <=5Fend+375a9da8/38549530>
>>esi; c0289db0 <init=5Ftask=5Funion+1db0/2000>
>>edi; c0288000 <init=5Ftask=5Funion+0/2000>
>>ebp; c0289d9c <init=5Ftask=5Funion+1d9c/2000>
>>esp; c0289d78 <init=5Ftask=5Funion+1d78/2000>

Trace; c0107624 <=5F=5Fdown+54/a0>
Trace; c0107784 <=5F=5Fdown=5Ffailed+8/c>
Trace; c01ee661 <.text.lock.usbserial+41/e0>
Trace; c018c5d8 <opost+18/1b0>
Trace; c018d4bf <n=5Ftty=5Freceive=5Fbuf+77f/f20>
Trace; c01dcba6 <pci=5Fpool=5Ffree+16/e0>
Trace; c01e5b69 <delete=5Fdesc+19/20>
Trace; c01e69c6 <uhci=5Fclean=5Ftransfer+86/1c0>
Trace; c01e869b <process=5Ftransfer+2cb/2e0>
Trace; c018bf57 <flush=5Fto=5Fldisc+d7/e0>
Trace; c018bff4 <tty=5Fflip=5Fbuffer=5Fpush+14/60>
Trace; c01ef735 <ftdi=5Fread=5Fbulk=5Fcallback+2a5/320>
Trace; c01e8c45 <process=5Furb+1c5/200>
Trace; c01e8d4c <uhci=5Finterrupt+cc/130>
Trace; c0109c7f <handle=5FIRQ=5Fevent+2f/60>
Trace; c0109dfe <do=5FIRQ+6e/b0>
Trace; c0106d50 <default=5Fidle+0/30>
Trace; c0106d50 <default=5Fidle+0/30>
Trace; c0106d50 <default=5Fidle+0/30>
Trace; c0106d50 <default=5Fidle+0/30>
Trace; c0106d73 <default=5Fidle+23/30>
Trace; c0106de2 <cpu=5Fidle+42/60>
Trace; c0105000 <=5Fstext+0/0>
Trace; c0105027 <rest=5Finit+27/30>

Code;  c01155ff <schedule+4f/320>
00000000 <=5FEIP>:
Code;  c01155ff <schedule+4f/320>   <=3D=3D=3D=3D=3D
   0:   0f 0b                     ud2a      <=3D=3D=3D=3D=3D
Code;  c0115601 <schedule+51/320>
   2:   34 02                     xor    $0x2,%al
Code;  c0115603 <schedule+53/320>
   4:   16                        push   %ss
Code;  c0115604 <schedule+54/320>
   5:   60                        pusha =20
Code;  c0115605 <schedule+55/320>
   6:   23 c0                     and    %eax,%eax
Code;  c0115607 <schedule+57/320>
   8:   83 c4 04                  add    $0x4,%esp
Code;  c011560a <schedule+5a/320>
   b:   8b 4d f4                  mov    0xfffffff4(%ebp),%ecx
Code;  c011560d <schedule+5d/320>
   e:   c1 e1 06                  shl    $0x6,%ecx
Code;  c0115610 <schedule+60/320>
  11:   81 c1 40 00 00 00         add    $0x40,%ecx

 <0>Kernel panic: Aiee, killing interrupt handler!

1 warning issued.  Results may not be reliable.

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F
Wenn POP f=FCr Sie mehr als nur Musik ist. Senden Sie Ihre SMS direkt aus
Outlook oder Netscape! http://freemail.web.de/features/=3Fmc=3D021177

Re: [Ftdi-usb-sio-devel] FT232BM

[Ian A. <ab...@me...>]

On Sat, 25 Jan 2003 20:33:37 -0000, Wayne Wylupski wrote:

>What is the current state of the FT232BM support within ftdi_sio?
>In an post in the archive it was mentioned that it should work if
>I add the proper vendor and product IDs; is the FT232BM more like
>the FT8U100AX or more like the 8U232AM?

It's like the 8U232AM, but with some extra features.  I don't think the
extra features are supported yet in ftdi_sio, but ISTR Bill was working
on it.

The current release versions of the VCP (Virtual Com Port) drivers for
Windows do not support the extra features either, but the D2XX drivers
for Windows do.  There are unsigned beta versions of the VCP drivers for
Windows available (but not off the ftdichip website) that do support the
extra features. (At least they support the extra baud rates. I can't
remember if they support the programmable latency timer.)

FTDI's Windows drivers distinguish the 8U232AM from the FT232BM not by
the PID and VID (which remain the same by default), but by a flag
programmed into the EEPROM by their EEPROM programming program for
Windows.  The later versions of this (possibly not the released version
on the website) has a "Rev 4" box that is checked to mark the device
being programmed as a "BM" part, rather than an "AM" part.  Presumably,
a future version of the ftdi_sio driver could read this flag to
distinguish the 8U232AM and FT232BM.

[Ftdi-usb-sio-devel] How to install a serial modem plugged via FTDI's USB to serial convertor in RH LINUX ?

[Alexander B. <ab...@za...>]

       Dear everybody !
After a had plugged 'USB to Serial convertor'  and started my RH Linux, 
it (Linux) found it.
How should I determ the modem ? When this modem plugges to PC via a 
serial port it was /dev/ttyS0,
but now, when plugged via FTDI's 'USB to serial convertor' it doesn't 
respond.
Please write me. Alexander

[Ftdi-usb-sio-devel] FT232BM

[Wayne W. <wa...@co...>]

Hello,

What is the current state of the FT232BM support within ftdi_sio?  In an =
post in the archive it was mentioned that it should work if I add the =
proper vendor and product IDs; is the FT232BM more like the FT8U100AX or =
more like the 8U232AM?

Thanks,

Wayne Wylupski

[Ftdi-usb-sio-devel] compile

[Collier, J. <Jac...@dr...>]

>From Jack Collier, 

I am using an FTDI cable to connect to a SICK scanner and want to install
the latest driver which I downloaded off your website.  Unfortunately I am
no expert at compiling modules and I am unable to compile mine.  I was
wondering if you had a makefile or any compiling instructions availiable.  I
am sure they would come in handy and may be a good thing to include on your
project site.  Or perhaps you could make a module availiable directly for
download.  Anyway, any help that you could give me would be greatly
appreciated.

Jack Collier
Defense R & D Canada
(403) 544-4871

[Ftdi-usb-sio-devel] FT245BM

[Sreekrishnan V. <s_k...@in...>]

Hello,

I have a FT245BM on my PDA. If I do a "cat /dev/ttyUSB0" on the host end
(and try to send data from the PDA end), the kernel panics.

Recreatable everytime this is done.

I have the latest driver. How do I proceed from here?

Thanks and Warm Regards,
krishnan

[Ftdi-usb-sio-devel] Full speed driver?

[Heinrich du T. <hd...@tl...>]

Hello

According to the docs I found your driver can handle 300 bytes per second.
This is very slow?

Is there any reason why the driver is not full speed i.e. 12MBit/s ??

I'm am intrested in writing such a full speed USB device driver.

Is this going to be difficult for anyreason?

I have already programmed a USB driver. So I am fimiliar with the kernel and
USB and so on.
(No good thought :-) But I can help myself.

Thanks
-Heinrich

P.S. does your driver compile for the 2.5 kernel?
Just wondering since the usb stuff changes alot in 2.5.x

[Ftdi-usb-sio-devel] Re: Any Linux support for "event characters"?

[David B. <db...@ya...>]

Bill Ryder wrote:

> If possible you should use hardware flow control though. .xon/xoff is 
> evil :-)

Actually, I'm not sure where this xon/xoff talk came from.  Since I'm
using the 245 I do use hardware flow control (i.e. the ucontroller obeys
the TXE# signal).

> If you want to be as efficient as possible you could use 64byte packets 
> in your protocol. That will trigger a flush I believe.

Yes, using the same usec timestamps I mentioned in my earlier post, I
can confirm this works pretty well also, except in the rare case where
you're unlucky enough to have the timer go off while you're stoking the
data bytes in.  

Actually, a transmit is triggered after 62 bytes of user data, since you
loose 2 bytes to the status.  So by adding 52 nulls to the end of my 10
bytes messages, the messages launch asap (except occasionally when the
timer intrudes).  I see the new device also has a new SENDI pin, which
sounds quite useful.

dB.

[Ftdi-usb-sio-devel] re: Any Linux support for "event characters"?

[David B. <db...@ya...>]

John Wilkins wrote:

> (*) If anyones got any suggestion on how I can test if this is working,
> please let me know -- I thought about just checking the last byte of
> each packet for the event char, but that doesn't work all the time as
> the buffer will still get flushed on the 16ms timer (I think).

I managed to verify that your hardcoded solution does indeed work.  I
added usec timestamps to the ftdi_sio.c debug messages.  Without event
characters, my incoming messages arrive on the next 16 msec tick,
regardless of when the slave ucontroller sent them.  With an event
character in place, the replies arrive much sooner, and definitely out
of sync with the original 16 msec tick.

Now, if I could just work out how to send 0xff up in the data stream.

regards,

David Bath.

Re: [Ftdi-usb-sio-devel] Any Linux support for "event characters"?

[Bill R. <br...@pa...>]

What John says is correct. Event characters are not implemented.

An appropriate way to use it is to maybe use the ioctl which sets an 
XON./XOFF type character but I haven't really given it much thought.

If possible you should use hardware flow control though. .xon/xoff is 
evil :-)

If you want to be as efficient as possible you could use 64byte packets 
in your protocol. That will trigger a flush I believe.

The newer devices do allow a tunable timeout but as usual I haven't got 
around to implementing support for this yet. (that would be done through 
the VTIME  mechanism).




John Wilkins wrote:

>On Sun, 2003-01-05 at 08:52, David Bath wrote:
>  
>
>>Hi again,
>>
>>Is there any Linux support for "event characters" as defined in:
>>
>>http://www.ftdichip.com/Documents/AN232-06.PDF
>>
>>I have an application that sends 10 bytes messages to the Linux host
>>periodically, and if possible, I'd rather not have to wait for the next
>>16msec timer expiration to launch the data.  I could easily make the
>>messages 11 bytes long by tacking an "event character" on the end of
>>each message to get things moving sooner.
>>
>>regards,
>>
>>David Bath.
>>    
>>
>
>Bill Ryder will have the definitive answer, but in the meantime, from
>spending the past couple of months looking at the ftdi_sio source, I
>don't think event characters are currently supported.
>
>If you look in the .h file you will see a section giving the control
>message structures and the #defines ready to be used but as far as I can
>see there isn't yet any implementation of it in the driver source.
>
>It **appears** that it could be quite straight-forward to do - fill
>a control message with the correct information and send it - the only
>variable param is your actual event char.  I've added the following
>code to my ftdi_sio.c to try to add event char support.  I haven't
>yet been able to do any real testing to check that it's working (*)
>though it compiles fine and the function executes without causing
>a kernel panic, so that's a start!!!!!!!!
>
>// added  to see if we can improve download speeds.
>// the win2k implementation seems to use event chars
>// not sure how to call it so we'll call it when we
>// do xonxoff
>static int set_event_char(struct usb_serial_port * port)
>{
>	struct usb_serial *serial = port->serial;
>	char buf[1];
>
>	err(__FUNCTION__ " begin ");
>
>	if (usb_control_msg(serial->dev,
>			    usb_sndctrlpipe(serial->dev, 0),
>			    FTDI_SIO_SET_EVENT_CHAR_REQUEST,
>			    FTDI_SIO_SET_EVENT_CHAR_REQUEST_TYPE,
>			    0x17e,/* <- 0x7e hardcoded as event char */
>			    0,
>			    buf,
>			    0,
>			    WDR_TIMEOUT) < 0)
>				err(__FUNCTION__ " failed");
>	err(__FUNCTION__ " end ");
>	return (0);
>}
>
>As eluded to by the comment, I couldn't see how to call this -- I mean, 
>things like the termios calls are as a result of tty/port setting
>changes but to my knowledge there isn't a high level way to set & enable
>this event character feature.  For the moment therefore I've "hardcoded"
>a call to this function (and the specific event character) as soon as
>the flow control is set up -- it's not ideal but then I wanted to prove
>the event char was working first!
>
>Hope this helps!
>
>
>john
>
>---------
>(*) If anyones got any suggestion on how I can test if this is working,
>please let me know -- I thought about just checking the last byte of
>each packet for the event char, but that doesn't work all the time as
>the buffer will still get flushed on the 16ms timer (I think).
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Ftdi-usb-sio-devel mailing list
>Ftd...@li...
>https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>
>
>  
>

Re: [Ftdi-usb-sio-devel] USC1000 & kernel 2.4.20

[Bill R. <br...@pa...>]

Yep - the FTDI_SIO fails on the 2.4.20 kernel.

The 8U232AM is OK but not the old device.

I'll have a look at it.



Wilbert Knol wrote:

> Thanks for reading this. I am having difficulties with the above 
> combination. On my Toshiba Satellite 2520CDS laptop, the ftdi_sio 
> driver loads OK (hot-plug agent) but as soon as I try to access 
> /dev/usb/tts/0 the machine crashes (kernel panic).
>
> When I used the 2.4.19 kernel with the laptop, the USC1000 adapter 
> would for a while (after plugging it in) until it would lose 
> communication with the RS232 device.
>
> I have also tried the USC1000 with my office desktop PC (kernel 
> 2.4.20). This machine doesn't crash. When I plug the USC1000 in, I 
> have to load the ftdi_sio module manually. When I do,  the USB1000 
> device 'refuses to accept new address' as per syslog below:
>
> Jan  7 10:29:44 wk kernel: usb.c: USB device not accepting new 
> address=3 (error=-110)
>
> The desktop machine uses usb-uhci and has an on-board dual port hub. 
> Both machines run Mandrake 8.2 with upgraded kernels.
>
> So far, I have had very little success with this gizmo (also bought at 
> Dick Smith in NZ)
> Any hints appreciated. I am considering trying the Keyspan serial 
> adapter instead.
>
> Wilbert.
> zl...@zl...
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>
>

[Ftdi-usb-sio-devel] USC1000 & kernel 2.4.20

[Wilbert K. <w....@ni...>]

Thanks for reading this. I am having difficulties with the above 
combination. On my Toshiba Satellite 2520CDS laptop, the ftdi_sio driver 
loads OK (hot-plug agent) but as soon as I try to access /dev/usb/tts/0 
the machine crashes (kernel panic).

When I used the 2.4.19 kernel with the laptop, the USC1000 adapter would 
for a while (after plugging it in) until it would lose communication 
with the RS232 device.

I have also tried the USC1000 with my office desktop PC (kernel 2.4.20). 
This machine doesn't crash. When I plug the USC1000 in, I have to load 
the ftdi_sio module manually. When I do,  the USB1000 device 'refuses to 
accept new address' as per syslog below:

Jan  7 10:29:44 wk kernel: usb.c: USB device not accepting new address=3 
(error=-110)

The desktop machine uses usb-uhci and has an on-board dual port hub. 
Both machines run Mandrake 8.2 with upgraded kernels.

So far, I have had very little success with this gizmo (also bought at 
Dick Smith in NZ)
Any hints appreciated. I am considering trying the Keyspan serial 
adapter instead.

Wilbert.
zl...@zl...

Re: [Ftdi-usb-sio-devel] Any Linux support for "event characters"?

[John W. <joh...@wi...>]

On Sun, 2003-01-05 at 08:52, David Bath wrote:
> Hi again,
> 
> Is there any Linux support for "event characters" as defined in:
> 
> http://www.ftdichip.com/Documents/AN232-06.PDF
> 
> I have an application that sends 10 bytes messages to the Linux host
> periodically, and if possible, I'd rather not have to wait for the next
> 16msec timer expiration to launch the data.  I could easily make the
> messages 11 bytes long by tacking an "event character" on the end of
> each message to get things moving sooner.
> 
> regards,
> 
> David Bath.

Bill Ryder will have the definitive answer, but in the meantime, from
spending the past couple of months looking at the ftdi_sio source, I
don't think event characters are currently supported.

If you look in the .h file you will see a section giving the control
message structures and the #defines ready to be used but as far as I can
see there isn't yet any implementation of it in the driver source.

It **appears** that it could be quite straight-forward to do - fill
a control message with the correct information and send it - the only
variable param is your actual event char.  I've added the following
code to my ftdi_sio.c to try to add event char support.  I haven't
yet been able to do any real testing to check that it's working (*)
though it compiles fine and the function executes without causing
a kernel panic, so that's a start!!!!!!!!

// added  to see if we can improve download speeds.
// the win2k implementation seems to use event chars
// not sure how to call it so we'll call it when we
// do xonxoff
static int set_event_char(struct usb_serial_port * port)
{
	struct usb_serial *serial = port->serial;
	char buf[1];

	err(__FUNCTION__ " begin ");

	if (usb_control_msg(serial->dev,
			    usb_sndctrlpipe(serial->dev, 0),
			    FTDI_SIO_SET_EVENT_CHAR_REQUEST,
			    FTDI_SIO_SET_EVENT_CHAR_REQUEST_TYPE,
			    0x17e,/* <- 0x7e hardcoded as event char */
			    0,
			    buf,
			    0,
			    WDR_TIMEOUT) < 0)
				err(__FUNCTION__ " failed");
	err(__FUNCTION__ " end ");
	return (0);
}

As eluded to by the comment, I couldn't see how to call this -- I mean, 
things like the termios calls are as a result of tty/port setting
changes but to my knowledge there isn't a high level way to set & enable
this event character feature.  For the moment therefore I've "hardcoded"
a call to this function (and the specific event character) as soon as
the flow control is set up -- it's not ideal but then I wanted to prove
the event char was working first!

Hope this helps!


john

---------
(*) If anyones got any suggestion on how I can test if this is working,
please let me know -- I thought about just checking the last byte of
each packet for the event char, but that doesn't work all the time as
the buffer will still get flushed on the 16ms timer (I think).

[Ftdi-usb-sio-devel] Any Linux support for "event characters"?

[David B. <db...@ya...>]

Hi again,

Is there any Linux support for "event characters" as defined in:

http://www.ftdichip.com/Documents/AN232-06.PDF

I have an application that sends 10 bytes messages to the Linux host
periodically, and if possible, I'd rather not have to wait for the next
16msec timer expiration to launch the data.  I could easily make the
messages 11 bytes long by tacking an "event character" on the end of
each message to get things moving sooner.

regards,

David Bath.

[Ftdi-usb-sio-devel] 0xff in device -> host direction gets duplicated?

[David B. <db...@ya...>]

Hi,

I'm using the 245 to send 10 bytes data messages from a ucontroller to
software running on the Linux host.  Everything works fine except when
the ucontroller generates the value 0xff in the data.  In that case, my
Linux user level read() seems to end up with two 0xff bytes instead of
one, and the message becomes 11 bytes long instead of 10.

Switching the ftdi_sio trace on, I see just the one 0xff (i.e. the
messages gets logged exactly as the remote ucontroller sent it):

ftdi_sio.c: ftdi_sio_read_bulk_callback - port 0
ftdi_sio.c: ftdi_sio_read_bulk_callback - length = 12, data = 31 60 bd
07 00 de 00 ad 00 be ff 00 

But my user level read actually gets 11 bytes:

bd 07 00 de 00 ad 00 be ff ff 00 

I suspect it's the tty subsystem doing some sort of break processing. 
Here's a snippet of the code I use to set things up...

  devfd = open(devname, O_RDWR|O_NOCTTY);
  if (devfd < 0) {
    perror("Cannot open device");
    exit(1);
  }


  if (tcgetattr(devfd, &newt) < 0) {
    perror("tcgetattr");
    exit(1);
  }
  newt.c_iflag |= (PARMRK|IGNBRK|IGNPAR|IGNCR);
  newt.c_iflag &=
~(BRKINT|ISTRIP|INLCR|IGNCR|ICRNL|IXON|IMAXBEL|IXOFF|INPCK|IUC
LC);
  newt.c_oflag &= ~(OPOST);
  newt.c_cflag |= (CLOCAL|CREAD|CS8);
  newt.c_cflag &= ~(CSTOPB|HUPCL|PARODD|PARENB|CRTSCTS);
  newt.c_lflag &= ~(ECHO|ECHOE|ECHOK|ECHONL|ICANON|ISIG|NOFLSH|TOSTOP);
  newt.c_cc[VMIN] = 0;
  newt.c_cc[VTIME] = 1;
  if (tcsetattr(devfd, TCSANOW, &newt) < 0) {
    perror("tcsetattr");
    exit(1);
  }


For now I've changed my ucontroller code and host code to "escape" any
0xffs from the data stream so they never occur, but I'd rather remove
that code if possible.  Anyone have any suggestions on how I can get
0xff treated just like any other byte?

In case it matters, I'm running the standard driver that come with
2.4.18, which logs itself as:

ftdi_sio.c: v1.2.0:USB FTDI RS232 Converters Driver

thanks in advance,

David Bath.

[Ftdi-usb-sio-devel] ft245 stop

[Alberto M. <ma...@ti...>]

By,
I'm novice in linux too (sorry)

I wrote this C program:
int main()
{
   int    fd,res;
   unsigned int  conta;
   int    max;
   unsigned char   mychar[1000];
        fd = open("/dev/ttyUSB0", O_RDONLY);
        if (fd <0) {perror("/dev/ttyUSB0"); exit(-1); }
        conta = 0;
        max = 0;
        while (1) { 
          res = read(fd,mychar,255);
          printf("\nconta=%d,conta=%d\n",conta,res);
          conta = 0;
          printf("conta=%d,conta=%d\n",conta,res);
          while (conta < res)
          {
                printf("l_");
                if (!conta) printf("%d %x ",max,mychar[conta]);
                conta++;
                max++;
          }
        }
  close(fd);
  return(0);
}

I' have a micro that write data in FT245
this is the sample result.

........
........
conta=0,conta=62
l_23188 e0
l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_
conta=62,conta=62
conta=0,conta=62
l_23250 fc
l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_l_
conta=62,conta=62
conta=0,conta=62

here the linux software stop.
It stop always before re-enter while(conta<res) after
casual chars readed;

I don't understand whats happen!
If I retry the software it start again and stop after
casual chars readed (but always in the same position).

When stop the FT245's pin (able write data) stop high and micro can't
write (buffer full)?.
When I restart linux software the FT245's pin (able write data) work
fine and stop after casual time (always in the same software position).
The hardware appear work fine!?
I'm using the kernel 2.4.18
Thank you

[Ftdi-usb-sio-devel] Re: Fw: FT232BM USB UART

[guido s. <gu...@li...>]

Hello Keith,
OK, this makes much more sence to me now. Thank you very much.
I will sign the agreement.

Regards
 Guido
On Mon, Dec 16, 2002, Keith Dingwall wrote:
> Hi Guido,
> 
> Yes this is how we interpret the use of the information when it comes to
> writing drivers for open source systems such as Linux.
> 
> Best Regards,
> 
> Keith Dingwall
> Applications Engineer
> FTDI Support
> 
> ----- Original Message -----
> From: guido socher <guido(at)linuxfocus.org>
> To: Keith Dingwall 
> Sent: Sunday, December 15, 2002 12:06 PM
> Subject: Re: Fw: FT232BM USB UART
> 
> 
> > Hello Keith,
> > I discussed this NDA issue with others who were involved the original
> > Linux driver design.
> > It seems that this NDA agreement should be interpreted such that
> > I may not distribute the ftdi manuals and documentation which I would
> > receive from you but I would be able use the information to write a driver
> > in C code and release the C source code under an open source license.
> >
> > Is this also your interpretation of the NDA?
> >
> > Thanks for clarifying this.
> >
> > Regards
> >  Guido
> >
> > On Thu, Dec 12, 2002, eith Dingwall wrote:
> > > Hi Guido,
> > >
> > > I just had a thought.... Since you're a Linux user a word doc is
> probably no
> > > use to you! Please find a .pdf version attached.
> > >
> > > Best Regards,
> > >
> > > Keith Dingwall
> > > Applications Engineer
> > > FTDI Support
> > >

-- 
The place for Linux documentation in your own language.
http://www.linuxfocus.org 

Re: [Ftdi-usb-sio-devel] ftdi_sio (what else)?

[Bill R. <br...@pa...>]

Hmm - actually I looked at your original message and you are using a 
1.2.0 driver which had bugs IIRC.

Try the 2.4.20 vanilla kernel.



Bill Ryder wrote:

> Hi Gary,
>
> Which kernel are you using?
>
> I am guessing a 2.4.20 ish kernel with the 1.2.1 driver from sourceforge.
>
>
> I note that they have moved all of the semaphore and module booking 
> keeping handling in the 2.4.20 into usbserial now so I am picking that 
> the 1.2.1 driver from sourceforge may no longer work.
>
> Try the stock driver from the 2.4.20 kernel.
>
> If you are not using the 2.4.20 kernel with the driver from 
> sourceforge -  I would need to see a full debug from the first attach 
> of the device (this is a bit of a hassle due to the constant polling 
> done by the device - but you could comment that read_bulk_callback 
> debugging stuff out).
>
> I would also like an strace of your test program.
>
>
>
> Gary Desrosiers wrote:
>
>>  Could anyone tell me why the driver hangs (loops) after a close() 
>> with this repeating loop in ftdi_read_bulk_callback? The device 
>> actually gets all of the 74 65 73 74 data so there's no problem there.
>>  
>>  ftdi_sio.c: ftdi_open
>>  ftdi_sio.c: ftdi_set_termios
>>  ftdi_sio.c: Setting CS8
>>  ftdi_sio.c: get_ftdi_divisor tty_get_baud_rate reports speed 9600
>>  ftdi_sio.c: get_ftdi_divisor Baud rate set to 9600 (divisor 16696) 
>> on chip FT8U232AM
>>  ftdi_sio.c: ftdi_set_termios Turning off hardware flow control
>>  ftdi_sio.c: ftdi_ioctl cmd 0x5401
>>  ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x5401
>>  ftdi_sio.c: ftdi_write port 0, 4 bytes
>>  ftdi_sio.c: data_offset set to 0
>>  ftdi_sio.c: ftdi_write Bytes: 4, First Byte: 0x74
>>  ftdi_sio.c: ftdi_write - length = 4, data = 74 65 73 74
>>  ftdi_sio.c: ftdi_write write returning: 4
>>  ftdi_sio.c: ftdi_write_bulk_callback
>>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>>  ftdi_sio.c: Just status 0o0610o000
>>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>>  ftdi_sio.c: Just status 0o0610o140
>>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>>  ftdi_sio.c: Just status 0o0610o140
>>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>>  ftdi_sio.c: Just status 0o0610o140
>>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>>  ftdi_sio.c: Just status 0o0610o140
>> ...
>> .... ad infinitum ...
>
>

Re: [Ftdi-usb-sio-devel] ftdi_sio (what else)?

[Bill R. <br...@pa...>]

Hi Gary,

Which kernel are you using?

I am guessing a 2.4.20 ish kernel with the 1.2.1 driver from sourceforge.


I note that they have moved all of the semaphore and module booking 
keeping handling in the 2.4.20 into usbserial now so I am picking that 
the 1.2.1 driver from sourceforge may no longer work.

Try the stock driver from the 2.4.20 kernel.

If you are not using the 2.4.20 kernel with the driver from sourceforge 
-  I would need to see a full debug from the first attach of the device 
(this is a bit of a hassle due to the constant polling done by the 
device - but you could comment that read_bulk_callback debugging stuff out).

I would also like an strace of your test program.



Gary Desrosiers wrote:

>  Could anyone tell me why the driver hangs (loops) after a close() 
> with this repeating loop in ftdi_read_bulk_callback? The device 
> actually gets all of the 74 65 73 74 data so there's no problem there.
>  
>  ftdi_sio.c: ftdi_open
>  ftdi_sio.c: ftdi_set_termios
>  ftdi_sio.c: Setting CS8
>  ftdi_sio.c: get_ftdi_divisor tty_get_baud_rate reports speed 9600
>  ftdi_sio.c: get_ftdi_divisor Baud rate set to 9600 (divisor 16696) on 
> chip FT8U232AM
>  ftdi_sio.c: ftdi_set_termios Turning off hardware flow control
>  ftdi_sio.c: ftdi_ioctl cmd 0x5401
>  ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x5401
>  ftdi_sio.c: ftdi_write port 0, 4 bytes
>  ftdi_sio.c: data_offset set to 0
>  ftdi_sio.c: ftdi_write Bytes: 4, First Byte: 0x74
>  ftdi_sio.c: ftdi_write - length = 4, data = 74 65 73 74
>  ftdi_sio.c: ftdi_write write returning: 4
>  ftdi_sio.c: ftdi_write_bulk_callback
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o000
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o140
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o140
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o140
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o140
> ...
> .... ad infinitum ...

Re: [Ftdi-usb-sio-devel] ftdi_sio (what else)?

[Bill R. <br...@pa...>]

HI there,

I can't see a close in there at all.

The device continually sends empty packets back when nothing is 
happening. This is why the read callback is called.

This will happen forever until it is disconnected. In other words what I 
see is normal behaviour when the device is NOT closed.

If the device was closed there should be a ftdi_close function call and 
I can't see this in your trace.

I suggest you strace your program to make sure a close was called. You 
may also have some other program holding the device open which will also 
prevent a close.


Gary Desrosiers wrote:

>  Could anyone tell me why the driver hangs (loops) after a close() 
> with this repeating loop in ftdi_read_bulk_callback? The device 
> actually gets all of the 74 65 73 74 data so there's no problem there.
>  
>  ftdi_sio.c: ftdi_open
>  ftdi_sio.c: ftdi_set_termios
>  ftdi_sio.c: Setting CS8
>  ftdi_sio.c: get_ftdi_divisor tty_get_baud_rate reports speed 9600
>  ftdi_sio.c: get_ftdi_divisor Baud rate set to 9600 (divisor 16696) on 
> chip FT8U232AM
>  ftdi_sio.c: ftdi_set_termios Turning off hardware flow control
>  ftdi_sio.c: ftdi_ioctl cmd 0x5401
>  ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x5401
>  ftdi_sio.c: ftdi_write port 0, 4 bytes
>  ftdi_sio.c: data_offset set to 0
>  ftdi_sio.c: ftdi_write Bytes: 4, First Byte: 0x74
>  ftdi_sio.c: ftdi_write - length = 4, data = 74 65 73 74
>  ftdi_sio.c: ftdi_write write returning: 4
>  ftdi_sio.c: ftdi_write_bulk_callback
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o000
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o140
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o140
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o140
>  ftdi_sio.c: ftdi_read_bulk_callback - port 0
>  ftdi_sio.c: Just status 0o0610o140
> ...
> .... ad infinitum ...

[Ftdi-usb-sio-devel] ftdi_sio (what else)?

[Gary D. <gtd...@co...>]

 Could anyone tell me why the driver hangs (loops) after a close() with =
this repeating loop in ftdi_read_bulk_callback? The device actually gets =
all of the 74 65 73 74 data so there's no problem there.

 ftdi_sio.c: ftdi_open
 ftdi_sio.c: ftdi_set_termios
 ftdi_sio.c: Setting CS8
 ftdi_sio.c: get_ftdi_divisor tty_get_baud_rate reports speed 9600
 ftdi_sio.c: get_ftdi_divisor Baud rate set to 9600 (divisor 16696) on =
chip FT8U232AM
 ftdi_sio.c: ftdi_set_termios Turning off hardware flow control
 ftdi_sio.c: ftdi_ioctl cmd 0x5401
 ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x5401
 ftdi_sio.c: ftdi_write port 0, 4 bytes
 ftdi_sio.c: data_offset set to 0
 ftdi_sio.c: ftdi_write Bytes: 4, First Byte: 0x74
 ftdi_sio.c: ftdi_write - length =3D 4, data =3D 74 65 73 74
 ftdi_sio.c: ftdi_write write returning: 4
 ftdi_sio.c: ftdi_write_bulk_callback
 ftdi_sio.c: ftdi_read_bulk_callback - port 0
 ftdi_sio.c: Just status 0o0610o000
 ftdi_sio.c: ftdi_read_bulk_callback - port 0
 ftdi_sio.c: Just status 0o0610o140
 ftdi_sio.c: ftdi_read_bulk_callback - port 0
 ftdi_sio.c: Just status 0o0610o140
 ftdi_sio.c: ftdi_read_bulk_callback - port 0
 ftdi_sio.c: Just status 0o0610o140
 ftdi_sio.c: ftdi_read_bulk_callback - port 0
 ftdi_sio.c: Just status 0o0610o140
...
.... ad infinitum ...

Re: [Ftdi-usb-sio-devel] ftdi 232BM bit bang

[Bill R. <br...@pa...>]

There is a risk that other manufacturers may copy their API to make a 
clone device apparently.

They were reasonable in the past though. It just means you can't publish 
their API - but you can implement it as part of the driver.

Considering they are giving us part of what they consider their 'family 
jewels' and allowing us linux people to use it I don't think it is too 
much to ask.

I wrote the original driver using information they supplied and I agreed 
not to release their programming manuals.

It's a little strange but I think the benefits are worth it.

---
Bill


guido socher wrote:

>FTDI wants me to sign an NDA! What kind of attitude is that !?
>How was the existing driver programmed?
>
>On Wed, Dec 11, 2002, gu...@li... (guido socher) wrote:
>  
>
>>OK, sounds good. I will ask ftdi for programming information.
>>Brix, I hope we can develop something together. It would be
>>my first real Kernel hack. I hope you have a bit more experience.
>>
>>On Wed, Dec 11, 2002, br...@gi... (Henrik Brix Andersen) wrote:
>>    
>>
>>>On Tue, 2002-12-10 at 23:09, guido socher wrote:
>>>      
>>>
>>>>Has anybody worked with the new bit bang mode of the FT232BM?
>>>>        
>>>>
>>>Not yet. I have ordered a few sample devices, but haven't recieved them
>>>yet.
>>>
>>>      
>>>
>
>  
>