FTDI UM245R FIFO-USB interface

On a sunny day (Wed, 01 Jul 2009 10:47:33 +0200) it happened Jeroen Belleman wrote in :

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

On a sunny day (Wed, 01 Jul 2009 14:23:17 +0200) it happened Jeroen Belleman wrote in :

OK, my fault.

I think that using cat from a device in that way is basically is very unreliable. One should perhaps use libusb to access an USB device, far as I know. And set up a decent loop with select(), so you do not mis out on data.

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

Yes, Linux is NOT for point and click people, so far I have plenty of problems with USB and my external USB harddisk too. You will have to write it yourself if you want it to work. I think nothing is perfect (anymore ;-) ???) these days, I get the weirdest data errors programming a PIC 16F648A, no matter how I write the code, worked around it by using a retry loop... until it is right.

I am even amazed you have not had to compile a kernel, and the sources available. then RatHead sucks so that could be an explanation too.

Sorry, I cannot help with that further...

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

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

Useless? At first the OS didn't support it, motherboards were shipped without the back plate and nothing was readily available to use it.

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 f*ck 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.

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.

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

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.

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

On a sunny day (Thu, 2 Jul 2009 09:02:35 -0500) it happened "Tim Williams" wrote in :

I have just been looking at the Linux kernel source for the USB interface. This because it sucks to have thousands of messages like this in the log: Jul 2 15:51:47 grml kernel: usb 5-2: reset high speed USB device using ehci_hcd and address 2

With some looking for those text strings I landed in /usr/src/linux/drivers/usb/core/hub.c The person knew what he was doing when writing that USB part. However : 'Windows does it different' but now we do it like windows' and should be OK, but leave the defines in in case you do not like it :_)))), and 'we take no changes and reset every time we get a chance', to quote: /* * We restart the list every time to avoid a deadlock with * deleting hubs downstream from this one. This should be * safe since we delete the hub from the event list. * Not the most efficient, but avoids deadlocks. */

No, 1 reset and log entry per second is horrible.... Yea, and there are a lot of other things too... And it has a lot of 'goto' in C, so it must be bad code :-)

So, but it works does it not???? LOL At least I could comment out the log printing to save disk space.

Nothing works right in Linux. It is all a big hack :-)

It is actually a big miracle that the PC even boots....