How do I implement a Wait signal from a peripheral on the Flex Bus

[loosePointer]

I have an Epson S1D13A05 LCD controller that wants to extend the write cycle if it happens to be busy when the chip select comes in with a WAIT# line.  The Epson Data sheet tells me to insert wait states while the WAIT is asserted.  And terminate the cycle when WAIT is de-asserted.

I tried tying WAIT to /TA but that only terminates the cycle when the 13A05 wants to extend the cycle.  
It works intermitantly ( I presuem it only works when the 13A05 wants to extend the cycle for just one clock)

I tried adding wait states but the 13A05 wants to extend the cycle a random length.   Seems like implementing a proper WAIT is the best way to do this.

any ideas??

[TomE]

What CPU are you using?

The answer to your problem is that you have to use external logic to generate the TA.

In the simplest case (assuming the LCD controller can generate the Wait in zero nanoseconds, which it can't), you just feed the CS back to TA through a gate which blocks the TA if the LCD controller drives its WAIT signal. For this to work, the TA has to be blocked PRIOR to the setup time on the next Flexbus clock. If your chip is fast enough and your Flexbus clock is slow enough, this might work. Otherwise it might work sometimes. You have to check all the timings and all the delays of the clock-to-CS, setup of TA-to-clock, delay of CS-to-Wait and the delays in the gates you're using.

The proper design generates a delayed version of the chip select (delay with some flip-flops clocked from FB_CLK) and feeds that back as the TA signal, blocked by the WAIT signal from your lcd controller.

Have you considered the MCF5329 with its inbuilt LCD controller?

****

Looking at the Product Brief, it says on the first page:

" The S1D13A05 utilizes a guaranteed low-latency CPU architecture that provides support for microprocessors without READY/WAIT# handshake signals".

It claims "'Fixed' low-latency CPU access times" and "Direct support for Motorola MC68xxx (REDCAP2, Dragonball, ColdFire)", so I don't see why you're worrying about the WAiT signals. Maybe you've got it in the wrong mode?

It has SEVEN configuration pins that allow selection of NINE different bus modes, together with WAIT polarity selection. The Reference Manual shows direct connection to different busses, including Motorola ones that require DTACK. You should be able to connect it up without any logic if you select the right mode (MC68k #1 or #2).

Interesting. There's a "no DTACK" mode, but 2D BitBLT isn't supported if you use it.

Tom

[loosePointer]

Thanks for the reply Tom,  

I'm using an MCF5485.  I'll give it a go.

[loosePointer · Accepted solution]

Figured I'd come back with an up date.

Turns out that I had the 13A05 in Generic Big Endian configuration and the LCD controller was generating an Intel-ish /WAIT signal that would go low about 4nS after Chip Select and terminate the cycle early.  Rather than a /DataStrobeAknowledge or /TransferAknowledge that my MCF5485 was expecting.  

After I changing the configuration to DragonBall (Because this configuration was the closest to how I had it already hooked up) things started looking good.  But curiously I had to change CNF5 form "wait is active Low" to "wait is active high" to get it to work.  With CNF5 tied to 3.3V (Wait is active High) the 13A05 outputs a signal idles High and asserts Low at the right time.  Which seems to disagree with the controllers Data Sheet.??  Which makes me nurvious.

Never the less, I'm now able to access the controller without enabling Auto Aknowledge and inserting wait states in the chip select configuration for it.