FT245 as mem. mapped IO Device?

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because of pins running out ( the same problem every time...) I want to connect my FT245 as a memory mapped device. I have RAM at the ext. Memory Interface (128k, 2 Banks). I know the probelmatic about the WR line (not WR\ line !) but with an AND Gate you can create an chipselect (CS_USB AND RD\ and CS_USB AND WR) and then invert the WR signal to WR\. Should work or?
Anyone has done this before?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

check the truth table of an AND and check if it fits your needs.
I suppose not.

But you are on the right way. Inverting signals and/or the use of other gates and it will run.
I´ve done this many times.

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should not invert the WR line. See the datasheet for details on how it work.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, first, thanks folks.
Then:
FTDI writes, that data will be took at the rising edge of WR, the AVR has its data stable on the falling edge...
if you AND the WR and the CS signal, you can make a "Chip select" (if you disable during this time the RAM)
But you are right, there's something wrong with the AND... negative logic....

Last Edited: Wed. Aug 31, 2005 - 08:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I think a NAND with 2 inverted inputs and a CS\ signal will do

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

NAND with 2 inverted inputs = OR
This helps a lot in finding the device.

Consider: AVR has data stable AFTER WR* goes low and at least till WR* goes high again. So it is usual that the AVR sends data out with falling WR* and the target (SRAM) latches in with rising edge of WR*. (All seen with the WR* of the AVR)

The other way round: Read SRAM
With falling edge of RD* the SRAM gives the data on the bus and with rising edge the AVR latches the data in. (Again seen with RD* of the AVR)

To avoid short circuit on the data bus you should ensure that only one (SRAM or FTDI) is active.

truth table for RD*

AVR_RD* | USB_CS* || USB_RD*
0 | 0 || 0 ; a valid READ from FTDI
0 | 1 || 1 ; READ but not from FTDI
1 | 0 || 1 ; no read, but FTDI selected
1 | 1 || 1 ; no read, FTDI not selected

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, whats about the setup time for the FTDI ? its 20ns.
Also, with the falling edge, the FTDI writes this Data in his FiFo and set's the Flag, if the FiFo is full. Therefore, the FTDI can only check if the Fifo is full, just before the AVR writes-> you must start a new write cycle and then decide if the Fifo is full.
I will done this in a CPLD, therefore an AND with 2 negated inputs is the same "cost" as an OR... but thanks for this hint...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I think there will be some mistakes....
FTDI: WR: rising edge=Update Fifo Flag (after falling edge then valid)
falling edge= fetch data from bus
idle=low
AVR: WR: rising edge=end of cycle
falling edge=start of cycle and data setup
idle=high
question: is the AVR Data min. 20ns stable BEFORE falling edge?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Look into the AVR datzasheet: external memory interface timing
Here you can see, that the avr puts data on the bus then activates the WR* and then deactivates WR*. the time form data output to deactivate WR* is much more than 20ns.--> no timing problem.

The FTDI always sets the FULL-flag after a write cycle, but it deactivates it after a period of min. 80ns when FIFO is not full. So check the flag immediately before you like to write to then FTDI and everything is fine.

Fastest way to check TXE* and RXF* is to wire it directly to a AVR port that is within the IO-area of the AVR. So you can use the SBIS/SBIC. Mind the pipelining timing of the AVR: You can not check the TXE*/RXF* immediately after a FTDI access.

A write routine should be like this:
1) fetch data to be transmitted into a AVR register
2) wait until TXE* is low
3) write to FTDI
4) if any other data has to be transmitted goto 1
5) return
Very simple.

Speed: ca. 8 AVR clocks per byte

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've looked into the datasheet (Mega8535): @16MHz, the setup time will be about 11 ns only!
(Data out to falling edge). ab bit short...
ok, you could use some inverters to slow down... but this is a bit dangerous (Timing of the inverters varies by temp and voltage and also per device)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
(Data out to falling edge).

You don´t need FALLING but RISING edge:
my datasheet (M128; M8535 will be about the same) says >60ns

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, the FTDI needs the falling edge....
They have a positive pulse for Write... Does anyone knows why?

AVR Datasheet (Paramter 13): 0.5*tclc-20ns =~11ns
What you meean is the Write Time for a normal connection to an external RAM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

it´s getting booring now....

I always referred to AVR´s signals. When avr outputs the WR* and FTDI needs WR then you have to invert the signal somehow. When AVR sends out a rising edge the FTDI sees (has to!) a falling edge.
Your datasheet parameter is not interesting in the communication with the FTDI.

"What I mean" is that i have done exactly this interface many times and many years now. No timing problems, no communication problems. It simply works. I´ve checked the signals/timings. Both with glue logic and CPLD.

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I think we have missunderstood us,
I thought you meant the interface WITHOUT inverter.....
If I use an inverter, all will work fine... (I hope so :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not place a small PAL/GAL/CPLD down instead of the glue logic to handle who's wr/rd lines get fired depending on a CS pin from the AVR?

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since you are bank-selecting a bunch of external RAM anyway, why not consider the FT232 (or the new model with enhanced interfaces)? That would let the existing stuff run unimpeded.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
it´s getting booring now....
It sure is.
I repeat.... You DO NOT need to invert the WR signal. Just connect the bloody chip directly to the AVR !
Yeah, I know it shouldn't work, but it does. I've done it on a number of boards. I have some delay in the chipselect/address decoding which may do the trick, but why discuss this to death ? Do some useful work instead !

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
(or the new model with enhanced interfaces)

If you're referring to the FT2232, it sure did have a nice looking enhanced FIFO interface ... in last year's data sheets. Unfortunately the enhanced FIFO function didn't work reliably, and it was silently removed from the data sheet published in November 04. I'll never forget this because it was about one week after I ordered two thousand dollars worth of PCBs. I recall I spoke sternly to FTDI about the importance of announcing changes like that in large red letters on the main website. Fortunately it wasn't a big change to convert to the 245 FIFO emulation.

However, @jesper, you can't connect a 245 straight to the AVR, otherwise it will hijack every external memory read and write. The 245 -RD and +WR have to be gated with the decoded address. And furthermore, the +WR pulse needs to be positive going, because if you hold it high the chip won't read reliably.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've written some entry's before, that I will use a CPLD for this stuff (I need also for some other things to do...)
A FT232 is NOT a choice, because I need to transfer about 2.3 MBit...
With this speed, you have the problem with the UART, because of it will need data to transfer and then you can do nothing else while data transferring. But 288kB/s are not a problem for the parallel Interface.
The general question I had/have, if someone has tried this with the FTDI Chip before and has some hints...
Thanks folks.
When it's done and works, I will post again ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
However, @jesper, you can't connect a 245 straight to the AVR, otherwise it will hijack every external memory read and write. The 245 -RD and +WR have to be gated with the decoded address.
Yes, ofcourse it has to be decoded, I just said so.
Quote:
And furthermore, the +WR pulse needs to be positive going, because if you hold it high the chip won't read reliably.

I give up. As I've said, I've done this several times, and it works fine. But you know better ofcourse.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Jesper: Perhaps it works with slower clocked AVRs. With 4 MHz you get about 100ns Setup Time, with 8 MHz you will have 42ns -> both ok (> 20ns), but with 16 MHz you get 11.25ns.... thats not enough...

@ JEsper, in your first YAMP's you have used MAS3507. I've done also, but had trouble with the SPI link, it wouldn't work until I had programmed it by feet (Pin Toggle in assembler). I've tried all possibilities (CPOL etc...) but nothing worked. I've looked with a scope and saw that what I've setup in the AVR (MEGA128 running @14.7 MHz)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

i agree with baer.ac.

My way of developing is to create reliable hardware by using datasheets and the async memory interface as it is meant to be. I believe that jasper´s design works.
But within a PLD (like baer.ac uses) i always would implement the inverter if i can relax the timing - all this with no cost.

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I give up. As I've said, I've done this several times, and it works fine. But you know better ofcourse.

Sorry, Jesper, I don't mean to add to your frustration. I was referring to FT2232 devices, which is all I've ever used; they don't reliably read-while-write, probably because the R/W pins are configurable and WR isn't really a hardware falling edge clock. Maybe the FT245 behaves differently. The data sheet isn't very explicit. But since you have to do some gating on the write line anyway, it's no big deal to invert the output.

More important, in a forum like this with a good percentage of hardware noobs asking for help with interface problems, we should be encouraging careful reading of and strict compliance with the manufacturers' data sheets. It's not doing anyone any favors to suggest short cuts that may or may not work when they're already having trouble following the authorized version.