FTDI UM245R FIFO-USB interface

[Jeroen Belleman]

Hello,

I'm trying to use an FTDI UM245R USB-FIFO module to read
ADC data into a Linux PC. My Linux is RedHat, kernel version
2.6.9 and the ftdi_sio driver is installed. When I connect
my gadget, a ttyUSB0 device appears in /dev.

I pump data into the FIFO at a rate of one byte every 192us
whenever there's room for it, as signalled by the /TXE flag.
If I don't read the data, the FIFO soon fills up. So far, so
good.

But when I try to read from /dev/ttyUSB0, no data comes out.
Reading attempts *do* consume data from the UM245R internal
FIFO, as is evident from the fact that the /TXE flag goes
down again, but I get no bytes, nothing.

I'm probably doing something wrong, but what? Can anyone here
give me a hint?

Thanks,
Jeroen Belleman


P.S.
FTDI UM245R USB-FIFO module data sheet:
<http://www.ftdichip.com/Documents/DataSheets/Modules/DS_UM245R.pdf>

 

[Jeroen Belleman]

I suppose you use hardware handshake RTS / DTR to ask the thing to
send more data?
No way to tell without looking at your code.

It's not an RS232 thingie. It has a parallel byte-wide FIFO interface
on the bottom end. It has flags to tell the state of the FIFOs, and
strobes to clock data into or out of them. That part of the design
seems to work. I'm only interested in one-way traffic: ADC -> UM245
-> PC.

It's just that my read attempts on /dev/ttyUSB0 yield zero bytes
read, even though the flag bit at the other end of the FIFO indicates
that data *is* being moved through.

I (try to) read from it using simply 'cat /dev/ttyUSB0 >data'.

I looked into getting a driver update, even though the installed
version dates from last March. Alas, that requires kernel sources,
which I don't have here. What did the 'U' in 'USB' stand for again?
What a mess.

Thanks,
Jeroen Belleman

 

[Jeroen Belleman]

On a sunny day (Wed, 01 Jul 2009 14:23:17 +0200) it happened Jeroen Belleman
What did the 'U' in 'USB' stand for again?

'U' for 'U' figure it out.

I tried to write a USB driver for my Canon scanner, so far no luck,
so I use MS windows for that.

What a mess.

Yes, Linux is NOT for point and click people, so far I have plenty of
problems with USB and my external USB harddisk too.
[...]

While Linux has its problems, the mess with U(not!)SB is not Linux's
fault. I believe USB wasn't really designed to be universal, but
rather as a regular revenue stream generator. For what other purpose
would someone design an interface where every damned gadget needs its
own low-level driver?

It just occurred to me that a tty 'cooks' its data stream, so I did
'stty --file=/dev/ttyUSB0 raw'. Now I get a continuous stream of 0xff
bytes, probably EOF markers, really.
Oh well.

Jeroen Belleman

 

[Jeroen Belleman]

[...]

It just occurred to me that a tty 'cooks' its data stream, so I did
'stty --file=/dev/ttyUSB0 raw'. Now I get a continuous stream of 0xff
bytes, probably EOF markers, really.
Oh well.

Jeroen Belleman

That was it, and also that I forgot to enable an output port
of this micro controller in my gadget. #$%^&*!

Sometimes there's nothing like trying to explain one's problem
to get the brain engaged.

It works now. Thanks for listening.

Jeroen Belleman

 

[Nobody]

While Linux has its problems, the mess with U(not!)SB is not Linux's
fault. I believe USB wasn't really designed to be universal, but
rather as a regular revenue stream generator. For what other purpose
would someone design an interface where every damned gadget needs its
own low-level driver?

What do you expect? A single driver that can talk to a mouse, keyboard,
scanner, hard disk, camera, modem, and every other piece of hardware,
including those which haven't been invented yet?

 

[Tim Williams]

What do you expect? A single driver that can talk to a mouse, keyboard,
scanner, hard disk, camera, modem, and every other piece of hardware,
including those which haven't been invented yet?

Well, the Unix paradigm would be, toss the kernel a 'universal' driver that
turns USB chatter into character streams, then let the ill-prepared user
pipe it wherever the **** he thinks it'll do any good. And throw in some
bizarre custom control characters and command line switches, just to throw
off the users, err I mean, give the users some additional information to be
proud of remembering. ;-)

Tim

 

[Jamie]

Well, the Unix paradigm would be, toss the kernel a 'universal' driver that
turns USB chatter into character streams, then let the ill-prepared user
pipe it wherever the **** he thinks it'll do any good. And throw in some
bizarre custom control characters and command line switches, just to throw
off the users, err I mean, give the users some additional information to be
proud of remembering. ;-)

Tim

or, use a known protocol like ModBus or similar

of course, they are lots of existing streaming protocols that can be
utilized.

 

[Ben Jackson]

I'm trying to use an FTDI UM245R USB-FIFO module to read

I pump data into the FIFO at a rate of one byte every 192us
whenever there's room for it, as signalled by the /TXE flag.

I haven't used the 245 but I have used the 232R in a similar app. My
conclusion was that FTDI never intended these parts to be used to read
bulk data like this. I was using the parallel mode of the 232 with
FTDI's own library and like you I could interact with the chip's fifo
just fine but I was still losing data. Turns out that the FTDI driver
itself was periodically reading and discarding data (via a thread it
would create when you opened the device). My program was slowed down
printing more and more debug and losing more and more data but worked
if I turned off all debug. I ended up driving it from a linux box with
an open source FTDI library.

I don't know if a serial mode (such as you must be in for ttyUSB0 to
work) suffers from the same problem, but I wouldn't be surprised to
find it's hard to get it to work.

 

[Jamie]

I haven't used the 245 but I have used the 232R in a similar app. My
conclusion was that FTDI never intended these parts to be used to read
bulk data like this. I was using the parallel mode of the 232 with
FTDI's own library and like you I could interact with the chip's fifo
just fine but I was still losing data. Turns out that the FTDI driver
itself was periodically reading and discarding data (via a thread it
would create when you opened the device). My program was slowed down
printing more and more debug and losing more and more data but worked
if I turned off all debug. I ended up driving it from a linux box with
an open source FTDI library.

I don't know if a serial mode (such as you must be in for ttyUSB0 to
work) suffers from the same problem, but I wouldn't be surprised to
find it's hard to get it to work.

when you open a serial device in Windows, you have the option of bumping
up the cache size (buffer) for the incoming data . Most people do not do
that, they simply leave it as is. This leads to issues with program
dogging behind, then you have the problem of drivers and the system
going so slow that it just can't get there.

I don't know the size of the FTDI cache on it's own uc, but I'm sure
the driver should respond to the change of buffer size and instruct the
chip to also increase it's size unless it's already at it's max and just
uses a time out procedure to forward the incoming data.

In the old days, serial ports didn't have much for buffers if not at
all. At last count, I think 16 bytes sounds about rite.

 

[Jeroen Belleman]

Well, the Unix paradigm would be, toss the kernel a 'universal' driver that
turns USB chatter into character streams, then let the ill-prepared user
pipe it wherever the **** he thinks it'll do any good. And throw in some
bizarre custom control characters and command line switches, just to throw
off the users, err I mean, give the users some additional information to be
proud of remembering. ;-)

I wouldn't have put it quite like that, but basically, yes, a low-level
driver should just deliver a stream of bytes. The semantics are the
next level up.

Jeroen Belleman

 

[Nobody]

I wouldn't have put it quite like that, but basically, yes, a low-level
driver should just deliver a stream of bytes. The semantics are the
next level up.

So you still need a "driver" to implement the semantics for each type of
device.

Also, there are already well-defined interfaces for things like serial
ports, hard disks, sound cards, etc. I would expect to be able to "mount"
a USB disk, rather than getting a stream of data which only works
with programs which have explicit support for talking to USB disks.

 

[Tim Williams]

In the old days, serial ports didn't have much for buffers if not at all.
At last count, I think 16 bytes sounds about rite.

First (in the Intel line) was the 8250, with all of 8 bits, and if you
didn't read them in time, you were SOL! The 16550 was basically an improved
version will all of 16 bytes FIFO. AFAIK, all computers equipped with
serial ports today are 16550-compatible.

Tim