I have been reading a textbook on embedded systems called An Embedded Software Primer by David E. Simon (great book, by the way.) I am trying to answer the questions after each chapter. I got through first two chapters, in chapter three there is a question:

Why can't you use microprocessor I/O pins as chip enable pins for ROM and RAM?

You normally encode address pins to do this, which also got me thinking: Can you use data pins and address pins as I/O pins for a processor? Like I/O pins you can write certain bits of data pins HIGH. If not, what is the difference between them? Do I/O pins have more current driving capability?

  • \$\begingroup\$ Think about the timing involved. You want to toggle IO pins high/low - which requires instructions to be executed - which requires code to be fetched from ROM - which requires chip-selects to be activated at the correct time ... \$\endgroup\$
    – brhans
    Mar 13, 2017 at 14:57
  • \$\begingroup\$ @brhans Yes that is correct but can the opposite be true? like, if you want to drive an LED can you use a data pin to do so? I have seen you need to use a D Flip-flop on data pin for this purpose, why? \$\endgroup\$ Mar 13, 2017 at 15:28
  • \$\begingroup\$ I guess the statement is incorrect because you can use I/O pins as CS. But if you do that you will have a segmented address space or a very complicated and slow way to work around it: e.g. when processor tries to access to a currently non-selected chip, MMU will intercept the access and generate a segfault, the processor handles the segfault by switching the GPIO and continue. If you think about it this way, it's actually a valid way of implementing a few more address lines. \$\endgroup\$ Mar 13, 2017 at 16:17

4 Answers 4


You can as long as you only want to access one memory type at a time.

Typically a micro is pulling in instructions from ROM in one or two cycles and the data from RAM in the next few cycles. Wash and repeat. IO lines will not respond fast enough so you decode the top few address lines to do this.

You can use the IO lines to select banks of memory. For instance if you had a lot of data stored in RAM or ROM chips you could split this into banks and use the IO lines to select between banks.

  • \$\begingroup\$ Glad you pointed that out @RoyC. Generalized statements like that dive me batty. Worse when a teacher tells you. Done the page switching thing many, many, times. \$\endgroup\$
    – Trevor_G
    Mar 13, 2017 at 15:11
  • \$\begingroup\$ Why do I/O lines not respond fast enough? does it have something to do with instructions to assert I/O line HIGH takes more time than Instruction to write to data lines? \$\endgroup\$ Mar 13, 2017 at 15:18
  • \$\begingroup\$ No one memory access instruction asserts both the data and address lines. Too assert an IO line you have to run a specific instruction to do that which involves an extra instruction and the complication of working out which memory you have selected at that point in time. \$\endgroup\$
    – RoyC
    Mar 13, 2017 at 15:21
  • \$\begingroup\$ Do not confuse apples and oranges @TejaAllani. The micro has it's own memory handling heartbeat that sequences control and address pins in a very specific way to fetch and store from external memory at the clock rate of the mirco. Other than bank switching, so you can use more memory than the chips address range, you cannot change that. Even then, careful control is required. \$\endgroup\$
    – Trevor_G
    Mar 13, 2017 at 15:52
  • \$\begingroup\$ However, @TejaAllani, that does not mean that you could not hook up a ram or rom chip to IO lines and access it under your own control for some other reason not related to the actual running of the Micro. For example to "select a particular state of an external state machine" \$\endgroup\$
    – Trevor_G
    Mar 13, 2017 at 15:54

ROM and RAM chips have exactly as many address lines as they need, so any pattern will form a valid address, so the IC always responds on the bus.

Obviously that is not what you want, because you only want one reply, so you generate the chip enable signal in a gate logic that compares the address range (i.e. the address lines not going to the memory chip).

On the C64, some GPIOs also go into this gate logic to allow switching certain areas between ROM and RAM. The write enable line is also used in that logic, so writes always address the RAM, which allows copying the ROM contents for later manipulation easily.

The same thing was done on PCs with the BIOS memory: at startup, the BIOS EEPROM would be mapped, then the BIOS code would copy the contents to RAM at the same address, then disable the EEPROM (because it is slower than regular RAM).

  • \$\begingroup\$ I was not asking why do we generate chip enable signals but why do we use address pins specifically for that purpose and why not I/O pins which are generally used for switching Devices on or off like LEDs. I have seen that to use data pins for that purpose(to drive an LED) you need to use a D flip-flop, why? \$\endgroup\$ Mar 13, 2017 at 15:25
  • \$\begingroup\$ The address and data lines are continually changing, depending on the current operations of the microprocessor. The user's program has no direct control of the state of those lines, so can't set a specific data lilne high to turn on an LED for a specified time. In older mini and microcomputers, it was common to have front-panel LEDs connected to the address lines - they would flicker continuously during normal program operation. If the processor was stopped and single-stepped, the operator could read the LEDs to see the current address and data. \$\endgroup\$ Mar 13, 2017 at 16:08

The questions asked in the books (textbooks) are usually based on what is being said/discussed in the book. The question asked

Why can't you use microprocessor I/O pins as chip enable pins for ROM and RAM?

is broad one, requiring precise definition of the terms listed in it, at least

  • what I/O pin is?
  • what chip enable signal is?

I scanned online version of the book to clarify it, and unfortunately definitions are weak in relation to this question.

Page 73 has title I/O pins not giving definition of what are they (in particular which other pins exist, and what are the difference between their classes).

Same issue with chip enable, it is mentioned several times, and you know that it is there, book explains how to operate it and it is assumed that its purpose is clear basing on the description how it should be operated.

Even more confusing for this question is figure 3.19 on page 74 where pins marked I/O are used to control EEPROM. EEPROM is a subclass of ROM, thus this picture means that you actually can use I/O pins to control ROM (again, I did not find chip enable term properly defined).

Ok, now to the right answer to this question - according the book. You will find it on the page 68 which says that

PAL will drive the chip enable signals

I can not see whole the book online, but I guess that this statement is based on the premise that CE is usually complex function of address and other control signals, these signals are fed into PAL (glue logic) which has single chip enable output signal for specific device in the circuit.

Other considerations relating to the question asked:

  • What I/O pins are - Z80's address pins are output pins, not I/O pins. Data pins are I/O pins. There're no other bidirectional pins in Z80;
  • Bus cycle and synchronous operation - it is probably bad idea to trigger start of ROM/RAM access cycle with multiple signals (e.g. use address lines) as it may not be physically possible, and there should be some logic in between creating single strobe signal informing device about its activation. While it is possible to control devices with non-buffered inputs (asynchronous devices), synchronous devices will need clock and chip enable (device activator) signals as inputs to start operation;
  • it is very bad idea to have chip enable input signal being driven by another input signal - when I/O pin is in input mode. These situations will cause conflicts on the bus, over-current and physical damage of the chips (because several chips may think they are selected and start outputting data onto the bus). Thus chip enable should by default be curcuit's output pin towards ROM/RAM's input CE wire.
  • \$\begingroup\$ Yes, what you stated about the book is on point, I saw many people recommending this book for embedded software beginners, so it might be a bit vague about hardware concepts or it might be that I still did not get to the part where they are explained in detail somewhere in the book. Do you recommend any source where I can learn more about hardware concepts like these?. Much appreciated. \$\endgroup\$ Mar 13, 2017 at 16:44
  • \$\begingroup\$ This book might still be a good one, as you see there's a difference between book and textbook. I authored several textbooks on programming and math, and the rule of thumb is that nothing should be taken for granted - e.g. statement like "everyone knows that ..." is not acceptable in good textbook. Provocative questions like this you spot are OK as soon as material explained before supports thinking in right direction. In addition, you should know that you might be just of very few people who bothers thorough reading and thinking on questions. Keep it up. \$\endgroup\$
    – Anonymous
    Mar 13, 2017 at 17:23

As long as you create the required signals, the ROM or RAM chip doesn't care how you do that.

The problem is the sequence of events. If you use a ROM chip to hold the microprocessor's code then every time it executes an instruction it will need to read the next instruction from ROM. If you connect the chip enable to an I/O pin then you need to use an instruction to set the chip enable high or low.

So how will the microprocessor read the instruction to set the chip enable high so that it can read instructions? It will try to read an instruction from ROM, and it will get some garbage byte (maybe 0x00 or 0xFF or a byte from a different chip) and run that instruction. Your only option is to leave the chip enable high all the time, but then, why bother connecting it to an I/O pin at all?

That's why you have to use an auxiliary output on the microprocessor which tells you whether it is currently reading an instruction. That output pin is controlled by the microprocessor itself and not the instructions running on it, so you don't have this paradox. Some microprocessors do have this output; for others, you use one of the address lines, e.g. you say that addresses $8000-$FFFF enable the ROM chip, and you put your code in those addresses so the processor reads instructions from those addresses.

If the processor is not reading instructions from this ROM, then you can absolutely use an I/O pin. However, it's more convenient to give it an address range so that the program can simply use different addresses to access different chips.

Connecting chip enable to an I/O pin is common with microcontrollers, which generally built-in RAM and ROM and have no ability to access outside chips by different addresses - all access to outside chips has to be done using I/O pin instructions.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.