Is there any 8080 Series Parallel Interface standard?

Question

I want to know whether there is a standard for 8080 like parallel interface. What I want to do is connect LCD driver to MCU(stm32). Some doc told me how to connect MCU to the drivers via 8080 like interface here But it didn't tell the detailed meaning of CS,RD,WR lines. I searched some LCD driver datasheets but found contrary info:

SSD1289 use CS as clock signal(page 51) while ILI9340 use WR/RD as clock signals(page 29). So, is there a official standard for 8080 like interface? Or do I have to read the datasheets in detail each time when I want to use a driver chip?

Answer 1

In this case it means seperate RD_ (read) and WR_ (write) lines rather than an E (enable) and R/W_ (read high, write low) line. Both RD_ and WR_ are active low. See page 10 of ST's AN2790. And CS_ is chip select, active low.

For clocking, CS_ or WR_ rising, whichever comes first, is the end of the write. For read either CS_ or RD_ rising tri-states the bus.

Answer 2

An 8080-like interface would presumably mean something compatible with the bus of an intel 8080 processor. However, in fact the actual 8080 is a bit primitive, with something like the Z80 competitive and somewhat compatible alternative more directly matching the actual bus interface people remember from that era. If you want a quintessential example of a peripheral chip from that bus style which survived to the modern era, look up the 8255 parallel peripheral chip used in hobbyists projects but rarely in computers, or the 8253/8254 programmable timers that survived in the 8088-powered IBM PC.

Essentially, yes, you need to read the data sheet for each peripheral chip, but after you have read a few for a given bus style, you will have a better idea of what the norms are, and be able to zero in on any unique differences.

With a modern micro controller you are probably going to hang the peripheral devices off of GPIO pins controlled via software rather than an external bus that is a direct logical (and 1:1 timing) extension of the internal bus. This makes things a lot simpler, in that you can probably conduct your experiments and fix your mistakes in software with no (or minimal) circuit modifications, and anything you get wrong with the peripheral interfacing is unlikely to prevent the MCU from being able to fetch and execute instructions from internal memory (unless you short out its power supply or trigger its reset), so you can see with your debug or serial monitor output or whatever that you are getting no/partial/corrupted data from the peripheral. Also if you probe these connections, you won't have all the unrelated instruction fetch cycles flying by to confuse the picture, instead the lines should be steady except when your software is talking to the peripheral (or another one you have sharing this re-created "bus").

Obviously in hooking up the "bus" lines to GPIOs you want to try to put the byte-wide data lines on some byte of a GPIO port, so that you can do easy access there. And for edge sensitive control lines, you'll want to be careful how you set them in software so that you don't accidentally trigger one while controlling another. The STM32 family you mention has an alternate register address for each GPIO port where you can write a bit in one position to set a single output bit, or write the bit in a different position to clear it.