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

On a sunny day (Wed, 01 Jul 2009 10:47:33 +0200) it happened Jeroen Belleman
<j...@nospam.please> wrote in <h2f7rh$ggg$1...@aioe.org>:

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

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.

Jan Panteltje wrote:
> On a sunny day (Wed, 01 Jul 2009 10:47:33 +0200) it happened Jeroen Belleman
> <j...@nospam.please> wrote in <h2f7rh$ggg$1...@aioe.org>:
> 
>> 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>;
> 
> 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
<j...@nospam.please> wrote in <h2fkg1$tuv$1...@aioe.org>:

>It's not an RS232 thingie.

OK, my fault.


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


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

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


>Thanks,

Sorry, I cannot help with that further...


>Jeroen Belleman
>

Jan Panteltje wrote:
> 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 wrote:
> [...]
> 
> 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

Jeroen Belleman wrote:
> 
>  What did the 'U' in 'USB' stand for again?


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


-- 
You can't have a sense of humor, if you have no sense!

On Wed, 01 Jul 2009 15:24:20 +0200, Jeroen Belleman wrote:

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

"Nobody" <n...@nowhere.com> wrote in message 
news:p...@nowhere.com...
> 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 fuck 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

-- 
Deep Friar: a very philosophical monk.
Website: http://webpages.charter.net/dawill/tmoranwms 

Tim Williams wrote:

> "Nobody" <n...@nowhere.com> wrote in message 
> news:p...@nowhere.com...
> 
>>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 fuck 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.