Changing the length of the cycle-stretch involves writing a single value to a single SFR, IIRC. I don't think that takes quite as much time as a delay loop in addition to the bit-manipulation, which is what's required for each access cycle. It's quicker to change the cycle-stretch value and restore it afterward than to time the cycle in firmware and perform the I/O via port bits.

Not all applications will work in this way, but if I have a block of output bits to write or a block of input bits to read, I do that in a block. Makes sense, doesn't it? So I'd set the SFR to the value required for the proper external memory-bus I/O, perform the necessary transfer(s) and then restore the prior SFR value. I have, in fact done that in a case wherein I had to read a floppy disk controller that otherwise had too slow a bus-side access time.



This last "conclusion" does not follow, logically, IMHO, for either class of reasons to which you refer.

Modern applications, at least according to some of the users here, seldom require external memory, and those cases that do require it are not often time-critical at the memory interface, so the benefit of using multiple cycle lengths would be limited to a VERY few applications. Naturally, in those cases where it is of benefit, there is an associated cost, namely the firmware overhead to manage the cycle lengths.

As for the conclusion that the fact that there are other devices, some equally capable, ... well the existence of the automobile is not obsoleted by the existence of the motorcycle. Each has its place, and there are circumstances in which one might prefer one over the other. Clearly, each has its place in the world.

RE