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

[Ftdi-usb-sio-devel] FT232AM/BM Vendor_Device: Request 90

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

Hi All,

I'm working through pages of SnoopyPro output, trying to work out
how my ftdi-based device works under Windows.

Most of the traces make sense, but on startup a lot of 
URB_FUNCTION_VENDOR_DEVICE urbs are sent down with small
responses back.  Examination of the returning urbs suggests
it's getting the product and vendor strings.

Example:
00000132	0.02340018	>>>>>>> URB 5 going down...	
00000133	0.02340493	-- URB_FUNCTION_VENDOR_DEVICE:	
00000134	0.02341275	  TransferFlags          = 00000003
(USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)	
00000135	0.02341890	  TransferBufferLength = 00000002	
00000136	0.02342588	  TransferBuffer       = f403bbb2	
00000137	0.02343063	  TransferBufferMDL    = 00000000	
00000138	0.02343594	  UrbLink                 = 00000000	
00000139	0.02344069	  RequestTypeReservedBits = 00	
00000140	0.02344572	  Request                 = 90 <<<HERE
00000141	0.02345075	  Value                   = 0000	
00000142	0.02345577	  Index                   = 0001	


Does this mean Request 90 is some type of 'get memory
location' request?  Can anyone confirm this and what the
full structure of the request urb for it is?

Thanks

jw

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

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

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.
> > 

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

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

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

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.
> 
> > There is an application note ( http://www.ftdichip.com/FTApp.htm )
> > but it says nothing about the actual interface. The application
> > note just introduces 3 functions and it does not even say how the
> > can be implemented (in linux).
> 
> Unfortunately, the only information from FTDI seems to be how to use
> their closed source windows drivers. :(
> 
> > Do we still need to write bit bang support for linux or is there
> > something?
> 
> I will definately need it for my device, so if it is not yet available,
> I will have to figure out how to do it. When I do, I will of course
> share it on this list. I hope others will do the same...
> 
> Sincerely,
> ./Brix
> PS: I am also looking for information on how to read/write the external
> EEPROM of the FT232BM chip...
> -- 
> Henrik Brix Andersen <br...@gi...>
> 
> "In addition to these ample facilities, there exists a powerful
> configuration tool called gcc."
>                                 -- Elliot Hughes, author of lwm
> 

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

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

[Henrik B. A. <br...@gi...>]

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.

> There is an application note ( http://www.ftdichip.com/FTApp.htm )
> but it says nothing about the actual interface. The application
> note just introduces 3 functions and it does not even say how the
> can be implemented (in linux).

Unfortunately, the only information from FTDI seems to be how to use
their closed source windows drivers. :(

> Do we still need to write bit bang support for linux or is there
> something?

I will definately need it for my device, so if it is not yet available,
I will have to figure out how to do it. When I do, I will of course
share it on this list. I hope others will do the same...

Sincerely,
./Brix
PS: I am also looking for information on how to read/write the external
EEPROM of the FT232BM chip...
-- 
Henrik Brix Andersen <br...@gi...>

"In addition to these ample facilities, there exists a powerful
configuration tool called gcc."
                                -- Elliot Hughes, author of lwm

[Ftdi-usb-sio-devel] cat /dev/ttyUSB0, kernel panic

[Simon B. <si...@we...>]

Was testing the driver with
$ cat /dev/ttyUSB0
which works, until ctrl-c and then the kernel panics.
So tried writing a program that does a read() and
then a close() and the kernel survives without hicup.
This is with (vanilla) kernel 2.4.20.

Thanks,

Simon Burton.


-- 
Simon Burton, B.Sc.
Licensed PO Box A66
ANU Canberra 2601
Australia
Ph. 02 6249 6940       \
------------------------\
------------------------/
http://arrowtheory.com /

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

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

Hello,
I was always looking for an easy way to design USB devices for
Linux and I am really glad that I found now FT232BM chip and this
linux driver.  Looks very good. 
Has anybody worked with the new bit bang mode of the FT232BM?

There is an application note ( http://www.ftdichip.com/FTApp.htm )
but it says nothing about the actual interface. The application
note just introduces 3 functions and it does not even say how the
can be implemented (in linux).
Do we still need to write bit bang support for linux or is there
something?

Thanks

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

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

[Karl R. <ka...@ho...>]

>Is anyone working on support for this device?

It works for me w/o any change to the driver.
Its just not very fast(see my old posting on this list).

Maybe, someone w/ some USB-stack knowledge can implement the ideas
Bill Ryder mentioned...


Karl


_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Ftdi-usb-sio-devel] ftdi usb slave device

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

Hi Bill,

On Tue, 10 Dec 2002 07:24:53 -0000, you wrote:

>Kendrick Hamilton wrote: 
>
>>	Soory for my ignorance about USB. We are looking at adding USB to
>>a board we are building. It runs uClinux on a coldfire processor (not the
>>5272). I am wondering if the FTDI usb drivers can be used for slave
>>devices or would I need to develop a new driver?
>
>Hmmm. Depends what you mean by a 'slave device'. USB lets lots of 
>devices hang off the usb bus so assuming your board has some kind of 
>support usb compliant host adapter (and linux supports it) you'll be 
>able to run lots of USB devices off the bus.

My guess is that he wants to implement a USB Device i.e. something to be
plugged into a PC or whatever.  If that is the case, an FT8U245AM or
FT245BM may or may not be useful for the hardware interface (he should
check the data sheets on www.ftdichip.com), but the ftdi_sio drivers
would be of no use to him (at the USB Device end) as the uCLinux would
driver would be talking to the asynchronous serial side of the FTDI
chip, not the USB side.

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

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

You will *possibly* find the current driver will work for it - you'll 
just need to put the PID/VID in the driver module and recompile.


===
Bill Ryder
Weta Digital Geek


Gary Desrosiers wrote:

> Is anyone working on support for this device?

Re: [Ftdi-usb-sio-devel] ftdi usb slave device

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

Hi there,

Kendrick Hamilton wrote:

>	Soory for my ignorance about USB. We are looking at adding USB to
>a board we are building. It runs uClinux on a coldfire processor (not the
>5272). I am wondering if the FTDI usb drivers can be used for slave
>devices or would I need to develop a new driver?
>

Hmmm. Depends what you mean by a 'slave device'. USB lets lots of 
devices hang off the usb bus so assuming your board has some kind of 
support usb compliant host adapter (and linux supports it) you'll be 
able to run lots of USB devices off the bus.

What you probably want to have a read of is something like:

Universal Serial Bus System Architecture (2nd Edition) 
<http://www.amazon.com/exec/obidos/tg/detail/-/0201309750/qid=1039505016/sr=1-2/ref=sr_1_2/103-3638596-5588626?v=glance&s=books>

but there are lots of other books and a cursory google search will give 
you lots of info.

I don't know anything about uClinux so I don't know what 'fun' you might 
have with that. Hopefully it runs a 2.4.x kernel.

Good luck!

----
Bill Ryder
Weta Digital Geek

[Ftdi-usb-sio-devel] FT245BM

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

Is anyone working on support for this device?

[Ftdi-usb-sio-devel] ftdi usb slave device

[Kendrick H. <ham...@se...>]

Hello,
	Soory for my ignorance about USB. We are looking at adding USB to
a board we are building. It runs uClinux on a coldfire processor (not the
5272). I am wondering if the FTDI usb drivers can be used for slave
devices or would I need to develop a new driver?
Kendrick
PS. please CC the answer to ham...@se..., I am not a member of
the mailing list.

Kendrick Hamilton E.I.T.
SED Systems, a division of Calian Ltd.
18 Innovation Blvd.
PO Box 1464
Saskatoon, Saskatchewan
Canada
S7N 3R1

Ham...@se...
Tel: (306) 933-1453
Fax: (306) 933-1486

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

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

You talk to the device as if it was a normal serial port.

So anything on the net about serial programming will work.

You will want to set up the port in 'raw' mode which you will find out 
about if you look at some of the serial programming info out there.

THis is a reasonable reference.


http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html

---
Bill


Frederic wrote:

>Hello there,
>
>I'm using a nice mp3 player called 'yampp3/usb'. You can find this project 
>at :
>
>   http://www.myplace.nu/mp3/index2.htm
>
>This mp3 player uses a window front-end to download mp3 files (or new 
>firmeware) through the ftdi FT8U245AM chip. I would like to develop tools 
>to do that under Linux.
>
>As a first step, I have to be able to read and write datas to the USB 
>chip. I read that the 245 uses the same driver as the 232. But I don't 
>understand how to use it. How can I read/write // datas ? Is it the same 
>that writing serial datas ? But What to do with speed and all RS323 stuff? 
>Can I skip it ?
>
>Could someone help me a little bit, maybe just by pointing me to an 
>example...
>
>Regards,
>
>  
>

Re: [Ftdi-usb-sio-devel] Non-standard Product ID (PID)

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

Hi John,

Can you send me the VID you got for that device?

I see the PID (0xfe38) but not a VID.

I might as well add it to the list.

And is it a BM or an AM?

I'm finally actually doing work on the driver (including your xon/xoff 
code for example).


John Wilkins wrote:

>Hi,
>For a couple of months now I've been using an ftdi based serial-to-usb
>device supplied by my ISP.  Needless to say the ISP doesnt "support"
>linux but with a bit of moderate hacking I've got the ftdi driver to
>work quite well.
>
>However, the ftdi-based convertor exhibits a different Product ID (PID)
>to the ones suggested in the .h file (it reports 0xfe38 instead of
>0x6001).  So when the device is plugged in, or the module insmod'ed the
>device is not recognised by the driver.
>
>I've got around this by adding the PID to the .h file and added a new
>entry to the usb_device_id tables at the top of the .c file.  This works
>well and now the device is recognised by the driver.  However, I want
>to get away from having to patch the ftdi driver if possible - 
>especially as the rest of the operation uses the 8U232AM code exactly
>(that's what the convertor is based on).
>
>My question is, should I ask for the PID/VID codes for this device to
>be added to the maintained sources or is there a way to "alias" the 
>VID/PID so that my device's codes get "translated" to the standard ones
>defined in the .h?
>
>Hope that makes sense!
>
>john
>
>
>
>
>-------------------------------------------------------
>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] Non-standard Product ID (PID)

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

Hi

John Wilkins wrote:

>However, the ftdi-based convertor exhibits a different Product ID (PID)
>to the ones suggested in the .h file (it reports 0xfe38 instead of
>0x6001).  So when the device is plugged in, or the module insmod'ed the
>device is not recognised by the driver.
>
>I've got around this by adding the PID to the .h file and added a new
>entry to the usb_device_id tables at the top of the .c file.  This works
>well and now the device is recognised by the driver.  However, I want
>to get away from having to patch the ftdi driver if possible - 
>especially as the rest of the operation uses the 8U232AM code exactly
>(that's what the convertor is based on).
>

As I understand the problem this is because the vid and pid are 
statically initialised when the module is compiled and statically added 
to the list of devices. This *seems* to preclude the possibility of 
doing it at run time (which is what you are doing if you pass the pid 
and vid to a module as arguments).

>My question is, should I ask for the PID/VID codes for this device to
>be added to the maintained sources or is there a way to "alias" the 
>VID/PID so that my device's codes get "translated" to the standard ones
>defined in the .h?
>

So the normal way is to get the vid/pid's added to the driver. Quite 
annoying really!

>
>Hope that makes sense!
>

It does and has been an annoyance for a while.

I still haven't figured out a way to do this nicely.

---
Bill

Re: [Ftdi-usb-sio-devel] USB serial converter

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

Don't know anything about Macs.

THis driver is for PC's on linux.

Also I wasn't aware there was ever a serial zip drive.

You should go see your mac shop.

Warren Sellers wrote:

>I have just obtained a USC 1000 as described on the page I linked here from
><http://ftdi-usb-sio.sourceforge.net>
>I want to use the converter to connect a serial Zip drive to an iMac.  I
>have downloaded the mac driver and installed it, but cannot get the iMac to
>recognise the converter, it tells me I don't have the software loaded.
>Anyone able to assist me?
>
>Warren
>5 Martin Road Paraparaumu Beach 6010 Aotearoa-New Zealand
>Ph/fax: +64 4 902 1386 Email: w.s...@pa... 
>
>
>
>-------------------------------------------------------
>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] Non-standard Product ID (PID)

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

Hi,
For a couple of months now I've been using an ftdi based serial-to-usb
device supplied by my ISP.  Needless to say the ISP doesnt "support"
linux but with a bit of moderate hacking I've got the ftdi driver to
work quite well.

However, the ftdi-based convertor exhibits a different Product ID (PID)
to the ones suggested in the .h file (it reports 0xfe38 instead of
0x6001).  So when the device is plugged in, or the module insmod'ed the
device is not recognised by the driver.

I've got around this by adding the PID to the .h file and added a new
entry to the usb_device_id tables at the top of the .c file.  This works
well and now the device is recognised by the driver.  However, I want
to get away from having to patch the ftdi driver if possible - 
especially as the rest of the operation uses the 8U232AM code exactly
(that's what the convertor is based on).

My question is, should I ask for the PID/VID codes for this device to
be added to the maintained sources or is there a way to "alias" the 
VID/PID so that my device's codes get "translated" to the standard ones
defined in the .h?

Hope that makes sense!

john

[Ftdi-usb-sio-devel] USB serial converter

[Warren S. <w.s...@pa...>]

I have just obtained a USC 1000 as described on the page I linked here from
<http://ftdi-usb-sio.sourceforge.net>
I want to use the converter to connect a serial Zip drive to an iMac.  I
have downloaded the mac driver and installed it, but cannot get the iMac to
recognise the converter, it tells me I don't have the software loaded.
Anyone able to assist me?

Warren
5 Martin Road Paraparaumu Beach 6010 Aotearoa-New Zealand
Ph/fax: +64 4 902 1386 Email: w.s...@pa... 

Re: [Ftdi-usb-sio-devel] FT245BM transfer rates

[Karl R. <ka...@ho...>]

>Perhaps another of the usb serial drivers has implemented a multiple buffer 
>scheme to improve performance but I haven't looked at them in AGES so don't 
>know.

OK, I digged a bit in linux/drivers/usb/serial/ and found:
visor.c:
* (07/23/2000) gkh
*      Added pool of write urbs to speed up transfers to the visor.
[...]
#define NUM_URBS                        24
#define URB_TRANSFER_BUFFER_SIZE        768
static struct urb       *write_urb_pool[NUM_URBS];
static spinlock_t       write_urb_pool_lock;

Is this the multiple buffer scheme you wrote about?
Or am I totaly on the wrong track here?

Karl




















_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: [Ftdi-usb-sio-devel] FT245BM transfer rates

[Karl R. <ka...@ho...>]

Hi!

>I believe the bottleneck is how the transactions are sent to the usb stack. 
>One packet at a time. The larger the writes/reads you can do the better - 
>ie reduce the number of system calls.

Well, my system handles 500 kByte/s bulk transfers from my DigiCam with a 
very light system-load. (Celeron 450)

>But some driver hacking would be required to attempt sending a bigger 
>packet than 128bytes and let the usb stack split that packet up. However I 
>don't know if the 245 would be happy with this.

I'm not sure if its reltated to the maximum packed size -
the '245.pdf says:

384 Byte FIFO Tx buffer / 128 Byte FIFO Rx Buffer


>It would be an interesting experiment though and would should give a lot 
>more performance.

I've took a closer look on the handshake signals(PC to '245 transfer):
It looks like the '245 gets *only* one 64 byte packet every 1 ms(aka 1 kHz 
USB-clock) - 384 should be OK, IMHO.


>Perhaps another of the usb serial drivers has implemented a multiple buffer 
>scheme to improve performance but I haven't looked at them in AGES so don't 
>know.

Anybody knows which files are involved in a USB-bulk-transfer?
I've only found ftdi_sio.c, usbserial.c  so far :-(


Karl






_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

[Ftdi-usb-sio-devel] FT232BM EEPROM rd/wr

[Henrik B. A. <br...@gi...>]

Hello,

I am wondering, has anyone figured out how to read/write the external
EEPROM of the FT232BM/FT245BM devices without using the supplied windows
drivers from FTDI?

I am asking since we am developing a device using this technology, and
our development platform i GNU/Linux - it would be nice if we could
write to the external EEPROM using our custom kernel module as well.

Sincerely,
./Brix
-- 
Henrik Brix Andersen <br...@gi...>

"In addition to these ample facilities, there exists a powerful
configuration tool called gcc."
                                -- Elliot Hughes, author of lwm

Re: [Ftdi-usb-sio-devel] FT245BM transfer rates

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

Hi there,

I believe the bottleneck is how the transactions are sent to the usb 
stack. One packet at a time. The larger the writes/reads you can do the 
better - ie reduce the number of system calls. But some driver hacking 
would be required to attempt sending a bigger packet than 128bytes and 
let the usb stack split that packet up. However I don't know if the 245 
would be happy with this. It would be an interesting experiment though 
and would should give a lot more performance.

Perhaps another of the usb serial drivers has implemented a multiple 
buffer scheme to improve performance but I haven't looked at them in 
AGES so don't know.

Karl Ran wrote:

> Hi,
>
> has anyone reached transfer rates higher than this:
> write( PC to FT245 ): 58 kByte/s
> read( FT245 to PC ) : 30 kByte/s
> ?
>
> Note: The burst rate with my curent test-setup is 400 kByte/s
>
> Anyone knows where the bottleneck is?
> driver, usb-stack, ?
>
> FTDI speced the chip with 1000 kByte/s :-/
>
> Karl
>
>
>
>
>
>
> _________________________________________________________________
> The new MSN 8: advanced junk mail protection and 2 months FREE* 
> http://join.msn.com/?page=features/junkmail
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>
>

[Ftdi-usb-sio-devel] FT245BM transfer rates

[Karl R. <ka...@ho...>]

Hi,

has anyone reached transfer rates higher than this:
write( PC to FT245 ): 58 kByte/s
read( FT245 to PC ) : 30 kByte/s
?

Note: The burst rate with my curent test-setup is 400 kByte/s

Anyone knows where the bottleneck is?
driver, usb-stack, ?

FTDI speced the chip with 1000 kByte/s :-/

Karl






_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

[Ftdi-usb-sio-devel] Looks like 2.2.20 ok?

[Mike R. <er...@es...>]

I'm really confused now, but part of my problem seems to be hardware.
With the modularized 2.2.20, and *no* changes to the ftdi_sio.c, all
my data goes down to a PIC and comes back to the user API.  I've got
voltage read problems, so some bits are low when they ought to be high,
but putting a scope probe on it tends to fix it.  I can fix that easy
enough.

But it looks like I don't have to touch the driver code at all, so I don't
know what the comment about the header byte means.  As long as 2.4.x
behaves the same (i.e. I just write(port, data, length) and it all shows
up in the ftdi buffer) I should be fine.

It looks like the module compile is different somehow than the monolithic,
or else I changed something when 2.4 wiped me out and I recovered from it.
In any case, it looks like I don't have to do any work on the driver.
Very nice job you guys, I really appreciate it!!!

Patience, persistence, truth,
Dr. mike

[Ftdi-usb-sio-devel] Back porting questions

[Mike R. <er...@es...>]

Howdy Bill,

I tried 2.4 on my system, and it took me a few days to recover from
all the things that broke.  So I recompiled my 2.2.20 kernel to be
modularized instead of monolithic and read thru some of the ftdi_sio.c
code.  One thing it wants is a header byte, 6 bits of size and '01'
on the end.  So I fed that into my serial stream, and data is flowing
thru the 2.2.20 usb-serial, my scope is happy, my PIC sees data (tho
I'm not yet sure it sees the correct data...) and it looks like it works!

What I'd like to do is get rid of the header byte, at least from the
serial port view of things.  How did you eliminiate this in the 2.4
version?  The header byte is sent all the way thru in my loop back
test - I just have the PIC send back exactly what it sees.  Since I
get the same number of reads and writes as there are bytes sent via
the serial write, it's clear that the header byte is being sent
all the way down the chain.  Eliminating it shouldn't hurt, and at
worst I can force the system to do fixed size block transfers.

With the modular kernel I should be able to patch the ftdi_sio.c
to work the same as the 2.4 version, at least from the write()
level.  Any hints you have on how to do that would be very much
appreciated!

Patience, persistence, truth,
Dr. mike