Just how does the programmer ensure "that their high address byte (if the hardware has one!) is set appropriately?" I know it's not the best thing, in this context, to refer to specific hardware examples, but, how would one do that, in the general case?


I've never tried that in a SiLabs or even a Maxim/Dallas part. It gets a bit sticky, though, as you address a larger block of RAM in the same way, e.g. using MOVX instructions, and the MCU automatically makes the transition from using its physically internal resources to physically external ones without a hitch. It often does that with different timing, despite the fact it's done as part of a single loop. It's the same way with code space. If you have a part that has, say, 16 kB of on-chip FLASH, and then uses code that is partially on-chip and partially off-chip, it makes the accesses quite transparently, possibly with different timing, yet as part of a single code segment. It can be entirely transparent to the programmer using a HLL.


Thoroughly agreed!



Yes, and I'd be really interested in what happens when you put on an external 32KB of SRAM and then address the on-chip 8KB and the off-chip 32 KB as though they were the same block. I'd also be interested in knowing what happens when you access that on-chip 8KB block (on the 'F12x) using a MOVX A,@Ri instruction rather than with DPTR, which specifies the upper address.



I'm still not clear on why it makes a difference whether the memory range in question is on-chip or off. I can see how it could become troublesome, but, from what little I've done with it, it's just an "external" RAM block that's not off-chip. How your code talks to it is indifferent to its physical location.

One simple way in which a 32 KB chip would be attached to a "normal" 805x chip would be with P0 providing the low address during ALE, and P2 providing the high address byte. If one simply were to use A15/P2.7 to select (as nCS) the external 32Kx8 part, the fact that the bottom 1KB, or 8KB or whatever, lives on-chip would be entirely transparent to the code, and to the coder. The only case in which it would make any difference at all would be if the access timing were different, which, under firmware control, it can be. However, if, for some reason, one wished, for some obscure reason, to conceal, from the external observer, the traffic on that portion of the "external" memory space that can be on-chip, one might actually want to do things in exactly this way.

I'm curious, too in what's the benefit of using that "PDATA" access (MOVX A,@Ri) to external or pseudo-external read/write memory, and in the general effect of using that mode for accessing on-chip memory on the various chips that provide more than 256 bytes. The DPTR instructions are single-cycle ones, too, aren't they?

As one who frequently has to move fairly large blocks of data from one place to another, often at substantially different rates, I frequently have to deal with external memory. Often, it influences my choice of processor. Many people believe that, if a thing can't be done easily with a few lines of 'C' code on an 805x, it has to be done with a "bigger" processor. I am not among them, however. As long as it's cheaper to use an 8-bit MCU, I'll do that, and attempt to wring every bit of utility out of the hardware. Once ARM's and big flash memory, and SDRAM become cheap enough, in combination with the external hardware they require, to do the job for less cost, that may change.

RE