Isn't time to someone produce a microcontroller with somekind of
programmable "dma" for fast uarts?
You just program the internal or external memory "transmit data buffer"
address and byte count, it will generate just one interrupt when all the
buffer was sent, so you can refill the buffer with new data to be tx.
The same is valid for reception.

This kind of "dma" could be used for several other functions, as to keep
polling few port bits and wait for a programmable bits combination to
generate an interrupt, useful for keyboard polling routines and other
devices.
Of course, all of this done in hardware, and if possible without holding
the main processor, could bust up the model in the market. We are at the
dawn of a new era, new dogs with old tricks are needed (the reverse is
also valid).

The actual very low cost of uC cores could allow to include more than
one CPU at the pkg, to deal with different intelligent tasks.  Two CPUs
running at 20Mhz will not consume the same power of one CPU at 40Mhz,
but certainly will do more job, since reducing interruptions it also
reduces lots of stack usage, and wasted time.

One can say that we should be thankful that we don't need to interrupt
the CPU for each bit transmitted at the UART, but then, why not just
interrupt for each complete message instead?

Just in time; An internal third CPU could be implemented with math and
special routines factory hard coded or custom code eeprom, how much
would cost that? extra $30 cents per unit?  I have done it externally,
using a second uC, single wire communication, just to do long math
(+-/*^SqrSinTanLog) to a very busy main uC.  Cost the fantastic amount
of $2.30, believe me, cost more the PCB real estate and designing labor.
So, why not have this inside the same package?

I bet that more sooner than later you will be hearing such monster roar.

Wagner.

Robin Abbott wrote:
[snip]
> Secondly it takes about 1mS to transmit a byte at 9600bps. If you had to
> wait for the transmitter to be empty then that's 1mS each byte transmitted -
> it could slow your code to unuseability. In the FED library routines for our
> C Compiler and visual assembler we provide interrupt driven communications
> routines which provide a transmit buffer - you add as many bytes as you wish
> to the transmit buffer and the interrupt handler transmits them one after
> another in the background whilst your program does some useful work !