You're absolutely right, Jan. Not all MCU's have this feature, but the one that Erik uses and writes about certainly does. His XRAM is an 8KB internal one, which is unaffected by the cycle stretching, unless there's something he hasn't mentioned. There's nothing to prevent him from attaching an external RAM, and, of course, unless he were to change the cycle-stretch-related SFR, he'd end up taking just as long for his SRAM as for his external 82C55, were he to use one (highly unlikely).

That would not have to be a concern, though, because the cycle-stretch is controlled internally to the MCU, meaning that a simple change of the SFR will change the cycle length. The requisite external decoding logic will prevent "stepping on" the slower device with a faster cycle.

Now, I don't have this problem because, though I use an external SRAM, and other external hardware that requires synchronization, I accomplish that with an actual clock switch, where the oscillator input is driven from switch logic that carefully synchronizes the driver clock with an externally timed process. No serial port activity is permitted to occur while the faster clock is in use, and no interrupts occur then either.


There are numerous ARM7, ARM9, and later, that are different in that they contain no program memory and no data memory, though they do have, in some cases quite significant, cache resources available.


That's what I suspected. I suppose one would call that "bit-fiddling, but not bit-banging, because the latter term has, over the years, accumulated baggage in the form of its association with serial communication for which purpose no dedicated hardware was involved. That is a semantic approximation, as I have no real convention on which to base this verbage. That, in fact, is why I carefully make the distinction between memory-mapped I/O and port-mapped I/O, of which the latter is the thing to which I believe to which you are referring.