Jason Voytilla wrote:
-------------------------------
I regards to aka j's reply, I was thinking along the same lines. As long as i never go above the 16k point in ram or eprom, then i should not have a problem.


- - - - - - - - - - - - - - - -
No, its not that easy.

External opcode fetches are ALWAYS 16 bit. The microcontroller doesn't know how much external addressing you require, and so it uses all 16 bits of external addressing ANYTIME it does an external opcode fetch with PSEN. PSEN won't be activated for internal opcode fetches. But you can still use this to your advantage.

This is why you must treate the A15 and A14 lines as complex. They will have dual use in this configuration and you can't stop them from being activated by external opcode fetches. Clever circuit design and programming can make the dual use compatible though.

NOT JUST LOW LOW - THINK LIKE A HACKER:
======================================
Just accept that A15 and A14 are going to go to WHATEVER bit pattern you chose by STRATEGIC addressing of the 16K block. *** This can be 00b for 0000h-3FFFh, 01b for 4000h-7FFFh, 10b for 8000h-BFFFh, or 11b for C000h-FFFFh.
Its up to you to ensure that those external opcode fetches don't occur in the middle of an A15 and A14 special IO. I'd suggest that you internally map the external 16K so that the address block ALWAYS forces A15 and A14 into the queisent state of you special interface.
But you still need to prevent the 8051 from accessing the 16K block while you're using A15 and A14.

See, I meant complex. :)

Sounds bad, but if you use A15 and A14 for secondary bit controls that require the controlled chip to be first enabled by a SAFE pin, from P3 as in the example circuit of a serial chip enable, THEN you just have to make sure you enable the chip, use A15 and A14 as for example DATA and CLOCK to serially transfer settings, AND then disable the chip again via the SAFE pin, THEN it should work AS LONG AS you prevent any code from running during this driver routine, FROM the external program space. Interrupts too.

CAVEAT
================================
The state machine of the 8051 is not a perfect specification. You can hack performance out of it in unintended ways because its designed for flexibility.

This is in the grey area of 8051 specifications. The manual says the external op code fetches use 16 bits of address line (of course because the micro doesn't know your circuitry), But the P2 input pins still can be controlled by 8051 commands. Obviously you MUST run the A15 and A14 special drivers OUT OF internal memory space that doesn't require external accesses that would toggle the A15 and A14 around while you're trying to use it.

Because there are so many derivatives of 8051s, if you are committing to a PCB layout design, I highly advise you get a written response from your microcontroller manufacture on its behaviour. Email is sufficient. And if you can quickly breadboard a test (or if its a classroom project) by all means verify before you risk finding out it doesn't work quite that way.

CONSDIER THIS:
=============
WARNING: You may be better off avoiding a complex implementation like this because often someone will later write some unrelated code module code that violates the mutual exclusion requirements and all sorts of bugs will mysteriously appear with no relation to the code change. Since people change jobs all the time in engineering, no one may remember the special behaviour of the circuitry when the project is later modified.

BACK TO THE ORIGINAL QUESTION:
=============================
If you need more pins, tell us what you are doing with the external 16K block. If its just EPROM you're better off using a bigger memory microcontroller.

I'd guess its RAM because programmers love RAM and never get enough inside a 8051. :) I'm of the school of thought that no one really needs as much RAM as they think (series of discussions last year on this) and its worth the extra thinking to do away with an external parallel bus.

If its external RAM, you might consider the extra burden of writing a high address (paging) into an exernal latch. This forces you to use 256 byte pages which are fine for movx a,@Ri type commands. You could load the latch through the data bus or P1 but you'd need one pin of the P2 bus to toggle the latching signal. This would work fine for external movx a,@Ri and movx @Ri,a reads and writes but you couldn't do external program space. Remember, you must update the latch (A8-A13) to access a new external RAM page BEFORE you movx with it.

If you can post a scanned drawing of the schematic, or if you prefer to send one to my email address, I'll look it over and offer suggestions.

POSTED SCHEMATICS VOIDS CONFIDENTIALITY:
========================================
Note that emailing or posting a schematic will release any legal claim to it. So if you're worried about someone stealing your ideas, its up to you to keep it secret.

aka j

http://www.geocities.com/mingpzong