Well, I'm just starting to consider this, and I'm certainly not going into competition with Philips or whoever, but, in the context of a soft-core, i.e. an FPGA-based version of the 805x core, I'm convinced that having to clear that bit after every transfer is a stupid, Stupid, STUPID feature that, first of all, makes Mode 0 utterly useless for synchronous communication because the bit rate is so much faster than the core can process the transfers, and because the interrupt flag isn't even set, on a 12-clocker, before it's too late to miss reloading the transmit buffer before the first bit of the new byte should have been "out the door" anyway.

I'm not at all certain exactly how this one function should be handled, but it's clear to me that dedicating bit-addressable SFR bit to it is wasteful. That same bit could live elsewhere, methinks, since it will be handled automatically, and its control can live elsewhere as well, outside the bit-addressable range.

What I want is to reduce the coupling between the CPU core and the peripherals, the timer/counters and UART(s) in this case, perhaps providing an extra level of buffering and restructuring the interrupt logic such that it allows using an externally provided clock to the timers, or perhaps a dedicated baud-rate-generator separate from the timers. Having the CPU core dependent on the baud-rate crystal frequency is a bit silly in an FPGA where it's possible to use a variety of different timebases, methinks. What's more, synchronizing additional peripherals within the FPGA to the CPU core is likely to be a bit tricky as the peripherals are decoupled from the core timing, so solving the problem generally will solve it specifically as well.

RE