Hi

There is a problem/shortcoming of the MPC555 serial driver that I've
discussed previously on the list that in its current implementation it
cannot cope with continuous concurrent reception and transmission of
characters as with the serial_echo.c test program. If a continuous
stream of characters are sent from a PC with something like a 16x5x chip
or superIO chip, then characters are almost immediately lost as the Rx
DSR is not run in time. I have added a sort of software circular buffer
between the ISR and DSR to allow a nominal number (say 256) of
characters to be buffered. This fixes or reduces the problem for
applications which require a serial packet of less than the buffer size
to be received, provided there is a rest period between packets.

For a continuous data stream, this buffer will eventually overflow no
matter how big it is made, so I have also separately implemented support
for the hardware serial queue facility on the mpc555. Unfortunately this
is only available on the first serial port (SCI1) on this chip (newer
5xx chips have it on both). It is available as a cdl option so that it
can be disabled and the old behaviour is restored. There are two
16-character buffers or queues, one for Rx and one for Tx. There are
half empty/full interrupts and full/empty interrupts as well as an Rx
line idle interrupt to flush the buffer/queue when there is a gap or
absence of incoming data.

I tried various methods for implementing this including separate DSRs
for the interrupt sources, a combined DSR that deals with each interrupt
source, but only reliable way I could get it to work is by using a
combined DSR which doesn't care what the actual ISR source was. The
trouble is that the status information is often lost by the time the DSR
is reached as reading from certain registers clears the contents. Also
DSRs seem to be run in the opposite order to which they are posted which
makes it even harder to work out what part of the queue to read/write.
The final implementation is perhaps the least elegant but nonetheless
works. It just reads/writes whatever data is available at the time of
the DSR running and subsequent DSR instances that have been posted just
drop through if there is no data left to read by the time they run.

I've tested this extensively but perhaps not exhaustively (all of the
type of parity/noise errors etc not fully tested as its perhaps
difficult to contrive these).

It seems to work well communicating with 16x5x chips, but some superIO
chips are able to trip it up after an extended period of time, not sure
wh this is.

Also I have experienced trouble when transmitting to USB-Serial adapters
(prolific etc). 
On the whole this works many times better than the existing driver as it
stands.

Steven Clugston