You remember the line from Hamlet ...

Yes, non-standard ... EEEK!!

However, if one wants a counter-timer that runs from a separate clock than that which times the CPU core ... well, what's a guy to do? If you need one UART to work at 9600 baud and another at 64Kbps in synchronous mode, what then? What if you don't need a counter/timer at all, or even a UART? The 128 SFR's are a precious resource. Why waste them on something that's not there?

It's like guys like you, Erik, who use the device for its fast core but don't care about the costly analog peripherals. It's a valid way to get the speed. If you were to roll-your-own with a custom peripheral in FPGA, wouldn't you rather have access to the SFR space, which is, effectively, I/O space, for operating your custom peripheral, rather than just wasting it?

This is a difficult issue, since everyone wants to be able to reuse code in which they have high confidence, so they can concentrate on the new stuff. However, a new header file containing SFR definitions can make some of that less onerous. I know it's not going to make everyone ecstatic, but there's got to be an optimum somewhere. Keep in mind that one goal is to make the use of Mode 0 reasonable for synchronous communication protocols. At present, it's not. The thing won't even do isochronous transfers because of the original timings.

RE