Re: Read full 8-bit character from serial port?

[dempson@actrix.gen.nz (David Empson)]

Jorge Chamorro Bieling <bieling@terra.es> wrote:

> David Empson <dempson@actrix.gen.nz> wrote:
> 
> > > 2.- Once a 4th rx char has been completely assembled (received) into the
> > > receiver, you won't get an overrun either : the receiver can be thought
> > > off as a 4th buffer byte.
> > > 
> > > 3.- In fact it's not until the *5th* rx char start bit appears at the
> > > SCC RxD pin that an overrun will happen.
> > 
> > I doubt that is correct.
> 
> It's not my opinion, I know it's (somewhere) in the 8530 SCC user's
> brick, er, book, the page is ... hmm, that was 14 years ago.
> 
> I still must have the book around. 
> Do you want me to look for it ?

So do I: "Z8030/Z8530 SCC Serial Communications Controller Technical
Manual, January 1983, Zilog".

I can't find anything clearly stating its behaviour either way. I
suggest you have a look and try to find something to justify your
theory.

The first description of the FIFO (page 2-4, section 2.2.2) says that it
creates a "3-byte delay time".

The other sections describing the receiver, receiving in async mode and
the overrun bit all have nothing to say on precisely when the byte is
transferred from the shift register to the FIFO.

The best clue is that details like framing and parity errors are
identified at the end of the character and will be transferred along
with the data into the FIFO. It also states that the overrun flag
indicates that a byte in the FIFO has been overwritten (i.e. it keeps
the new byte, not the old one).

Think about it logically:

If there is enough space in the FIFO then the byte must be transferred
at the point the stop bit is received. If the SCC always waited until
the next start bit, you would never receive the last byte.

It would therefore make sense for the overrun condition to be dealt with
at the same point. The byte is always transferred into the FIFO when the
stop bit is received, and the overrun flag will be set if the third FIFO
position was already used.

If the SCC worked as you described (waiting for the next start bit to
avoid causing an overrun) then it would need additional logic to delay
the byte transfer until either the next start bit arrives or the CPU
reads the FIFO.

In synchronous modes, the shift register is always needed one bit time
later, so this would be a fairly complex piece of logic to allow the
application one extra bit time to empty the FIFO. In async mode, the
worst case is one bit time (two if you count the start bit plus the
first data bit), but it might be longer before the start bit arrives.

-- 
David Empson
dempson@actrix.gen.nz