Searching \ for '[PIC]: High speed USART: fast is slow' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=usart
Search entire site for: 'High speed USART: fast is slow'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: High speed USART: fast is slow'
2001\05\18@144641 by embedded engineer

flavicon
face
Hello,

The hardware is a 16F876 running at 3.579545 mHz.  When programming with
two versions of the firmware, the only difference being the value in
SPBRG, the following can be observed with an oscilloscope:

SPBRG=11 (19200 baud [actually 18643])

Start bit time is about 55us followed by about 480us before next start
bit.  55us is almost exactly 1/18643.  My measuremet could be off that
much.

SPBRG=5 (38400 baud [actually 37286])

Start bit is about 185us followed by about 240us before next start bit.

By doubling the baud, the throughput only improves about 20 percent
because of the apparent lengthening of the start bit timing.  Again, the
*only* difference between the two versions is the value for SPBRG.  Note
that transmitting 64k bytes of data at both rates is successful.

Any clues?

Best Regards,
David Koski

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@152602 by embedded engineer

flavicon
face
embedded engineer wrote:
>
> Hello,
>
> The hardware is a 16F876 running at 3.579545 mHz.  When programming with
> two versions of the firmware, the only difference being the value in
> SPBRG, the following can be observed with an oscilloscope:
>
> SPBRG=11 (19200 baud [actually 18643])
>
> Start bit time is about 55us followed by about 480us before next start

Correction: Not the start bit but the high (idle) just before the start
bit.  Sorry.

David Koski

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@160352 by Olin Lathrop

face picon face
> The hardware is a 16F876 running at 3.579545 mHz.  When programming with
> two versions of the firmware, the only difference being the value in
> SPBRG, the following can be observed with an oscilloscope:
>
> SPBRG=11 (19200 baud [actually 18643])
>
> Start bit time is about 55us followed by about 480us before next start
> bit.  55us is almost exactly 1/18643.  My measuremet could be off that
> much.
>
> SPBRG=5 (38400 baud [actually 37286])
>
> Start bit is about 185us followed by about 240us before next start bit.
>
> By doubling the baud, the throughput only improves about 20 percent
> because of the apparent lengthening of the start bit timing.  Again, the
> *only* difference between the two versions is the value for SPBRG.  Note
> that transmitting 64k bytes of data at both rates is successful.

I don't believe the UART is stretching the start bit.  Are you perhaps
seeing the space between characters?  If the rest of the system can't feed
the UART to keep up with 37286 baud, then you'd see a space between
characters.  However, this space would have the opposite polarity of the
start bit.  If you look at the PIC TX pin, the space between characters is
high, and the true start bit is low.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spam_OUTolinTakeThisOuTspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@162619 by David Cary

flavicon
face
Dear David Koski,

Koski saw something unexpected and said
> By doubling the baud, the throughput only improves about 20 percent

Maybe the UART is now running so fast that it's done with one byte long before
your software gets around to stuffing in the next byte ?

--
David Cary

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@165814 by embedded engineer
flavicon
face
Olin Lathrop wrote:

> I don't believe the UART is stretching the start bit.  Are you perhaps
> seeing the space between characters?  If the rest of the system can't feed
> the UART to keep up with 37286 baud, then you'd see a space between
> characters.  However, this space would have the opposite polarity of the
> start bit.  If you look at the PIC TX pin, the space between characters is
> high, and the true start bit is low.

Right, see my correction post.  It (55us vs 185us) is the idle time
(high state before start bit.)  Sorry for the confusion.

Thanks,
David Koski

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@170214 by embedded engineer

flavicon
face
David Cary wrote:
>
> Dear David Koski,
>
> Koski saw something unexpected and said
> > By doubling the baud, the throughput only improves about 20 percent
>
> Maybe the UART is now running so fast that it's done with one byte long before
> your software gets around to stuffing in the next byte ?

Then I would expect the idle time before transmission (incorrectly
referred to as start bit time, see my correction post) of 55us to be
about the same instead of half or 22.5us.  But it is about 185us.

Am I thinking about this wrong?

Thanks,
David Koski

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@171653 by David VanHorn

flavicon
face
>
>Then I would expect the idle time before transmission (incorrectly
>referred to as start bit time, see my correction post) of 55us to be
>about the same instead of half or 22.5us.  But it is about 185us.
>
>Am I thinking about this wrong?


Sounds to me like the first byte's over and done with, and then you're not
reloading the uart for quite a while.

Got a spare pin? Ping it when you load the uart, and then scope that along
with TXD.

--
Dave's Engineering Page: http://www.dvanhorn.org

I would have a link to FINDU here in my signature line, but due to the
inability of sysadmins at TELOCITY to differentiate a signature line from
the text of an email, I am forbidden to have it.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@180717 by embedded engineer

flavicon
face
David VanHorn wrote:
>
> >
> >Then I would expect the idle time before transmission (incorrectly
> >referred to as start bit time, see my correction post) of 55us to be
> >about the same instead of half or 22.5us.  But it is about 185us.
> >
> >Am I thinking about this wrong?
>
> Sounds to me like the first byte's over and done with, and then you're not
> reloading the uart for quite a while.
>
> Got a spare pin? Ping it when you load the uart, and then scope that along
> with TXD.

Good point.  I'll have to try that even though it doesn't seem to be
logically the cause since the program code is the same in either case.
Only SPBRG, the baud divisor differs between tests.  I guess it is
another one of those "it can't be but is" situations.  Thanks for the
suggestion.

Regards,
David Koski

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@181956 by David VanHorn

flavicon
face
>
>Good point.  I'll have to try that even though it doesn't seem to be
>logically the cause since the program code is the same in either case.
>Only SPBRG, the baud divisor differs between tests.  I guess it is
>another one of those "it can't be but is" situations.  Thanks for the
>suggestion.

I'm not having a problem with this .

Your byte transmission time adds to whatever processing between bytes time
there is.
If you have a lot of that, then doubling the baud rate wouldn't make much
difference.

Anyhoo, ping and probe, it will likely reveal something.

--
Dave's Engineering Page: http://www.dvanhorn.org

I would have a link to FINDU here in my signature line, but due to the
inability of sysadmins at TELOCITY to differentiate a signature line from
the text of an email, I am forbidden to have it.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@182551 by Bob Ammerman

picon face
In general you can maximize output speed if you test for transmitter ready
just before sending a new byte, instead of waiting for transmitter ready
after sending a byte.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2001\05\18@184107 by embedded engineer

flavicon
face
Bob Ammerman wrote:
>
> In general you can maximize output speed if you test for transmitter ready
> just before sending a new byte, instead of waiting for transmitter ready
> after sending a byte.

Good point.  I am using the CCS built-in function, but I'll check it.

David koski

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@184148 by embedded engineer

flavicon
face
David VanHorn wrote:
>
> >
> >Good point.  I'll have to try that even though it doesn't seem to be
> >logically the cause since the program code is the same in either case.
> >Only SPBRG, the baud divisor differs between tests.  I guess it is
> >another one of those "it can't be but is" situations.  Thanks for the
> >suggestion.
>
> I'm not having a problem with this .
>
> Your byte transmission time adds to whatever processing between bytes time
> there is.
> If you have a lot of that, then doubling the baud rate wouldn't make much
> difference.

My point is it is making a *lot* of difference--the "wrong" way.  At
19.2k the idle time between bytes is 55us whereas at 38.4k the idle time
is about 185us.

David Koski

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\18@213428 by Josh Koffman

flavicon
face
I know I should probably keep my mouth shut as I don't really have any
experience with the USART (though I must learn soon...new project).
Anyway, I realize that the problem seems to be a larger idle time
between bytes. David K. made the point that in theory it should be
smaller. Many others have made the point that perhaps the buffer isn't
being loaded quick enough. Here is my wild just off the top of my head
pseudo-theory. If the buffer is trully not being loaded quick enough, at
a faster baud rate, the buffer is emptied quicker, and has to wait
longer for more data, thus a longer idle time. For example, Let's say I
get 1 apples every 10 minutes. Supposing it takes me 5 minutes to eat an
apple,  once I eat my apple (empty my buffer) I have to wait 5 minutes
for another apple. If I increase my apple eating rate (baud rate) to an
apple every 2 minutes, and I still only get an apple every ten minutes,
I finish my apple quicker, but I now have to wait 8 minutes for the next
apple. I don't know if this is even remotely correct or proper, just an
idea. Also, I hope I haven't offended anyone with my analogy. It just
seemed the easiest way to transmit my ideas. I hope I actually managed
some sort of grasp on the situation.

Thanks,
Josh
.....joshyKILLspamspam@spam@mb.sympatico.ca

embedded engineer wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\19@120712 by Olin Lathrop

face picon face
> My point is it is making a *lot* of difference--the "wrong" way.  At
> 19.2k the idle time between bytes is 55us whereas at 38.4k the idle time
> is about 185us.

That is what you expect to get with a properly written UART routine (waits
for ready before writing to TXREG, not after, as Bob pointed out) when the
rest of the system doesn't produce bytes as fast as they can be sent.  One
character transmit time is always overlapped with the processing for the
next byte.  The remaining processing time turns into a gap between the
bytes.  At the slower baud rate, more of the processing time is overlapped
with the UART sending the previous byte, and therefore the gap between bytes
goes up by a large ratio as the baud rate is increased.  Does this make
sense, I'm not sure I'm saying this right?


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamKILLspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\19@135756 by Josh Koffman

flavicon
face
That was the point I was trying to make with my apple analogy. I
couldn't quite get it to sound right, but Olin seems to be a much better
linquist than I :)

Josh
.....joshyKILLspamspam.....mb.sympatico.ca

Olin Lathrop wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\19@162738 by Bill Westfield

face picon face
   > My point is it is making a *lot* of difference--the "wrong" way.  At
   > 19.2k the idle time between bytes is 55us whereas at 38.4k the idle time
   > is about 185us.

   That is what you expect to get with a properly written UART routine (waits
   for ready before writing to TXREG, not after, as Bob pointed out) when the
   rest of the system doesn't produce bytes as fast as they can be sent.

Most uarts have at least one byte worth of transmit buffering (and modern
uarts are likely to have 10+ bytes of transmit FIFO.)  As you're noticing
here, and other people are pointing out, big FIFO don't help if you simply
can't produce/consume bytes quickly enough, they only help if your attention
to the uart is "sporadic."

Lets's say that it takes 1ms to transmit a byte at 9600bps, and your code
can only source bytes every 1.5ms.  At 9600, you'll see .5ms between bytes.
If you increase the bitrate to 19200, each byte will only take .5ms, but
the gap BETWEEN bytes will increase to 1ms...

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\21@040325 by Snail Instruments

flavicon
face
> My point is it is making a *lot* of difference--the "wrong" way.  At
> 19.2k the idle time between bytes is 55us whereas at 38.4k the idle time
> is about 185us.

Simple calculation - since you set up SPBRG=5 then you have (5+1)*10*16/4 = 240 instruction cycles to generate new byte of data. And since the TXBUF can hold one byte while another is being transmitted from the shift register, you can also generate 2 bytes after 480 cycles and still keep your transmition back to back (no idle time).

You could either speed up the computation or increase the main clock frequency. BTW, there are also 3.6864MHz crystals very common and they give exact baud rate, but baud rate difference is not your problem this time.

Josef

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2001\05\21@142054 by embedded engineer

flavicon
face
Olin Lathrop wrote:
>
> > My point is it is making a *lot* of difference--the "wrong" way.  At
> > 19.2k the idle time between bytes is 55us whereas at 38.4k the idle time
> > is about 185us.
>
> That is what you expect to get with a properly written UART routine (waits
> for ready before writing to TXREG, not after, as Bob pointed out) when the
> rest of the system doesn't produce bytes as fast as they can be sent.  One
> character transmit time is always overlapped with the processing for the
> next byte.  The remaining processing time turns into a gap between the
> bytes.  At the slower baud rate, more of the processing time is overlapped
> with the UART sending the previous byte, and therefore the gap between bytes
> goes up by a large ratio as the baud rate is increased.  Does this make
> sense, I'm not sure I'm saying this right?

It makes a lot of sense--in terms of percentage.  But I wouldn't expect
the actual "processing time" (real time) to lengthen--especially by a
factor of three--simply by increasing the rate at which the TX buffer
becomes available.

David Koski

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\05\21@143446 by Barry Gershenfeld

picon face
>Lets's say that it takes 1ms to transmit a byte at 9600bps, and your code
>can only source bytes every 1.5ms.  At 9600, you'll see .5ms between bytes.
>If you increase the bitrate to 19200, each byte will only take .5ms, but
>the gap BETWEEN bytes will increase to 1ms...
>
>BillW

And so, please measure the time between one start bit and the next, not
the gap between characters, and tell us what you see then.  That's
what everyone is trying to say.

Also: Substitute a dummy routine that just sends characters as fast as
it can, and see if all the mysterious delays go away.

Barry

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\05\21@144202 by embedded engineer

flavicon
face
Barry Gershenfeld wrote:
>
> >Lets's say that it takes 1ms to transmit a byte at 9600bps, and your code
> >can only source bytes every 1.5ms.  At 9600, you'll see .5ms between bytes.
> >If you increase the bitrate to 19200, each byte will only take .5ms, but
> >the gap BETWEEN bytes will increase to 1ms...
> >
> >BillW
>
> And so, please measure the time between one start bit and the next, not
> the gap between characters, and tell us what you see then.  That's
> what everyone is trying to say.
>
> Also: Substitute a dummy routine that just sends characters as fast as
> it can, and see if all the mysterious delays go away.

Ok, I see the light, my face is red.  May this thread rest in peace.

David Koski

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...