[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [oc] UART16550




John,

Thanks for the reply.  We're testing the second stop bit now.

This still leaves open the compliance issue of using 1, 1.5, or 2 stop bits.
I'm reading thru the serial spec and haven't seen as yet a specification on
back to back characters.  The 16x oversampling and the baudrate control the
detection of char's at the 57.6 rate and works every single time for single
character transmissions but for packets of data (200 characters long) we
loose data.

Anybody else have this problem?

Steve
----- Original Message -----
From: "John Sheahan" <jrsheahan@optushome.com.au>
To: <cores@opencores.org>
Sent: Tuesday, April 15, 2003 5:17 PM
Subject: Re: [oc] UART16550


>
> try changing labview to use 2 stop bits if possible. This may help
> verify the exact problem.
>
> certainly the uart should start looking for a start bit just after
> the midpoint of the first stop bit, (to allow for baud rate mismatch)
> when running in single stop bit mode.
>
> john
>
>
> On Tue, Apr 15, 2003 at 03:25:14PM -0100, tate@aos-inc.com wrote:
> > Hello all,
> >
> > I've just compeleted my first UART16550 core instantiation and have run
> > into a problem.  I'm setup to run at 57.6k and the core performs
> > perfectly for individual characters received.  However,  if I chain to
> > bytes back to back (from a labview application running on win98) I
> > sometimes loose the second byte.
> >
> > Reviewing the source code I notice the receiver statemachine goes to
> > a "stop" state that detects the stop bit and then counts down...  This
> > count down causes me to miss the next startbit of the second byte...
> >
> > Has anyone else seen this problem?
> >
> > Thanks,
> > Steve
> > --
> > To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml
> --
> To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml
>


--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml