The continuity is a compelling argument. However, I've always considered the 805x oscillator-timer/counter-serial channel bond to be a severe weakness. Fewer than 1 out of 25 of my MCU applications have used the 805x, largely for that reason. It is cheap, at least sometimes, and it's pretty well understood. Further, there are decent enough tools with which to support code generation for it. In fact, that code generation support looks to me as though it would still continue to be valid even if the UART to timer/counter bond were no longer there, nor the UART itself. After all the SFR's are defined in a header or in an include file. A few new functions would have to be written to support new peripherals, and a few headers, but that's to be expected with custom hardware.

Those headers, etc, would not have any effect on the coder's perception of his task, i.e. the bits would still be bits, and the bytes would still be bytes. The instruction set wouldn't be altered. The effect of each SFR bit in an altered SFR would be different, of course, but only to the extent that it impacts the function of the peripheral to which it applies.

What I am after from this learned forum is what impact it would have on users with a different view than my own, if a few changes such as I've mentioned were applied. It's obvious that not every bit of code would be readily portable, particularly if it weren't accompanied by the hardware to which it applies.

I fully expected that Erik would be unhappy that his UART might be gone, along with the SFR's associated with it. However, I think it utterly silly to maintain SFR's for hardware that's not present. I also think it equally silly to have to go and check a bit, read a register, then clear that bit once it's set, when hardware can do that just as easily.

I'm sure I'm going to learn a few things.

RE