What is serial USART advantage?

[Azchris]

HI all,

Im an EE which uses Picbasic in robotics engineering work, and have used the serial out command forever to communicate with our various serial attachments to the robots. I see on devices that have an internal USART I can use the Hserout comand instead. So Im guessing the advantage is that you set and forget the serial data and send it in this way so that I dont tie up the processor for like a tenth of a second sending serial data?

In other words, Is it like using the onboard PWM where you send a fast command to set up up and get it going and then go about your buissiness while it does the work in the background?

Thanks for any help you can provide.

[HenrikOlsson]

Hi,
Yes and no.
When using HSEROUT PBP loads each byte, into the transmit register of (E)USART which then sends it out. However, because the TXReg is only one byte "deep" a command like...

HSEROUT "This is a string and we're sending it with HSEROUT", 10,13]
...will still tie up the PIC until the last byte (13 in this case) is loaded into the TXReg. As soon as (13) is transfered to the TXReg (not actually sent) the program continues at the next statement.

It's possible, either thru interrupts or polling, to have the program continue and keep sending "in the background" by having a buffer from which you feed the USART as soon as there's room in the TXreg.

Using the USART also allows higher baudrates than the bit-banged SEROUT(2) command.

/Henrik.

[Charles Linquis]

On the SEND side (serout,serout2,hserout), there generally isn't much advantage in using the hardware serial port.

To send a byte using serout at 9600 baud takes about 1millisecond of program time.
To send a 10 bytes using serout at 9600 baud takes about 10 milliseconds.
To send a byte using hserout takes only a few instructions (400-600nSec, my guess without looking).

But... to send 10 bytes using hserout takes a little over 9 milliseconds - only about 1 millisecond less than using serout/serout2. The reason is that the hardware send works as follows:

PBP loads the transmit buffer register with the first byte.
If the transmit shift register is empty, then the transmit buffer register transfers its contents to the transmit shift register. The shift register starts sending the byte.
The transmit buffer register is now empty and can be loaded with the second byte.
When the last bit of the first byte has been shifted out, the transmit buffer register transfers the second byte to the transmit shift register.
...

So, unless you are using interrupts on send, your code sits around and waits until all the characters have been sent before moving on. You only save one byte-send time by using hardware.

So, again (and neglecting the minor overhead) -
To send one byte with hardware is nearly instantaneous.
To send one byte with software takes 1mSec (@9600 baud)
To send 100 bytes with hardware takes 99 mSec
To send 100 bytes with software takes 100 mSec.

Not much of a saving!

You can, however, send at much higher baud rates using hardware.

Of couse, all this assumes you aren't using hardware TX interrutps. If you are, you can send data in the background.

The REAL advantage to the hardware serial port is on the RECEIVE side. You don't have to sit in a loop and wait for data to come in. Often, you don't even need to use interrupts or manage buffers. For most of my menus, I use the ESCAPE key as a means to "break into" the input mode. My main loop polls PIR1.5 every 250mSec or so. If that bit is set, I use HSERIN to read the byte. If it is $1B (ESC), I jump to the menu/input screens.
You can't do things like that with SERIN.

[Azchris]

Thanks charles - thats a lot of help