Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

USB interface for 1Mb/s & no interrupts?

Status
Not open for further replies.

farminbob

Newbie level 4
Joined
Feb 16, 2009
Messages
6
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,358
ft245 project

Hi to all, just found this forum and it looks like i might get some answers to my problem :)

I am trying to make an interface for a Digital television transmitter for Amateur radio..
Original design used the parallel port for 1.024Mb/s 8-bit parallel transfer rate in dos with no interrupts to the parallel input of the transmitter, it pulsed the strobe input on the printer port to request each byte of data.

I'm trying to make a USB version of this and currently experimenting with the FTDI FT245 chip conntected directly to my external interface.

With this setup i have got a semi working system but as you may have guessed i get some problems with interrupts on the USB bus at regular intervals and i loose a number bytes each time which can not happen if it is to work correctly.

so... dumb questions time... i have 128000 bytes/s , with 1ms? interrupt for usb = 128 bytes lost at each interrupt?
i guess i need a buffer bigger than 128 bytes to make it a lossless transfer?
Interestingly the FTDI chip states it has a 128 byte TX buffer so i guess i'm close to full throughput..

Has anyone any simple ideas about an alternate usb interface with a bigger buffer or a FIFO buffer idea that i can use that's not too complicated, Digital designs are not my strong point!

many thanks

Rob
 

ftdi isochronous

There seems to be a misunderstanding with USB ms SOF (start of frame) tic. It doesn't restrict the througput, it's rather a kind of idle signaling. The host can start a new transmission at any time and it's also required to send a new request packet following a full data packet received from the device. Thus a FT245 has no problems to achieve up to 8 MBbps throughput. If you loose data in your application, it's either an issue of incorrect FIFO handling at the FT245 or a software problem at the host side.
 

ftdi d2xx slow

Thanks for the reply, interesting about the 1ms bit, all other pages i had read before saying this was the limitation, maybe i can make some progress then..!

Well at the moment i'm sending the data to the FIFO from some VB code at full speed, i.e. no FIFO control but i think this is done already within the FTDI driver?

At the FT245 end i'm strobing the RD pin to read the bytes of data off the 8-bit port @128KHz and seeing ~200-400us gaps in the data stream (probably more than once a second) on the FF pin which corresponds to the errors in the data i'm seeing so this must point to when the transmit buffer on the FT245 is empty, if it were just not full i should not see errors on the stream..right?

If i clock the RD pin @50KHz i see no errors at all and FF output from the chip stays low... what this tells us i'm not exactly sure but it's a start!

I will have a bit more read about the software side of things again, maybe that is where i'm getting the trouble.
Is visual basic ok for this sort of application as i've heard on other pages that it's not the fastest language..? (but it's the only one i know!!)

Thanks

Rob
 

ftdi interrupts

The throughput specifications can be read from FT245 datasheet and they are correct, as far as I experienced. FIFO handling is on the FT245 side, of course. Although probably expect to have data present in the FIFO all the time, the FIFO logic may require a read to be done only if RXF# is asserted. A FIFO underrun would be an easy detectable error condition then.

The problem is more likely at the PC side however. I didn't ever use VB with FTDI D2XX driver, with C++-Builder or Delphi, I didn't see any. As an additional hint, a software USB monitor can help to trace the communication.
 

lower usb sof interrupts

Ok thanks for that information, i have made a couple of changes to the software but it's just semi educated guesswork here with my knowledge to make things happen and from that i have not noticed any difference with the output stream dropouts.

I have come to the conclusion that it's running out of FIFO buffer in the FT245 device ratehr than software.
So i need to make an external FIFO buffer which is larger, for this i have an IDT72221 chip which i think is same as the CY7C4221 with 1K bytes which should be enough..

Now i have managed to fit this into the hardware but am having a few problems.
If i slow the clocks down to a lower speed i can see that the buffer is being filled on the new FIFO by EF going high so the write inputs seem to be functioning.
When i try to read bytes i can see the FF go low brieflly during each read cycle but i see no data on the output ports... they are staying low...

REN1, REN2 and OE are low when trying to read bytes..

Anyone have any ideas?

Rob
 

fifo ft245 vb

So today i have finally got the FIFO chip working. I have used a PIC to load the bytes into the FIFO chip and the output is read at a constant speed.

I now have a working setup that gives 1.024Mbit without any errors :)
Next i will try to go up to 2Mbit throughput but i have one question to ask..

I'm using a 16F84 to do the loading of the fifo and some picbasic code - the fastest load speed i can acheive with a 20MHz xtal is ~180KHz i need 200KHz or more for 2Mbit transfer...

The code goes like this

Any comments welcome...

Thanks

Rob

>>>>>>>>>>>>
'FIFO

TRISA = %11111
TRISB = %00000000


' CONNECTION INFO:
'
' PIN 7 PORTB.1 = WEN1 WRITE ENABLE TO FIFO
' PIN 8 PORTB.2 = RD READ DATA TO FT245
' PIN 9 PORTB.3 = WCLK WRITE CLOCK TO FIFO
'
' PIN 17 PORTA.0= RXF GOES HIGH WHEN FT245 IS EMPTY
' PIN 18 PORTA.1= FF GOES LOW WHEN FIFO CHIP IS FULL


'START STATE
PORTB.1 = 1
PORTB.2 = 1
PORTB.3 = 1

MAIN:

PORTB.3 = 0
PORTB.1 = 1
PORTB.2 = 1

if PORTA.0 = 0 THEN 'IF FT245 HAS DATA THEN CONTINUE
IF PORTA.1 = 1 THEN 'IF FIFO CHIP IS NOT FULL THEN CONTINUE
PORTB.2 = 0 'LOW PULSE OUT FOR RD
PORTB.1 = 0 'LOW PULSE OUT FOR WRITE ENABLE
ENDIF
ENDIF
PORTB.3 = 1 'WCLK needs to be cycled to refresh FF status all times.
GOTO MAIN

>>>>>>>>>>>>>>>>>>
 

pic usb interrupt transmitter

I guess, the PIC16F is restricting the throughput here, but actually I don't understand it's role related to the original problem description.

As another point, the FT245 mentions an isochronous option, that may me meaningful to achieve a sustained data rate without external FIFO chip.
 

make a usb interfacing chip

Yes the PIC is the problem.. cant get enough routine done in the cycles available..

The pic controls the loading of each byte from the FT245 into the FIFO, i could do this with an external clock and some gates but it was easier logically to do it with the pic for getting the WEN/WCLK/RD in the right sequence.

Isochronous mode is not possible was the reply from FTDI a year or so back when i started the project...
Lots of information on the net about useing the FT245 for INPUT but always the question is why will it not work at fast speeds when using it to OUTPUT data.
Iw ill look some further into a faster PIC or avr maybe...

Rob
 

ft245 error

O.K., I didn't try isochronous mode with FT245 (I only read from the datasheet) nor do I know about worst case gaps in bulk transmission, I just know from experience, that the specified transfer rate is feasible. So I simply assume, an external FIFO is necessary for your application. But it's a very simple glue logic, that can be provided by a few standard logic ICs or one programmed logic device. Why are you trying with an unsuitable slow PIC?

P.S.: I think, something like 74HC00 + 74HC74 will do for the glue logic.
 

1mb/s

Ok thanks for that, i thought the pic would be better originally but obviously not!

I have now got a 7414 and 4081 to do the same work as the PIC and it seems to work fine with 1Mbit transfers, obviously i should have spent more time with the basic logic first!

The 1Mbit data looks good once it gets decoded at the other end so it looks like error free, can not be 100% sure!

It looks like i have got things working better and now 2Mbit seems to work but with some small errors... will take a closer look.

Once you have something good you always want more!!!

Basically what i'm doing is making an MPEG Transport stream with Audio/Video using VLC (videolan.org) and adding some error correction to the stream. It then gets sent through the USB interface/FIFO to a 'serialiser' and the to the modulator to be able to transmit DVB-S TV standard then receive it on a normal satellite receiver @1.2GHz.
Maybe that will interest someone....hmmmm


Rob
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top