How to interface SN74 buffer with microcontroller into another data bus

Question

I am hoping to interface a 3.3V ARM M4 microcontroller into an already established 5V data bus, and have it respond to interrupts to either read data from the bus or write data to the bus. The data bus is between a 5V cpu (m68000) and a 3.3V flash. To do this safely I am planning on using SN74LVCH16245As to translate between 5V and 3.3V.

The system already has 3 control lines that are useful.
1) One is brought low whenever it needs to read/write to flash.
2) Another is brought low when needing to read/write to the ARM system I am trying to interface into the data bus.
3) And finally another control line to determine if it is reading (5V) or writing (0V).

So my plan is for the data lines from the CPU to go through one SN74LVCH16245A to the flash, with output enable (OE) on the SN74LVCH16245A connected to the first control line. Before the data lines connect to that SN74LVCH16245A however, they are split off with vias to another SN74LVCH16245A which is then connected to the ARM GPIO pins, with the second control line being used as the output enable for that SN74LVCH16245A.

Like this:

FLASH -----                         -------ARM
                  |                        |
SN74LVCH16245A       SN74LVCH16245A
                  |                       |
                   -------------------
                              |
                           CPU

That means that only one SN74LVCH16245A should have it's output enable pin activated at one time. So the data bus is only used by either the flash or the arm chip at one time. This should solve bus contention.

My problem is on the ARM side, and how I should configure the GPIO pins for both inputs and outputs. Let's say an interrupt comes through from the system and it wants to READ a byte to the ARM chip. The interrupt will come through, the ARM will set it's pins to be OUTPUTs, and then I can set the data onto the pins, and end the interrupt. The ARM will keep those pins on OUTPUT until told otherwise. But what if the next interrupt is a WRITE command? The SN74LVCH16245A will change direction, and the side of the SN74LVCH16245A that connects to the ARM will be OUTPUT, but the ARM will still have it's GPIO pins set to OUTPUT. That would be a problem, wouldn't it?

Looking at the technical documentation for the ARM chip, it takes 10 cycles before the ARM chip starts the first line of your interrupt code, if not using the floating point unit. At 120MHz, that is 83 nano seconds. So I won't be able to change the GPIO pins to INPUTS for up to at least 95 nano seconds or so. Will this not cause damage to either the ARM or the SN74LVCH16245A? If this is electrically fine to have the output of the SN74LVCH16245A facing OUTPUTs of the ARM (and visa versa, INPUTs of the SN74LVCH16245A facing INPUTs of the ARM in the reverse situation), then great, but I want to confirm with people more knowledgeable than me first before I mock up my first PCB.

If that is not electrically sound I had another idea on how to possibly interface the ARM chip into the data bus: have one 8bit half of the SN74LVCH16245A connected to pins on the ARM which are always configured as INPUTs, and the other 8bit half of the SN74LVCH16245A connected to different pins on the ARM chip as OUTPUTs, and based on the interrupt I can look at the read/write pin and determine what the interrupt wants me to do, either read from the first 8 lines or write to the second set of 8 lines. The SN74LVCH16245A's output enables would be set using the second control line mentioned above either ANDed with the read/write control line or ANDed with the inverse of the read/write line, respectively.

If I could solve this problem in a much better way I am really hoping to hear from you about what I could do better. Is there a device more suited to what I am doing than the SN74LVCH16245A? I'm a beginner with electronics but have been thinking about this for a long time and realised I really need to ask advice rather than just mulling over it in my head every day!

Thanks everyone.

Answer 1

The interrupt will come through, the ARM will set it's pins to be OUTPUTs, and then I can set the data onto the pins, and end the interrupt. The ARM will keep those pins on OUTPUT until told otherwise. But what if the next interrupt is a WRITE command?

You should have the uC return its GPIO pins to input mode after the read transaction is over.

You should know how quickly it can do this, and your protocol should require that no other transaction is allowed until after this happens.

have one 8bit half of the SN74LVCH16245A connected to pins on the ARM which are always configured as INPUTs, and the other 8bit half of the SN74LVCH16245A connected to different pins on the ARM chip as OUTPUTs, and based on the interrupt I can look at the read/write pin and determine what the interrupt wants me to do, either read from the first 8 lines or write to the second set of 8 lines.

If you have enough spare GPIOs on the uC, and you need more speed than you can get from the prior method, this might work.

If I could solve this problem in a much better way I am really hoping to hear from you about what I could do better. Is there a device more suited to what I am doing than the SN74LVCH16245A?

The problem you're running into is that your uC (like most) is not designed to work as a slave on a parallel interface. You can fudge it with interrupts like you propose, but it will never be as fast as a device with a dedicated hardware parallel interface.

Devices like FPGAs, CPLDs, and memories are types of chips that are typically able to provide fast parallel slave interfaces.